Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code
Alan.Bateman at oracle.com
Fri Feb 1 21:25:38 UTC 2013
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
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
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.
More information about the core-libs-dev