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 _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
