JDK-6432517 : Policy missing in GC parallel reference processing
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2006-05-31
  • Updated: 2010-04-02
  • Resolved: 2006-06-14
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
5.0u10Fixed 6 b88Fixed
Description
A policy for soft references is not being set for the case of
parallel reference processing.

Comments
WORK AROUND Do not use parallel reference processing: -XX:-ParallelRefProcEnabled
09-06-2006

SUGGESTED FIX The following changes have been putback (targeted to Mustang/b88): 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/20060605140043.ysr.par/workspace (prt-web:/net/prt-web.sfbay/prt-workspaces/20060605140043.ysr.par/workspace) User: ysr Comment: --------------------------------------------------------- Job ID: 20060605140043.ysr.par Original workspace: sr1-usca-01:/net/spot/scratch/ysr/par Submitter: ysr Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20060605140043.ysr.par/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20060605140043.ysr.par/workspace/webrevs/webrev-2006.06.05/index.html Fixed 6432517: Policy missing in GC parallel reference processing Webrev: http://analemma.sfbay/net/spot/scratch/ysr/par/webrev The parallel reference processing code was not initializing the _policy field in the ReferenceProcessorParallel object, which was leading inadvertently to the premature immediate clearing of SoftReferences whenever +ParallelRefProcEnabled. Thanks to andreins at http://forum.java.sun.com/thread.jspa?threadID=726854&tstart=0 for noticing this problem and providing a test case, and to Jon for diagnosing the problem. Reviewed by: Tony Printezis, Jon Masamitsu Approved by: Azar Nohadani (Mustang Core Team) Fix Verified: yes Verification Testing: . the GCSoftRefDemo test in the bug report run with java -server/-client -XX:+UseConcMarkSweepGC \ -XX:+ParallelRefProcEnabled -XX:+PrintGCDetails \ -XX:CMSInitiatingOccupancyFraction=1 -Xmx6m \ -XX:NewSize=4m -XX:MaxNewSize=4m GCSoftRefDemo Other testing: The following with +ParallelRefProcEnabled (note that as of today +ParallelRefProcEnabled is a no-op for all but CMS; this is being extended to all collectors by Andrey for Dolphin): . PRT . refworkload Files: update: src/share/vm/memory/concurrentMarkSweepGeneration.cpp update: src/share/vm/memory/referenceProcessorMT.hpp Examined files: 3845 Contents Summary: 2 update 3843 no action (unchanged)
05-06-2006

EVALUATION See suggested fix section. This should be fixed in Mustang b88 and in Tiger 5u9.
01-06-2006

SUGGESTED FIX ------- concurrentMarkSweepGeneration.cpp ------- 5461c5461 < ReferenceProcessorParallel parallel_rp(rp, &rp_task); --- > ReferenceProcessorParallel parallel_rp(rp, soft_ref_policy, &rp_task); neeraja-63% sccs diffs referenceProcessorMT.hpp ------- referenceProcessorMT.hpp ------- 117c117 < ReferenceProcessorParallel(ReferenceProcessorMT* rp, --- > ReferenceProcessorParallel(ReferenceProcessorMT* rp, ReferencePolicy* policy, 121a122 > rp->_policy = policy;
01-06-2006