JDK-6407414 : 1.4.2_11 java_g with iCMS Error: assert(_pending_decrements > 0,"can't be zero or negative")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 1.4.2_11
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: sparc
  • Submitted: 2006-04-03
  • Updated: 2010-04-02
  • Resolved: 2006-04-19
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
1.4.2_13Fixed 6 b81Fixed
Description
Customer is having problems running his application.  A run with java_g met with the following assertion.

(dbx)  where
  [1] __lwp_kill(0x0, 0x6, 0x0, 0xff33c000, 0x0, 0x0), at 0xff31e71c
  [2] raise(0x6, 0x0, 0xc7afe9f0, 0x7efefeff, 0x81010100, 0xff00), at 0xff2cd754
  [3] abort(0xc7afea98, 0xfee3624e, 0xfee3624b, 0x4d, 0x81010100, 0xff00), at 0xff2b69e8
=>[4] os::abort(dump_core = 1), line 1345 in "os_solaris.cpp"
  [5] VMError::report_and_die(this = 0xc7afec40), line 705 in "vmError.cpp"
  [6] report_assertion_failure(file_name = 0xfed38ca0 "/export1/jdk142-update/ws/fcs/hotspot/src/share/vm/runtime/concurrentMarkSweepThread.hpp", line_no = 149, message = 0xfed38cf9 "assert(_pending_decrements > 0,"can't be zero or negative")"), line 211 in "debug.cpp"
  [7] ConcurrentMarkSweepThread::asynchronous_yield_request(), line 149 in "concurrentMarkSweepThread.hpp"
  [8] ConcurrentMarkSweepThread::stop_icms(), line 271 in "concurrentMarkSweepThread.cpp"
  [9] CMSCollector::allocation_limit_reached(this = 0x10cb58, space = 0xd3930, top = 0xd02fd370, word_size = 64768U), line 899 in "concurrentMarkSweepGeneration.cpp"
  [10] ConcurrentMarkSweepGeneration::allocation_limit_reached(this = 0xe5000, space = 0xd3930, top = 0xd02fd370, word_sz = 64768U), line 953 in "concurrentMarkSweepGeneration.cpp"
  [11] DefNewGeneration::allocate(this = 0xd1f90, word_size = 64768U, is_large_noref = 0, is_tlab = 1), line 24 in "defNewGeneration.inline.hpp"
  [12] GenCollectedHeap::attempt_allocation(this = 0xd0348, size = 64768U, is_large_noref = 0, is_tlab = 1, first_only = 1), line 197 in "genCollectedHeap.cpp"
  [13] TwoGenerationCollectorPolicy::mem_allocate_work(this = 0xcfec0, size = 64768U, is_large_noref = 0, is_tlab = 1), line 172 in "collectorPolicy.cpp"
  [14] GenCollectedHeap::mem_allocate(this = 0xd0348, size = 64768U, is_large_noref = 0, is_tlab = 1), line 209 in "genCollectedHeap.cpp"
  [15] GenCollectedHeap::allocate_new_tlab(this = 0xd0348, size = 64768U), line 762 in "genCollectedHeap.cpp"
  [16] CollectedHeap::allocate_from_tlab_slow(thread = 0xaf31e8, size = 4U), line 100 in "collectedHeap.cpp"
  [17] CollectedHeap::allocate_from_tlab(thread = 0xaf31e8, size = 4U), line 134 in "collectedHeap.inline.hpp"
  [18] CollectedHeap::common_mem_allocate_noinit(size = 4U, is_noref = 0, __the_thread__ = 0xaf31e8), line 56 in "collectedHeap.inline.hpp"
  [19] CollectedHeap::common_mem_allocate_init(size = 4U, is_noref = 0, __the_thread__ = 0xaf31e8), line 79 in "collectedHeap.inline.hpp"
  [20] CollectedHeap::obj_allocate(klass = CLASS, size = 4, __the_thread__ = 0xaf31e8), line 148 in "collectedHeap.inline.hpp"
  [21] instanceKlass::allocate_instance(this = 0xeef38fa0, __the_thread__ = 0xaf31e8), line 452 in "instanceKlass.cpp"
  [22] OptoRuntime::new_C(klass = 0xeef38f98, thread = 0xaf31e8), line 173 in "runtime.cpp"
  [23] 0xf30b0a58(0xeef38f98, 0x4, 0x48c78622, 0x48c78622, 0x0, 0xcfa6afd0), at 0xf30b0a58
  [24] 0xf336bdd8(0xcfa04d50, 0x6, 0x1a, 0xd94f6dd0, 0x1, 0xc7aff480), at 0xf336bdd8
  [25] 0xf332134c(0xcfa04d30, 0xcfa04d50, 0x1, 0xfb40a000, 0xeec49444, 0xd91be878), at 0xf332134c
  [26] 0xf37a63b0(0xcfa04d30, 0xef645090, 0xcfa04280, 0xd0c14250, 0x4, 0xc7aff520), at 0xf37a63b0
  [27] 0xf348e584(0xd94ea050, 0xaf31e8, 0xeec49438, 0xef0e3510, 0xd94ea050, 0xcfa04280), at 0xf348e584
  [28] 0xf34e32c4(0xd94ffcc0, 0xcfa079f8, 0x1a, 0xd94f6dd0, 0xd0cdbd38, 0xeec55898), at 0xf34e32c4
  [29] 0xf3483b60(0xcfa04350, 0xeec49444, 0x0, 0xcfa04280, 0xeec49438, 0xaf31e8), at 0xf3483b60
  [30] 0xf348c69c(0xeec49438, 0xd0cdbd38, 0xcfa04280, 0xef5ebff8, 0xeec49438, 0x1), at 0xf348c69c
  [31] 0xf344362c(0xeec49778, 0xeec00398, 0xd9429e40, 0xeec092e8, 0x0, 0xcfa6afd0), at 0xf344362c
  [32] 0xf35d835c(0xd9429e40, 0xcfa6afd0, 0xdd, 0xd9505900, 0xd0c12980, 0x0), at 0xf35d835c
  [33] 0xf34b2e50(0xd9505ac0, 0xcfa6afd0, 0xef05ead0, 0xf3029e20, 0xc, 0xc7aff7d0), at 0xf34b2e50
  [34] 0xf35615b0(0x1, 0x1, 0xaf31e8, 0xd0c138b8, 0xcfa6afd0, 0xeec49438), at 0xf35615b0
  [35] 0xf320bb38(0xc7aff99c, 0xeec21e68, 0xf0180fdc, 0xf3025510, 0x4, 0xc7aff8a0), at 0xf320bb38
  [36] 0xf30075f0(0xc7affa14, 0xaf31e8, 0x0, 0xf302aae0, 0x4, 0xc7aff940), at 0xf30075f0
  [37] 0xf30002b8(0xc7affaa0, 0xc7affe08, 0xa, 0xeec228d0, 0x4, 0xc7aff9b8), at 0xf30002b8
  [38] JavaCalls::call_helper(result = 0xc7affe00, m = 0xc7affc60, args = 0xc7affd1c, __the_thread__ = 0xaf31e8), line 364 in "javaCalls.cpp"
  [39] os::os_exception_wrapper(f = 0xfe6bb318 = &JavaCalls::call_helper(JavaValue*,methodHandle*,JavaCallArguments*,Thread*), value = 0xc7affe00, method = 0xc7affc60, args = 0xc7affd1c, thread = 0xaf31e8), line 2757 in "os_solaris.cpp"
  [40] JavaCalls::call(result = 0xc7affe00, method = CLASS, args = 0xc7affd1c, __the_thread__ = 0xaf31e8), line 300 in "javaCalls.cpp"
  [41] JavaCalls::call_virtual(result = 0xc7affe00, spec_klass = CLASS, name = CLASS, signature = CLASS, args = 0xc7affd1c, __the_thread__ = 0xaf31e8), line 187 in "javaCalls.cpp"
  [42] JavaCalls::call_virtual(result = 0xc7affe00, receiver = CLASS, spec_klass = CLASS, name = CLASS, signature = CLASS, __the_thread__ = 0xaf31e8), line 193 in "javaCalls.cpp"
  [43] thread_entry(thread = 0xaf31e8, __the_thread__ = 0xaf31e8), line 1843 in "jvm.cpp"
  [44] JavaThread::thread_main_inner(this = 0xaf31e8), line 1187 in "thread.cpp"
  [45] JavaThread::run(this = 0xaf31e8), line 1171 in "thread.cpp"
  [46] java_start(thread_addr = 0xaf31e8), line 733 in "os_solaris.cpp"

They are also meeting with assertion with the codeBuffer.cpp(line 94) when running server compiler and and crashes in compiled code (both client and server), thats why the long command line.  Full hs_err is available.

The relevant flags are
 -ea -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxNewSize=32m -XX:NewSize=32m -Xms512m -Xmx512m -XX:SurvivorRatio=128
 -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=60 -Dsun.rmi.dgc.server.gcInterval=0x7FFFFFFFFFFFFFFE -Dsun.rmi.dgc.client.gcInterval=0x7FFFFFFFFFFFFFFE -XX:+DisableExplicitGC -XX:+UseTLAB -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing -XX:CMSIncrementalDutyCycleMin=0 -XX:CMSIncrementalDutyCycle=10 -XX:CodeCacheMinimumFreeSpace=4M -XX:ReservedCodeCacheSize=128M -XX:CompileCommand=exclude,com/opencloud/ob/capv2conductor/af,a -XX:CompileCommand=exclude,com/opencloud/ob/rhino/fs,a
Comments
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: /net/prt-web.sfbay/prt-workspaces/20060411152339.ysr.par/workspace (prt-web:/net/prt-web.sfbay/prt-workspaces/20060411152339.ysr.par/workspace) User: ysr Comment: --------------------------------------------------------- Job ID: 20060411152339.ysr.par Original workspace: neeraja:/net/spot/scratch/ysr/par Submitter: ysr Archived data: /net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20060411152339.ysr.par/ Webrev: http://analemma.sfbay.sun.com/net/prt-archiver.sfbay/data/archived_workspaces/main/gc_baseline/2006/20060411152339.ysr.par/workspace/webrevs/webrev-2006.04.11/index.html Fixed 6407414: 1.4.2_11 java_g with iCMS Error: assert(_pending_decrements > 0,"can't be zero or negative") Webrev: http://analemma.sfbay/net/spot.sfbay/scratch/ysr/par/webrev.yield The assertions were a tad too strong in that the CMS thread may already have decremented the appropriate counters (preparatory to yielding) by the time the requesting mutator came around to testing the assert following its request. This is low risk in the sense that it affects only the debug VM. Reviewed by: J. Coomes, I. Veresov, J. Masamitsu Approved by: D. Cox (zero risk) Fix verified: yes Verification testing: - icms w/ artificially widened window between yield request and assert - (ongoing) Abhijit has sent Fui-Shien a 1.4.2_13 derivative with fix for use at customer site Other testing: PRT, refworkload Files: update: src/share/vm/runtime/concurrentMarkSweepThread.hpp Examined files: 3824 Contents Summary: 1 update 3823 no action (unchanged)
12-04-2006
SUGGESTED FIX http://analemma.sfbay/net/spot/scratch/ysr/par/webrev.yield The following diffs wrt Mustang, weaken the assertions as stated in the comments section: ------- concurrentMarkSweepThread.hpp ------- 121c121 < assert(_pending_yields > 0, "can't be zero or negative"); --- > assert(_pending_yields >= 0, "can't be negative"); 132c132 < assert(_pending_decrements > 0, "can't be zero or negative"); --- > assert(_pending_decrements >= 0, "can't be negative");
10-04-2006
WORK AROUND -XX:SuppressErrorAt:concurrentMarkSweepThread.hpp:149
10-04-2006
EVALUATION The assertion is a tad too strong and should be weakened. It should have no effect in product mode execution however. The assertion will be suitably weakened in Mustang, and backported to Tiger and Mantis updates.
10-04-2006