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

[Vladimir Ivanov]

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