Question about JDK-8205878 (tolerating missing JNI Detach)

[David Holmes]

On 20/11/2023 4:15 pm, Thomas Stüfe wrote:
> Thank you, David, for explanation and confirmation!
> 
> I try to understand what that means for SafePoints. A thread can only 
> have exited on its own in third-party native code. So in native, which 
> would make it safepoint-safe, the VM would not wait for it, right?

Right.

> Other than that, I wonder whether we keep pointers to thread stack in 
> global state somewhere. That seems to be the most obvious vulnerability.

Well the obvious place would be if the thread exited with locked 
monitors and then we'd have a BasicObjectLock* in the object's markword. 
That could be a crash waiting to happen.

> If this would be really an issue, I think one could add a facility that 
> checks threads for existence periodically, possibly as part of the JNI 
> check. Maybe similar to what we do in java.process, where we ascertain 
> identity via a (pid, start time) tupel. But as you wrote, there have 
> been almost no observed issues on the other *nixes.

The aim here is not to try and make things safe for such errant threads 
- you do this and you're on your own. We just stumbled across this with 
a badly written test and so wanted to check that we didn't crash with 
the obvious cases if we operated on the java.lang.Thread.

Cheers,
David
-----

> ..Thomas
> 
> On Mon, Nov 20, 2023 at 2:21 AM David Holmes <david.holmes at oracle.com 
> <mailto:david.holmes at oracle.com>> wrote:
> 
>     Hi Thomas,
> 
>     On 18/11/2023 1:42 am, Thomas Stüfe wrote:
>      > Hi,
>      >
>      > the AIX folks have problems with
>      > runtime/jni/terminatedThread/TestTerminatedThread.java. I am
>     trying to
>      > understand some details and would be happy for pointers.
>      >
>      > The way I understand TestTerminatedThread.java and the RFR
>     discussion
>      > for 8205878 [1], the test seems to deliberately omit
>      > JNI_DetachCurrentThread to simulate a JNI coding error, right?
> 
>     Right.
> 
>      > It joins
>      > the thread, causing the OS to clean out all associated resources.
>     The
>      > pthread_t, kernel thread id, stack, etc all become invalid. The test
>      > then nudges the VM in various ways to shake out problems relating
>     to the
>      > continued use of these resources.
>      >
>      > Is my understanding correct, or am I missing something?
> 
>     That is correct.
> 
>      > If I got this right so far, is this not inherently unstable?
> 
>     Not sure if "unstable" is the right word but yes it can have issues.
> 
>      > What
>      > happens if the associated resources get reused by the libc?
>     pthread_t
>      > could be a pointer to a struct or a slot index into a table, and get
>      > reused by a different thread. The kernel thread id could be
>     reused too.
> 
>     It is an interesting question, but beyond this test what happens with
>     real code if that were the case? We can't detect it. We will just have
>     an "orphan" Thread that we can query in various ways hence ...
> 
>     ... the test is just a "canary" to see if the VM encounters any
>     problematic scenarios when the various API's are applied to a thread
>     that terminated without detaching, and which the VM can handle more
>     robustly.
> 
>     It turned out that other than the original CPU time issue, nothing bad
>     is observed on Linux, BSD/macxOS in general. We did have one case on
>     Linux PPC [1] were we saw something unexpected and had to adjust the
>     test. It may be that we need something for AIX too? Or we can skip
>     it on
>     AIX if necessary.
> 
>     Cheers,
>     David
> 
>     [1] https://bugs.openjdk.org/browse/JDK-8211931
>     <https://bugs.openjdk.org/browse/JDK-8211931>
> 
> 
> 
>      > Thanks, Thomas
>      >
>      > [1]
>      >
>     https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html> <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html <https://mail.openjdk.org/pipermail/hotspot-runtime-dev/2018-July/029022.html>>
>