JDK-6200138 : hs101t004 fails assert(unloading_occurred,"should not reach here if no classes got unloaded")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 5.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: sparc
  • Submitted: 2004-11-24
  • Updated: 2010-04-02
  • Resolved: 2005-03-02
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
5.0u4Fixed 6 b26Fixed
Description
If the hs101t004.java NSK test is modified to call System.gc() during
its processing loop, then the jvmg VM will fail an assertion.

------- hs101t004.java -------
*** /tmp/sccs.QBaiGt	Wed Nov 24 11:55:45 2004
--- hs101t004.java	Wed Nov 24 11:37:03 2004
***************
*** 94,99 ****
--- 94,100 ----
          try {
              for (i = 0; flag && (i < numbers.length); i++) {
                  numbers[i] = ackermann(3, i);
+ System.gc();
              }
          } catch (StackOverflowError e) {
              // ignore

java version "1.5.0_02-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-ea-b03)
Java HotSpot(TM) Client VM (build post_tiger-jvmg-debug, mixed mode)
/net/producer/export3/dcubed/work/jdk/1.5.0-sparc/bin/java_g -XX:-PrintVMOptions -XX:CompileOnly=nsk -Xss2m -client-test -agentlib:HotSwap=-waittime=2\ package=nsk\ samples=100\ mode=compiled\ bci=call nsk.jvmti.scenarios.hotswap.HS101.hs101t004
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/nmethod.cpp:836]
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  Internal Error (/export3/dcubed/work/build/post_tiger/src_ws/src/share/vm/code/nmethod.cpp, 836 [ Patched ]), pid=9944, tid=2
#
# Java VM: Java HotSpot(TM) Client VM (post_tiger-jvmg-debug mixed mode)
#
# Error: assert(unloading_occurred,"should not reach here if no classes got unloaded")
# An error report file with more information is saved as hs_err_pid9944.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Current thread is 2
Dumping core ...
doit.ksh[86]: 9944 Abort(coredump)
status=134
Comments
SUGGESTED FIX Here are the context diffs for the proposed fix: ------- src/share/vm/code/nmethod.cpp ------- *** /tmp/sccs.lBaiNd Wed Nov 24 16:51:57 2004 --- nmethod.cpp Wed Nov 24 16:18:59 2004 *************** *** 914,919 **** --- 914,936 ---- // (See comment above.) } + // RedefineClasses() can rewrite the bytecodes in a method which + // causes a new methodOop to be created. The old methodOop is + // eventually GC'ed and, since we are here, that old methodOop is + // associated with an nmethod. In the regular system, the + // unloading_occurred flag indicates that a class was unloaded + // and we sanity check that follow_root_or_mark_for_unloading(). + // With RedefineClasses() that flag also needs to be set when the + // method holder has been redefined. + bool klass_was_redefined = // leave a debugging breadcrumb in local flag + instanceKlass::cast(method()->method_holder())->is_rewritten_by_redefine(); + if (klass_was_redefined) { + // This set of the unloading_occurred flag is done before the + // call to post_compiled_method_unload() so that the unloading + // of this nmethod is reported. + unloading_occurred = true; + } + if (unloading_occurred) { post_compiled_method_unload(is_alive); } ###@###.### 2004-11-25 00:55:45 GMT The above fix was revised and will be included in a batch of JFluid/RedefineClasses fixes targeted for a Tiger-Update release. See the jfluid-merge-update4-full-webrev.tar.Z attachment in 5088035 for the complete set of changes. ###@###.### 2005-2-25 22:38:19 GMT
25-11-2004
EVALUATION follow_roots_or_mark_for_unloading() needs to recognize when JVM/TI RedefineClasses() has rewritten a compiled method. That is another situation in which a methodOop can be unloaded. ###@###.### 2004-11-25 00:55:45 GMT
25-11-2004