Losing features of JVM_Open, e.g. CLOEXEC
neugens.limasoftware at gmail.com
Wed Oct 29 21:15:52 UTC 2014
We should have spotted it in the review though.
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
> | 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
> | longer uses JVM_Open, which is a code hygiene regression.
> | What we want is to have almost all file descriptors have the
> | 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
> | *more* shared native code infrastructure, but here we seem to be moving
> | 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.
More information about the core-libs-dev