Re: Storage management

["Randy Brukardt" <randy@rrsoftware.com>]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message 
news:87abciurrl.fsf@mid.deneb.enyo.de...
...
> This sounds interesting.  Unfortunately, the language-mandated
> overhead (primarily abort deferral) is difficult to get rid of.  I
> hope that there will be a configuration pragma which eliminates it,
> even if it means using a self-compiled run-time.

Actually, that's the easiest to get rid of (or minimize enough to make it 
irrelevant most of the time). The Janus/Ada implementation of controlled 
types is roughly the same as the GNAT one. We take two steps to reduce the 
overhead of abort-deferral:

(1) If the program has no tasks, there is no task supervisor and the abort 
deferral routine does nothing (it gets called, but the overhead is just an 
indirect call and a return instruction). We optimized programs not 
containing tasks so that we have less of a disadvantage in benchmarks 
against other non-tasking languages (like C and C++). (It's not as common 
for real Ada programs to not contain tasks, but it helps any that don't as 
well.)

(2) We made abort deferral as cheap as possible. It is just a counter in the 
TCB of a task, and we change it directly in the supervisor interface code 
(this is a big advantage of not use OS threads for task mapping). It takes 4 
machine instructions (this is assembler code). Re-enabling aborts is 
slightly more expensive, as we have to check if someone did abort the task 
while it was abort deferred. But that is the rare case, and it add only two 
machine instructions.

Actually adding or removing an object from the finalization chain isn't that 
expensive, either. It takes about 10 machine instructions.

The biggest expense with Janus/Ada is putting the needed exception handler 
around a Finalize call (we have to turn all exceptions into Program_Error). 
That's probably cheaper with GNAT.

I find I have more sympathy with those that worry about the 16-byte per 
object space overhead (that can be significant for smart pointers, for 
instance, if there are a lot of them in the program). The time will matter 
only in the most critical of applications. (And, based on another thread 
here, moving a few bytes around in some random location will change the 
performance of your program +/- 50% anyway -- that effect will completely 
swamp any finalization overhead.) I doubt anyone with truely critical 
performance needs is going to be using smart pointers or containers or 
anything else that adds overhead.

                                        Randy.