The signal handler is triggered by the mutator thread due to the installed halt instructions in JIT code (which we already confirmed higher up in the signal handler). Hence, the mutator cannot be in C++ code, and therefore, cannot be already holding the codeBlockSet lock.   The only time the codeBlockSet lock could be in contention is if the Sampling Profiler thread is holding it.  In that case, we'll simply wait till the Sampling Profiler is done with it.  There are no lock ordering issues w.r.t. the Sampling Profiler on this code path.

Note that it is not ok to return SignalAction::NotHandled here if we see contention.  Doing so will cause the fault to be handled by the default handler, which will crash.  It is also not productive to return SignalAction::Handled on contention.  Doing so will simply trigger this fault handler over and over again.  We might as well wait for the Sampling Profiler to release the lock, which is what we should do.

This issue was detected by the stress/get-array-length-concurrently-change-mode.js.ftl-no-cjit-validate-sampling-profiler test, resulting in intermittent crashes.