RFR: 8320652: ThreadInfo.isInNative needs to be updated to say what executing native code means

[Jaikiran Pai]

On Thu, 23 Nov 2023 10:25:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a docs only change to j.l.management.ThreadInfo::isInNative. 
> 
> The method currently specifies that it tests if the thread is  "executing native code via the Java Native Interface (JNI)".  It would be clearer to say that it tests if the thread is executing a native method, and expand it to include native code invoked using the new foreign linker APIs.
> 
> The existing javadoc has wording to try to clarify that "native code" does not include runtime or compiled code. I went through a few iterations to work this in but all attempts just invite more questions and nit picking. To keep it simple, this sentence is dropped so that the method description is focused on the cases where the method returns true.

src/java.management/share/classes/java/lang/management/ThreadInfo.java line 552:

> 550:      * java.lang.invoke.MethodHandle method handle} obtained from the
> 551:      * {@linkplain java.lang.foreign.Linker native linker}.
> 552:      *

This area is new to me, but I happened to be in this code few days back. I'm mostly curious on what the actual definition of a thread being in native means.
When a thread is executing any of the following,  does it end up being considered as being in a "native method":

- A syscall (for example, `write()`)
- A C function exposed by a platform specific library
- A JNI method (either part of the JDK or the application) which then may or may not do any syscall or C function call on a platform specific library

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16791#discussion_r1404779719