On Thu, 23 Nov 2023 10:25:31 GMT, Alan Bateman <[email protected]> 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
