Re: Garbage Collection - The Trash Begins To Pile Up
On Jan 12, 7:54 am, Edward Diener No Spam
<eldiener_no_spam_h...@earthlink.net> wrote:
Andreas Huber wrote:
C++ is employed in so many different areas that you have to excuse me
when I don't take the experience of a single programmer as
representative for the whole community.
Of course, cycles are just one (but easily explainable) example of where
a GCed language is better than a language that employs
reference-counting. Other examples are:
- Lock-free programming
- Library-design (with only few exceptions a program in a GCed language
typically performs best when all heap-objects are referenced by GCed
pointers, you no longer have to find out exactly what kind of
smart-pointer performs best in your particular situation).
I disagree with both of the above. The second point is completely
subjective. If you care to tell me why you think the first is true,
please go ahead and do so.
Google is great: <http://erdani.org/publications/cuj-2004-10.pdf>
Oh, and I forgot to mention that GCed systems often perform better than
ref-counted systems.
meaning that any cycles are not handled for resource objects. For all
other non-resource objects cycles are handled in GC in the usual mark
and sweep way.
This is a limitation on cross-referenced objects within resource
objects, but worthwhile in my opinion and experience.
I strongly disagree. Manual simplicity is often better than
half-automated complexity. There is a very simple rule when you program
in a GCed language: If an object has a Dispose() method, you need to
call it after the object has been used for the last time (and obviously
before the last reference goes out of scope). With the regime you
propose, it is rather difficult to find out whether you need to call
Dispose() or not. I bet that most programmers would either overlook the
few cases where they have to call Dispose() or would simply always call
Dispose() for safety.
Dispose() would not be needed since the destructor of the object, or the
finalizer if you will, will be called when the object is finalized.
That is only true for objects allocated on the stack (which have
nothing to do with GC or reference-counting anyway). What I was talking
about is the following situation:
class A // resource class
{
public:
~A() { /* ... */ } // resource is released here
B * pB_ = 0; // public to reduce the amount of code
};
class B // normal class
{
public:
A * pA_ = 0; // public to reduce the amount of code
}
int main()
{
A * pA = new A();
B * pB = new B();
pA.pB_ = pB; // *** 1 ***
pB.pA_ = pA; // *** 2 ***
delete pA; // *** 3 ***
return 0;
}
To make things interesting, imagine three versions of the above code:
a) As written above
b) As written above, but with line 1 deleted
c) As written above, but with line 2 deleted
If we assume C++ had Java-like GC then for deterministic destruction
line 3 would be necessary for all versions of the code. If you forgot
to do that, the GC would later call the destructor
non-deterministically.
IIUC, with the regime you propose for deterministic destruction line 3
is necessary only for version a). In versions b) & c) the A object
would be finalized deterministically in any case. Correct?
If so then it is rather difficult to find out whether you need to
delete a certain object for determinism or not. I bet that most
programmers would either overlook the few cases where they have to
delete or would simply always delete for safety.
Once again we will just have to disagree about manual disposal of the
resource being better than automatic disposal of the resource. Having to
worry about if an object needs disposal, when it should be done and by
whom, and making sure I catch all possible exceptions on the object
every time I use it just to make sure that I dispose of the resource is
all a PITA to me.
Please explain how a programmer can easily decide whether to delete or
not in situations like the above. It seems to me it is more of a PITA
to do that analysis than to simply always delete.
In my non-cyclic deterministic finalization of resource objects in GC,
before a resource object, the root object, is finalized, all nested
resource objects are considered for finalization, and all nested
non-resource objects are completely ignored.
So a resource object that is only referenced by a pointer in a
non-resource object, which in turn is only referenced by a pointer on
the stack will not be finalized?
Why does the above follow from my explanation above ?
It doesn't, sorry. Add a "deterministically" to the end of the sentence
to get what I meant.
Perhaps this will not work with current GC notions of mark and sweep
when a resource object is found in the normal course of GC collection.
But I believe that it is easier to program or change GC if the notion
of deterministic finalization of resource objects were a part of the
implementation than it is to claim that it could not be done or that
it is too complicated.
You have not said exactly how you intend to solve the problems that
Brian Harry mentions under "The next best thing". A few of those are so
hard to tackle, possible solutions are so ugly and the side-effects are
so undesired that I personally don't see any point in investigating any
further just to get *inherently incomplete* deterministic finalization.
You are just copping out here.
No, I'm far away from doing that.
I have no idea what "The next best thing"
is about and I refuse to once again argue when I have already addressed
points made in the article in a post which you decided to largely ignore.
You're obviously no longer paying much attention. In the article you
refer to there's a section called "The next best thing".
Concerning the points in your post I have not yet addressed, I said I
will do that as soon as we have cleared the disagreement concerning how
GC can possibly work regarding deterministic release. As you see above
and below I don't think we're through with that yet.
On top of that, as we've already seen, transparent synchronous
finalization is undesirable anyway because it can lead to
hard-to-diagnose deadlocks or even data corruption.I do not agree with
this and your saying so by you means nothing to me here.
If you have particular points to address, do so.
Well, AFAICT you have failed to show how Hans Boehms and my reasoning
concerning transparent synchronous finalization is flawed, it seems you
simply ignored the points I made in the following post:
<http://groups.google.com/group/comp.lang.c++.moderated/msg/cbaa420fe849846a
For more information please also see the exchange I had with Peter
Dimov.
Otherwise you are just
duplicating for me the responses I have gotten in the past when I
proposed deterministic destruction of resource objects in other NGs
connected to GC languages. This was the mindset that it was not to be
considered because some supposed authority ( Microsoft, Sun, other .Net
or Java programmers considered experts ) said it could not be done or it
was too much trouble to consider or think about.
I have no clue why you're saying this. Yes, I did quote some experts
but I also tried to explain why they are right. The last time I did
this, you failed to reply.
--
Andreas Huber
When replying by private email, please remove the words spam and trap
from the address shown in the header.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]