[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: Constructor bombs for copy objects.
- To: <mark>, <michael>
- Subject: Re: Constructor bombs for copy objects.
- From: Roger Gregory <roger>
- Date: Tue, 26 Jun 90 15:41:16 PDT
- Cc: <xtech>
>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
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
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.
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.
This is my conclusion also.