Losing features of JVM_Open, e.g. CLOEXEC

[Martin Buchholz]

On Thu, Oct 30, 2014 at 6:08 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> The change in behavior from JVM_Open ito open was missed but there is a long
> way to go in JDK 9 so lots of time to fix the issue (if there is an issue).

The changes to zip file file descriptors is just the one most visible to me.

> As was noted in one of the replies, the only usages of JVM_Open were in the
> zip code, it hasn't been used consistently used in the libraries for at
> least 10+ years. When doing significant changes then thorough code reviews
> are important but good tests are equally, and sometimes more, important. I
> understand that having a test for the O_CLOEXEC might be too hard so I'm
> interested to know how you ran into it. Maybe it was inspection?

My hobby is running strace on the JDK and counting the fds with
close-on-exec flag.
I noticed that the calls to fcntl(...FD_CLOEXEC) had disappeared!
You're unlikely to get bug reports because of the action-at-a-distance
non-debuggability.

> Maybe an
> app that opens lots of zip files and executes fork/exec itself? For
> ProcessBuilder and Runtime.exec usages then the I thought the childproc code
> handled this by looping over the open file descriptors and closing them. So
> even if O_CLOEXEC or fcntl(FD_CLOEXEC) isn't used then it should be closed
> in the child.

In general, Java is just a guest inside some Unix process, and should
be well-behaved.

> As to whether we need a JVM_Open replacement in libjava then maybe we do but
> I think it needs a discussion as to whether the JDK really needs a porting
> interface or just useful infrastructure. Also I think going forward then I
> assume that the amount of native code will reduce, particularly when FFI
> comes along and we start to get rid of some of the native code (at least I
> hope that happens).

I think it will just become more convenient to call the native code.
Perhaps the common infrastructure can be written in Java, but it
should still exist.

> In the mean-time then I think I'd like to understand more as to whether the
> O_CLOEXEC is an issue or not. Aside from the zip code then I don't think
> we've been using it consistently so I'm wondering if the issue is some
> native code calling fork+exec or something else?

Yes.  All broken since forever.

I'm focused on close-on-exec, but there's also restartable system
calls to consider.
And partial reads ...