Quick look at JavaFX methods above the HotSpot inlining threshold

[Chris Newland]

Hi Scott,

MaxInlineSize (default 35) is the size under which methods will be inlined
regardless of whether they meet the "hot" criteria (number of invocations
observed; 10,000 for server VM).

FreqInlineSize (default 325 on Linux x86_64) is the size up to which
HotSpot will inline methods if they meet the "hot" criteria.

Documentation on these is bit sparse but they are defined in
hotspot/src/cpu/x86/vm/c1_globals_x86.hpp in the OpenJDK source code.

>From my experiments, tuning (increasing) these parameters can often worsen
overall application behaviour, probably because they were arrived at
empirically after profiling the core libs.

In some of the core libs, method bytecode is pushed above the inling
threshold by assert code that under most conditions (no -ea VM switch)
will never be executed. I've seen assertions account for up to 25% of a
method's bytecode.

JITWatch has a "Sandbox" mode where you can rapidly profile the effects of
tuning these parameters and can also highlight badly predicted branches
and polymorphic dispatches (which can't be type-sharpened).

I think it will be interesting to run JITWatch over some JavaFX
applications as graphics code can have some really hot loops where small
gains can make a difference.

I can't promise any performance silver bullets and this is observation is
only about inlining (saving the method invocation overhead). Hot code will
still be JIT-compiled to native even if it's above the FreqInlineSize
threshold (in fact I've seen some UI blit methods generate >32KBytes of
native code thanks to some aggressive loop unrolling!).

Will let you know what I find.

Cheers,

Chris
@chriswhocodes

p.s. the JITWatch UI is written in JavaFX and I've found it a really nice
technology to work with :)

On Tue, November 4, 2014 02:05, Scott Palmer wrote:
> JITWatch looks like an interesting project.
>
>
> Where did you get the information about the 325 byte limit?  The data I
> found indicated that the default limit was *much* smaller.
>
> From this page:
> http://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html#BA
> BDDFII
>
>
> -XX:MaxInlineSize=size
> Sets the maximum bytecode size (in bytes) of a method to be inlined.
> Append the letter k or K to indicate kilobytes, m or M to indicate
> megabytes, g or G to indicate gigabytes. By default, the maximum bytecode
> size is set to 35 bytes:
>
> -XX:MaxInlineSize=35
>
>
>
> It would be interesting to see how adjusting some of those parameters
> affects performance.  Does JITWatch have tools for measuring that sort of
> thing?
>
> Cheers,
>
>
> Scott
>
>
>
>> On Nov 3, 2014, at 6:42 PM, Chris Newland <cnewland at chrisnewland.com>
>> wrote:
>>
>>
>> Hi all,
>>
>>
>> As part of the JITWatch[1] project I've written a tool called JarScan
>> which counts the bytecode size of methods in a jar and logs those
>> methods which are above HotSpot's 325 byte size threshold for inlining
>> methods it determines are "hot".
>>
>> In jfxrt.jar from Oracle's JDK 1.8.0_25 on Linux x86_64 there are 774
>> methods above the threshold which I've listed in this gist:
>> https://gist.github.com/chriswhocodes/c474e49f0d111757dbf2
>>
>>
>> A lot of these won't be found in hot code but perhaps the methods under
>>  com.sun.javafx.geom and javafx.scene.transform could be candidates for
>>  examination with JIT compilation in mind?
>>
>> Has anybody on the list done any experiments in this area? If not I'll
>> try and find some time to see if there are any gains to be made by
>> trimming methods (in the OpenJFX source) to fit inside the inlining
>> threshold.
>>
>> Cheers,
>>
>>
>> Chris
>> @chriswhocodes
>>
>>
>> [1] https://github.com/AdoptOpenJDK/jitwatch
>>
>>
>
>