RFR: 8253794: TestAbortVMOnSafepointTimeout never timeouts

[Robbin Ehn]

On Fri, 2 Oct 2020 04:24:44 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Robbin,
> 

Hi David,

> So.... The old test used an "uncounted loop" (based on internal JIT knowledge) to create looping code with no safepoint
> polls so that it remains safepoint-unsafe (and Patricio had to tweak the test conditions to avoid unexpected
> safepoints). The new code has a WhiteBox entry that uses an internal naked_sleep which keeps the thread _thread_in_VM
> IIUC, which is not safepoint-safe, but also potentially different to being _thread_in_Java. But lets just accept the
> net effect is the same - the thread will prevent a safepoint from being reached until the sleep time has elapsed. If
> that time is > (GuaranteedSafepointInterval + SafepointTimeoutDelay) then we should see a safepoint timeout and the VM
> abort. Okay ... so how does that solve the problem the test currently experiences with handshakes ... if we are at a
> handshake the handshake can't proceed until the sleep time expires, but then when we transition back to Java the thread
> will see the handshake and so the handshake will proceed. As long as the WB function returns false we will repeat the
> process, eventually when the expected safepoint is requested we should again trigger the safepoint timeout and abort.
> But like Dan I'm unclear how the WB function can ever return true as the safepoint state can't change whilst the thread
> is in the naked sleep. ??

It can't return true if the VM is working. So yes the safepoint tracker maybe overkill.

> 
> Aside: rather than using "args.length > 0" to discriminate between the original and subsequent executions of the test
> class, it can be clearer (IMO) to add a static nested class which has the main method that performs the actual test,
> and you invoke that via ProcessTools.

I didn't change any of that.

> That all said, for the record, we really should have a handshake timeout mechanism the same as we have the safepoint
> timeout mechanism.

We have a timeout mechanism but default off HandshakeTimeout.
But it doesn't fire SIGILL to troubled thread as safepoint does.

Thanks, Robbin

> 
> Thanks,
> David

-------------

PR: https://git.openjdk.java.net/jdk/pull/465