Observations on the New Constructor Bomb Style

[Mark S. Miller <vlad!mark>]

The following is a result of conversations with Mr. Hill, Michael, and
Roland.

Many have advocated avoiding having the translator generate the new
constructor bomb style everywhere by default for of fear of the cost
of the bomb setup and takedown on every construction.  We just
realized that *in fact* the cost is less than the cost of the
"saveThis" pointer which the translator now generates by default, and
which the new style would replace.  The cost is less because the new
style sets up one bomb per object constructed, whereas the old
"saveThis" was a strong pointer (and thus a bomb) which was setup and
taken down for each class for each object (i.e. for each constructor).

Mr. Hill's recent postings about garbage collection bugs show that
"saveThis" isn't really a safe way to protect objects from being
collected while being constructed.  The new constructor bomb style is.
For all these reasons, I think that the new constructor bomb style
should be the default way of invoking a constructor.

However, it would be good to be able to get rid of this overhead when
we can safely do so for those (small number of) objects whose
allocation time matters to performance (remember the old 80/20 rule).
Doing so is safe if both: 1) during construction no BLASTs can happen,
and 2) during construction no further allocations can happen.  Such
safety is a non-local property of a program, so we should do this only
if we can figure out how to get XLint to tell us when we are screwing
up.  Here's the proposal:

Introduce a new X++ keyword "SAFE".  A function/member-function/
constructor can be declared SAFE.  If it is so declared, then XLint
should check that it itself doesn't "BLAST" or "new", and that all
things it calls are declared SAFE.  For a constructor to be SAFE, the
specific superclass constructor it (implicitly or explicitly) invokes
must in turn be declared SAFE.  

For a start (in order to not have XLint do full overload resolution),
we can say that a constructor is SAFE if the superclass constructor is
SAFE, it doesn't BLAST or new, and it *doesn't call anything*.  For
most constructors, this route to safety should be easy as the calls
can be done ahead of time by the pseudo-constructor.  Most
constructors probably just initialize data members from corresponding
arguments.

For an earlier start, I suggest forgetting about SAFEty for now and
using the new constructor bombs universally in translated code.  Let's
worry about SAFEty when we know where we should bother.


Performance engineering phase only:

Btw, knowing which constructors are SAFE enables a further important
optimization that I have in mind for later--transparently
incorporating certain objects into the storage of their container,
instead of pointing as we now do.  By introducing a new pointer macro,
"IPTR", we can costlessly make it seem to be just another instance
variable which points at the object in question.  An IPTR pointer
would lack assignment, and would have to be intialized by constructing
the pointed to object in a data-member initializer in the containing
object.  Remember that BLASTs do not work during member
initialization; hence the need for contained objects to be constructed
with SAFE constructors.