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