JDK-4948040 : returning out of memory when -XX:+UseConcMarkSweepGC is used.
  • Type: Bug
  • Status: Closed
  • Resolution: Fixed
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P3
  • Affected Version: 5.0
  • OS: solaris_9,windows_xp
  • CPU: x86,sparc
  • Submit Date: 2003-11-03
  • Updated Date: 2003-12-17
  • Resolved Date: 2003-12-10
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 Availabitlity Release.

To download the current JDK release, click here.
Other
1.4.2_11Resolved
Description
jdk:	   tiger-beta b26
VM:	   client/server/-d64
mode:	   -XX:+UseConcMarkSweepGC  (pass without this mode)
OS:	   Sol 9 Sparc/x86, Windows XP  was tested.

Testcase:

nsk/stress/except/except001
nsk/stress/except/except002
nsk/stress/except/except003
nsk/stress/except/except004
nsk/stress/except/except005
nsk/stress/except/except006
nsk/stress/except/except007
nsk/stress/except/except008
nsk/stress/except/except009
nsk/stress/except/except010
nsk/stress/except/except011
nsk/stress/except/except012

This testcase may also have the same problem.

nsk/stress/memory/memleak005

To reproduce
------------
 run the attached files.

  Sol_sparc :  sparc_runme.sh
  Sol_x86:     x86_runme.sh
  Winxp:       win_runme.sh  (map your y: to \\cady.sfbay\export)

Output
------

x86 and winXP
---
##
## That problem is caused by the known JDK/HotSpot bugs:
##     4239841 (P1/S5) 1.1: poor garbage collector performance
##     4245060 (P4/S5) poor garbage collector performance
##
## This message is just intended to work-around that problem.
## If printing should fail even so.
#
#Exception java.lang.OutOfMemoryError: requested 8 bytes for promotion. Out of s
wap space?


Sparc (64-bit)
-----
## While printing this message, JVM seems to initiate the output
## stream, so that it will not need more memory to print later,
## when the heap would fail to provide more memory.
## 
## That problem is caused by the known JDK/HotSpot bugs:
##     4239841 (P1/S5) 1.1: poor garbage collector performance
##     4245060 (P4/S5) poor garbage collector performance
## 
## This message is just intended to work-around that problem.
## If printing should fail even so.
#
#Exception java.lang.OutOfMemoryError: requested 16
Exception java.lang.OutOfMemoryError: requested 16 bytes for promotion. Out of swap space?


System Info
-----------

X86
---
                           Solaris 9 s9_58shwpl3 INTEL
           Copyright 2002 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                             Assembled 15 April 2002
===========
Memory size: 256 Megabytes

Sparc
-----
                        Solaris 9 4/03 s9s_u3wos_08 SPARC
           Copyright 2003 Sun Microsystems, Inc.  All Rights Reserved.
                        Use is subject to license terms.
                           Assembled 25 February 2003
===========
Memory size: 1024 Megabytes


###@###.### 2003-11-03

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: tiger-beta FIXED IN: tiger-beta INTEGRATED IN: tiger-b31 tiger-beta VERIFIED IN: tiger-beta
2004-06-14

EVALUATION see comments section.
2004-06-11

SUGGESTED FIX 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: /prt-workspaces/20031202175121.ysr.auto/workspace (prt-web:/prt-workspaces/20031202175121.ysr.auto/workspace) User: ysr Comment: --------------------------------------------------------- Original workspace: neeraja:/net/spot/archive02/ysr/auto Submitter: ysr Archived data: /net/prt-archiver.sfbay/export2/archived_workspaces/main/gc_baseline/2003/20031202175121.ysr.auto/ Webrev: http://analemma.sfbay.sun.com/net/prt-web.sfbay/prt-workspaces/20031202175121.ysr.auto/workspace/webrevs/webrev-2003.12.02/index.html Fixed: 4948040 returning out of memory when -XX:UseConcMarkSweepGC is used Fixed: 4947814 CMS: assert during mark-word restoration webrev: http://analemma.sfbay/net/spot/archive02/ysr/auto/webrev description: ----------- 4948040: we were not correctly accounting for the worst-case "expansion" when promoting into the CMS generation, where the minimum block size is 3 HeapWords (at least), from a contiguous young generation where the minimum object size is 2 HeapWords. This also brought to light an unbounded recursion problem when CMSIndexedFreeListReplesnish is 1. Fixed the CMS initiating criteria to correctly use the automatic pacing feature, by tuning CMSTriggerRatio upwards (so as to obtain a nominal initiating occupancy of 92%) and using an occupancy threshold of 50% to trigger a collection that helps bootstrap the CMS automatic pacing statistics. The flags may need further tuning to work well across a range of platforms and applications. 4947814: There was a bug in the handling of the blocks used for spooling non-prototypical mark-words when we are temporarily out of scratch space in the CMS generation. Our fix uses a new splice point field which remembers the tail of an active list where a new buffer can be added when available as a result of expanding the generation. Reviewed by: John Coomes, Jon Masamitsu Approved by: Jerry Driscoll Verification testing: . test in 4948040 with -XX:+/-HandlePromotionFailure . GCBasher -d64 for several days, debug & product Other testing: . spec . refworkload . volanotest . tomcat Files: update: src/share/vm/memory/compactibleFreeListSpace.cpp update: src/share/vm/memory/compactibleFreeListSpace.hpp update: src/share/vm/memory/concurrentMarkSweepGeneration.cpp update: src/share/vm/memory/concurrentMarkSweepGeneration.hpp update: src/share/vm/memory/specialized_oop_closures.hpp update: src/share/vm/runtime/globals.hpp Examined files: 3013 Contents Summary: 6 update 3007 no action (unchanged)
2004-06-11