RFR: 8367475: Incorrect lock usage in LambdaFormInvokers::regenerate_holder_classes

[Ioi Lam]

On Thu, 11 Sep 2025 20:58:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The assert happens because we attempt to allocate Java objects while holding a mutex:
>> 
>> 
>>     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
>>     list_lines = oopFactory::new_objArray_handle(vmClasses::String_klass(), len, CHECK);
>>     for (int i = 0; i < len; i++) {
>>       Handle h_line = java_lang_String::create_from_str(_lambdaform_lines->at(i), CHECK);
>> 
>> 
>> It's possible for the allocations to trigger a call to Java when JVMTI is enabled.
>> 
>> The fix is to do the allocation outside of the mutex. However, we still use the mutex to make sure we have a consistent view of `_lambdaform_lines`, which may be modified by concurrent Java threads.
>
> src/hotspot/share/cds/lambdaFormInvokers.cpp line 133:
> 
>> 131:     // Stop other threads from recording into _lambdaform_lines.
>> 132:     MutexLocker ml(Thread::current(), LambdaFormInvokers_lock);
>> 133:     _stop_appending = true;
> 
> Should we assert only one thread can set this _stop_appending? If multiple threads go through this, I recommend adding a distinct logging message from the "Nothing to regenerate" below.

I added an assert that this function can be called only from the "dumper thread", which is the Java thread that drives the AOT cache creation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27231#discussion_r2342415440