On Wed, Sep 8, 2010 at 7:10 AM, John Rose <[email protected]> wrote: > Also, to make the compiler really spill its guts, try +LogCompilation (google > for the wiki page that discusses it).
For whatever reaons, PrintInlining wouldn't show anything but intrinsics. Perhaps it's my build. I opted to use LogCompilation instead. > 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. I do a periodic survey of LogCompilation output for key parts of JRuby (like the parser) to ensure we haven't grown any methods beyond various inlining budgets. You get the idea pretty quickly that Hotspot hates big method bodies... > 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. I'll give that another read. I feel like the logic I have in place for inserting direct static (typed) invocations to "hot" methods at a JRuby call site is a good step forward, but the bytecode size increase is a harsh mistress. Add to that this seeming problem with inlining a bimorphic invokeinterface (that's actually monomorphic from the base implementation) and you have a very frustrated JRuby compiler writer. > 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. How about at an invokeinterface? It appears to collect type profiles, but for only resolving to the immediate types, and not the actual method-to-be-invoked or the common superclass of both that actually provides the implementation... At this point I'm also not above exploring C2, if it's possible to localize this case to something I can consume. I'll have a gander at your patches in the morning. - Charlie -- 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.
