Bill Pugh wrote:
> Given the subtlety here, I'm thinking we should just punt
> in JSR-133 about which classloaders are reachable. In other words,
> just take "reachable classloaders" as a term defined elsewhere
> that we can use in our definitions.
>
> If we had an very formal definition that worked in the single-threaded
> case, we could try to nail down the additional issues that come up
> in the multithreaded case.
>
> But since these issues aren't entirely nailed down, I think
> we should just punt, rather than trying to decide in JSR-133
> on things like whether executing a static method of a class
> means that the classloader that loaded the class is reachable.
Just as an observation, it is interesting to compare this with the
simplicity of System.keepAlive:
The finalization of object O comes-after a decision point d such that if
no finalization was performed after d, then there would be no keepAlive
calls on O after d. Also, the finalization of O happens-after all
keepAlive calls on O that come-before d.
Note that this rule handles class loaders without having to mention them
explicitly. Specifically, this rule implicitly handles the case of
finalization of an object referred to only by a reference in a static
field of a class loaded by an "unreachable" class loader. Also, for this
rule we do not need a definition of reachability, or a fortiori a
definition of reachability of class loaders.
The fact that we need to treat class loaders explicitly in the current
thinking is a consequence of the rule that references in static fields
keep objects alive. If we abandon that rule, then we get a simpler
specification.
-------------------------------
JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:01:07 EDT