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

[Alan Bateman]

On 01/02/2013 18:12, Martin Buchholz wrote:
> :
>
> My comments are all very high level.
>
> The history of generic C-level infrastructure in the JDK is 
> unsuccessful.  The JVM_ functions were apparently a failure, but who 
> is willing to own the problem of a suitable replacement?  Leaving the 
> problem up to individual component teams is a recipe for each 
> component having different interesting bugs using the same functionality.
>
> The obvious examples are: all internal file operations in the JDK 
> should be using LARGEFILE variants on 32-bit platforms.   And all file 
> descriptor creations should be using O_CLOEXEC by default (much less 
> important).  Does anyone own this problem?
>
The JVM/HPI was useful and important (particularly to I/O and networking 
areas) when we had different threading models. We've required native 
threading support for a long time now so the need to go through the VM 
has mostly gone away. Also in recent years we are making using of highly 
platform specific I/O facilities that aren't intended for porting to 
other platforms.

We don't have a replacement and it's a good discussion point. A porting 
interface for the libraries would help in some areas, although not all 
because of the broad set of services and interfaces that are used. 
Without such an interface then it does mean a little bit of duplication 
and potential for inconsistencies. Common operations like we are 
discussing here could be easily supported as utility functions in 
libjava or elsewhere, we just haven't had any discussion here about this 
topic.

Anyway, on the specifics then we should be using open64 or open with the 
LARGEFILE flag everywhere. You pointed out issue a few days ago with the 
launcher parsing the JAR manifest. You should push the patch for that. 
Also shout/propose patches if you find others.

I think the close-on-exec issue does need a bit of thought. We have 
several places that open files or sockets and they aren't using it so we 
are dependent on the exec code to close the file descriptors in the 
child. I haven't come across any bug reports so it's possible that there 
aren't too many people doing fork/equivalent in native code. I do agree 
we should look at it, although it less important as you point you.

-Alan