Re: Constructor bombs for copy objects.

[Roger Gregory <roger>]

>From michael Tue Jun 26 08:01:15 1990
	
	The only consequence of not using constructor bombs is a memory leak,
	which we can accept during development, but not for product.  If we
	can assure the garbage collector will find the memory, and are willing
	to ship product with garbage collection as a way of life, we can skip
	it for GCed objects.

I'll be investigating this, it depends on the incremental implementation,
the current implementation isn't interesting because it can't be used for product.

	So there's no need to rush into this - we can punt such decisions off
	until the tuning phase.  I'm bringing it up now because I'm hacking the
	place where it would be installed, so if we're going to install it, now
	would be a convenient time to do so.
You might want to flag the place, or implement it and turn it off, but 
don't waste much time, and please don't leave it on.

	I think you have the impression that a constructor bomb exists to trap
	trouble in the memory allocation routines.  This is not the case.
	(The constructor bomb isn't even armed until the allocation routine
	successfully returns.

	Constructor bombs trap BLASTs passing out of the construction of an object
	after its memory has been allocated - and if they trap one, it's because
	you didn't WANT the constructor to succeed.  These BLASTs not only occur
	after the alloc routine has returned, but perhaps after it has been called
	again many times (which means the alloc routine would have to stack the
	information somehow).

	I'd love to be able to trap them in something attached to operator new,
	but haven't figured out a way to do it. 
That's too expensive also.

	On the other hand, constructor bombs are not a lot of overhead.  Inlined,
	in a constructor that actually allocates memory, and with a good optimizer
	on the compiler, they do:

	 - one link and one unlink of a double-linked list,
	 - two tests-of-BooleanVar,
	 - three stores-of-constant,
	 - one store-of-variable.

	(and we could diddle them to cut out a store and a test, and perhaps use
	some local knowlege to speed the list twiddle.)  It would be hard to put
	a hook into the memory allocation routines that would do less.  In fact,
	just planting and arming one bomb of any sort in the allocator would have
	at least as much time overhead (which we couldn't diddle down).  The real
	overhead is code size.

	In a constructor that ends up not allocating memory (such as a concrete
	superclass with a constructor bomb, which we usually don't use) a
	constructor bomb will do one store-of-constant and one test-of-BooleanVar.
	It will not link and unlink the list.

	Right now constructor bombs aren't inline, but I don't see any problems
	with making that change - other than compiler bugs with inline, of course.
The above code may be too much to inline, that's a lot of stuff by our inline standards.

	> The very
	> few constructors that will want to do the work themselves, should do that.
	> We will have to make some way to do it, perhaps a create.withbomb message or 
	> "create/delete with bomb"   protocol to give the translator a handle for
	> doing the bomb stuff.

	Wrong default.  The consequence of installing an unnecessary constructor
	bomb is some code space and run time.  The consequence of not installing
	a necessary one is a very subtle bug.  So you install them automatically,
	and when you prove you don't need some particular one you do something
	special to not install it.

I will have to check that the appropriate thing in the garbage-collector is cheaper,
that isn't axiomatic.  I'm not currently sure where the constructed space gets 
chwcked into the gc system, probably inside new, so everything should work but I'm
not certain.  Note that constructors leaving garbage should be relatively rare,
so the overhead of collecting it should be very small.

	I agree that if we can somehow get rid of them, or selectively suppress
	them when they're not needed it's a GOOD THING.

	Also, I believe the language has enough hooks for XLint (or an XLint
	derivative) to detect exactly when constructor bombs are necessary,
	and warn about both unnecessary and missing occurrences.
That might be possible, it would be nice.
		michael
	From tribble Tue Jun 26 13:33:50 1990
	  If I have a
	constructor that won't abort, do I need constructor bombs?  This might
	be very common because we have such shallow inheritance trees.

	dean
This is my conclusion also.