Re: Garbage collection problem

From: Dale King (kingd[at]tmicha[dot]net)
Date: 03/11/04 

Date: Wed, 10 Mar 2004 18:40:46 -0500

"Lee Fesperman" <firstsql@ix.netcom.com> wrote in message
news:404D80E3.821@ix.netcom.com...
> Dale King wrote:
> >
> > "Lee Fesperman" <firstsql@ix.netcom.com> wrote in message
> > news:4047D17A.5653@ix.netcom.com..
> > >
> > > I'll vote for better optimization. As you say, your approach would
> > > limit VM optimization. For instance, the runtime compiler could
> > > use a register instead of a variable. On some machines,
> > > "accessibility" could force a register save/restore.
> >
> > And I'll vote for correctness of program execution. C++ has the RAII
> > paradigm where they create an object and they rely on the fact the
object
> > will be destructed when the variable "holding" it goes out of scope.
There
> > are several reasons why RAII does not work well in Java but the primary
> > reason is that the object may not be finalized until long after the
variable
> > goes out of scope. RAII is not ver usefull in that case.
>
> C++ has no relevance here since it doesn't have GC.

I wasn't saying that C++ was relavent, but that the RAII paradigm is one
that depends upon objects not being destructed until the variable goes out
of scope. And in this sense C++ does have a GC. The stack variables are
collected automatically when they go out of scope.

C# has a mechanism for RAII with a garbage collector that eliminates the
need for most finally clauses. It uses an IDisposable interface and a using
statement. See Jon Skeet's RFE to add a similar feature to Java:

http://groups.google.com/groups?selm=MPG.1929810f411094bf98c14e%40dnews.pera
mon.com

> However, a VM could use RAII
> (including finalization) as an optimization. A Java programmer just can't
take advantage
> of it.

Funny, I don't see that in the spec. I know a Java programmer should not use
RAII because the finalization is not immediate, but this optimization says
that it is fine for the VM to do it prematurely. As long as there is a
finalize method which can have side effects then it seems to me that doing
it prematurely can break code.

> > But you are talking about allowing the opposite extreme where the object
may
> > be finalized long before (could be hours or days) the variable goes out
of
> > scope. That is just plain wrong.
>
> Exactly how is it wrong (other than in your opinion)? I reread the
exchange from last
> year, again. You may remember that I contributed to the thread.

Let's say I had code like this:

    new FooBar();
    callSomeMethod();

Would it be OK for the VM to simply omit the creation of the FooBar instance
or perhaps reorder it to do it after the method call? Of course not. The
reason is that the constructor can have side effects that affect the state
of objects outside of itself. So why does not the same logic apply to the
finalize method. It can have side effects that affect the state of objects
outside of itself. Why should the VM be allowed to do it for finalize, but
not for constructors. I personally do not see why the same rules do not
apply.

> You failed to find any
> authority for your position, and you failed to convince any posters to the
thread.

I wasn't looking for authority just reasoning.

> You also didn't deal with the finalization aspect. There is some consensus
that
> finalizeers should be used carefully and rarely. There are those who
recommend not using
> them at all. I won't go that far; I have implemented finalizers for very
solid reasons.
> I tend to think that finalizers that are vulnerable in this situation are
poorly
> implmented. They really shouldn't have side effects except on external
resources under
> their sole control.

But that is not enforceable. Finalizers can have side effects. I agree it is
not recommended practice. But I don't go as far as to say that the JVM is
free to run them prematurely.

> > > I fully expect VMs to do this optimization and much, much more. It
> > > would be best to heed my caveat: "it [accessibility/reachability]
> > > is not guaranteed."
> >
> > Your opinion has little weight. It should be explictly specified.
>
> Your first comment is uncalled-for, though it is typical for you to use
bluster and
> insults in technical discussions. I'd be glad to stack my knowledge and
experience
> against yours any day.

Sorry, that was not meant as an insult at all! Very poor wording on my part.
I didn't mean that your opinion had little weight because it was *your*
opinion, but because it was just an *opinion*. My opinion doesn't have any
weight either.

My point was that our opinions don't count, the only thing that has any
weight in these sort of matters is the specification. And the spec. needs to
be clarified on this point.

And it is certainly *not* typical for me to use bluster and insults in
technical discussions and I was not doing so here.

> I develop very complex systems software in Java. It's of great importance
to me that JVM
> optimization go as far as it can. I don't want it hamstrung by C++
concepts or poor Java
> programming practices.

And I would have no trouble with that if the spec. explicitly said that it
could make such an optimization and that the behavior is not guaranteed.
Until that time, I think a JVM should be conservative on that point and
guarantee it and that developers should also be conservative and follow your
advice and assume that it is not guaranteed. 

--
 Dale King

Relevant Pages

  • Re: JRuby disabling ObjectSpace: what implications?
    ... I'm guessing Java has its own library for temp files. ... Finalizers could be implemented using Java's finalizemethod for classes that need it. ... The example you pointed ou is class iteration, used for completion, but it's more general iteration than test/unit uses, and #inherited techniques that can be used for test/unit may not work here. ...
    (comp.lang.ruby)
  • Re: Deconstructor and finalize
    ... my java book states that finalize is not a deconstructor. ...
    (comp.lang.java.programmer)
  • Deconstructor and finalize
    ... my java book states that finalize is not a deconstructor. ...
    (comp.lang.java.programmer)
  • Re: finalize() not guaranteed to be called -- ever
    ... a Java object that's backed by a non-Java entity via JNI could use finalize() to tell its counterpart it's no longer needed. ... I like to explain the difference between C++ and Java this way. ... It is a little more manual, but since Java only needs to do this for non-memory resources it is not that common and generally only needs to occur for files, DB connections, etc. ... With Java you have a safety net in the garbage collector and the finalize method which can be used to free resources if they haven't already been freed. ...
    (comp.lang.java.programmer)