RFR 8195627: [Graal] nsk/jdi/VirtualMachine/redefineClasses/redefineclasses026 hangs with Graal in Xcomp mode

[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]

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]

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]

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