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

[Vladimir Ivanov]

>> I'm not sure I understand fully, but I'm now generously sprinkling
>> class LDCs into my jitted methods' static initializers now. This seems
>> like an incredibly onerous series of requirements just to load some
>> dynamic code.
> 
> So I moved the Class.forName's out of the OneShot constructor and into
> the static initializer (as LDC) in the jitted methods' classes. I went
> ahead and loaded everything that is in the signatures in question.
> 
> https://urldefense.com/v3/__https://gist.github.com/headius/6408b8392096d7932020870022374a9d__;!!GqivPVa7Brio!OkSq8FcGAVnPJ05eVhXtpKqO3AddrYi7X2GF732M6jh55-DknpgkGo2GUB3uPTsQOGKg5fU$
> 
> Running the original script, I no longer see "unloaded signature
> class" warnings from PrintInlining, and as shown in the above gist I
> eventually get the asm I expect!
> 
> But this is a hacky workaround, right? Do other frameworks that
> dynamically generate code also have to do this aggressive classloading
> within that generated code? This doesn't seem right, does it?

I agree it requires too much work on user side to workaround the 
limitation, so I'm looking into possible ways to relax the restriction 
on JVM side.

Still, I don't see it as a general problem for dynamic bytecode 
generation. If loaded code is placed inside single class loader, 
stepping on unloaded class (either absent of not-yet-loaded) is much 
less likely to happen. Having loader per class already stresses JVM in 
multiple directions and all the downsides should be taken into account 
before adopting it.

So, I see it as yet another initialization-related corner case and it 
would be nice to get it fixed to avoid the pathological behavior you 
observe.

Best regards,
Vladimir Ivanov