RFR 9: 8003488 Add Process.getPid

[David M. Lloyd]

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 at 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