Longjumps considered inexpensive...until they aren't

[John Rose]

On Jun 3, 2008, at 4:56 PM, Charles Oliver Nutter wrote:

> Ok, I've done some investigation with a LogCompilation tool and  
> noticed
> a few things.
>
> - We have a few key methods in the call path that are "too big" in the
> log output...important stuff like InlineCachingCallSite.call. Those  
> will
> be obvious areas we can look to fix. For now I've continued some
> investigation setting MaxInlineSize up a bit.

Yes, that's a good start.

> - The max inline level seems to be a larger problem. It appears in my
> OpenJDK source that the default max level is 9. If you look at the
> traces I provided in earlier emails we're looking at a bare minimum of
> 8-9 calls in the simpliest case of a non-local return, and there's  
> very
> little I can do to reduce that on pre-invokedynamic JVMs:

Yes.

> at ruby.__dash_e__.block_0$RUBY$__block__(-e:1)
> at ruby.__dash_e__BlockCallback$block_0$RUBY$__block__xx1.call(Unknown
> Source)
> at org.jruby.runtime.CompiledBlockLight.yield 
> (CompiledBlockLight.java:107)
> at org.jruby.runtime.CompiledBlockLight.yield 
> (CompiledBlockLight.java:88)
> at org.jruby.runtime.Block.yield(Block.java:109)
> at org.jruby.RubyInteger.times(RubyInteger.java:163)
> at org.jruby.RubyIntegerInvoker$times_method_0_0.call(Unknown Source)
> at org.jruby.runtime.CallSite$InlineCachingCallSite.call 
> (CallSite.java:312)
>           at ruby.__dash_e__.method__0$RUBY$foo(-e:1)

Are a lot of those (effectively) tail calls?  This will be more  
common in dynamic languages, and we could tune the inline heuristics  
to prefer to inline tail calls.

We should probably also experiment with (gulp) an @Inline annotation  
for methods, not to override the heuristics, but to add a vote from  
the code writer.  It could be made Hotspot-specific, to start with.   
(I have an annotation parser for the VM classloader, that will be in  
my next post to the mlvm repo.)  For a gross, gross POC hack, the VM  
could try putting looking for the string "_inline" in the method  
name, and bias the inlining heuristic.  There is also a compiler  
oracle function in the JVM which can be used to place advice on  
individual methods, but it is hard to use and not modular (single  
property file).

> Based on these two findings, I tried bumping up the inline level but
> have not been able to re-profile yet. I'd like to know if I'm on the
> right track. Obviously we want to do whatever we can to reduce the
> length of the call path, but it seems like even the best case for  
> us now
> is going to be a few levels deeper than the standard inlining process
> can handle.

Yes, that's the right track.  We should also keep talking about  
incremental changes to the inlining heuristics.

> Are there other settings I might want to look at for tweaking this? I
> have a build of OpenJDK7 I can fiddle with.

I started a wiki page to collect such information, and added a few  
more points there:
   http://wikis.sun.com/display/HotSpotInternals/Inlining

Please consider contributing as you learn what works and doesn't.

-- John