Re: Garbage collection problem

From: Lee Fesperman (firstsql_at_ix.netcom.com)
Date: 03/05/04 

Date: Fri, 05 Mar 2004 01:04:05 GMT

Dale King wrote:
>
> "John C. Bollinger" <jobollin@indiana.edu> wrote in message
> news:c257do$9n9$1@hood.uits.indiana.edu..
> > Lee Fesperman wrote:
> >
> > > For Java, it is best to assume that (as you said) a local variable
> > > remains reachable until the method terminates. However, it is not
> > > guaranteed.
> >
> > It is seperate question whether a VM might reuse a local variable slot
> > that would otherwise go unused for the remainder of the execution of
> > some method. Doing so requires some degree of program flow analysis in
> > order to determine in the first place that the slot is available. I'm
> > having trouble imagining a scenario where a compliant VM could
> > reasonably elect to do that outside the scope of JIT compilation, but
> > once you JIT a piece of bytecode a wide variety of optimizations are
> > possible.
>
> Chris Smith and I had a long discussion on this a while back and could not
> come to an agreement. Consider the following case:
>
> public void method()
> {
> { Object o = new FooBar(); }
> someMethodThatExecutesALongTime();
> }
>
> I think we would agree that it would not be in error for the object to be
> eligible for garbage collection during the call to the other method, since
> it is no longer accessible and the variable itself has gone out of scope.
>
> What if we remove that scope:
>
> 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.
>
> I say that the VM should not be allowed to do this because while the
> variable will not be accessed again, technically it is still visible after
> the method returns and would be accessible even though it isn't actually
> accessed.
>
> If you agree with me that in the second case it would be wrong for the
> object to be garbage collected before the called method returns, then you
> have to conclude that the VM is quite limited in what it can do to optimize
> garbage collection and it doesn't matter what program flow analysis that you
> do. The VM can only tell if the variable *will* be accessed again, but has
> no way to know when it ceases to be "accessible".

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.

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

-- 
Lee Fesperman, FirstSQL, Inc. (http://www.firstsql.com)
==============================================================
* The Ultimate DBMS is here!
* FirstSQL/J Object/Relational DBMS  (http://www.firstsql.com)

Relevant Pages

  • Re: Garbage collection problem
    ... The whole point of optimization is to ... > same camp as Chris Smith on the matter. ... declare a scope for the variable I may be depending on the object remaining ...
    (comp.lang.java.programmer)
  • Re: general performance question
    ... (It seems to me that the JVM should be free to null out the reference once it goes out of scope, or even if it's in scope but flow analysis makes it clear that it can't be used any more, but that was a minority opinion.) ... If you create an Object in a loop and then reassign another Object to the same reference in the loop, the first Object is eligible for garbage collection. ...
    (comp.lang.java.programmer)
  • Re: Optimizing with GCC
    ... The final optimization with garbage collection made the rest. ... I wonder why the ENTRY() keyword was not sufficient - that was all I ... At the top of the linker script. ...
    (comp.arch.embedded)
  • Re: argument returning
    ... because there is still a live reference to it. ... long as the variable is in scope, ... The object will only be eligible for garbage collection ... Matt Humphrey matth@xxxxxxxxxxxxxx http://www.iviz.com/ ...
    (comp.lang.java.programmer)
  • Re: Declaring outside a loop: speed? memory?
    ... the last instance after the loop terminates ... it certain to be eligible for garbage collection, ... references is not eligible for garbage collection even though you can ... elegible for GC if the ref isn't used for the rest of the scope. ...
    (comp.lang.java.programmer)