[External] : Re: How to trigger the original compilation from a reply file with invokedynamic?
Vladimir Ivanov
vladimir.x.ivanov at oracle.com
Mon Mar 15 08:56:20 UTC 2021
Hi Liu,
There are different (mostly unrelated) problems which hinder compilation
replay for indy, most notably:
* stable class names and bytecode shapes are required for dynamically
generated classes;
* unresolved call sites during compilation replay.
At some point, I was able to successfully trigger a failure involving
indy with the following patch:
https://github.com/openjdk/jdk/compare/master...iwanowww:replay.indy
But it is still just a hack/workaround targeted mostly at
ConstantCallSite case (lambda expressions) and required replay file
tweaking.
In order to reliably replay compilations involving indy and
MethodHandles, the full MethodHandle chain linked at the indy call site
has to be serialized into the replay file and then restored during replay.
Best regards,
Vladimir Ivanov
On 15.03.2021 11:08, Liu, Xin wrote:
> Hi, Dean,
>
> Thanks for letting me know the background. MethodHandle is new for me. I still need a couple days to understand it.
> I tried one, it doesn't work. I think I need to resolve the specialized MethodHandle.invokeBasic to get the broken code shape.
> I'd like to explore if it's possible to resolve the special case by hacking code(approach 2). If it pans out, we may be capable of adding a new command in replay file to help hotspot to resolve it automatically.
>
> Thanks,
> --lx
>
>
> On 3/12/21, 6:41 PM, "dean.long at oracle.com" <dean.long at oracle.com> wrote:
>
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>
>
>
> Hi Xin. MethodHandle.invokeBasic is a special "SignaturePolymorphic"
> method, which is why replay has trouble with it. There are some
> suggested workarounds to this particular problem in
> https://bugs.openjdk.java.net/browse/JDK-8012267, but I haven't had time
> to work on it yet:
>
> 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)
>
> For 1), try deleting invokeBasic methods from your replay file.
>
> dl
>
> On 3/11/21 2:07 AM, Liu, Xin wrote:
> > Hi, Dean and Roberto
> >
> > Thank you for sharing JDK-8253921. Yes, I think my problem is same.
> >
> > I do try your workaround. No luck. It does generate some class files for LambdaForm.
> > Eg . DUMP_CLASS_FILES/java/lang/invoke/LambdaForm$MH015.class.
> > But they don't match the replay file.
> >
> > Your approach gives me a new idea. I load the Java replay program in gdb and manage to figure out why it has uncommon_trap uninitialized class.
> > It turns out that bci:684 invokedyanmic expects to see this method: java/lang/invoke/MethodHandle::invokeBasic(Ljava/lang/String;)Ljava/lang/String;. It is unloaded.
> >
> > It seems not a complex form. When JVM boots up, I see that C2 compiles 23 MethodHandle methods. The 3rd one is invokeBasic, which should be a variant of invokeBasic(L)L.
> > 547 3 n 0 java.lang.invoke.MethodHandle::invokeBasic(LLLLLL)L (native)
> >
> > Now my idea is to hack jvm to execute some code to compile "java/lang/invoke/MethodHandle::invokeBasic(Ljava/lang/String;)Ljava/lang/String;"
> >
> > In this way, hotspot will load class java/lang/invoke/MethodHandle and its method "invokeBasic(Ljava/lang/String;)Ljava/lang/String;".
> > This should pave the road to execute the compile command in replay file.
> >
> > What do you think about this workaround? Do you know how to "directive" hotspot to compile "invokeBasic(Ljava/lang/String;)Ljava/lang/String" like it does for invokeBasic(LLLLLL)L?
> >
> > Thanks,
> > --lx
> >
> >
> >
> > On 3/10/21, 2:31 AM, "hotspot-compiler-dev on behalf of dean.long at oracle.com" <hotspot-compiler-dev-retn at openjdk.java.net on behalf of dean.long at oracle.com> wrote:
> >
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> >
> >
> >
> > 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://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/2570*issuecomment-793474669__;Iw!!GqivPVa7Brio!Poo1oS50DrngdWN_a70rX54utMFIfOHN-KLk_U00DBV6n1_StK50Q-LVU-DjXPo$
> > >
> > > 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://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.java*L75__;Iw!!GqivPVa7Brio!Poo1oS50DrngdWN_a70rX54utMFIfOHN-KLk_U00DBV6n1_StK50Q-LVczw1epI$
> > >
> > > 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
> > >
> >
>
More information about the hotspot-compiler-dev
mailing list