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
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.
> PLUG: http://plug.org, #utah on irc.freenode.net
> Unsubscribe: http://plug.org/mailman/options/plug
> Don't fear the penguin.
Assistant CSR, System Administrator
Chemistry and Biochemistry Department
Brigham Young University
Provo, UT 84602
More information about the PLUG