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

[Dan Xu]

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