MethodType cache and class unloading

[Rémi Forax]

John Rose a écrit :
> 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.
>   
Ok. I will think about that.
> 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.
>   
I assume that anonymous  classes is a kind of temporary types you talk.
In my opinion, temporary types should not appear in MT, MT are method 
descripors.
In the same time, anonymous class must be supported because it's a
clean way to create closure and stuff like that.

In my opinion, the best solution is to have an overloaded method findVirtual
that take an Object as first parameter and works like a combination
of findVirtual and insertArgument :
    MethodHandle findVirtual(Object target, String name, MethodType type)
    this method will return a method handle that store the target as 
first argument and
    that will have a method type equals (==) to type.

This trick should avoid to create a MethodType with temporary type.

> Thanks for raising this issue.
>   
Rémi
> -- John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>