The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
noreg-manual justification:
Test is to manually inspect logs from GC with -verbose:gc -XX:+PrintGCDateStamps.
The non-determinism of the GC will also make an automatic regression test harder to create
Originally java2d demo was used to reproduce the problem, but in my experience most programs with a heavy GC load will reproduce it.
Example of problem:
2012-06-18T11:39:36.223+0200: [GC 5834K->5925K(8128K), 0.0007256 secs]
[Full GC 5925K->383K(8128K), 0.0192694 secs]
2012-06-18T11:39:36.262+0200: [GC 1203K->752K(8128K), 0.0008404 secs]
04-04-2013
EVALUATION
Missing a call to date_stamp() in GenCollectedHeap::do_collection. Bug has existed since -XX:+PrintGCDateStamps was added in hs10/jdk6u4.
Needs '!complete' flag to avoid double date stamps on other events.
03-09-2012
SUGGESTED FIX
diff --git a/src/share/vm/memory/genCollectedHeap.cpp b/src/share/vm/memory/genCollectedHeap.cpp
--- a/src/share/vm/memory/genCollectedHeap.cpp
+++ b/src/share/vm/memory/genCollectedHeap.cpp
@@ -533,6 +533,7 @@
increment_total_full_collections();
}
pre_full_gc_dump(); // do any pre full gc dumps
+ gclog_or_tty->date_stamp(!complete && PrintGC && PrintGCDateStamps);
}
// Timer for individual generations. Last argument is false: no CR
TraceTime t1(_gens[i]->short_name(), PrintGCDetails, false, gclog_or_tty);