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
