Process API Updates (JEP 102)
roger.riggs at oracle.com
Thu Aug 28 16:58:06 UTC 2014
I have not looked at that idea closely but I would be concerned
about the robustness of the 2nd, execve'd Java runtime. Since it would
a brand new process, there might be leftover state from the previous
execution that would break the usual assumptions of a newly started Java
Anything from signal handler state to open file descriptors to the specific
memory mapping and there may be others.
On 8/26/2014 7:25 AM, Ron Pressler wrote:
> I might be a little late to this party, but recently I've had a (rather
> frustrating) need for the ability to execve a process rather than fork-exec
> it. I understand that the ability to exec (replace the current process's
> image) is also available on Windows. This operation (on ProcessBuilder?),
> which never returns, would have the same semantics as
> System.exit(pb.start().waitFor()), only it would replace the current JVM
> process (i.e. maintain the same pid/handle) with the command.
> This is required when a JVM process is used to set up and launch another,
> JVM or other, process, but we'd want the user running the program to be
> oblivious to the setup process (because, say, they want to monitor the
> running program with some OS tool).
More information about the core-libs-dev