Cast not your Perl before swine?

Levi Pearson levi at cold.org
Tue Dec 18 10:55:04 MST 2007


Although I fully agree with the sentiment you expressed below, I want
to make a couple of minor factual corrections.

Michael L Torrie <torriem at chem.byu.edu> writes:

> C++ programmers typically rely on the scoping rules to help manage
> resources.  (C++ on .NET is broken in this area.)  They do employ things
> that Java also does (but did not invent) such as reference counting via
> smart pointer objects.   

This is not technically correct.  Java does not emply reference
counting; it uses a generational garbage collector.  C++ can
optionally use a conservative mark/sweep garbage collector instead of
manual memory management or smart pointers, which would be the option
most similar to Java's memory management, but it would be less
efficient than Java's garbage collector.  It true, however, that
Java's basic garbage collection scheme was not invented by the Java
implementors.

> For many short-lived objects, C++ programmers don't bother to
> allocate them on the heap at all.  They are just allocated extremely
> quickly right on the stack.  Java has no such ability, and so
> *every* allocation *has* to be a heap allocation.  I'd say in C++,
> at least 50% of all objects are allocated on the stack and
> manipulated there, to be automatically destroyed when they go out of
> scope.  Thus the explicit memory management issue isn't really as
> big a deal as you make it out to be.

Also not quite accurate for the latest Java implementations.  The
compiler can do escape analysis for objects, and allocate them on the
stack.  This doesn't result in a particularly faster allocation, since
Java's allocation is already pretty much just a pointer bump, but it
does keep pressure off of the heap, which reduces the frequency at
which GC must run.

It is true that you can't explicity allocate on the stack, and
probably most experience people have had with Java has been with a JVM
that does not do escape analysis.

                --Levi



More information about the PLUG mailing list