JDK-2148180 : CMS: excessively long abortable preclean cycles
  • Type: Backport
  • Backport of: JDK-6538910
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P5
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2007-04-03
  • Updated: 2011-03-09
  • Resolved: 2011-03-07
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.
Other Other
5.0u16,hs11Fixed hs11Fixed
Description
see parent CR.

Comments
EVALUATION Depending on which 5uR this gets putback to, we may or may not need a 6u3 subCR (thanks to HX). The bug has been fixed in 7.0, see the suggested fix section for webrev pointer.
17-07-2007

SUGGESTED FIX Event: putback-to Parent workspace: /net/jano2.sfbay/export2/hotspot/ws/main/gc_baseline (jano2.sfbay:/export2/hotspot/ws/main/gc_baseline) Child workspace: /net/prt-web/prt-workspaces/20070717022133.ysr.mustang/workspace (prt-web:/net/prt-web/prt-workspaces/20070717022133.ysr.mustang/workspace) User: ysr Comment: --------------------------------------------------------- Job ID: 20070717022133.ysr.mustang Original workspace: karachi:/net/jano2.sfbay/export2/hotspot/users/ysr/mustang Submitter: ysr Archived data: /net/prt-data.east/archives/main/gc_baseline/2007/20070717022133.ysr.mustang/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2007/20070717022133.ysr.mustang/workspace/webrevs/webrev-2007.07.17/index.html Fixed 6538910: CMS: excessively long abortable preclean cycles http://analemma.sfbay/net/jano/export/disk05/hotspot/users/ysr/mustang/webrev The original bug was filed on 5u8 by Nortel and visual inspection of the code revealed the problem, which was that we were confusing a seconds reading from a timer as a milliseconds reading. The customer was able to workaround the problem by scaling down the default timeout by a factor of 1000. This code had already been fixed in the course of 6.0 development so that this was no longer an issue in 6.0 and later. (It's being fixed in 5uXX by Poonam.) However, examination of this code also showed that some of the timer manipulations in the code were incorrect and were not measuring intended work intervals correctly. The problem was that the timer had initially started out being used merely for printing verbose gc data when it had been protected by PrintGCDetails. Subsequently these timer values started being used for certain ergonomic decisions, but the PrintGCDetails guards were overlooked. This can cause ergonomic decisions to become different (and incorrect) when verbose gc is disabled. This fixes and regularizes those timer manipulations and adds some useful assertions to protect against inadvertent misuse of the timer. Reviewed by: Andrey Petrusenko, Jon Masamitsu, Igor Veresov Fix Verified: y Verification Testing: Ran with -XX:+PrintGCDetails and visually examined preclean/abortable preclean statistcs. Other testing: refworkload Files: update: src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp update: src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp Examined files: 3994 Contents Summary: 2 update 3992 no action (unchanged)
13-07-2007

WORK AROUND Not needed; see comments section of parent CR, and reason for dropping priority of forward port to P5 from the parent CR's P3 priority.
03-04-2007

EVALUATION see parent CR's comments section.
03-04-2007

SUGGESTED FIX see parent CR's comments section.
03-04-2007