Cast not your Perl before swine?

Michael L Torrie torriem at chem.byu.edu
Tue Dec 18 12:01:18 MST 2007


Levi Pearson wrote:
> 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.

I didn't mean to imply that Java used reference counting as a garbage
collection scheme.  Only that the garbage collector does track reference
counts in some fashion with some algorithm..

C++ smart pointers simply check reference counts when the scope is
destroyed, and call the destructor on the object they point to and free
the memory, if the count hits zero.  I do not consider this technique to
be "garbage collection" as most Java programmers would think of it.
Rather it's just a method of managing resources in C++ that happens to
be, in my opinion, very efficient from a programmer's point of view.

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

Thanks for the clarification.

> 
>                 --Levi
> 
> /*
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
> */
> 


-- 
Michael Torrie
Assistant CSR, System Administrator
Chemistry and Biochemistry Department
Brigham Young University
Provo, UT 84602
+1.801.422.5771




More information about the PLUG mailing list