JDK-8040201 : JSR 292: old non-redefined code is entered again after JVMTI PopFrame followed by class redefinition in MethodHandle.invoke
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 7u66,7u71,emb-8u6,8,8u5,8u11,8u20,9
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2014-04-14
  • Updated: 2014-05-26
  • Resolved: 2014-05-23
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
8u20Resolved
Related Reports
Duplicate :  
JDK-8013267 - move MemberNameTable from native code to Java heap, use to intern MemberNames
Relates :  
JDK-8023004 - JSR 292: java.lang.RuntimeException: Original target method was called.
Description
This issue has symptoms similiar to fixed JDK-8023004.
Comments
Just want to explain the hack above. It shows that there are two different MNs referring the same method. The hack caches the second one in the static variable 'tmp_cache'. Later the variable is used to replace the old and obsolete method address with the address of new method from the redefined class. The originally failing tests are passed with this hack which proves that this issue is the same as described in the bug 8013267.
23-05-2014
The test is passed with the following tmp hack: diff -r 2c2aa6de8f60 src/share/vm/prims/methodHandles.cpp --- a/src/share/vm/prims/methodHandles.cpp Wed May 21 14:36:18 2014 -0400 +++ b/src/share/vm/prims/methodHandles.cpp Thu May 22 17:36:13 2014 -0700 @@ -946,9 +946,22 @@ MemberNameTable::~MemberNameTable() { } } +static jweak tmp_cache[100] = { NULL }; + void MemberNameTable::add_member_name(int index, jweak mem_name_wref) { assert_locked_or_safepoint(MemberNameTable_lock); - this->at_put_grow(index, mem_name_wref); + oop mname0 = (index < _len) ? this->get_member_name(index) : NULL; + if (mname0 == NULL) { + this->at_put_grow(index, mem_name_wref); + if (index == 1) { + printf("MY_VM_TRACE: added elem with index: %d\n", index); fflush(0); + } + } else { + tmp_cache[index] = mem_name_wref; + if (index == 1) { + printf("MY_VM_TRACE: added cache with index: %d\n", index); fflush(0); + } + } } // Return a member name oop or NULL. @@ -991,6 +1004,18 @@ void MemberNameTable::adjust_method_entr oop mem_name = find_member_name_by_method(old_method); if (mem_name != NULL) { java_lang_invoke_MemberName::adjust_vmtarget(mem_name, new_method); + if (j == 1) { + printf("MY_VM_TRACE: adjusted elem with index: %d\n", j); fflush(0); + + if (tmp_cache[j] != NULL) { + oop mem_name = JNIHandles::resolve(tmp_cache[j]); + Method* method = (Method*)java_lang_invoke_MemberName::vmtarget(mem_name); + if (method == old_method) { + java_lang_invoke_MemberName::adjust_vmtarget(mem_name, new_method); + printf("MY_VM_TRACE: adjusted cache with index: %d\n", j); fflush(0); + } + } + } if (RC_TRACE_IN_RANGE(0x00100000, 0x00400000)) { if (!(*trace_name_printed)) { This means that this issue is a duo of the bug: https://bugs.openjdk.java.net/browse/JDK-8013267 Closing this one as a dup.
23-05-2014
This is not a regression as it fails the same way with the jdk 8. I suspect this is a dup of: https://bugs.openjdk.java.net/browse/JDK-8013267 The bug above is appeared when there are multiple member names referring the same method. Will try to prove it.
22-05-2014