Re: Garbage collection problem

From: John C. Bollinger (jobollin_at_indiana.edu)
Date: 03/09/04 

Date: Mon, 08 Mar 2004 18:09:46 -0500

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.

 From where I stand "will be" is equivalent to "can be" plus "cannot be
otherwise". It is thus a stronger and inequivalent condition. It may
be impossible or impractical to evaluate a "will be" condition, so the
spec relies on the weaker "can be". The implementation is not in fact
required to make the determination precisely, so long as it doesn't
erroneously mark anything unreachable, because, as you know, it is not
required to GC those objects that are unreachable on any particular
schedule.

>>Optimizing transformations of a program
>>can be designed that reduce the number of objects that are reachable to be
>
> less
>
>>than those which would naively be considered reachable. For example, a
>
> compiler
>
>>or code generator may choose to set a variable or parameter that will no
>
> longer
>
>>be
>>used to null to cause the storage for such an object to be potentially
>>reclaimable
>>sooner.
>>========
>>
>>Granted that that may not be a normative specification of what
>
> optimisations
>
>>may be performed, but does seem to be sufficiently explicit about that
>
> such a
>
>>normative spec would say if there were any such spec. E.g. I'd expect it
>
> to be
>
>>legal for the compiler (let alone the JVM) to rewrite the above quoted
>
> snippet
>
>>to:
>
>
> 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?

John Bollinger
jobollin@indiana.edu

Relevant Pages

  • Re: Dual Xeon Linux vs. dual G5 : Where can I find direct speed comparison?
    ... (Treating SPEC numbers as _the_ single defining metric, ... Intel appears to have added specific optimizations in their compiler to ... Using gcc instead of the Intel compiler was a reasonable decision, ... Either a dual Xeon or a dual G5 is *way* faster than anything that you ...
    (comp.os.linux)
  • ADA compilers can reject types arbitrarily?
    ... I assume I can expect an O'size spec to be ... a compile time error if the operational spec grows independant of the ... in favor of compiler dependant but readable code. ... So an ADA compiler can arbitrarily decide whether to accept a ...
    (comp.lang.ada)
  • Re: I think C# is forcing us to write more (redundant) code
    ... > ..locals init in order to initialize the locals. ... > compiler, if you run Peverify on the assembly following error message will ... the spec on MSDN is the ECMA spec. ... verifiability. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Java -> ActionScript?
    ... Nachdem wie ich es verstanden habe ist diese Implementierung da um zusätzliche Fragen zu beantworten, ... Und nachdem manche Menschen rummeckern wenn es keine Spec gibt, ist das wohl auch besser so.... ... einen Parser braucht man dann natürlich trotzdem.Ich weiss nicht wie deren Compiler aufgebaut ist, aber wenn es ein Multipasscompiler mit AST ist, dann reicht es wahrscheinlich den Parser auszutauschen und einen kompatiblen AST zu generieren. ...
    (de.comp.lang.java)
  • Re: Newest phone still supporting dial up wap?
    ... Yeah i know Chris, ive seen the spec of it, and that was gonna be my main choice, but thought i had better contact Nokia support who assure me it doesnt have CSD wap! ...
    (uk.telecom.mobile)