Hi Martin, Alan mentioned this case but it seemed more difficult to use than the primitive. For the other parts of JEP 102, I expect to represent a process with a type that can have additional methods. That type would provide stronger typing and a set of useful operations. It seems less desirable to use a String in those cases. Roger On 5/12/2014 4:47 PM, Martin Buchholz wrote:

Thanks for taking on yet another task that has been on my TODO list for a decade.

I decided many years ago that the "process identifier" should actually be a string (or at least not something as constrained as an int), in keeping with Java's OS-independent nature, even though all implementations may in fact use an integer. IIRC, Apollo computers used a hostname/int pair as a process identifier, and such a convention may become popular again in the future.

Furthermore, returning a string is in practice at least as convenient, since the only thing you can typically do with a pid today is pass it as a string to a system command like "kill".

On Mon, May 12, 2014 at 12:44 PM, roger riggs <roger.riggs@oracle.com <mailto:roger.riggs@oracle.com>> wrote:

Please review and comment on this long requested addition to provide the native process id of a spawned Process.

Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ <http://cr.openjdk.java.net/%7Erriggs/webrev-getpid-8003488/> Issue: https://bugs.openjdk.java.net/browse/JDK-8003488

Thanks, Roger

Alan has by far the most experience with system-dependent java objects that have some kind of static structure, but enough flexibility to adapt dynamically to different systems. Perhaps Alan could apply some of that design expertise to e.g. java.lang.Process. On Mon, May 12, 2014 at 1:52 PM, Paul Benedict <pbenedict@apache.org> wrote:

I was thinking about this ticket today. Regarding Alan Bateman's comment that the pid may not be representable as an int/long, I was expecting some sort of Pid-like-object to be returned. I'd rather see an abstraction that *might* be able to convert into an int/long ... or even a String, as Martin B. just said.

Cheers, Paul

On Mon, May 12, 2014 at 3:47 PM, Martin Buchholz <martinrb@google.com>wrote:

...

Thanks for taking on yet another task that has been on my TODO list for a decade.

I decided many years ago that the "process identifier" should actually be a string (or at least not something as constrained as an int), in keeping with Java's OS-independent nature, even though all implementations may in fact use an integer. IIRC, Apollo computers used a hostname/int pair as a process identifier, and such a convention may become popular again in the future.

Furthermore, returning a string is in practice at least as convenient, since the only thing you can typically do with a pid today is pass it as a string to a system command like "kill".

On Mon, May 12, 2014 at 12:44 PM, roger riggs <roger.riggs@oracle.com

...

wrote:

...

Please review and comment on this long requested addition to provide the native process id of a spawned Process.

Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ Issue: https://bugs.openjdk.java.net/browse/JDK-8003488

Thanks, Roger

Hi, For system local process identifiers, all of the systems I'm aware are 32 bit integers, printed and parsed in decimal for ease of use. I would describe the native pid as: The native process id is the identifier commonly used in the operating system APIs and commands to show the status of and manage processes; typically a decimal number with 1 to 6 digits. The Apollo system used a string to be able to uniformly address processes across hosts and it was parseable to host and decimal pid. I anticipate a ProcessHandle type with methods to check if the process is alive, to destroy it, wait for it to terminate, etc. It would be a supertype of Process but not all ProcessHandles would be processes since they were not created by Process/ProcessBuilder and have different security concerns and checks. ProcessHandles would be returned from factory methods like current(long pid) or current(). If Java is ported to a system with non-numeric process identifiers it would be viable to add appropriate factory methods. Roger On 5/12/2014 5:01 PM, Alan Bateman wrote:

On 12/05/2014 20:44, roger riggs wrote:

...

Please review and comment on this long requested addition to provide the native process id of a spawned Process.

Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 I think the representation of the pid needs consideration - we need to be happy that using a long is the right thing to do and won't cause us problems in the future and won't conflict with other APIs that we might add in this area.

In terms of spec then it might be helpful to say a bit more to define a "native process id", even in an abstract way.

-Alan

Hi, The webrev has been updated to more completely describe the pid: "The native process id is an identification number that the operating system assigns to the process." Any other comments? Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ <http://cr.openjdk.java.net/%7Erriggs/webrev-getpid-8003488/> Issue: https://bugs.openjdk.java.net/browse/JDK-8003488 Thanks, Roger

Hi Roger! On 22.05.2014 17:49, roger riggs wrote:

Hi,

The webrev has been updated to more completely describe the pid: "The native process id is an identification number that the operating system assigns to the process."

Any other comments?

I assume it compiles fine, but in src/windows/native/java/lang/ProcessImpl_md.c: 258 DWORD pid = GetProcessId(handle); GetProcessId requires an argument of type HANDLE, which is defined as void*. Wouldn't it be better to explicitly cast jlong to HANDLE? Sincerely yours, Ivan

Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ <http://cr.openjdk.java.net/%7Erriggs/webrev-getpid-8003488/> Issue: https://bugs.openjdk.java.net/browse/JDK-8003488

Thanks, Roger

Thanks for the feedback and recommendations; the webrev has been updated. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ Alan, on the use of tasklist, I think a cleaner test can be written when the Java API to inspect other processes is available. I did not find a straightforward eqivalent for $$; there is a possible hack using tasklist but it would be a throwaway. Roger On 5/22/2014 11:01 AM, Alan Bateman wrote:

On 22/05/2014 14:49, roger riggs wrote:

...

Hi,

The webrev has been updated to more completely describe the pid: "The native process id is an identification number that the operating system assigns to the process."

Any other comments?

Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ Roger and I discussed this one last week so I'm happy with the signature and javadoc.

I see Ivan has picked up on the HANDLE <--> jlong and jlong_to_ptr is normally the macro that we use for that.

A minor consistency point is that the getPid is added before the constructor whereas the other overrides are below the constructor.

For the test then it would be good to add the issue number to the @bug line.

One question on the test as I'm not familiar with output of tasklist. If 2+ test were to run tasklist at the same time then could it confuse this test? I'm just wondering if there is anything closer to echo $$.

Otherwise looks good to me.

-Alan.

Looks good to me too (but I'm sure Alan did a more careful review than I). On Tue, May 27, 2014 at 6:30 AM, Alan Bateman <Alan.Bateman@oracle.com> wrote:

On 22/05/2014 20:47, roger riggs wrote:

...

Thanks for the feedback and recommendations; the webrev has been updated.

Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/

Alan, on the use of tasklist, I think a cleaner test can be written when the Java API to inspect other processes is available. I did not find a straightforward eqivalent for $$; there is a possible hack using tasklist but it would be a throwaway.

Roger

The updated webrev looks good to me. On tasklist then what you have is fine for now, it can always be re-visited if it gives trouble or there is an API available.

-Alan.

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. -Alan.

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.

On 05/22/2014 10:34 AM, David M. Lloyd wrote:

On 05/22/2014 08:49 AM, roger riggs wrote:

...

Hi,

The webrev has been updated to more completely describe the pid: "The native process id is an identification number that the operating system assigns to the process."

Any other comments?

Webrev: http://cr.openjdk.java.net/~rriggs/webrev-getpid-8003488/ <http://cr.openjdk.java.net/%7Erriggs/webrev-getpid-8003488/> Issue: https://bugs.openjdk.java.net/browse/JDK-8003488

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.

Refining that thought - on Linux, process IDs and thread IDs share a namespace, but maybe that isn't true on all platforms. Still calling it "getPid" seems very UNIX-specific. Process.getNativeId() seems "safer" or more future-proof to me, somehow. -- - DML