RFR: 8244936: Reduce JNI overhead of accessing FileDescriptor

Peter Levart peter.levart at gmail.com
Mon May 18 10:18:25 UTC 2020


On 5/18/20 11:11 AM, Alan Bateman wrote:
> On 18/05/2020 09:59, Peter Levart wrote:
>> :
>>
>> Please elaborate. Do you have an example of such use case? Are there 
>> any existing races possible?
> Everywhere that closes a file descriptor needs to coordinate the 
> closing with threads that may be accessing that file descriptor, 
> otherwise you risk doing I/O on file descriptors that have been 
> recycled. This has always been problematic for the legacy java.io 
> classes, so the concern is that increasing the window where you are 
> using the "raw" file descriptor will make it worse.
>
> -Alan.


Ah, that. So the concern is that the operation performed would be 
performed on the wrong file because the fd/handle would be recycled. So 
here you assume that transition from java to native code takes 
considerably more time than the part of GetIntField JNI API call between 
reading the field value and completing the call? Or is the transition to 
native code equipped with some sort of implicit memory barrier so that 
reading the filed from native code makes it more recent? If that last is 
the case then perhaps such memory barrier could be issued in java code 
too...


Regards, Peter




More information about the core-libs-dev mailing list