SUGGESTED FIX
update heap_*_at_last_gc figures at each major cms cycle
or after each partial train collection.
Here's a more easily accessible link to the webrev of changes:
http://analemma.sfbay.sun.com/net/balvenie.sfbay/export/imgr_home/archive/main/gc_baseline/2003/20030528172906.ysr.tiger/webrev/
###@###.### 2003-05-29: Fixed in Tiger; putback to gc_baseline
on 5/28/03.
Subject: Code Manager notification (putback-to)
Date: Wed, 28 May 2003 23:34:33 -0700 (PDT)
From: "Y. S. Ramakrishna" <###@###.###>
To: ###@###.###
Event: putback-to
Parent workspace: /net/jano/export/disk05/hotspot/ws/main/gc_baseline
(jano:/export/disk05/hotspot/ws/main/gc_baseline)
Child workspace: /export/imgr_home/ws/20030528172906.ysr.tiger
(balvenie:/export/imgr_home/ws/20030528172906.ysr.tiger)
User: ysr
Comment:
Original workspace: neeraja:/net/spot/archive02/ysr/tiger
Parent workspace: /net/jano/export/disk05/hotspot/ws/main/gc_baseline
Submitter: ysr
imgr data: /net/balvenie.sfbay/export/imgr_home/archive/main/gc_baseline/2003/20030528172906.ysr.tiger
4867172 CMS/Train: soft refs not cleared as intended
Webrev: http://analemma.sfbay/net/spot/archive02/ysr/webrevs/webrev_soft
The soft ref policy objects use, as input, the heap size and
occupancy at the previous old collection to drive decisions
on soft ref clearing at the next gc. In the case of the
concurrent and incremental collectors, these values were
not being sampled except at a stop-world mark-sweep. An
unintended consequence of this might be that soft refs
may not be cleared sufficiently quickly, thus, potentially
precipitating a concurrent/incremental mode failure.
Consolidated the interface used to cache the heap
information used by the soft ref policy objects.
Reviewed by: pbk
Fix Verified: y
Verification Testing:
(1) -XX:+TraceReferenceGC and examine diagnostic output
(2) place breakpoint in policy object and examine
values used for decision
(3) VolanoTest
Other testing: (cms, train, default)
[no new regressions, but i discovered exitsing failures
which i will file a bug for.]
server refworkload (c2)
runThese -quick
runThese -testbase
runThese -regression
passed linux i486 product SPECjvm98 GeoMean 38.05 58.46
passed linux i486 product1 SPECjvm98 GeoMean 44.93 50.32
passed linux i486 productcore SPECjvm98 GeoMean 90.11 90.11
passed linux ia64 productcore SPECjvm98 GeoMean 28.87 28.87
passed solaris i486 product SPECjvm98 GeoMean 36.12 56.05
passed solaris i486 product1 SPECjvm98 GeoMean 43.25 48.66
passed solaris i486 productcore SPECjvm98 GeoMean 85.63 85.63
passed solaris sparc product SPECjvm98 GeoMean 23.22 35.03
passed solaris sparc product1 SPECjvm98 GeoMean 23.67 25.97
passed solaris sparc productcore SPECjvm98 GeoMean 38.35 38.35
passed solaris sparcv9 product SPECjvm98 GeoMean 24.06 35.35
passed solaris sparcv9 productcore SPECjvm98 GeoMean 39.54 39.54
passed windows i486 compiler2 SPECjvm98 GeoMean 48.16 103.16
passed windows i486 compiler1 SPECjvm98 GeoMean 60.33 74.66
passed windows i486 core SPECjvm98 GeoMean 127.90 127.90
passed windows ia64 core SPECjvm98 GeoMean 16.51 16.51
Files:
update: src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp
update: src/share/vm/memory/concurrentMarkSweepGeneration.cpp
update: src/share/vm/memory/genMarkSweep.cpp
update: src/share/vm/memory/trainGeneration.cpp
update: src/share/vm/memory/universe.cpp
update: src/share/vm/memory/universe.hpp
Examined files: 2727
Contents Summary:
6 update
2721 no action (unchanged)
|
WORK AROUND
-XX:SoftRefLRUPolicyMSPerMB=1 <or some suitably small number, even 0>
would mitigate the problem for GC by more eagerly clearing soft refs.
However, very eager clearing might detract from application performance
where caches used to memoize the result of previous computations
would be cleared and might require fresh computation.
|
Java