On Fri, Feb 24, 2012 at 10:31 AM, Charles Oliver Nutter <head...@headius.com> wrote: > ...but they're still defined by separate classloaders, so I still > think there's an indy problem here.
Ok...I think I have a solution that works for me, and I'm still pretty sure this is an indy problem. My fix was to make every jitted class name unique to the JRuby runtime it's jitted within. The class names now additionally have the hashcode of the current JRuby runtime, which is sufficiently unique for my purposes, as the last part of their names. With this change, tests run again. It seems to me that when bound by indy, classes in one classloader hierarchy are getting seen by classes in another classloader. In my case, the basic layout is like this: <System ClassLoader> # loads JRuby classes ...<JRubyClassLoader> # loads runtime-loaded Java classes from Ruby scripts ......<OneShotClassLoader> # loads jitted Ruby code, one per classloader .........[MyJittedClass_1A2B3] # the jitted method, as a Java class ...<JRubyClassLoader> # this is in another JRuby runtime ......<OneShotClassLoader> # jits the same Ruby code but loads it as a new class for this hierarchy .........[MyJittedClass_1A2B3] # the same code as a different Java class When MyJittedClass_1A2B3 is involved in indy-based method binding, it seems that indy is using the first version it encountered for binding argument types, rather than the second version from its own classloader. So although it has version #2 of MyJittedClass in-hand, the argument linking proceeds against version #1 of MyJittedClass. I will try to come up with a test for this, but it's a tricky combination. - Charlie _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
