Hi, Thanks for the rationale. Using the natural terminology familiar to developers seems most useful. Mac, Windows, and Linux refer to these values a process id or pid as the handle for a Process; it appears in the tools like ps and tasklist. The javadoc can explain anything more specific or system dependent. Roger On 5/22/2014 11:55 AM, David M. Lloyd wrote:
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.