compiler monitorig/tuning

Brian Toal brian.toal at
Wed Jun 22 23:56:58 UTC 2016

Thanks Vladmir,

Will look into -XX:+PrintTieredEvents.  Might be useful to make queue
lengths available by an MBean or whatever so that service owners can
integrate those metrics with existing monitoring systems, and can
understand when it might make sense to add more JIT threads to keep up with
the enqueue rate.

We recently upgraded from u66 -> u72 and around the same time we've noticed
that 1-2 JVM's out of ~30-40 that are servicing the application tier run
significantly slower and as a result take on more load, until the host is
completely over saturated, exacerbating the problem worse.  The workload is
uniform across the hosts.   We are looking at addressing the feedback
system to ensure the requests are throttled, how ever we are trying to
understand if some change in JIT behavior is causing the system to take
longer to warm up.

Looking at stacks from the active threads on the load ramp up, there isn't
one hotspot that would explain the increase in load due to a feature
regression, but rather what we see are arbitrary code paths.  Could be due
to the host being completely saturated and no real work progressing, or
could be due to the code still running interpreted.

- Brian

On Tue, Jun 21, 2016 at 9:01 PM, Vladimir Kozlov <vladimir.kozlov at
> wrote:

> Hi Brian
> Could you explain what problems you are observing? Which JDK 8 update
> version you are testing?
> On 6/16/16 11:00 AM, Brian Toal wrote:
>> Good day,
>> - How do I monitor the length of the compiler queues (client and
>> server)?  I want to understand the backlog (if any) to
>> determine if the application could benefit from more compilation threads.
> There is -XX:+PrintTieredEvents flag which outputs on display queues sizes
> for each compilation request (a lot of output).
>> - I remember in the past being able to get detailed compiler statistics
>> from a mbean or something where the metric was
>> prefixed with <> and it contained execution count,
>> total time, thread count exec for the client
>> and server compilers.  Where can I find this data in realtime for
>> monitoring purposes?  If I know the total time and
>> thread count I suppose I can work out if the utilization of the
>> compilation threads.
> May be it was jvmstat monitoring utility (now jstat). But it does not
> collect queues sizes.
>> - What other compilation metrics should I be paying close attention to?
> Very detailed compilation output file is created (on JVM exit) with
> -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation.
> You can build this output parser tool from sources in
> (note it is jdk 9, for 8 update build from clone of
>> - Other than tiered compilation becoming the default in Java 8, where
>> there any significant changes that would have
>> slowed down compilation time?  We've had -XX:-TieredCompilation set in
>> Java 7 and 8 and haven't touched any other JIT
>> related config.  Was there some other setting default that changed which
>> we would have needed to change when going fro 7
>> to 8?  Looking at the various compiler parameters that I know about via
>> PrintFlagsFinal from 7 and 8, there doesn't seem
>> to be any change other than -XX:-TieredCompilation.
> There were a lot of changes which could affected JIT compilation speed.
>> Regards,
>> - Brian
> Regards,
> Vladimir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the hotspot-compiler-dev mailing list