Re: OO compilers and efficiency

Jon Harrop wrote:
> Rob Thorpe wrote:
> > Objects in Java are heap allocated, no matter what they are. There are
> > no stack allocated objects as there are in C++. This means that the
> > heap must take on the roll filled by both the stack and heap in other
> > languages. This means the garbage-collector must waste time cleaning
> > up stuff that's gone out of scope that in other languages would be
> > dealt with by just moving the stack pointer.
> >
> > This means that compared to other languages with GC Java relies more on
> > it's garbage collector,
>
> No. I believe many other language implementations (e.g. ocamlopt) work in
> the same way but are much faster than Java. I think Java's poor performance
> is due to Java implementations failing to optimise common OO patterns.

Really?
The problems with Java are mostly semantic: everything is an object and
every object must be on the heap. I'm fairly sure that those who write
JVMs have mastered the art of optimizing them under these limitations.

Java is a very big business, probably many hundreds of programmers
spend their time optimizing JVMs. OCaml on the other hand is written
by only a handful of people. I expect that the coders of JVMs have
optimized into the ground the OO patterns they have found to be the
most common.

More likely the semantics and common usage patterns of OCaml make it
easier.

> > and of course it has the extra overhead of GC unlike C++ and C.
>
> GC is often faster than manual allocation and deallocation so it isn't
> really fair to call it an "overhead". Indeed, I'd call manual allocation
> and deallocation an overhead...

It's certainly mental overhead. I doubt that there would be hardly any
situations where a GC would outperform manual allocation though.

.

Relevant Pages

  • Re: OO compilers and efficiency
    ... > Objects in Java are heap allocated, ... > no stack allocated objects as there are in C++. ... GC is often faster than manual allocation and deallocation so it isn't ...
    (comp.programming)
  • Re: Environment "Aha"
    ... the heap is never implicitly used. ... that different from the implicit allocation needed by ThreadLocal ... variables in Java. ...
    (comp.lang.lisp)
  • Re: Multi-cpu and ruby Threading
    ... but invoke a pure Java traitement: ... Running an allocation profile of your benchmark (which actually runs ... Fixnum objects with a smaller amount in Float objects. ... "every object is on the heap". ...
    (comp.lang.ruby)
  • Re: Environment "Aha"
    ... that different from the implicit allocation needed by ThreadLocal ... variables in Java. ... There would be no heap allocation going on at all! ... neat things about Lisp, though, is that you could add a new binding form ...
    (comp.lang.lisp)
  • Re: forth and virtual memory
    ... too, maybe even the same order, so ordering the blocks by allocation ... on systems with too little memory ... What Java is known for, and what it actually does, are two distinct ... My measurements indicate that some of the benchmarks (from SpecJVM98, ...
    (comp.lang.forth)