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

[Charles Oliver Nutter]

Ok that's a lot to parse...

On Thu, Sep 3, 2020 at 5:20 AM Vladimir Ivanov
<vladimir.x.ivanov at oracle.com> wrote:
>    (1) Class loading request should go through the JVM, so its result is
> persisted in SystemDictionary. It means that ClassLoader::loadClass() is
> not enough, Class::forName() should be used instead.

I've switched these loads to forName throughout.

>    (2) Class loading request should be performed in the context of the
> script. Since JRuby classes have protection domain set for them, there's
> additional check required for them as part of class loading request. It
> is implemented on Java side by ClassLoader::checkPackageAccess, but
> since JIT-compilers aren't allowed to call into Java, they rely on the
> cache which keeps all protection domains for which the check succeeded.
> So, there should be a class loading request performed which goes through
> the JVM with the very same protection domain instance.

I'm not sure what you mean by "the context of the script". There is no
such context; the secondary loaded script (inline.rb) is never itself
compiled. It is interpreted for its initial load, and then the "foo"
and "bar" methods later get jit-compiled to bytecode as they get hot
enough.

> So, triggering class loading from static initializer of the script class
> should do the job. But, while looking through Class::forName()
> implementation, I noticed that it optionally fills caller info depending
> on whether SecurityManager is set, but JVM always checks protection
> domain. So, the only reliable option left to satisfy both #1 and #2 is
> to trigger loading on bytecode level (for example, by using ldc +
> CP_Class).

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.

- Charlie