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 _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
