On 05/22/2014 10:44 AM, Alan Bateman wrote:
On 22/05/2014 16:34, David M. Lloyd wrote:
I guess this is a little late, and minor, but the "jstack" tool uses
the acronym "nid" for this purpose, which I believe is mapped to the
same concept (on Linux it is anyway).
I think either this terminology should be unified on the jstack side,
or else the method should be called "getNativeId" or "getNid" or
something.
Are you thinking of "vmid" by any chance? If so then that term comes
from jvmstat. It uses String for the identifier because it can support
inspecting the counters of remote VMs (pid@host for example). If I
recall correctly then jstack allows for a String too, mostly because it
has its roots as a SA tool where it can connect to a remote VM when
jsadebugd is running.
Nah I'm thinking of this:
$ jstack 30044
2014-05-22 10:39:55
Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.51-b03 mixed mode):
[...]
"RMI TCP Accept-0" daemon prio=10 tid=0x00007ff884143000 nid=0x756e
The "nid" here is the hex-encoded process ID of the thread. But instead
of saying "process ID" or whatever, it's "native ID". As stated earlier
though, on Linux the thread and process IDs share a namespace so it's
not always true that these are the *same* thing; however, it illustrates
that in general, threads have a "native ID", reserving "thread ID" as an
internal JVM concept. I would think the same would apply to processes,
especially given that "process ID" is a first-order concept on some (but
maybe not all) OSes, and even OSes without that first-order PID concept
might still have some other meaningful numeric mapping for the native ID
of a Process.
--
- DML
