Tiered compilation leads to "unloaded signature class" inlining failures in JRuby

[Vladimir Ivanov]

>> What surprised me is that the absent class which causes the failure is
>> java.lang.String. But it turns out java.lang.String is never accessed
>> from callee method [1] and hence there are no guarantees it is resolved
>> in the context of the context class loader (instance of
>> org/jruby/util/OneShotClassLoader) by the time the compilation kicks in.
>>
>> You can workaround that by forcing j.l.String resolution when
>> instantiating the class loader.
> 
> I can give this a shot, but if I'm resolving the target method's
> class, and that class is using String (there's definitely references
> to String in the generated code), why is String still unresolved at
> the point where I actually bind the method and call it?

As I can see with the test case, target method is loaded in a separate 
instance of OneShotClassLoader (and, moreover, I see j.l.String loaded 
there!). So, it doesn't mattter whether a class is loaded in a "parent" 
(?) script at all since they are loaded by separate class loaders.

> I guess I can't tell whether you're saying "this is not your fault and
> here's a workaround" or "this is your fault and this is how you should
> fix it".

It's hard to draw a line here. My feeling is JVM can do a better job 
here (but I haven't worked out all the consequences yet). But if you 
want to get rid of this quirk running on 8u, you definitely better fix 
your app (JRuby).

Best regards,
Vladimir Ivanov