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

[Dan Xu]

Hi Karen,

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 
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 O_CLOEXEC 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 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);
>>>                }
>>>            #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 
>>> 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.
>>
>>>
>