Subj : Re: OO compilers and efficiency
To   : comp.programming
From : Chris Dollin
Date : Thu Jul 21 2005 05:58 pm

Rob Thorpe wrote:

> Chris Dollin wrote:

>> [And of course this isn't a property of Java particularly; isn't the
>>  same true in Lisp, Smalltalk, Pop11, SML, OCaml, etc?]
> 
> No, not all of them.
> 
> Let's call the commonly used data structures of each of those languages
> "things", for want of a better word.  In many of those languages the
> compiler can (and will) allocate those things on the stack so long as
> no pointer to them could possibly leave the context.

In what way is it different for Java? If no pointer to a `new Spoo()`
can leave the context, then why can't a Java compiler allocate the
Spoo on the stack?

[Here, the `compiler` is whatever post-processes the bytecode at
 runtime, not the Java source -> classfile compiler.]

I can see that the analysis for "no pointer could possibly leave
the context" can be harder, much harder, because of polymorphism.
So mayhap a Java compiler can stackallocate much less often for
just this reason. Is that the claim?

[Do you happen to have cites for any of Lisp, Smalltalk, Pop11, SML, 
 or OCaml doing stack-allocation, 'cos I'd like to chase them up.
 I'm sure I remember reading stuff about Lisp compilers attempting
 it; I'm equally - or more - sure that Pop11 doesn't do it.]

>> > This means that compared to other languages with GC Java relies more on
>> > it's garbage collector, and of course it has the extra overhead of GC
>> > unlike C++ and C.
>>
>> And it *loses* the overhead of the manual management of both C and C++;
>> malloc/free or new/delete are not free.
> 
> Yes, that's true, but malloc and free are generally very efficient.

Well ... even if that were true (and whether it is depends on what
one might mean by "very efficient"), a bunch of the overhead isn't
malloc/free themselves; it's the bookkeeping needed to decide when
it's time to call `free`, plus the copying needed to allow the
bookkeeping to happen.

My understanding is that measurements have been done, and that the
amortised (time) cost of GC among the measured applications was roughly
the same as that of manual memory management and of the average order 
of 10%. But this is a fragile memory from several years ago; things
have changed a lot since then. 

-- 
Chris "electric hedgehog" Dollin
predicting self-predictors' predictions is predictably unpredictable.

.