JDK-8008684 : CMS: concurrent phase start markers should always be printed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-02-21
  • Updated: 2013-04-30
  • Resolved: 2013-03-13
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.

To download the current JDK release, click here.
JDK 8 Other
8Fixed hs25Fixed
Description
The start markers in the gc logs for CMS are only printed 
if PrintGCTimeStamps is on.  Change this so that they are
printed if PrintGCDetails is turned on.
Comments
The problem is that the start marker for concurrent phases such as the concurrent marking start marker 0.464: [CMS-concurrent-mark-start] is only printed when PrintGCTimeStamps is turned on. Although it does make sense to actually print the time stamp, I think that is a separate issue that should be addressed by turning on PrintGCTimeStamps when PrintGCDetails is turned on.
06-03-2013

Suggestion from Bengt In the constructor CMSPhaseAccounting::CMSPhaseAccounting() we do: if (PrintGCDetails && PrintGCTimeStamps) { ... gclog_or_tty->stamp(); gclog_or_tty->print_cr(": [%s-concurrent-%s-start]", _collector->cmsGen()->short_name(), _phase); } But in the destructor CMSPhaseAccounting::~CMSPhaseAccounting() we do: if (PrintGCDetails) { ... gclog_or_tty->stamp(PrintGCTimeStamps); gclog_or_tty->print("[%s-concurrent-%s: %3.3f/%3.3f secs]", _collector->cmsGen()->short_name(), _phase, _collector->timerValue(), _wallclock.seconds()); ... } Note that we do gclog_or_tty->stamp() in the constructor but gclog_or_tty->stamp(PrintGCTimeStamps) in the destructor, so this seems to have been a conscious decision. Maybe it is a way to try to be consistent with just printing one line per "GC". But it does not make sense to me since this is on the PrintGCDetails-level. I think we should have the same guard in both case, and it seems most logical to me to only guard it with PrintGCDetails.
21-02-2013