JDK-6266735 : intermittent extreme mutator slowdown in jbb runs with ParNew/DefNew
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.
synopsis says it all.
###@###.### 2005-05-06 20:25:06 GMT
Please see http://analemma.sfbay/net/spot/scratch/ysr/policy/webrev
###@###.### 2005-05-13 18:17:58 GMT
Parent workspace: /net/jano.sfbay/export/disk05/hotspot/ws/main/gc_baseline
Child workspace: /net/prt-web.sfbay/prt-workspaces/20050608153451.ysr.policy/workspace
Original workspace: sr1-unwk-11:/net/spot/scratch/ysr/policy
Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2005/20050608153451.ysr.policy/
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:
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
jbb2005 with ParNew was run by Brian Doherty
Other testing: PRT, refworkload
Examined files: 3277
3271 no action (unchanged)
###@###.### 2005-06-09 22:05:10 GMT