JDK-8042796 : jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs25,8u60,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2014-02-05
  • Updated: 2017-08-17
  • Resolved: 2014-05-16
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.
JDK 8 JDK 9
8u60Fixed 9 b15Fixed
Related Reports
Relates :  
JDK-8068162 - jvmtiRedefineClasses.cpp: guarantee(false) failed: OLD and/or OBSOLETE method(s) found
Relates :  
JDK-8048185 - [TESTBUG] need a JTREG test for the fix of JDK-8042796 (OLD and/or OBSOLETE method(s) found)
Description
#  Internal Error (/opt/jprt/T/P1/183545.vkozlov/s/src/share/vm/prims/jvmtiRedefineClasses.cpp:3598), pid=24710, tid=5
#  guarantee(false) failed: OLD and/or OBSOLETE method(s) found

V  [libjvm.so+0x292c304]  void VMError::report(outputStream*)+0x92c;;  __1cHVMErrorGreport6MpnMoutputStream__v_+0x92c
V  [libjvm.so+0x292d84d]  void VMError::report_and_die()+0x579;;  __1cHVMErrorOreport_and_die6M_v_+0x579
V  [libjvm.so+0x1002147]  void report_vm_error(const char*,int,const char*,const char*)+0x55f;;  __1cPreport_vm_error6Fpkci11_v_+0x55f
V  [libjvm.so+0x1ce8f33]  void VM_RedefineClasses::CheckClass::do_klass(Klass*)+0x337;;  __1cSVM_RedefineClassesKCheckClassIdo_klass6MpnFKlass__v_+0x337
V  [libjvm.so+0xe19cf5]  void ClassLoaderDataGraph::classes_do(KlassClosure*)+0x55;;  __1cUClassLoaderDataGraphKclasses_do6FpnMKlassClosure__v_+0x55
V  [libjvm.so+0x1cbc850]  void VM_RedefineClasses::doit()+0x3e0;;  __1cSVM_RedefineClassesEdoit6M_v_+0x3e0
V  [libjvm.so+0x295d630]  void VM_Operation::evaluate()+0x114;;  __1cMVM_OperationIevaluate6M_v_+0x114
V  [libjvm.so+0x2959ad0]  void VMThread::evaluate_operation(VM_Operation*)+0x1fc;;  __1cIVMThreadSevaluate_operation6MpnMVM_Operation__v_+0x1fc
V  [libjvm.so+0x295a7b4]  void VMThread::loop()+0x870;;  __1cIVMThreadEloop6M_v_+0x870
V  [libjvm.so+0x29595b6]  void VMThread::run()+0xb6;;  __1cIVMThreadDrun6M_v_+0xb6
V  [libjvm.so+0x22f7b56]  java_start+0x1ce;;  java_start+0x1ce
C  [libc.so.1+0x121555]  _thrp_setup+0xa5;;  _thrp_setup+0xa5
C  [libc.so.1+0x121800]  _lwp_start+0x0;;  _lwp_start+0x0

# JRE version: Java(TM) SE Runtime Environment (8.0-b126) (build 1.8.0-fastdebug-b126)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b62-internal-201401291835.vkozlov.8033117-fastdebug compiled mode solaris-amd64 )

