Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code (original) (raw)

Martin Buchholz martinrb at google.com
Fri Feb 1 02:23:08 UTC 2013

You could operate in paranoid mode and do both : use O_CLOEXEC and use fcntl to set the bit after creating it, perhaps after verifying via fcntl whether the bit was successfully set by open.

Martin

On Thu, Jan 31, 2013 at 12:07 PM, Dan Xu <dan.xu at oracle.com> wrote:

Hi Karen,

In my opinion, it is recommemded to use OCLOEXEC flag directly in open() function than setting it later via fcntl(). And according to the man page on Solaris and Mac, open() behaves the same on those platforms. I only find the support platform list for jdk7 at http://www.oracle.com/** technetwork/java/javase/**config-417990.html<http://www.oracle.com/technetwork/java/javase/config-417990.html>. Because Linux 2.6.23 was released long ago on Oct 9, 2007, most platforms should already have the support to OCLOEXEC flag. Thanks, -Dan

On 01/31/2013 07:30 AM, Karen Kinnear wrote: Dan, I had a question on this comment. Should we fix this in hotspot? So you mention recent Linux open() documentation. How does this behave on Solaris and Mac? I assume the library code is shared code across platforms. Also - what is the oldest Linux we support for JDK8? thanks, Karen On Jan 29, 2013, at 6:55 AM, Alan Bateman wrote:

- I don't think the OCLOEXEC code is needed in handleOpen, was this copied from HotSpot? In the original hotspot code, it has one section to enable the close-on-exec flag for the new file descriptor as the following. #ifdef FDCLOEXEC { int flags = ::fcntl(fd, FGETFD); if (flags != -1) ::fcntl(fd, FSETFD, flags | FDCLOEXEC); } #endif According to the comment, "All file descriptors that are opened in the JVM and not specifically destined for a subprocess should have the close-on-exec flag set. If we don't set it, then careless 3rd party native code might fork and exec without closing all appropriate file descriptors (e.g. as we do in closeDescriptors in UNIXProcess.c), and this in turn might: - cause end-of-file to fail to be detected on some file descriptors, resulting in mysterious hangs, or - might cause an fopen in the subprocess to fail on a system suffering from bug 1085341." And the recent open() function (since Linux 2.6.23) already has OCLOSEXEC flag to enable this flag by default. And it is a preferred way according to the man page, " Specifying this flag permits a program to avoid additional fcntl(2) FSETFD operations to set the FDCLOEXEC flag. Addi-tionally, use of this flag is essential in some multithreaded programs since using a separate fcntl(2) FSETFD operation to set the FDCLOEXEC flag does not suffice to avoid race conditions where one thread opens a file descriptor at the same time as another thread does a fork(2) plus execve(2). Additionally, if OCLOEXEC is not supported, FDUPFDCLOEXEC is preferred than FDCLOEXEC, which is what hotspot is using right now. I don't think we need this because the file descriptor will be closed at exec time anyway (there is logic in Runtime.exec to iterate over the file descriptors and close them). Also we don't do this in other areas of the platform where we use open directly.

More information about the core-libs-dev mailing list