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

[Charles Oliver Nutter]

It does not ring any bells but we do generate runtime-compiled methods
into their own classloaders. They should be pretty simple, though...
same protection domain as parent classloader and as each other.

I have also tried forcing all methods to be generated into the same
classloader and did not see any improvement.

I would love for this to be my problem, so I can fix it!

- Charlie

On Fri, Aug 28, 2020 at 10:51 AM Vladimir Ivanov
<vladimir.x.ivanov at oracle.com> wrote:
>
> Hi Charles,
>
> I'll take a look and will try to reproduce it myself.
>
> Meanwhile, here's what Charlie reported:
>
> "Starting at the error message unloaded signature classes I worked
> backwards to find the class(es) which were causing the error. The first
> class in the signature that caused issues was org/jruby/RubyModule. This
> class was found on the current class loader but it is rejected due to a
> protection domain check. There was a 2nd failure related to
> java/lang/String which is just not found on the particular class loader."
>
> It does sound like there's something fishy happening with class loaders
> and compilation context. Does it ring any bell for you?
>
> Best regards,
> Vladimir Ivanov
>
> On 28.08.2020 18:41, Charles Oliver Nutter wrote:
> > It has been a couple months so I want to wake this thread up again. As
> > far as I know nothing has changed.
> >
> > Just to emphasize the importance here: if indy call sites are not
> > inlining, then JRuby is clearly missing out on tons of performance. It
> > seems likely to also affect other languages using invokedynamic, and
> > based on other reports (and my own experiments) it may not matter if
> > exotic classloader structures are in use.
> >
> > What is the next step for me to help get this problem solved?
> >
> > - Charlie
> >
> > On Mon, Jun 15, 2020 at 4:38 PM Charles Oliver Nutter
> > <headius at headius.com> wrote:
> >>
> >> Charlie Gracie figured out a nice Hotspot incantation to reproduce
> >> 100% and dump just the PriintInlining graph in question.
> >>
> >> He also managed this with tiered compilation *turned off*, so that may
> >> have been a red herring.
> >>
> >> jruby \
> >>      -Xcompile.invokedynamic \
> >>      "-J-XX:CompileCommand=option *::*foo*,PrintInlining" \
> >>      "-J-XX:CompileCommand=compileonly,*::*foo*" \
> >>      "-J-XX:-TieredCompilation" \
> >>      main.rb
> >>
> >> On Mon, Jun 15, 2020 at 4:23 PM Claes Redestad
> >> <claes.redestad at oracle.com> wrote:
> >>> If so, a possible workaround might be to pass the generated class
> >>> through Unsafe.ensureClassInitialized (or Lookup.ensureInitialized if on
> >>> 15+)
> >>
> >> I added Unsafe.ensureClassInitialized right after the JIT class has
> >> been defined, and it did not appear to help.
> >>
> >> I tried turning off JRuby's background JIT threads, which could cause
> >> a method to get jitted and loaded twice (into separate classloaders).
> >> The JRuby flag is "-Xjit.background=false" but it also did not help.
> >>
> >> - Charlie