On Sun, 26 Jun 2022 09:50:11 GMT, Alan Bateman <al...@openjdk.org> wrote:

> This is a fix to a recently added test. The test uses pthread_create to 
> create native threads that invoke a Java method via a generated "upcall 
> stub". The upcall stub is created in an implicit memory session but the test 
> doesn't do anything to ensure that the memory session remains open. Testing 
> in higher tiers runs the test with options that sometimes lead to a cleaner 
> closing the memory session before the native threads have terminated. The 
> failure mode is exit code 133 due to a child VM exiting with SIGTRAP. The 
> test needs to be changed to ensure that the memory session is not closed 
> until the threads terminate. To keep it simple, I've changed it to use the 
> global memory session. The alternative is to change it to use a shared 
> session or a reachability fence, coupled with a pthread_join to ensure that 
> all native threads with a reference to stub terminate before the session is 
> closed. The test is intended to exercise concurrent implicit attaching so 
> keeping it as simple as possib
 le seems best.
> 
> The test is also changed too use shouldHaveExitValue(0) as the original test 
> discarded the child VM exit code when the test failed.

Marked as reviewed by mcimadamore (Reviewer).

For the records - the implicit upcall will be kept alive for the duration of 
the downcall to which it is passed to. In this case, since the downcall forks 
another thread and then returns (and the call to the stub occurs at some point 
later in the other thread), it is possible for the implicit session to be 
reclaimed _before_ the async thread had a chance to execute it. With fully 
synchronous code this would never be an issue, as the standard safety 
"keep-alive" provided by the linker would have been enough.

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

PR: https://git.openjdk.org/jdk19/pull/73

Reply via email to