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

[Karen Kinnear]

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.
> 
>>