Please Review (S): CR 6782663: Data produced by PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime is not accurate
David Holmes - Sun Microsystems
David.Holmes at Sun.COM
Sat Jul 11 03:09:47 PDT 2009
Hi John,
The problem with these flags and values is that the names (old or new)
don't really tell you what exactly is being measured, and so noone
really knows what they measure without going into the code in detail,
and then they find that invariably they don't measure what the developer
would like them to measure.
I suspect these started as GC flags because they were measuring the
duration of, and time between GC (safepoint) VM operations, and over
time this morphed into measuring some aspect of the
safepoint+vm-operation-execution code.
As far as I can see from the current placement what is actually measured
now is the safepoint duration:
- from after the Threads_lock acquisition in SafepointSynchronize::begin
- to just before the Threads_lock release in SafepointSynchronize::end
and the time between safepoints. So the flag names should reflect this
directly. People should be able to correlate these values with those
obtained from PrintSafepointStatistics.
I think these are useful measures (even if the info can already be
obtained from PrintSafepointStatistics) but I'm not sure that changing
the behaviour of existing flags is a good thing to do to the user. I
believe there are people out there that build up execution profiles of
their apps based on what these flags report - even if the actual
measurement is not ideal they can see how the measurements change across
VM releases. Given this will end up in JDK7 and JDK6 I think it might be
better to deprecate the old flags but leave them functioning as-is and
add the news ones in addition. You might choose to support only the new
ones in JDK7 while allowing JDK6 to use old or new.
Cheers,
David Holmes
john cuthbertson - Sun Microsystems said the following on 07/11/09 06:45:
> Hi Everyone,
>
> Can I have a couple of volunteers look over the attached changes for
> this CR? The changes can be found at:
>
> http://cr.openjdk.java.net/~johnc/6782663/webrev.00/
>
> The issue here was that the code that was printing this information was
> only executed for synchronous safepoints and ignored forced safepoints.
> The user would see missing chunks of time (especially with also
> displaying GC time stamps) giving the impression that the JVM and app
> were idle. I was able to see this in the first few minutes of SPECjbb2005.
>
> The simple solution was to move the printing into the routines that
> record safepoint starts and ends, capturing guaranteed safepoints. I
> have also changed the names of the flags to more accurately describe
> that GCs are not the only things we take a safepoint for (and deprecated
> the old flag names).
>
> With these changes I see a delta between (application time + safepoint
> time) and the GC timestamp of around 0.1s instead of around 5 and 7
> seconds previously.
>
> Testing: SPECjbb2005 (exhibited behavior), IBM UK's own evaluation, and
> JPRT.
>
> Thanks,
>
> JohnC
More information about the hotspot-runtime-dev
mailing list