Discussion:
RFR 8195627: [Graal] nsk/jdi/VirtualMachine/redefineClasses/redefineclasses026 hangs with Graal in Xcomp mode
(too old to reply)
Daniil Titov
2018-10-29 18:13:07 UTC
Permalink
Please review the change that fixes the issue when the test hangs with Graal and XComp mode on.

One of the test cases the test runs is to call com.sun.jdi.VirtualMachine.redefineClasses() while the target VM is suspended. The bytes passed to com.sun.jdi.VirtualMachine.redefineClasses() don't correspond to the reference type (the names do not match) and the test expects NoClassDefFoundError to be thrown.

The problem here is that the compiler thread is suspended while "JDWP Transport Listener" thread enters CompileBroker::wait_for_jvmci_completion() method and the code inside CompileBroker::wait_for_jvmci_completion() method falsely assumes that some progress by the compiler thread was made. As a result, it resets the progress wait attempt counter and goes into an endless loop waiting for JVMCI to complete the compilation.


Webrev: http://cr.openjdk.java.net/~dtitov/8195627/webrev.01/
Issue: https://bugs.openjdk.java.net/browse/JDK-8195627

Thanks!
--Daniil
s***@oracle.com
2018-10-30 09:04:25 UTC
Permalink
The Compiler team needs to review this as well, so added
hotspot-compiler-dev mailing list.

Thanks,
Serguei
Post by Daniil Titov
Please review the change that fixes the issue when the test hangs with Graal and XComp mode on.
One of the test cases the test runs is to call com.sun.jdi.VirtualMachine.redefineClasses() while the target VM is suspended. The bytes passed to com.sun.jdi.VirtualMachine.redefineClasses() don't correspond to the reference type (the names do not match) and the test expects NoClassDefFoundError to be thrown.
The problem here is that the compiler thread is suspended while "JDWP Transport Listener" thread enters CompileBroker::wait_for_jvmci_completion() method and the code inside CompileBroker::wait_for_jvmci_completion() method falsely assumes that some progress by the compiler thread was made. As a result, it resets the progress wait attempt counter and goes into an endless loop waiting for JVMCI to complete the compilation.
Webrev: http://cr.openjdk.java.net/~dtitov/8195627/webrev.01/
Issue: https://bugs.openjdk.java.net/browse/JDK-8195627
Thanks!
--Daniil
Vladimir Kozlov
2018-10-30 15:51:26 UTC
Permalink
Looks good.

Thanks,
Vladimir
The Compiler team needs to review this as well, so added hotspot-compiler-dev mailing list.
Thanks,
Serguei
Post by Daniil Titov
Please review the change that fixes the issue when the test hangs with Graal and XComp mode on.
One of the test cases the test runs is to call com.sun.jdi.VirtualMachine.redefineClasses() while the target VM is
suspended.  The bytes passed to com.sun.jdi.VirtualMachine.redefineClasses()  don't correspond to the reference type
(the names do not match) and the test expects NoClassDefFoundError to be thrown.
The problem here is that the compiler thread is suspended while "JDWP Transport Listener" thread enters
CompileBroker::wait_for_jvmci_completion() method and the code inside CompileBroker::wait_for_jvmci_completion()
method falsely assumes that some progress by the compiler thread was made.  As a result, it resets the progress wait
attempt counter and goes into an endless loop waiting for JVMCI to complete the compilation.
Webrev: http://cr.openjdk.java.net/~dtitov/8195627/webrev.01/
Issue: https://bugs.openjdk.java.net/browse/JDK-8195627
Thanks!
--Daniil
s***@oracle.com
2018-10-30 21:24:09 UTC
Permalink
Hi Daniil,

It looks good.

Thanks!
Serguei
Post by Daniil Titov
Please review the change that fixes the issue when the test hangs with Graal and XComp mode on.
One of the test cases the test runs is to call com.sun.jdi.VirtualMachine.redefineClasses() while the target VM is suspended. The bytes passed to com.sun.jdi.VirtualMachine.redefineClasses() don't correspond to the reference type (the names do not match) and the test expects NoClassDefFoundError to be thrown.
The problem here is that the compiler thread is suspended while "JDWP Transport Listener" thread enters CompileBroker::wait_for_jvmci_completion() method and the code inside CompileBroker::wait_for_jvmci_completion() method falsely assumes that some progress by the compiler thread was made. As a result, it resets the progress wait attempt counter and goes into an endless loop waiting for JVMCI to complete the compilation.
Webrev: http://cr.openjdk.java.net/~dtitov/8195627/webrev.01/
Issue: https://bugs.openjdk.java.net/browse/JDK-8195627
Thanks!
--Daniil
Loading...