RFR: 8308745: ObjArrayKlass::allocate_objArray_klass may call into java while holding a lock

Coleen Phillimore coleenp at openjdk.org
Wed Mar 6 13:01:50 UTC 2024


On Tue, 5 Mar 2024 23:13:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This change creates a new sort of native recursive lock that can be held during JNI and Java calls, which can be used for synchronization while creating objArrayKlasses at runtime.
>> 
>> Passes tier1-7.
>
> Is the caller always a JavaThread?  I'm wondering if your new recursive lock class could use the existing ObjectMonitor.  I thought David asked the same question, but I can't find it.

@dean-long An ObjectLocker on the mirror oop for InstanceKlass might work for this but as @dholmes-ora said we've been trying to purge the ObjectLocker code from the C++ code because it's complicated by the Java Object monitor project.  The JOM project may throw exceptions from the ObjectLocker constructor or destructor and the C++ code doesn't currently know what to do.  We removed the ObjectLockers around class linking and some JVMTI cases.  There are some in class loading but with a small amount of work, they can be removed also. 

The caller is always a JavaThread, some lockers are at a safepoint for traversal but the multi-arrays are only created by JavaThreads.

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

PR Comment: https://git.openjdk.org/jdk/pull/17739#issuecomment-1980812019


More information about the hotspot-dev mailing list