Re: Garbage collection problem

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

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

"John C. Bollinger" <jobollin@indiana.edu> wrote in message
news:c2iuhv$1f5$1@hood.uits.indiana.edu...
> Dale King wrote:
>
> > "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> wrote in message
> > news:396dnfmITpFI2tHdRVn-vA@nildram.net...
> >
> >>[I posted a different version of this a couple of days back, but it
seems
> >
> > to
> >
> >>have vanished into thin aether.]
> >>
> >>Dale King wrote:
> >>
> >>
> >>>public void method()
> >>>{
> >>> Object o = new FooBar();
> >>> someMethodThatExecutesALongTime();
> >>>}
> >>>
> >>>The question is whether the VM is allowed to make the object created
> >>>eligible for garbage collection before the called method returns. It is
> >
> > no
> >
> >>>longer accessed in this method but it is still in scope.
> >>
> >>My apologies if this is a point that you covered in your thread with
Chris
> >>Smith, but it seems to me that the JLS2 is pretty clear on this point.
> >
> > From
> >
> >>12.6.1 "Implementing Finalization":
> >
> >
> > Yes, it was discussed and is not as clear as you seem to think.
> >
> >
> >>========
> >>A reachable object is any object that can be accessed in any potential
> >>continuing
> >>computation from any live thread.
> >
> >
> > Here is one of the unclear parts. What does *can be* accessed mean. Does
> > *can* be accessed require that it *will* be accessed. Or is *could have*
> > been sufficient.
>
> I agree that the JLS is a bit vague on this point, but I think you are
> taking an extreme position. To be sure, a VM that complied with your
> assertion of the required behavior certainly would be compliant on this
> point, but I don't interpret the spec as restrictively. In particular,
> I think it is not required and not useful to interpret "can be accessed
> in any potential continuing computation from any live thread" in any
> other context than that of the classes currently loaded by the VM and
> any that might be loaded in the course of any of the computations
described.
>
> For instance, in the example quoted above, the Java compiler or VM could
> determine that there is no read of method()'s local variable "o" in the
> byte code currently loaded into the VM. How could that not mean that o
> cannot be accessed? I simply don't accept that the compiler or VM is
> required to take into account the continuum of possible alternative
> implementations of method(). The whole point of optimization is to
> shortcut a program is a way that has no effect on the results except for
> resource consumption and/or running time. I see absolutely no point to
> interpreting the spec as you describe. I guess all this puts me in the
> same camp as Chris Smith on the matter.

I am not asking it to look at all possible alternative implementations, but
that it should respect my code where I declared the actual scope of the
variable, which says when the variable is accessible. You are saying that
the JVM should be able to circumvent what is declared in the program. If I
declare a scope for the variable I may be depending on the object remaining
alive. It just seems to me that you are being over optimistic and violating
the correctness of the program. In the end it probably doesn't matter
because the only way being over optimistic can matter is if you have side
effects from a finally clause and even if you did the garbage collector
usually delays finalization.

> > I agree with the spec that "a compiler or code generator" may do that. I
> > don't agree that the JVM should be allowed to do that, because it does
not
> > have sufficient information.
>
> Hold your horses, there. What information is the VM missing? If it had
> that information (or an equivalent) would it be permitted to perform the
> transformation, via JIT or otherwise?

Sure if the class file actually has the optional local variable table, then
it is free to reclaim objects referenced from variables that have gone out
of scope.

Relevant Pages

  • Re: What with this open file descriptor/"Read on closed filehandle " stuff?
    ... >> variables in as small a scope as possible, and simply declare them the ... It is not so much a matter of taste as a matter of good programming ... If variables are declared in the smallest scope possible ... But you can install File::Glob from CPAN and use that. ...
    (comp.lang.perl.misc)
  • Please advise of basic problem in my code (using opendialog)
    ... Thankyou for your time Olie, I do understand the basics of classes, but ... One of those principals is variable scope. ... In your example you declare file in the function Form1_Loadbut this ... private void Form1_Load ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Java needs "goto" (was Re: hi)
    ... cause they won't go out of scope. ... as if they are hit, you are COMPLETELY out to lunch, ... that exception was hit if you are using declarations ... so a "declare at the top" style should still yield to ...
    (comp.lang.java.programmer)
  • Re: Garbage collection problem
    ... >> It is seperate question whether a VM might reuse a local variable slot ... > it is no longer accessible and the variable itself has gone out of scope. ... > eligible for garbage collection before the called method returns. ... I'll vote for better optimization. ...
    (comp.lang.java.programmer)
  • Re: advice on package design
    ... > for following scope. ... the compiler would have to do ... the extra verbiage required just to declare X. ... Unfortunately this is also untrue in Ada. ...
    (comp.lang.ada)