[External] : Re: Virtual Threads - deadlock with synchronized (Main.class) and System.out.println

[Ron Pressler]

TBD. We know there’s a problem with class loading that we’d like to fix, and compensation is a possible approach we’re testing.

> On 18 Jul 2023, at 00:22, Brian S O'Neill <bronee at gmail.com> wrote:
> 
> Is the native upcall work intended to fix all native upcalls or just for class loading?
> 
> On 2023-07-17 04:18 PM, Ron Pressler wrote:
>> The best fix is to get synchronized to not pin; we’re working hard on that.
>> The problem can occur whenever a shared j.u.c lock is acquired both inside and outside a synchronized (and println acquires a shared lock for the output stream). For now, this can be detected with the JFR pinning event, and the fix is to replace the synchronized that guards the lock acquisition with a j.u.c lock.
>> This can also happen with pinning due to a native methods on the stack, which, in practice, primarily means class loading (class loading uses a native VM method that calls back into Java). For the past couple of months we’ve been testing a specialized fix for that that uses compensation (just note that it isn’t the same as compensating due to a blocking native method — what we recently discussed here — only a pinning native method, i.e. a native method that upcalls into Java, and class loading in particular).
>> — Ron