United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6407414 1.4.2_11 java_g with iCMS Error: assert(_pending_decrements > 0,"can't be zero or negative")
JDK-6407414 : 1.4.2_11 java_g with iCMS Error: assert(_pending_decrements > 0,"can't be zero or negative")

Details
Type:
Bug
Submit Date:
2006-04-03
Status:
Resolved
Updated Date:
2010-04-02
Project Name:
JDK
Resolved Date:
2006-04-19
Component:
hotspot
OS:
solaris
Sub-Component:
gc
CPU:
sparc
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.2_11
Fixed Versions:

Related Reports
Backport:
Backport:

Sub Tasks

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
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.
                                     
2006-04-10
WORK AROUND

-XX:SuppressErrorAt:concurrentMarkSweepThread.hpp:149
                                     
2006-04-10
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");
                                     
2006-04-10
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)
                                     
2006-04-12



Hardware and Software, Engineered to Work Together