It starts to fail after PPC64 integration.
Comments
Added 8u60 to the "Affected Versions". This backport is necessary to make the 8046246 backport applied cleanly. It is also nice to fix this issue in 8u60 by itself.
17-03-2015
The failing guarantee was added by the following fix: https://bugs.openjdk.java.net/browse/JDK-7182152 changeset: 4127:8d9fc28831cc parent: 4094:f3ea1af9207a user: dcubed date: Wed Feb 06 14:31:37 2013 -0800 summary: 7182152: Instrumentation hot swap test incorrect monitor count I have a concern about its full correctness. It seems that it needs to be relaxed for the deleted methods.
09-05-2014
Thanks, Kirill! I've moved the issue back to hotspot/jvmti and re-assigned it to myself. The suggested fix is: diff -r 21130eb5768d src/share/vm/oops/cpCache.cpp --- a/src/share/vm/oops/cpCache.cpp Tue May 06 09:56:55 2014 -0400 +++ b/src/share/vm/oops/cpCache.cpp Fri May 09 02:52:11 2014 -0700 @@ -496,9 +496,10 @@ bool ConstantPoolCacheEntry::check_no_ol // _f1 == NULL || !_f1->is_method() are OK here return true; } - // return false if _f1 refers to an old or an obsolete method + // return false if _f1 refers to a non-deleted old or obsolete method return (NOT_PRODUCT(_f1->is_valid() &&) _f1->is_method() && - !((Method*)_f1)->is_old() && !((Method*)_f1)->is_obsolete()); + (!f1_as_method()->is_old() && !f1_as_method()->is_obsolete() || + f1_as_method()->is_deleted())); } bool ConstantPoolCacheEntry::is_interesting_method_entry(Klass* k) { diff -r 21130eb5768d src/share/vm/oops/method.hpp --- a/src/share/vm/oops/method.hpp Tue May 06 09:56:55 2014 -0400 +++ b/src/share/vm/oops/method.hpp Fri May 09 02:52:11 2014 -0700 @@ -669,6 +669,8 @@ class Method : public Metadata { void set_is_old() { _access_flags.set_is_old(); } bool is_obsolete() const { return access_flags().is_obsolete(); } void set_is_obsolete() { _access_flags.set_is_obsolete(); } + bool is_deleted() const { return access_flags().is_deleted(); } + void set_is_deleted() { _access_flags.set_is_deleted(); } bool on_stack() const { return access_flags().on_stack(); } void set_on_stack(const bool value); diff -r 21130eb5768d src/share/vm/prims/jvmtiRedefineClasses.cpp --- a/src/share/vm/prims/jvmtiRedefineClasses.cpp Tue May 06 09:56:55 2014 -0400 +++ b/src/share/vm/prims/jvmtiRedefineClasses.cpp Fri May 09 02:52:11 2014 -0700 @@ -2966,7 +2966,8 @@ void VM_RedefineClasses::check_methods_a assert(!old_method->has_vtable_index(), "cannot delete methods with vtable entries");; - // Mark all deleted methods as old and obsolete + // Mark all deleted methods as old, obsolete and deleted + old_method->set_is_deleted(); old_method->set_is_old(); old_method->set_is_obsolete(); ++obsolete_count; @@ -3572,7 +3573,7 @@ void VM_RedefineClasses::CheckClass::do_ no_old_methods = false; } - // the constant pool cache should never contain old or obsolete methods + // the constant pool cache should never contain non-deleted old or obsolete methods if (ik->constants() != NULL && ik->constants()->cache() != NULL && !ik->constants()->cache()->check_no_old_or_obsolete_entries()) { diff -r 21130eb5768d src/share/vm/utilities/accessFlags.hpp --- a/src/share/vm/utilities/accessFlags.hpp Tue May 06 09:56:55 2014 -0400 +++ b/src/share/vm/utilities/accessFlags.hpp Fri May 09 02:52:11 2014 -0700 @@ -55,6 +55,7 @@ enum { JVM_ACC_IS_OBSOLETE = 0x00020000, // RedefineClasses() has made method obsolete JVM_ACC_IS_PREFIXED_NATIVE = 0x00040000, // JVMTI has prefixed this native method JVM_ACC_ON_STACK = 0x00080000, // RedefinedClasses() is used on the stack + JVM_ACC_IS_DELETED = 0x00008000, // RedefineClasses() has deleted this method // Klass* flags JVM_ACC_HAS_MIRANDA_METHODS = 0x10000000, // True if this class has miranda methods in it's vtable @@ -131,6 +132,7 @@ class AccessFlags VALUE_OBJ_CLASS_SPEC { bool has_jsrs () const { return (_flags & JVM_ACC_HAS_JSRS ) != 0; } bool is_old () const { return (_flags & JVM_ACC_IS_OLD ) != 0; } bool is_obsolete () const { return (_flags & JVM_ACC_IS_OBSOLETE ) != 0; } + bool is_deleted () const { return (_flags & JVM_ACC_IS_DELETED ) != 0; } bool is_prefixed_native () const { return (_flags & JVM_ACC_IS_PREFIXED_NATIVE ) != 0; } // Klass* flags @@ -195,6 +197,7 @@ class AccessFlags VALUE_OBJ_CLASS_SPEC { void set_has_jsrs() { atomic_set_bits(JVM_ACC_HAS_JSRS); } void set_is_old() { atomic_set_bits(JVM_ACC_IS_OLD); } void set_is_obsolete() { atomic_set_bits(JVM_ACC_IS_OBSOLETE); } + void set_is_deleted() { atomic_set_bits(JVM_ACC_IS_DELETED); } void set_is_prefixed_native() { atomic_set_bits(JVM_ACC_IS_PREFIXED_NATIVE); } void clear_not_c1_compilable() { atomic_clear_bits(JVM_ACC_NOT_C1_COMPILABLE); }
09-05-2014
One more detail to the puzzle... The Aurora copy of the SQE testbase has inconsistency between the original and redefined version of the class INDIFY_Dummy0. The original (non-redefined) class has these 3 methods in the class file (the redefined class does not): MT_bootstrap(), MH_bootstrap(), INDY_call() : % /net/sc11152541/export/home/sspitsyn/hs25/hsx1/solaris-sparcv9/bin/javap -private -classpath /net/aurora-ds.us.oracle.com/data/export/aurora/sca/vmsqe/testbase/vm/9/build/execution/vm/bin/classes vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0 Compiled from "INDIFY_Dummy0.java" public class vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0 { private static java.lang.invoke.MethodHandle INDY_call; public vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0(); private static java.lang.invoke.MethodType MT_bootstrap(); private static java.lang.invoke.MethodHandle MH_bootstrap() throws java.lang.NoSuchMethodException, java.lang.IllegalAccessException; public static java.lang.invoke.CallSite bootstrap(java.lang.invoke.MethodHandles$Lookup, java.lang.String, java.lang.invoke.MethodType) throws java.lang.Throwable; public static java.lang.Boolean target(java.lang.Object, java.lang.String, int); public static void redefineNow(); private static java.lang.invoke.MethodHandle INDY_call() throws java.lang.Throwable; public static boolean invokeTarget() throws java.lang.Throwable; private static boolean invokeTarget0() throws java.lang.Throwable; public static boolean isRedefinedClass(); } The most strange detail is that in my own SQE testbase build both the original class file and the redefined miss these 3 methods: % /net/sc11152541/export/home/sspitsyn/hs25/hsx1/solaris-sparcv9/bin/javap -private -classpath /net/sc11152541/export/home/sspitsyn/utb9/vm/bin/classes vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0 Compiled from "INDIFY_Dummy0.java" public class vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0 { private static java.lang.invoke.MethodHandle INDY_call; public vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0(); public static java.lang.invoke.CallSite bootstrap(java.lang.invoke.MethodHandles$Lookup, java.lang.String, java.lang.invoke.MethodType) throws java.lang.Throwable; public static java.lang.Boolean target(java.lang.Object, java.lang.String, int); public static void redefineNow(); public static boolean invokeTarget() throws java.lang.Throwable; private static boolean invokeTarget0() throws java.lang.Throwable; public static boolean isRedefinedClass(); } % /net/sc11152541/export/home/sspitsyn/hs25/hsx1/solaris-sparcv9/bin/javap -private -classpath /net/sc11152541/export/home/sspitsyn/utb9/vm/bin/newclass vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0 Compiled from "INDIFY_Dummy0.java" public class vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0 { private static java.lang.invoke.MethodHandle INDY_call; public vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0(); public static java.lang.invoke.CallSite bootstrap(java.lang.invoke.MethodHandles$Lookup, java.lang.String, java.lang.invoke.MethodType) throws java.lang.Throwable; public static java.lang.Boolean target(java.lang.Object, java.lang.String, int); public static void redefineNow(); public static boolean invokeTarget() throws java.lang.Throwable; private static boolean invokeTarget0() throws java.lang.Throwable; public static boolean isRedefinedClass(); } It looks to me, the SQE testbase needs to be rebuilt and reinstalled to the Aurora location. Probably, the new cat/sub-cat are not fully correct as it needs to reflect the SQE infrastructure area. But I leave it to the VM SQE engineers. Kirill, I temporarily assigned this issue to you as you are the author of these tests. Could you, please, take a look what is wrong with the class files preparation? Also, please, re-assign it back to me as there is still issue on the JVMTI side. We may need to create another bug for the SQE infrastructure issue. However, I hope, it will be resolved automatically after the new SQE testbase release deployment.
06-05-2014
A part of this issue is still on the hotspot/jvmti side. If a class redefinition deletes some private methods from the class then only one of the invariants must be true: 1. The removed methods should not be present in the constant pool cache 2. The guarantee in the VM_RedefineClasses::CheckClass::do_klass() must be relaxed: 3614 guarantee(false, "OLD and/or OBSOLETE method(s) found");
06-05-2014
Ok, it seems, these 3 methods are deleted by the indify-tool. I've found the following fragment in my SQE testbase build log: indify-tool: [echo] Indify: /net/sc11152541/export/home/sspitsyn/utb9/vm/bin/pre-indify/newclass/vm/mlvm/indy/func/jvmti/mergeCP_indy2manyDiff_a/INDIFY_Dummy0.class -> /net/sc11152541/export/home/sspitsyn/utb9/vm/bin/pre-sde/newclass/vm/mlvm/indy/func/jvmti/mergeCP_indy2manyDiff_a/INDIFY_Dummy0.class [java] patching vm/mlvm/indy/func/jvmti/mergeCP_indy2manyDiff_a/INDIFY_Dummy0.invokeTarget0()Z [java] 15:invokestatic 46 INDY_call()L;...; 21:invokevirtual 47 => invokedynamic 172:InvokeDynamic[0, 170] [java] 29:invokestatic 46 INDY_call()L;...; 35:invokevirtual 47 => invokedynamic 172:InvokeDynamic[0, 170] [java] 75:invokestatic 46 INDY_call()L;...; 81:invokevirtual 47 => invokedynamic 172:InvokeDynamic[0, 170] [java] 90:invokestatic 46 INDY_call()L;...; 96:invokevirtual 47 => invokedynamic 172:InvokeDynamic[0, 170] [java] 105:invokestatic 46 INDY_call()L;...; 111:invokevirtual 47 => invokedynamic 172:InvokeDynamic[0, 170] [java] pattern methods removed: [MT_bootstrap()L, INDY_call()L, MH_bootstrap()L] [java] wrote /net/sc11152541/export/home/sspitsyn/utb9/vm/bin/pre-sde/newclass/vm/mlvm/indy/func/jvmti/mergeCP_indy2manyDiff_a/INDIFY_Dummy0.class I guess, the indify-tool must be used consistently to equally indify both the original and redefined class files, so that, both versions have these 3 methods removed: MT_bootstrap(), INDY_call(), MH_bootstrap()
06-05-2014
Something is wrong with the aurora copy of the testbase build as the source and binary of the newclass/INDIFY_Dummy0.java do not match: The javap shows just 7 methods in the newclass/ class file /INDIFY_Dummy0.class from the build: INDIFY_Dummy0(), bootstrap(), target(), redefineNow(), invokeTarget(), invokeTarget0(), isRedefinedClass() : % /net/sc11152541/export/home/sspitsyn/hs25/hsx1/solaris-sparcv9/bin/javap -private \ ? -classpath /net/aurora-ds.us.oracle.com/data/export/aurora/sca/vmsqe/testbase/vm/9/build/execution/vm/bin/newclass \ ? vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0 Compiled from "INDIFY_Dummy0.java" public class vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0 { private static java.lang.invoke.MethodHandle INDY_call; public vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a.INDIFY_Dummy0(); public static java.lang.invoke.CallSite bootstrap(java.lang.invoke.MethodHandles$Lookup, java.lang.String, java.lang.invoke.MethodType) throws java.lang.Throwable; public static java.lang.Boolean target(java.lang.Object, java.lang.String, int); public static void redefineNow(); public static boolean invokeTarget() throws java.lang.Throwable; private static boolean invokeTarget0() throws java.lang.Throwable; public static boolean isRedefinedClass(); } However, the source file newclass/INDIFY_Dummy0.java cached in the test working directory should have 10 methods: MT_bootstrap(), MH_bootstrap(), INDY_call(), INDIFY_Dummy0(), redefinenow(), invokeTarget(), invokeTarget0(), bootstrap(), target(), isRedefinedClass(): cat -n /net/sc11152541.us/export/home/sspitsyn/bug/8033684/v9/ResultDir/mergeCP_indy2manyDiff_a/newclass/INDIFY_Dummy0.java 1 package vm.mlvm.indy.func.jvmti.mergeCP_indy2manyDiff_a; 2 3 import java.lang.invoke.CallSite; 4 import java.lang.invoke.ConstantCallSite; 5 import java.lang.invoke.MethodHandle; 6 import java.lang.invoke.MethodHandles; 7 import java.lang.invoke.MethodType; 8 9 import vm.mlvm.share.MlvmTest; 10 11 public class INDIFY_Dummy0 { 12 13 private static MethodType MT_bootstrap() { 14 return MethodType.methodType(CallSite.class, MethodHandles.Lookup.class, String.class, MethodType.class); 15 } 16 17 private static MethodHandle MH_bootstrap() throws NoSuchMethodException, IllegalAccessException { 18 return MethodHandles.lookup().findStatic( 19 INDIFY_Dummy0.class, 20 "bootstrap", 21 MT_bootstrap()); 22 } 23 24 public static CallSite bootstrap(MethodHandles.Lookup l, String name, MethodType mt) throws Throwable { 25 MlvmTest.getLog().display("Redefined bootstrap(): Lookup " + l + "; method name = " + name + "; method type = " + mt); 26 CallSite cs = new ConstantCallSite(l.findStatic(INDIFY_Dummy0.class, "target", mt)); 27 return cs; 28 } 29 30 public static Boolean target(Object o, String s, int i) { 31 MlvmTest.getLog().display("Redefined target called! Object = " + o + "; string = " + s + "; int = " + i); 32 MlvmTest.getLog().display("The rest of methods are from " + (isRedefinedClass() ? "redefined" : "original") + " class"); 33 return true; 34 } 35 36 public static void redefineNow() {} 37 38 private static MethodHandle INDY_call; 39 private static MethodHandle INDY_call() throws Throwable { 40 if (INDY_call != null) 41 return INDY_call; 42 43 CallSite cs = (CallSite) MH_bootstrap().invokeWithArguments( 44 MethodHandles.lookup(), 45 "greet", 46 MethodType.methodType(Boolean.class, Object.class, String.class, int.class)); 47 48 return cs.dynamicInvoker(); 49 } 50 51 public static boolean invokeTarget() throws Throwable { 52 return invokeTarget0(); 53 } 54 55 private static boolean invokeTarget0() throws Throwable { 56 Object o = new Object(); 57 String s = "Redefined"; 58 int i = 456; 59 boolean b = (Boolean) INDY_call().invokeExact(o, s, i); 60 b ^= (Boolean) INDY_call().invokeExact(o, s, i); 61 o = new Object(); 62 s = s + s; 63 i = i + i; 64 b ^= (Boolean) INDY_call().invokeExact(o, s, i); 65 b ^= (Boolean) INDY_call().invokeExact(o, s, i); 66 b ^= (Boolean) INDY_call().invokeExact(o, s, i); 67 return b; 68 } 69 70 public static boolean isRedefinedClass() { 71 return true; 72 } 73 } As we can see these 3 methods are missed in the class file from the build: MT_bootstrap(), MH_bootstrap(), INDY_call() It is why these 3 methods are marked as deleted after class redefinition which is wrong.
06-05-2014
I'm moving this bug to the qe_test/hotspot category/sub-category and requesting the SQE guys to take a look and check what is going on with the Aurora copy of the SQE testbase. Please, feel free to move this bug back to the development if the SQE infrastructure is Ok and the artifact above can be somehow explained.
06-05-2014
Ok, the difference is in the testbase build that is used. When I run with the short name 'ute' then it is defaulted to one of the old VM testbase builds. The option -testbase /net/aurora-ds.us.oracle.com/data/export/aurora/sca/vmsqe/testbase/vm/9/build/execution/vm forces to use the same testbase build as used in the nightly.
03-05-2014
Thanks, Vladimir! It helped to reproduce the issue. Now I wonder, what is the difference? Will try to discover.
02-05-2014
The command I'm using to run the tests: Latest JDK promoted build: % ute -component vm -testlist ./my.testlist -tlists empty -bits d64 \ -vmopts '-server -Xcomp -ea -esa -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:-TieredCompilation -XX:CompileThreshold=100' \ -vmopts '-XX:+UnlockExperimentalVMOptions -XX:+AggressiveOpts -XX:-UseCompressedOops -XX:TraceRedefineClasses=16384' \ -jdk /java/re/jdk/1.8.0/promoted/latest/binaries/solaris-amd64/fastdebug Latest JDK 9 promoted build: % ute -component vm -testlist ./my.testlist -tlists empty -bits d64 \ -vmopts '-server -Xcomp -ea -esa -XX:MaxRAMFraction=8 -XX:+CreateMinidumpOnCrash -XX:-TieredCompilation -XX:CompileThreshold=100' \ -vmopts '-XX:+UnlockExperimentalVMOptions -XX:+AggressiveOpts -XX:-UseCompressedOops -XX:TraceRedefineClasses=16384' \ -jdk /java/re/jdk/1.9.0/promoted/latest/binaries/solaris-amd64/fastdebug % cat ./my.testlist vm/mlvm/indy/func/jvmti/redefineClassInBootstrap execute_positive vm/mlvm/indy/func/jvmti/redefineClassInTarget execute_positive vm/mlvm/indy/func/jvmti/mergeCP_none2indy_a execute_positive vm/mlvm/indy/func/jvmti/mergeCP_none2indy_b execute_positive vm/mlvm/indy/func/jvmti/mergeCP_indy2none_a execute_positive vm/mlvm/indy/func/jvmti/mergeCP_indy2none_b execute_positive vm/mlvm/indy/func/jvmti/mergeCP_indy2same_a execute_positive vm/mlvm/indy/func/jvmti/mergeCP_indy2same_b execute_positive vm/mlvm/indy/func/jvmti/mergeCP_indy2manyDiff_a execute_positive vm/mlvm/indy/func/jvmti/mergeCP_indy2manyDiff_b execute_positive vm/mlvm/indy/func/jvmti/mergeCP_indy2manySame_a execute_positive vm/mlvm/indy/func/jvmti/mergeCP_indy2manySame_b execute_positive No luck to reproduce this failure mode yet.
02-05-2014
Coleen reminded me about that this bug. I've not really worked on it yet. Returning to it.
01-05-2014
I'm not able to reproduce this issue yet. Used the following set of flags on both solaris-sparcv9 and solaris-amd64: -vmopts '-server -Xcomp -ea -esa -XX:-TieredCompilation -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -XX:+AggressiveOpts -XX:TraceRedefineClasses=16384' \
01-05-2014
I'm looking into this issue. Will try to isolate the push caused this regression.
25-03-2014
Moving from hotspot/svc -> hotspot/jvmti since this assertion failure indicates that JVM/TI RedefineClasses() is broken.
24-03-2014
Looks like these new tests fail always. # Internal Error (/tmp/workspace/2-build-solaris-amd64/jdk8/5205/hotspot/src/share/vm/prims/jvmtiRedefineClasses.cpp:3554), pid=5333, tid=36 # guarantee(false) failed: OLD and/or OBSOLETE method(s) found # # JRE version: Java(TM) SE Runtime Environment (8.0-b100) (build 1.8.0-ea-fastdebug-b100) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b42-fastdebug compiled mode solaris-amd64 ) I am giving these to serviceability group to investigate. I used rerun scripts from failing test directory to reproduce the failure.
06-02-2014
Also with jdk9 promoted: # Internal Error (/tmp/workspace/9-2-build-solaris-amd64/jdk9/11/hotspot/src/share/vm/prims/jvmtiRedefineClasses.cpp:3598), pid=5319, tid=36 # guarantee(false) failed: OLD and/or OBSOLETE method(s) found # # JRE version: Java(TM) SE Runtime Environment (9.0-b01) (build 1.9.0-ea-fastdebug-b01) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b62-fastdebug compiled mode solaris-amd64 )
06-02-2014
Not related to ppc64 changes. Tests failed with jdk8b126 promoted build which is used in bundle: # Internal Error (/tmp/workspace/8-2-build-solaris-amd64/jdk8/1635/hotspot/src/share/vm/prims/jvmtiRedefineClasses.cpp:3595), pid=5291, tid=36 # guarantee(false) failed: OLD and/or OBSOLETE method(s) found # # JRE version: Java(TM) SE Runtime Environment (8.0-b126) (build 1.8.0-fastdebug-b126) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b67-fastdebug compiled mode solaris-amd64 )
06-02-2014
Added hs25 as affected version until JDK9 JPRT builds report correct version.
05-02-2014