JDK-4328741 : assert(!Scavenge::is_active() && !MarkSweep::is_active(), "locking failed")
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: 1.3.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2000-04-07
  • Updated: 2002-08-30
  • Resolved: 2002-08-30
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 Other
1.3.1 betaFixed 1.4.0Fixed
Related Reports
Relates :  
JDK-4381840 - JVM/DI CLASS_UNLOAD event is never issued
Relates :  
JDK-6453681 - AsyncGetCallTrace and CLASS_UNLOAD event reveal bad memory delete
Description

Name: icC57033			Date: 04/07/2000


The HotSpot VM 1.3.0rc2-Y both win32 and Solaris fail the test
        nsk/jvmpi/events/clsunload001
from
        testbase_nsk

To reproduce the bug run Korn shell script
        doit.ksh <jdk_root_directory>
in
        /net/sqesvr/vsn/GammaBase/Bugs/<this bug number>
Classic VM passes test.

Running in Solaris the script output:
java version "1.3.0rc2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0rc2-Y)
Java HotSpot(TM) Client VM (build 1.3.0rc2-Y, interpreted mode)
------------------------ java -------------------------------
/export/ld24/java/hotspot/jdk1.3.0/solaris/bin/java -Xrunclsunload001 clsunload001
Loading classfile clsunload001a...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
Loading classfile clsunload001b...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
######## JVMPI_EVENT_CLASS_UNLOAD ########
Loading classfile clsunload001c...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
######## JVMPI_EVENT_CLASS_UNLOAD ########
clsunload001.trygc(): java.lang.OutOfMemoryError
clsunload001.trygc(): java.lang.OutOfMemoryError
Loading classfile clsunload001a...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
Loading classfile clsunload001b...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
######## JVMPI_EVENT_CLASS_UNLOAD ########
######## JVMPI_EVENT_CLASS_UNLOAD ########
Loading classfile clsunload001c...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
######## JVMPI_EVENT_CLASS_UNLOAD ########
clsunload001.trygc(): java.lang.OutOfMemoryError
clsunload001.trygc(): java.lang.OutOfMemoryError
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
exit 95
------------------------ java_g ---------------------------------
/export/ld24/java/hotspot/jdk1.3.0/solaris/bin/java_g -Xrunclsunload001 clsunload001
Loading classfile clsunload001a...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
Loading classfile clsunload001b...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
Loading classfile clsunload001c...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
#
# HotSpot Virtual Machine Error, assertion failure
#
# assert(!Scavenge::is_active() && !MarkSweep::is_active(), "locking failed")
#
# Error happened during: scavenge
#
# Error ID: 
/usr/re/hotsparc_client1.3/ws/solsparc/hotsparc_client1.3fcs/build/solaris/../../src/share/vm/memory/gcLocker.hpp, 27 [ 
Patched ]
#
Dumping core....
./doit.ksh[53]: 4853 Abort
exit 134
------------------------ java -classic --------------------------
/export/ld24/java/hotspot/jdk1.3.0/solaris/bin/java -classic -Xrunclsunload001 clsunload001
Loading classfile clsunload001a...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
Loading classfile clsunload001b...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
Loading classfile clsunload001c...
######## JVMPI_EVENT_CLASS_UNLOAD ########
######## JVMPI_EVENT_CLASS_UNLOAD ########
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
clsunload001.trygc(): java.lang.OutOfMemoryError
clsunload001.trygc(): java.lang.OutOfMemoryError
Loading classfile clsunload001a...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
Loading classfile clsunload001b...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
Loading classfile clsunload001c...
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
######## JVMPI_EVENT_CLASS_UNLOAD ########
######## JVMPI_EVENT_CLASS_UNLOAD ########
######## JVMPI_EVENT_CLASS_UNLOAD ########
clsunload001.trygc(): java.lang.OutOfMemoryError
clsunload001.trygc(): java.lang.OutOfMemoryError
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
######## JVMPI_EVENT_CLASS_LOAD_HOOK ########
exit 95

======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: ladybird FIXED IN: ladybird INTEGRATED IN: ladybird-beta merlin-beta VERIFIED IN: ladybird-rc1 merlin-rc1
14-06-2004
EVALUATION karen.kinnear@East 2000-08-14 The problem is due to post_class_unload_event disabling GC to post the event. In this case, post_class_unload_Event is actually called during GC: MarkSweep::mark_sweep_phase1 SystemDictionary::follow_roots_phase2 - this will unload an unreachable class loader which skips sending a jvmdi event, but does post a jvmpi event. daniel.daugherty@Eng 2000-10-20 This is a good example of a JVM/PI 1.0 design problem. This event is defined to be issued with GC disabled, but the perfect time to issue a CLASS_UNLOAD event is when you are doing a GC and purging unused classes. There are a couple of possible solutions: - Do a dry-run GC that generates a list of what classes should be unloaded, issue the CLASS_UNLOAD events, and then do the real GC. A big problem is issuing a CLASS_UNLOAD event for a class that gets "marked" during the dry-run, but not actually unloaded during the real GC. - Keep track of the classes that are unloaded during the GC and issue CLASS_UNLOAD events after the GC has finished. The problem here is that keeping the "unloaded" class alive may cause problems for the other GC phases. daniel.daugherty@Eng 2000-10-23 A more refined solution is to add a cache of information that can be accessed by the CLASS_UNLOAD event handler.
23-10-2000
SUGGESTED FIX daniel.daugherty@Eng 2000-10-23 See attached webrev.tar for the changes.
23-10-2000