Understanding PrintOptoAssembly

[Charles Oliver Nutter]

Charles Oliver Nutter wrote:
> I'm trying to take JRuby performance up a notch, and it seems like the 
> next best thing for me to do is examine what hotspot is actually 
> emitting. At the JVM Languages Summit, Cliff Click informed me that 
> paths we expected were inlining actually were not. As a result of my 
> dicussions with him I've decided to try other flags to get more 
> information. The first such flag I have easy access to is 
> PrintOptoAssembly.
> 
> However, I'm having some trouble understanding the output. Would it be 
> possible for someone to post (on a wiki, perhaps) a snippit of a log and 
> some walkthrough of what each element means?

Here's an example a confusing bit for me:

29f     CALL,static  org.jruby.runtime.ThreadContext::pollThreadEvents
         # org.jruby.runtime.ThreadContext::callThreadPoll @ bci:19  L[0]=_
         # org.jruby.runtime.callsite.CachingCallSite::pollAndGetClass @ 
bci:1  L[0]=_ L[1]=_ L[2]=esp + #144 L[3]=_
         # org.jruby.runtime.callsite.CallSiteInvoker::call @ bci:3 
L[0]=esp + #32 L[1]=esp + #28 L[2]=esp + #144 L[3]=e
sp + #144 L[4]=esp + #48 L[5]=_ L[6]=_
         # bench.bench_fib_recursive::method__0$RUBY$fib_ruby @ bci:114 
  L[0]=esp + #152 L[1]=esp + #28 L[2]=esp + #144 L
[3]=_ L[4]=_ L[5]=_ L[6]=esp + #20 L[7]=_ L[8]=_ L[9]=_ L[10]=_ 
L[11]=esp + #64 STK[0]=esp + #24 STK[1]=esp + #28 STK[2]=esp + #144 
    # AllocatedObj(0x90f90b20)
AllocatedObj(0x90f90b20)
AllocatedObj(0x90f90b20)
AllocatedObj(0x90f90b20)
AllocatedObj(0x90f90b20)
AllocatedObj(0x90f90b20)
AllocatedObj(0x90f90b20)
AllocatedObj(0x90f90b20)
AllocatedObj(0x90f90b20)

I can handle most of the x86ish assembly in the code bodies, but I'm not 
sure what all these lines around the CALL are. Obviously the L bits are 
describing how the local variables for the methods are being allocated, 
but what do the bits mean exactly? Why are there four different method 
descriptions after the CALL line?

Also, this is appearing in the assembly for fib_ruby, and I see it 
listed here as well. This particular call could be one of the recursions 
  back into fib_ruby via the CachingCallSite stuff.

- Charlie