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 <cnewl...@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 >
