Bug ID: JDK-6468516 CMS: deal correctly with concurrently cleared or enqueued Reference objects

JDK-6468516 : CMS: deal correctly with concurrently cleared or enqueued Reference objects

Type: Bug
Component: hotspot
Sub-Component: gc
Affected Version: 6

Priority: P4
Status: Resolved
Resolution: Fixed
OS: generic
CPU: generic

Submitted: 2006-09-08
Updated: 2010-04-02
Resolved: 2006-11-14

Versions (Unresolved/Resolved/Fixed)

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	JDK 7	Other
5.0u12,hs10Fixed	6u2Fixed	7Fixed	hs10Fixed

Related Reports

Relates :	JDK-6417901 - Generalize parallel reference processing to all collectors.
Relates :	JDK-6412288 - 1.4.2_11 java_g iCMS assert(referent->is_oop(),"Adding a bad referent")")

Description

See attached test case (CMSassert.java) courtesy of Poonam (with
minor cosmetic mods by me):

% /net/jano/export/disk05/hotspot/users/ysr/testing/jdk1.6.0/bin/java -server -XX:CMSInitiatingOccupancyFraction=1 -XX:ParallelGCThreads=2 -XX:+UseConcMarkSweepGC -XX:+PrintGCDetails -XX:NewSize=10m -Xmx50m -Xms50m CMSassert

