How to trigger the original compilation from a reply file with invokedynamic?

[dean.long at oracle.com]

Hi Xin,

as a partial workaround, you can try running with 
-Djdk.internal.lambda.dumpProxyClasses=DUMP_CLASS_FILES
     -Djava.lang.invoke.MethodHandle.DUMP_CLASS_FILES=true and then for 
the replay add the classes dumped to  DUMP_CLASS_FILES/ using the 
appropriate classpath/module option.  That might make more progress, but 
like Roberto said, it's not guaranteed to work.

dl

On 3/9/21 11:52 PM, Liu, Xin wrote:
> Hi,
> I am debugging 2 replay files.  Even with the class files and reply files, I still can’t trigger the original compilations, which is supposed to trigger my bug.
> https://github.com/openjdk/jdk/pull/2570#issuecomment-793474669
>
> I try to use the following cmdline to trigger assertion failure. no luck.
> ./build/linux-x86_64-server-slowdebug/jdk/bin/java -XX:+ReplayCompiles -XX:+ReplayIgnoreInitErrors -XX:ReplayDataFile=replay_pid18829.log -XX:+PrintCompilation -cp build/linux-x86_64-server-slowdebug/test-support/jtreg_test_jdk_java_lang_management_MemoryMXBean_LowMemoryTest2_sh/classes/0/java/lang/management/MemoryMXBean/LowMemoryTest2.d/ -XX:+PrintInlining -XX:+TraceOptoParse
>
> Here is the output messages.
> …
> java.lang.NoClassDefFoundError: java/lang/invoke/LambdaForm$MH+0x0000000801009000
> java.lang.NoClassDefFoundError: java/lang/invoke/LambdaForm$MH+0x0000000801009000
> Error while parsing line 3080: Can't find method
>
> Error while parsing line 3082: Can't find method
>
> Error while parsing line 3085: Can't find method
>
> Error while parsing line 3102: Can't find method
>
> Error while parsing line 3103: Can't find method
>
> java.lang.NoClassDefFoundError: java/lang/invoke/LambdaForm$MH+0x0000000801009000
> Error while parsing line 3139: Can't find holder klass
>
> java.lang.NoClassDefFoundError: java/lang/invoke/LambdaForm$MH+0x0000000801009000
> Error while parsing line 3141: Can't find holder klass
>    2107   24   !b  4       LowMemoryTest2$BoundlessLoaderThread::loadNext (838 bytes)
> …
> Uncommon trap reason='uninitialized' action='reinterpret' debug_id='0' at bci:684
> ...
>                                @ 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
>                                    @ 1   java.lang.Object::<init> (1 bytes)   force inline by ciReplay
>
>
> LowMemoryTest2$BoundlessLoaderThread::loadNext is a method of 838 bytes, which contains many string calls.
> https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java#L75
>
> Obviously, my compilation in replay mode is significantly simpler than the original code.  The other evident is that there are 161 inline entries for the compile command in the replay file.  The deepest level of InlineTree is 8!
> In replay mode, my inline tree is very simple.
>
> I strongly suspect that it’s because the uncommon_trap at bci:684.  This uncommon trap may chop off a big chunk of code from the compilation unit, which includes those string function calls.
> In real scenario, I don’t think C2 would meet this uncommon trap  whose reason is uninitialized class. Using javap to inspect the class file, I found that bci:684 happens to be an invokedyanmic.
>       684: invokedynamic #31,  0             // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
>
> Back to the output messages, Hotspot does complain a few NoClassDef problems ahead of  ‘compile’ command. It seems that those classes are generated on-the-fly. Is there a way to force hotspot to generate and load those classes in replay mode?
> If not,  then how can I use a reply file to reproduce the original compilation when an invokedynamic is present?
>
> I also don’t know why I can’t reproduce this problem using VM_OPTIONS=”-ea -esa -XX:CompileThreshold=100”. Indyconcat should happen unconditionally, shouldn’t it? is there other hint to trigger InvokeDynamic #0:makeConcatWithConstants?
>
> Thanks,
> --lx
>