Review Request: JDK-8001334 - Remove use of JVM_* functions from java.io code
dan.xu at oracle.com
Tue Mar 5 18:39:09 UTC 2013
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!
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
>> 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
More information about the core-libs-dev