On 30/10/2014 7:15 AM, Mario Torre wrote:
+1
We should have spotted it in the review though.
My thoughts exactly! Further only 2 calls were changed both in the zip
code, while raw open is used in quite a number of other places in the
JDK code. So while I can understand there may be a desire to add an
abstraction layer where things like CLOEXEC can be added, I don't think
the removal of JVM_Open can be considered a "lost feature".
David
Cheers,
Mario
Il 29/ott/2014 21:47 "Christos Zoulas" <[email protected]> ha scritto:
On Oct 29, 1:12pm, [email protected] (Martin Buchholz) wrote:
-- Subject: Losing features of JVM_Open, e.g. CLOEXEC
| throwing away use of old shared infrastructure and replacing with "naked"
| calls to the OS. Although understandable, this abandons benefits of
using
| shared infrastructure. Here I'm thinking of the close-on-exec flag. I
| just added use of O_CLOEXEC to linux hotspot, but e.g. zip file opening
no
| longer uses JVM_Open, which is a code hygiene regression.
|
| What we want is to have almost all file descriptors have the
close-on-exec
| flag automatically set at fd creation time, using O_CLOEXEC where
| available, and FD_CLOEXEC where not. How do we get there?
|
| I'm distressed that the JDK core libraries should be moving towards
having
| *more* shared native code infrastructure, but here we seem to be moving
in
| the opposite direction. Having abandoned JVM_Open, the responsibility of
| doing these things right belongs entirely to the core libraries team. So
| where's the core-library replacement for JVM_Open?
I totally agree with Martin here. Changes like this are harmful.
christos
