Quick look at JavaFX methods above the HotSpot inlining threshold

Scott Palmer swpalmer at gmail.com
Tue Nov 4 02:05:15 UTC 2014

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

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:


It would be interesting to see how adjusting some of those parameters affects performance.  Does JITWatch have tools for measuring that sort of thing?



> 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

More information about the openjfx-dev mailing list