OPERATING SYSTEM:
Data gathered on Solaris 10 (may apply to others)

FULL JDK VERSION:
All

DESCRIPTION:
The time data produced when the options PrintGCApplicationConcurrentTime and PrintGCApplicationStoppedTime are enabled is not always accurate when compared to the GC timestamps - the two sets of values often disagree by a significant margin. This prevents accurate analysis of application and GC performance.

The problem exists with 1.4.2 and 5.0 JREs, but the problem seems to be most pronounced with the parallel collectors on 5.0. Here is an example from 5.0:

...
348692.751: [GC 348692.751: [ParNew: 252339K->6510K(286720K), 0.0321036 secs] 513266K->267444K(1372160K), 0.0324390 secs]
  Total time for which application threads were stopped: 0.0355259 seconds
Application time: 45.6524701 seconds
349097.447: [GC 349097.447: [ParNew: 252270K->6741K(286720K), 0.0368750 secs] 513204K->267683K(1372160K), 0.0372196 secs]
...

Application stopped time: 0.0355259 seconds
Application time: 45.6524701 seconds
=> the total time between the two GC cycles according to these values was 45.688 seconds.

But the GC timestamps indicate that the time between the two cycles was 404.696 seconds (348692.751 - 349097.447). The two calcuations disagree by 359.008, or nearly six minutes!

In the same run lasting several days we saw the following:

Disagreement | number | % of all GC
 (seconds) | of cases | cycles (2381)
-----------------------------------------
   > 400 | 2 | 0.08%
   > 300 | 11 | 0.46%
   > 200 | 26 | 1.09%
   > 100 | 39 | 1.64%
   > 50 | 53 | 2.23%
   > 25 | 97 | 4.07%
   > 10 | 220 | 9.24%
   > 5 | 267 | 11.21%
   > 2 | 301 | 12.64%
   > 1 | 454 | 19.06%
   > 0.1 | 680 | 28.56%
   > 0.01 | 787 | 33.05%

So nearly 20% of the event timings disagreed by at least a second. The usefulness of the information is seriously reduced by this level of inaccuracy.