JDK-8219974 : REDO JDK-8219492: Restore static callsite resolution for the current class
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 12,13
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-03-01
  • Updated: 2019-05-17
  • Resolved: 2019-03-05
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 12 JDK 13
12.0.2Fixed 13 b11Fixed
Related Reports
Relates :  
JDK-8219492 - Restore static callsite resolution for the current class
Relates :  
JDK-8219969 - Backout JDK-8219492
Relates :  
JDK-8223213 - Implement fast class initialization checks on x86-64
Relates :  
JDK-8223437 - Backout JDK-8219974 Restore static callsite resolution for the current class
Description
Reapply the fix for JDK-8219492 after resolving the assertion failure that occurred.
Comments
Okay, this issue was backed out, and is not of interest for backports. Retracting versions and tags.
17-05-2019
Interesting. I retracted jdk11u-fix-request for a while, until we get the full understanding of future fixes.
07-05-2019
While restoring some performance the fix is not compatible with JDK-8205714. A full fix will be available under JDK-8223213 (and related issues). This fix will be backed out under JDK-8223437.
07-05-2019
Fix Request This patch resolves a performance issue that affects 11u users. Patch does not apply cleanly to 11u due to a slightly changed code. Patched version passes tier1 and some startup benchmarks. 11u RFR (already reviewed): https://mail.openjdk.java.net/pipermail/jdk-updates-dev/2019-April/000948.html
23-04-2019
12u Fix request: This performance regression affects all trains in which the original security bug was fixed, so it is important to address that regression in 12u. The fix is low-risk.
10-03-2019
Simplest fix, to ensure no other surprises, is to restrict the new assertions to the invoke_static case.
04-03-2019
This is the basic scenario that fails the assertion: interface I1 { default void m() {} } interface I2 extends I1 {} class C implements I2 {} and then an invocation bytecode on an instance of C: invokespecial I2::m This results in I2 being the method_holder for m, but I2 is not initialized (nor should it be as it doesn't define any default methods). Hence the assertion fails. I expected the method_holder to be I1 in this case not I2.
04-03-2019
We see an assertion fail running one particular JCK test, and only that one test. The assertions, while not guarded by an invoke_static path, do not need to be as they should hold regardless of the invoke instruction being used, due to the rules for class initialization. The failure relates to reflection: Stack: [0x00007fd66f5f6000,0x00007fd66f6f7000], sp=0x00007fd66f6f44a0, free space=1017k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xa26532] ConstantPoolCacheEntry::set_direct_call(Bytecodes::Code, methodHandle const&, bool, InstanceKlass*)+0xb62 V [libjvm.so+0xd9a7c4] InterpreterRuntime::resolve_invoke(JavaThread*, Bytecodes::Code)+0xa84 V [libjvm.so+0xd9b54b] InterpreterRuntime::resolve_from_cache(JavaThread*, Bytecodes::Code)+0x12b j javasoft.sqe.tests.vm.constantpool.resolveIntMethod.resolveIntMethod007.resolveIntMethod00701m4.resolveIntMethod00701m40n.run([Ljava/lang/String;Ljava/io/PrintStream;)I+7 v ~StubRoutines::call_stub V [libjvm.so+0xdaeb9a] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x76a V [libjvm.so+0x1479cce] invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) [clone .constprop.102]+0xbde V [libjvm.so+0x147cc86] Reflection::invoke_method(oop, Handle, objArrayHandle, Thread*)+0x196 V [libjvm.so+0xf15c16] JVM_InvokeMethod+0x1d6 j jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 java.base@13-internal j jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100 java.base@13-internal J 2120 c1 jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@13-internal (10 bytes) @ 0x00007fd6a1455d8c [0x00007fd6a1455c80+0x000000000000010c] J 2119 c1 java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@13-internal (65 bytes) @ 0x00007fd6a145561c [0x00007fd6a14553c0+0x000000000000025c] j javasoft.sqe.tests.vm.constantpool.resolveIntMethod.resolveIntMethod007.resolveIntMethod00701m4.resolveIntMethod00701m4.runNegative(Ljava/lang/String;Ljava/lang/Class;[Ljava/lang/String;Ljava/io/PrintStream;)I+160 j javasoft.sqe.tests.vm.constantpool.resolveIntMethod.resolveIntMethod007.resolveIntMethod00701m4.resolveIntMethod00701m4.run([Ljava/lang/String;Ljava/io/PrintStream;)I+6 j javasoft.sqe.tests.vm.constantpool.resolveIntMethod.resolveIntMethod007.resolveIntMethod00701m4.resolveIntMethod00701m4.main([Ljava/lang/String;)V+4 v ~StubRoutines::call_stub V [libjvm.so+0xdaeb9a] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x76a V [libjvm.so+0x1479cce] invoke(InstanceKlass*, methodHandle const&, Handle, bool, objArrayHandle, BasicType, objArrayHandle, bool, Thread*) [clone .constprop.102]+0xbde V [libjvm.so+0x147cc86] Reflection::invoke_method(oop, Handle, objArrayHandle, Thread*)+0x196 V [libjvm.so+0xf15c16] JVM_InvokeMethod+0x1d6 j jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Ljava/lang/reflect/Method;Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+0 java.base@13-internal j jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object;+100 java.base@13-internal J 2120 c1 jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@13-internal (10 bytes) @ 0x00007fd6a1455d8c [0x00007fd6a1455c80+0x000000000000010c] J 2119 c1 java.lang.reflect.Method.invoke(Ljava/lang/Object;[Ljava/lang/Object;)Ljava/lang/Object; java.base@13-internal (65 bytes) @ 0x00007fd6a145561c [0x00007fd6a14553c0+0x000000000000025c] j applications.runthese.Runner$TestRunner$1.run()V+9 v ~StubRoutines::call_stub V [libjvm.so+0xdaeb9a] JavaCalls::call_helper(JavaValue*, methodHandle const&, JavaCallArguments*, Thread*)+0x76a V [libjvm.so+0xdaa8ea] JavaCalls::call_virtual(JavaValue*, Handle, Klass*, Symbol*, Symbol*, Thread*)+0x3ea V [libjvm.so+0xef5a63] thread_entry(JavaThread*, Thread*)+0xa3 V [libjvm.so+0x1648cfa] JavaThread::thread_main_inner()+0x26a V [libjvm.so+0x1650a7e] JavaThread::run()+0x1ae V [libjvm.so+0x164e556] Thread::call_run()+0xf6 V [libjvm.so+0x135dadd] thread_native_entry(Thread*)+0x10d
02-03-2019