Losing features of JVM_Open, e.g. CLOEXEC

[David Holmes]

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