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

Dan Xu dan.xu at oracle.com
Tue Mar 5 18:39:09 UTC 2013

Hi All,

Thanks for your good suggestions. I have updated this fix and put the new webrev at http://cr.openjdk.java.net/~dxu/8001334/webrev.01/. Please help review it. Thanks!

-Dan

On 02/01/2013 01:25 PM, Alan Bateman wrote:

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

More information about the core-libs-dev mailing list