Re: Constructor bombs for copy objects.

[Michael McClary <michael>]

> Constructing a constructor bomb for all constructors strikes me as excessive.

Me too.  Unfortunately, it also strikes me as necessary.  Eventually.

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.

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.

> Most constructors will want to have the problem trapped in the alloc
> routines and dealt with there, this would allow them to succeed.

It took me a while to figure out this sentence, but some later ones
clarify it:

> I expect bombs to be a big efficiency hit and get 
> in the way of inlines.  We should probably try to start doing this right,
> now rather than adding a gross inefficency, and ignoring the required fixes
> to the allocation stuff.  Most constructors can only fail due to allocation
> failure, so we should do the fixes there.

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.  (I haven't given up hope, but
I'm not spending time hunting.)  Operator new, like the alloc routines
themselves, occurs one level of scope-nesting too deep.  Similarly,
pseudoconstructors are one level of nesting too shallow.

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 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 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.

	michael