Re: Do you use a garbage collector (java vs c++ difference in "new")

On Fri, 11 Apr 2008 03:35:53 GMT, "Mike Schilling"
<mscottschilling@hotmail.com> wrote:


There was nothing wrong with my basic premise that creating objects
with on heap is much faster in java than in c++.

---- quote---------
Creating heap objects in C++ is typically much slower because it's
based on the C concept of a heap as a big pool of memory that (and
this is essential) must be recycled. When you call delete in C++ the
released memory leaves a hole in the heap, so when you call new, the
storage allocation mechanism must go seeking to try to fit the
storage
for your object into any existing holes in the heap or else you'll
rapidly run out of heap storage. Searching for available pieces of
memory is the reason that allocating heap storage has such a
performance impact in C++, so it's far faster to create stack-based
objects.

Again, because so much of C++ is based on doing everything at
compile-time, this makes sense. But in Java there are certain places
where things happen more dynamically and it changes the model. When
it
comes to creating objects, it turns out that the garbage collector
can
have a significant impact on increasing the speed of object
creation.
This might sound a bit odd at first - that storage release affects
storage allocation - but it's the way some JVMs work and it means
that
allocating storage for heap objects in Java can be nearly as fast as
creating storage on the stack in C++.

[...] In some JVMs, the Java heap is quite different; it's more like
a
conveyor belt that moves forward every time you allocate a new
object.
This means that object storage allocation is remarkably rapid. The
"heap pointer" is simply moved forward into virgin territory, so
it's
effectively the same as C++'s stack allocation. (Of course, there's
a
little extra overhead for bookkeeping but it's nothing like
searching
for storage.)

Now you might observe that the heap isn't in fact a conveyor belt,
and
if you treat it that way you'll eventually start paging memory a lot
(which is a big performance hit) and later run out. The trick is
that
the garbage collector steps in and while it collects the garbage it
compacts all the objects in the heap so that you've effectively
moved
the "heap pointer" closer to the beginning of the conveyor belt and
further away from a page fault. The garbage collector rearranges
things and makes it possible for the high-speed, infinite-free-heap
model to be used while allocating storage.