On Sep 7, 2010, at 11:34 PM, Charles Oliver Nutter wrote: > I'll give that a shot, Tom, thanks. Should have thought of it myself.
Also, to make the compiler really spill its guts, try +LogCompilation (google for the wiki page that discusses it). Your prejudice against "fat" bytecodes corresponds somewhat to the HotSpot inlining heuristics. HotSpot strongly prefers to inline small methods, and the algorithm has a non-linear side to it. Two cold methods of 30 bytecodes each are much more likely to get inlined than one method of 60 bytecodes. Likewise for a hot call to two methods of 300 bytecodes each. (Smoothing out these heuristics would be a great post-graduate thesis, IMO.) For an example of experimenting with the inlining heuristics see: http://blogs.sun.com/jrose/entry/an_experiment_with_generic_arithmetic http://blogs.sun.com/jrose/resource/jsr292/SumWithIndy.zip Any such use of the tuning flags must be regarded as purely experimental, but tuning experiments can lead to real improvements. -- John P.S One recent change (to type profiles, not inlining heuristics) was motivated by a performance tuning exercise similar to the present one: http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/4b29a725c43c The improvement is to collect type profiles up at the 'if' instead of down at the cast in idioms like this: if (x instanceof C) ((C)x).somethingFast(); else MyRuntime.somethingSlow(x); With a successful type profile, this will be able to collapse like this: if (x.getClass() != C42.class) trap(); inline C42.somethingFast(x); HotSpot was already collecting type profiles at the cast and the invokevirtual, but not at the instanceof. -- You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en.
