Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code
dan.xu at oracle.com
Thu Jan 31 20:07:24 UTC 2013
In my opinion, it is recommemded to use O_CLOEXEC 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
Because Linux 2.6.23 was released long ago on Oct 9, 2007, most
platforms should already have the support to O_CLOEXEC flag.
On 01/31/2013 07:30 AM, Karen Kinnear wrote:
> 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?
> On Jan 29, 2013, at 6:55 AM, Alan Bateman wrote:
>>>> - I don't think the O_CLOEXEC 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 FD_CLOEXEC
>>> int flags = ::fcntl(fd, F_GETFD);
>>> if (flags != -1)
>>> ::fcntl(fd, F_SETFD, flags | FD_CLOEXEC);
>>> 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
>>> O_CLOSEXEC 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) F_SETFD
>>> operations to set the FD_CLOEXEC flag. Addi-tionally, use of this
>>> flag is essential in some multithreaded programs since using a
>>> separate fcntl(2) F_SETFD operation to set the FD_CLOEXEC 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 O_CLOEXEC is not supported, F_DUPFD_CLOEXEC is
>>> preferred than FD_CLOEXEC, 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