VM option 'CMSInitiatingOccupancyFraction=1'
VM option '+UseConcMarkSweepGC'
VM option '+PrintGCDetails'
VM option 'ParallelGCThreads=2'
VM option 'NewSize=10m'
[GC [ParNew: 8184K->1012K(9216K), 0.2991557 secs] 8184K->8077K(50176K), 0.3008026 secs]
[GC [1 CMS-initial-mark: 7064K(40960K)] 8203K(50176K), 0.1238431 secs]
[GC [ParNew: 9189K->1019K(9216K), 0.2955122 secs] 16254K->16160K(50176K), 0.2969500 secs]
[CMS-concurrent-mark: 1.239/1.701 secs]
[CMS-concurrent-preclean: 0.024/0.029 secs]
[GC[YG occupancy: 1667 K (9216 K)][checkpointRootsFinalWork[Rescan (parallel) , 0.0357604 secs][refProcessingWork[weak refs processing, 0.0000726 secs], 0.0003497 secs], 0.0383676 secs] [1 CMS-remark: 15140K(40960K)] 16807K(50176K), 0.0389492 secs]
[CMS-concurrent-sweep: 0.007/0.008 secs]
[CMS-concurrent-reset: 0.008/0.008 secs]
[GC [ParNew: 9211K->765K(9216K), 0.2856602 secs] 24352K->16910K(50176K), 0.2883828 secs]
[GC [1 CMS-initial-mark: 16145K(40960K)] 17011K(50176K), 0.2025471 secs]
[CMS-concurrent-mark: 0.527/0.539 secs]
[CMS-concurrent-preclean: 0.017/0.017 secs]
[GC [ParNew: 8957K->514K(9216K), 0.3672953 secs] 25102K->17310K(50176K), 0.3693416 secs]
[CMS-concurrent-abortable-preclean: 0.581/1.437 secs]
[GC[YG occupancy: 6326 K (9216 K)][checkpointRootsFinalWork[Rescan (parallel) , 1.5697082 secs][refProcessingWork[weak refs processing, 0.0067538 secs], 0.0071328 secs], 1.5783948 secs] [1 CMS-remark: 16795K(40960K)] 23122K(50176K), 1.5789165 secs]
[CMS-concurrent-sweep: 0.040/0.040 secs]
[CMS-concurrent-reset: 0.015/0.015 secs]
[GC [ParNew: 8706K->654K(9216K), 0.2982008 secs] 25390K->17337K(50176K), 0.2995237 secs]
[GC [1 CMS-initial-mark: 16683K(40960K)] 17476K(50176K), 0.2644289 secs]
[CMS-concurrent-mark: 0.611/0.611 secs]
[CMS-concurrent-preclean: 0.013/0.013 secs]
[GC [ParNew: 8846K->949K(9216K), 0.3570276 secs] 25529K->17821K(50176K), 0.3581730 secs]
[CMS-concurrent-abortable-preclean: 0.393/1.390 secs]
[GC[YG occupancy: 7760 K (9216 K)][checkpointRootsFinalWork[Rescan (parallel) , 1.7399427 secs][refProcessingWork[weak refs processing, 0.0120494 secs], 0.0125068 secs], 1.7535078 secs] [1 CMS-remark: 16871K(40960K)] 24632K(50176K), 1.7540283 secs]
[GC [ParNew: 9141K->644K(9216K), 0.3382687 secs] 25901K->17585K(50176K), 0.3394313 secs]
[CMS-concurrent-sweep: 0.129/0.470 secs]
[CMS-concurrent-reset: 0.014/0.014 secs]
[GC [ParNew: 8836K->459K(9216K), 0.2788733 secs] 25681K->17304K(50176K), 0.2800155 secs]
[GC [1 CMS-initial-mark: 16844K(40960K)] 17463K(50176K), 0.2129514 secs]
[CMS-concurrent-mark: 0.742/0.742 secs]
[CMS-concurrent-preclean: 0.011/0.011 secs]
[GC [ParNew: 8651K->667K(9216K), 0.2789957 secs] 25496K->17512K(50176K), 0.2801606 secs]
[CMS-concurrent-abortable-preclean: 0.297/1.174 secs]
[GC[YG occupancy: 7421 K (9216 K)][checkpointRootsFinalWork[Rescan (parallel) , 1.9176566 secs][refProcessingWork[weak refs processing, 0.0087822 secs]# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/referenceProcessorMT.cpp:157]
#
# An unexpected error has been detected by Java Runtime Environment:
#
#  Internal Error (/net/spot/scratch/ysr/gc_baseline/src/share/vm/memory/referenceProcessorMT.cpp, 157 [ Patched ]), pid=1845, tid=8
#
# Java VM: Java HotSpot(TM) Server VM (1.6.0-internal-debug mixed mode)
#
# Error: assert(*java_lang_ref_Reference::next_addr(obj) == 0,"The reference should not be enqueued")
# An error report file with more information is saved as hs_err_pid1845.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Current thread is 8
Dumping core ...
Abort

Comments

SUGGESTED FIX The following additional changes came about as a result of a later code review; although these are strictly not nceessary to have in a backport, it would be desirable to have them, since that would reduce difference between files and ease downstream maintenance. 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/20061019165809.ysr.mustang/workspace (prt-web:/net/prt-web.sfbay/prt-workspaces/20061019165809.ysr.mustang/workspace) User: ysr Comment: --------------------------------------------------------- Job ID: 20061019165809.ysr.mustang Original workspace: neeraja:/net/spot/scratch/ysr/mustang Submitter: ysr Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20061019165809.ysr.mustang/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20061019165809.ysr.mustang/workspace/webrevs/webrev-2006.10.19/index.html Fixed 6468516: CMS: deal correctly with concurrently cleared or enqueued Reference objects Webrev: http://analemma.sfbay/net/spot/scratch/ysr/mustang/webrev Some minor changes (no change in semantics except for removal of a redundant assert, remaining changes syntactic) based on review comments. See previous putback for details of main changes; i am merely reusing the same bug id for this putback. Reviewed by: Peter Kessler Fix Verified: yes (see previous putback) Verification Testing: Poonam's CMSAssert test Other testing: see previous putback Files: update: src/share/vm/memory/referenceProcessor.cpp update: src/share/vm/memory/referenceProcessor.hpp update: src/share/vm/memory/referenceProcessorMT.cpp Examined files: 3884 Contents Summary: 3 update 3881 no action (unchanged)
23-10-2006
WORK AROUND Don't use CMS.
12-10-2006
EVALUATION The fix has been put back to gc_baseline and is, thus, in the pipe for dolphin b03, as far as i can tell. This should probably be backported to 6u1 and 5uXX since a lot of current CMS clientele runs on 5uXX (and is apt to move to 6u1 in due course; as such subCR's on those two releases have been opened to facilitate the backport.)
08-09-2006
SUGGESTED FIX The following has been put back to gc_baseline and is, thus, in the pipe for dolphin b03, as far as i can tell. This should probably be backported to 6u1 and 5uXX since a lot of current CMS clientele runs on 5uXX (and is apt to move to 6u1 in due course; as such subCR's on those two releases have been opened to facilitate the backport.) 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/20061018110803.ysr.mustang/workspace (prt-web:/net/prt-web.sfbay/prt-workspaces/20061018110803.ysr.mustang/workspace) User: ysr Comment: --------------------------------------------------------- Job ID: 20061018110803.ysr.mustang Original workspace: karachi:/net/spot/scratch/ysr/mustang Submitter: ysr Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20061018110803.ysr.mustang/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20061018110803.ysr.mustang/workspace/webrevs/webrev-2006.10.18/index.html Fixed 6468516: CMS: deal correctly with concurrently cleared or enqueued Reference objects Webrev: http://analemma.sfbay/net/spot/scratch/ysr/mustang/webrev.6452300 CMS reference processing was not dealing correctly with the possibility of Reference objects being cleared or enqueued concurrently with the discovery process. This putback corrects that issue. [Digression: Some more fixes (as detailed in 4965777 and related bugs) remain for this to work in a completely foolproof manner. Note: 4965777 and older cousins are orthogonal to CMS or concurrent discovery. Those changes however may constitute a flag day, requiring coordinated changes in the JVM and JDK libraries, and will be made in a separate putback somewhat later in the 7.0 dev cycle (the backport of those changes to the update release train is still subject to debate, but not as part of this review).] Reviewed by: Andrey Petrusenko Fix Verified: yes Verification Testing: Poonam's CMSAssert test Other testing: CMS/PSGC fastdebug/product . refworkload . runThese -quick Files: update: src/share/vm/memory/concurrentMarkSweepGeneration.cpp update: src/share/vm/memory/referenceProcessor.cpp update: src/share/vm/memory/referenceProcessor.hpp update: src/share/vm/memory/referenceProcessorMT.cpp update: src/share/vm/memory/referenceProcessorMT.hpp Examined files: 3884 Contents Summary: 5 update 3879 no action (unchanged)
08-09-2006