Quick look at JavaFX methods above the HotSpot inlining threshold

[Scott Palmer]

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#BABDDFII

-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
>