JDK-4867172 : CMS/Train: soft refs not cleared as intended
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 5.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2003-05-21
  • Updated: 2004-06-11
  • Resolved: 2003-06-20
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
1.4.2_05 05Fixed
Description
That's because the inputs to the policy objects that decide
whether to clear soft refs are samples of heap occupancy
at major collections and these samples were not being
updated (in the case of the train and cms) until we
had a concurrent or incremental mode failure, causing
a stop-world mark-sweep collection.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_05 generic tiger FIXED IN: 1.4.2_05 tiger INTEGRATED IN: 1.4.2_05 tiger tiger-b09 VERIFIED IN: 1.4.2_05
08-07-2004
EVALUATION see suggested fix section. ###@###.### 2003-06-05: This bug affects the Orion stack, in particular S1AS deployments that choose to use CMS; it therefore makes sense to get this into the earliest possible Mantis update (i am nominating this for 1.4.2_02 by committing it to that release).
08-07-2004
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.
08-07-2004
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)
08-07-2004