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

[Chen Liang]

On Thu, 11 Sep 2025 17:22:20 GMT, Ioi Lam <iklam 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.

Seems reasonable.

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.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27231#pullrequestreview-3213815081
PR Review Comment: https://git.openjdk.org/jdk/pull/27231#discussion_r2342327339