Losing features of JVM_Open, e.g. CLOEXEC

[Mario Torre]

+1

We should have spotted it in the review though.

Cheers,
Mario
Il 29/ott/2014 21:47 "Christos Zoulas" <christos at zoulas.com> ha scritto:

> On Oct 29,  1:12pm, martinrb at google.com (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
>