Subj : Re: OO compilers and efficiency
To   : comp.programming
From : Rob Thorpe
Date : Thu Jul 21 2005 11:22 am

Chris Dollin wrote:
> 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.]

I'll look it up, and post a reply when I have.

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

It's certainly true that a very tight GC can achieve better memory
consumption than manual allocation.  Though most real GCs allocate
actually use more, because it's quicker and a better trade-off these
days.

I've heard similar things.  I read a paper by Zorn long ago that said
that GC was quicker than malloc/free for some group of programs which
looked plausible.  But since then relative memory latency has
increased, making GCs that pass over large amount of memory more
wasteful of performance, so I doubt it's still true.

.