Re: Garbage collection problem

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


Date: Mon, 15 Mar 2004 10:40:45 -0500

Dale King wrote:

> "John C. Bollinger" <jobollin@indiana.edu> wrote in message
> news:c2iuhv$1f5$1@hood.uits.indiana.edu...
>>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.

I agree that the Java source determines where the variable is
"accessible" in an informal sense, but as I tried to define that sense
of the term I realized that I was just coming up with something
equivalent to "in scope". That leaves me unable to take any useful
information from your statement.

The JLS does not apply the term "accessible" to local variables, and
does not use it in its defined sense in the discussion of finalization
(back to JLS 12.6.1). The JLS also does not explicitly rely on the Java
scope of reference variables to define reachability, and it certainly
does not depend on the semantics of bytecode for that definition.

> You are saying that
> the JVM should be able to circumvent what is declared in the program.

No, I'm saying that the JLS does not specify that the scope of a local
reference variable has any special relationship to the reachability of
its current referrent within that scope. To read such a requirement
into the spec you are depending on interpreting "can be accessed [...]"
to include the in-scope reference variable case, but I think that is a
mistake. The context of the statement is program _execution_, to which
questions of variable scope in the source code are irrelevant.

> If I
> declare a scope for the variable I may be depending on the object remaining
> alive.

And your program may therefore be incorrect. As Chris Smith wrote a
couple days ago, even if your interpretation were technically right, JVM
implementors may, and some apparently do, use the more permissive
interpretation. You may claim the high moral ground for yourself if you
wish, but if you want your programs to be reliable with respect to this
detail then you must assume the more permissive interpretation is in use
in the JVM.

> It just seems to me that you are being over optimistic and violating
> the correctness of the program.

Funny, I'd say exactly the same thing about your position.

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

Agreed that if a program that assumes finalization will be delayed until
all references are out of scope runs in a JVM that does not ensure that
that assumption is valid then actual misbehavior still requires a
combination of unlikely circumstances. Still, no matter how unlikely,
chances are that eventually it will happen, and that the failure will be
extremely difficult to diagnose. Even if I agreed with you on the
technical point, I would be inclined to play it safe.

John Bollinger
jobollin@indiana.edu



Relevant Pages

  • Re: Visual Studio .NET Verdict? Are People Using C#?
    ... scope so they have to be constructed outside the try. ... Sometimes I think the flood of developers to Java is ... > language better though) but it if you're developing for Windows I think ... but they're on different ends of an ideological split. ...
    (microsoft.public.vstudio.development)
  • Re: I really did get burned today [LONG]
    ... even sure my interpretation is right. ... On the scope question... ... This is about how the standard did design them. ... some of the DOs have construct-scoped variables and others ...
    (comp.lang.fortran)
  • Re: Nulling an object
    ... because the variable won't go out of scope anytime soon. ... variable than by a null-assignment hack. ... In all JVM implementations? ... Tom Anderson's anecdote was a good example; ...
    (comp.lang.java.programmer)
  • Re: Nochn Closure Proposal
    ... Programmiersprachen mit statischem Typsystem Closures erlauben? ... [mit Schreibzugriff auf alle Variablen im Scope] ... Oft werden aber (so auch bei Java) lokale Variablen auf ...
    (de.comp.lang.java)
  • Re: Nochn Closure Proposal
    ... Programmiersprachen mit statischem Typsystem Closures erlauben? ... [mit Schreibzugriff auf alle Variablen im Scope] ... Oft werden aber (so auch bei Java) lokale Variablen auf ...
    (de.comp.lang.java)