RFR: 8266310: deadlock while loading the JNI code [v5]

[Aleksei Voitylov]

On Mon, 24 May 2021 06:24:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix whitespace
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 511:
> 
>> 509:             if (currentLock.getCounter() == 1) {
>> 510:                 // unlock and release the object if no other threads are queued
>> 511:                 currentLock.unlock();
> 
> This isn't atomic so I don't see how it can work as desired. Overall I don't understand what the semantics of this "counted lock" are intended to be.

Hi David,

The locking strategy is as follows:

CountedLock is a subclass of ReentrantLock that allows exact counting of threads that intend to acquire the lock object. Each time a thread calls acquireNativeLibraryLock() with a certain name, either a new CountedLock object is allocated and assigned 1 as the counter, or an existing CountedLock is incremented prior to invocation of the lock() method on it. The increment operation to the lock object is performed in the context of execution of compute() method, which is executed atomically. This allows to correctly dispose the CountedLock object when the last thread in the queue leaves releaseNativeLibraryLock(). The entire remapping function passed to computeIfPresent() method is executed atomically. 

Could you be more specific on what is not performed atomically?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3976