JDK-8012267 : ciReplay: fails to resolve @SignaturePolymorphic methods in replay data
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2013-04-15
  • Updated: 2021-09-17
  • Resolved: 2021-09-03
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 18
18 b14Fixed
Related Reports
Blocks :  
Blocks :  
Blocks :  
Blocks :  
Relates :  
Description
During compilation replay data parsing, VM fails to resolve signature-polymorphic method entries.

For example:
ciMethod java/lang/invoke/MethodHandle invokeBasic (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; 1 1 1 0 -1
ciMethod java/lang/invoke/MethodHandle invokeBasic (Ljava/lang/Object;)Ljava/lang/Object; 1 1 1 0 -1
ciMethod java/lang/invoke/MethodHandle invokeBasic (Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object; 1 1 1 0 -1
ciMethod java/lang/invoke/MethodHandle invokeBasic (Ljava/lang/Object;Ljava/lang/Object;Ljava/lang/Object;)V 1 1 1 0 -1
ciMethod

It's one of the blockers to successfully replay compilations of methods which use JSR292. 

I see 2 possible solutions:
    1) don't dump signature-polymorphic methods into replay file (it seems there's no useful info there anyway)
    2) try to resolve, but as a special-case (ignore method signature)
 
Comments
Changeset: 14a3ac09 Author: Dean Long <dlong@openjdk.org> Date: 2021-09-03 23:23:10 +0000 URL: https://git.openjdk.java.net/jdk/commit/14a3ac09fe504ea97d269b78872bef6021c976fd
03-09-2021

I didn't make any progress. I still need to get familiar with method handle first.
08-07-2021

[~xliu] Any updates on this one?
08-07-2021

Reproducible: 1. run the jtreg test LowMemoryTest2 2. rebuild using the replay_pid18829.log ./build/linux-x86_64-server-slowdebug/jdk/bin/java -XX:+ReplayCompiles -XX:ReplayDataFile=./replay_pid18829.log -XX:+ReplayIgnoreInitErrors -cp build/linux-x86_64-server-slowdebug/test-support/jtreg_test_jdk_java_lang_management_MemoryMXBean/classes/1/java/lang/management/MemoryMXBean/LowMemoryTest2.d/ -XX:+PrintInlining -XX:+TraceOptoParse -Xbatch -XX:+PrintCompilation the compilation fails due to an uncommon trap. Uncommon trap reason='uninitialized' action='reinterpret' debug_id='0' at bci:684 Skipped dead block 1 at bci:670 @ 681 java.lang.Integer::toString (55 bytes) force inline by ciReplay @ 1 java.lang.Integer::stringSize (47 bytes) force inline by ciReplay @ 18 java.lang.Integer::getChars (131 bytes) force inline by ciReplay @ 28 java.lang.String::<init> (15 bytes) force inline by ciReplay here is the invoke dynamic. 684: invokedynamic #31, 0 // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String; This method can't be resolved because it can't find invokebasic (Ljava/lang/String;)Ljava/lang/String;
25-05-2021

This issue is difficult to reproduce in isolation without being also affected by JDK-8012268.
03-11-2020

These methods are also marked native. What if we didn't dump any native methods to the replay file? I don't think they add any useful information.
27-10-2020

[~vlivanov] What's the best way to reproduce this?
09-10-2020