JDK-8024345 : 'assert(_value != NULL) failed: resolving NULL _value' from VM_RedefineClasses::set_new_constant_pool
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: hs25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-09-05
  • Updated: 2013-09-24
  • Resolved: 2013-09-14
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 Other
8Fixed hs25Fixed
Description
#  Internal Error (/localhome/stefank/hg/hsx-gc/src/share/vm/runtime/handles.hpp:173), pid=25187, tid=140072352110336
#  assert(_value != NULL) failed: resolving NULL _value

Stack: [0x00007f6522ba5000,0x00007f6522ca6000],  sp=0x00007f6522ca3700,  free space=1017k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xe29918]  VMError::report_and_die()+0x158
V  [libjvm.so+0x698063]  report_vm_error(char const*, int, char const*, char const*)+0x83
V  [libjvm.so+0x5550ff]  constantPoolHandle::operator->() const+0x3f
V  [libjvm.so+0xa4593d]  VM_RedefineClasses::set_new_constant_pool(ClassLoaderData*, instanceKlassHandle, constantPoolHandle, int, Thread*)+0xad
V  [libjvm.so+0xa492e2]  VM_RedefineClasses::merge_cp_and_rewrite(instanceKlassHandle, instanceKlassHandle, Thread*)+0x662
V  [libjvm.so+0xa49820]  VM_RedefineClasses::load_new_class_versions(Thread*)+0x510
V  [libjvm.so+0xa4a252]  VM_RedefineClasses::doit_prologue()+0xa2
V  [libjvm.so+0xe4e806]  VMThread::execute(VM_Operation*)+0x2d6
V  [libjvm.so+0xa0d908]  JvmtiEnv::RedefineClasses(int, _jvmtiClassDefinition const*)+0x28
V  [libjvm.so+0x9a82d6]  jvmti_RedefineClasses+0x1b6

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  runtime.ParallelClassLoading.shared.ClassLoadingController.redefineClasses(Ljava/lang/ClassLoader;Lruntime/ParallelClassLoading/shared/ClassLoadingController$ByteCodeForRedefinitionHandler;)I+0
j  runtime.ParallelClassLoading.shared.ClassLoadingController.startLoadingIterator()Z+806
j  runtime.ParallelClassLoading.shared.ClassLoadingController.runIt([Ljava/lang/String;Ljava/io/PrintStream;)I+9
j  runtime.ParallelClassLoading.shared.SecureClassLoaderController.run([Ljava/lang/String;Ljava/io/PrintStream;)I+9
j  runtime.ParallelClassLoading.shared.SecureClassLoaderController.main([Ljava/lang/String;)V+4
v  ~StubRoutines::call_stub

We assert because we don't handle the OOME correctly in this code:
void VM_RedefineClasses::set_new_constant_pool(
       ClassLoaderData* loader_data,
       instanceKlassHandle scratch_class, constantPoolHandle scratch_cp,
       int scratch_cp_length, TRAPS) {
  assert(scratch_cp->length() >= scratch_cp_length, "sanity check");

  // scratch_cp is a merged constant pool and has enough space for a
  // worst case merge situation. We want to associate the minimum
  // sized constant pool with the klass to save space.
  constantPoolHandle smaller_cp(THREAD,
          ConstantPool::allocate(loader_data, scratch_cp_length, THREAD));

  // preserve version() value in the smaller copy
  int version = scratch_cp->version();
  assert(version != 0, "sanity check");
  smaller_cp->set_version(version);

  // attach klass to new constant pool
  // reference to the cp holder is needed for copy_operands()
  smaller_cp->set_pool_holder(scratch_class());

  scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, 1, THREAD);
  scratch_cp = smaller_cp;

  // attach new constant pool to klass
  scratch_class->set_constants(scratch_cp()); 

We should probably be using CHECK_NULL instead of THREAD.
Comments
This is a tmp patch from Stefan: # HG changeset patch # Parent 525e72e57aa5170ee5ea73983d6898cee8bcd40e diff --git a/src/share/vm/prims/jvmtiRedefineClasses.cpp b/src/share/vm/prims/jvmtiRedefineClasses.cpp --- a/src/share/vm/prims/jvmtiRedefineClasses.cpp +++ b/src/share/vm/prims/jvmtiRedefineClasses.cpp @@ -1396,7 +1396,7 @@ ConstantPool* merge_cp_oop = ConstantPool::allocate(loader_data, merge_cp_length, - THREAD); + CHECK_(JVMTI_ERROR_INTERNAL)); MergeCPCleaner cp_cleaner(loader_data, merge_cp_oop); HandleMark hm(THREAD); // make sure handles are cleared before @@ -2484,8 +2484,9 @@ // scratch_cp is a merged constant pool and has enough space for a // worst case merge situation. We want to associate the minimum // sized constant pool with the klass to save space. - constantPoolHandle smaller_cp(THREAD, - ConstantPool::allocate(loader_data, scratch_cp_length, THREAD)); + ConstantPool* cp = ConstantPool::allocate(loader_data, scratch_cp_length, CHECK); + constantPoolHandle smaller_cp(THREAD, cp); + // preserve version() value in the smaller copy int version = scratch_cp->version(); @@ -2496,7 +2497,7 @@ // reference to the cp holder is needed for copy_operands() smaller_cp->set_pool_holder(scratch_class()); - scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, 1, THREAD); + scratch_cp->copy_cp_to(1, scratch_cp_length - 1, smaller_cp, 1, CHECK); scratch_cp = smaller_cp; // attach new constant pool to klass
06-09-2013

It seems to work with 4m.
05-09-2013

Maybe if max_alignment is big (I'm thinking Large Pages) then this code will fail: MaxMetaspaceSize = align_size_down(MaxMetaspaceSize, max_alignment()); if (MetaspaceSize > MaxMetaspaceSize) { MetaspaceSize = MaxMetaspaceSize; } I get the same if I set it to 1MB on my Linux x64 machine where the large pages size is 2MB: $ java -XX:MaxMetaspaceSize=1m -XX:MetaspaceSize=1m -version Error occurred during initialization of VM Too small initial Metaspace size
05-09-2013

No. 2m is the important part. I don't understand why you get that error message. The code I'm looking at says: if (MetaspaceSize < 256*K) { vm_exit_during_initialization("Too small initial Metaspace size"); } It seems like your MetaspaceSize gets set to a weird value.
05-09-2013

I guess, 2m is a typo, it must be 32m as -XX:ClassMetaspaceSize=32m.
05-09-2013

I'm getting this error: sspitsyn@sc11152541 ute -testlist vm.quick-pcl.testlist -jdk /net/sc11152541/export/home/sspitsyn/hs25/hsx3/solaris-sparc -vmflavor server -bits d64 -component vm -vmopts '-XX:MaxMetaspaceSize=2m -XX:MetaspaceSize=2m -XX:ClassMetaspaceSize=32m' Error occurred during initialization of VM Too small initial Metaspace size ERROR Version command failed with exit code 1 ERROR jdk_release is not set ERROR Unsupported jdk_release: Is it Ok to increase the MetaspaceSize?
05-09-2013

Hit another path: Stack: [0x00007f27fef5f000,0x00007f27ff060000], sp=0x00007f27ff05da70, free space=1018k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xe28f78] VMError::report_and_die()+0x158 V [libjvm.so+0x698063] report_vm_error(char const*, int, char const*, char const*)+0x83 V [libjvm.so+0x5550ff] constantPoolHandle::operator->() const+0x3f V [libjvm.so+0xa48e18] VM_RedefineClasses::merge_cp_and_rewrite(instanceKlassHandle, instanceKlassHandle, Thread*)+0x168 V [libjvm.so+0xa49852] VM_RedefineClasses::load_new_class_versions(Thread*)+0x512 V [libjvm.so+0xa4a2e0] VM_RedefineClasses::doit_prologue()+0xa0 V [libjvm.so+0xe4de66] VMThread::execute(VM_Operation*)+0x2d6 V [libjvm.so+0xa0d908] JvmtiEnv::RedefineClasses(int, _jvmtiClassDefinition const*)+0x28 V [libjvm.so+0x9a82d6] jvmti_RedefineClasses+0x1b6
05-09-2013