JDK-6266735 : intermittent extreme mutator slowdown in jbb runs with ParNew/DefNew
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0u4,6
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris
  • CPU: generic,sparc
  • Submitted: 2005-05-06
  • Updated: 2011-12-27
  • Resolved: 2005-08-16
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 JDK 6
1.4.2_13Fixed 6 b43Fixed
Related Reports
Duplicate :  
JDK-6430367 - CMS - Application hang with 100% CPU
Relates :  
JDK-6261660 - CMS promotion failure & gc_locker induced GC malinteraction
Description
synopsis says it all.

###@###.### 2005-05-06 20:25:06 GMT
Comments
SUGGESTED FIX Please see http://analemma.sfbay/net/spot/scratch/ysr/policy/webrev ###@###.### 2005-05-13 18:17:58 GMT Event: putback-to Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/main/gc_baseline (jano.sfbay:/export/disk05/hotspot/ws/main/gc_baseline) Child workspace: /net/prt-web.sfbay/prt-workspaces/20050608153451.ysr.policy/workspace (prt-web:/net/prt-web.sfbay/prt-workspaces/20050608153451.ysr.policy/workspace) User: ysr Comment: --------------------------------------------------------- Original workspace: sr1-unwk-11:/net/spot/scratch/ysr/policy Submitter: ysr Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2005/20050608153451.ysr.policy/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2005/20050608153451.ysr.policy/workspace/webrevs/webrev-2005.06.08/index.html Fixed 6266375: intermittent extreme mutator slowdown in jbb runs with ParNew/DefNew This was a day-one policy bug that was unmasked recently because of enabling PromotionFailureHandling in Parnew/DefNew. Many thanks to Brian Doherty for drawing our attention to this problem, doing several test runs and collecting additional information to help with the diagnosis, and for verifying the fixes. There were two problems -- when an incremental collection was about to fail (because the expected promotion out of the young gen would exceed the available free space in the old gen): . we would start allocating slow path (via the runtime with the heap lock held) from the survivor space until we exhausted the survivor space, and, . worse, we would then attempt a safepoint for the purpose of collecting the old gen, but then decide to allocate space from the old gen and skip the collection (we call this very slow path allocation). The above are fine policies if we are truly running out of space and are trying to limp along in a highly heap-constrained setting. But they are not OK when all we need to do is a complete collection in order to empty old gen and start allocating full speed again. The fix was to take recourse to allocation out of from space and from old gen in the slow path when we think we are out of space, and never do any allocation in the very slow path (except following a gc). Details in the webrev: http://analemma.sfbay/net/spot/scratch/ysr/policy/webrev Some further interactions (not new) with resizing policy and with gc locker induced GC are covered by a separate bug and will be handled separately. Reviewed by: Jon Masamitsu Fix Verified: yes Verification Testing: jbb2005 with ParNew was run by Brian Doherty Other testing: PRT, refworkload Files: update: src/share/vm/includeDB_core update: src/share/vm/memory/collectorPolicy.cpp update: src/share/vm/memory/defNewGeneration.cpp update: src/share/vm/memory/defNewGeneration.hpp update: src/share/vm/memory/genCollectedHeap.cpp update: src/share/vm/memory/genCollectedHeap.hpp Examined files: 3277 Contents Summary: 6 update 3271 no action (unchanged) ###@###.### 2005-06-09 22:05:10 GMT
13-05-2005
EVALUATION see comments section. ###@###.### 2005-05-19 01:22:14 GMT ###@###.### 2005-05-24 00:48:28 GMT
06-05-2005