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