In order to avoid stranding the Objective-C runtime lock, we switched from objc_copyRealizedClassList to its non locking variant objc_copyRealizedClassList_nolock. Not taking the lock was relatively safe because we run this expression on one thread only, but it was still possible that someone was in the middle of modifying this list while we were trying to read it. Worst case that would result in a crash in the inferior without side-effects and we'd unwind and try again later.
With the introduction of macOS Ventura, we can use objc_getRealizedClassList_trylock instead. It has semantics similar to objc_copyRealizedClassList_nolock, but instead of not locking at all, the function returns if the lock is already taken, which avoids the aforementioned crash without stranding the Objective-C runtime lock. Because LLDB gets to allocate the underlying memory we also avoid stranding the malloc lock.
rdar://89373233
grammar