MethodType cache and class unloading

[John Rose]

On Oct 29, 2008, at 8:32 AM, Rémi Forax wrote:

> In order to allow to use == between method types,
> MethodType must used a cache to intern MethodType.

Yes, they are like interned strings.  At least on some internal token  
like a MethodType, we have to support == comparison.  Otherwise the  
signature check will be too slow.  For simplicity, the signature  
check token should be the MethodType itself (not a hidden C-level  
token derived from it).

As far as the Java API is concerned, it is cleaner to call MT.equals  
instead of use ==, even if the programmer knows they are interned.   
(Compare the case of string literals:  It is rare to use ==, because  
of the risk of bugs.)

> But that cache seems to prevent class unloading.
> => oups

Interned strings can be unloaded...  So can loaded classes (which are  
referred to from the system dictionary).  The issue is putting the  
right kind of weak links into the intern table or system dictionary.

It requires care to make the links (from intern table to method type  
to class) weak enough to allow unloading.  This care is not in the  
mlvm code yet.  I am assuming that we can do this in Java.   Do you  
see a problem with this?  I know it's complicated; I believe the  
complexity can be put into Java code instead inside the JVM.  This is  
a chunk of Java code that should be shared across JSR 292  
implementations.

More analysis:  The MT objects used at call sites are not likely to  
mention unloadable types; they are likely to mention Object, etc.   
But the MT objects for intermediate, pre-adapted MH's, such as are  
returned by findVirual, are likely to mention temporary types,  
especially in the first argument position, where the receiver  
appears.  So this is a problem.  Perhaps the intern table should be  
used only for call site checking.  This complicates the design, since  
it appears to require lazy interning of target method types, at any  
JSR 292 call site.  I have preferred to intern everything from the  
start.

Thanks for raising this issue.

-- John