Virtual Threads - deadlock with synchronized (Main.class) and System.out.println

Brian S O'Neill bronee at gmail.com
Mon Jul 17 23:22:24 UTC 2023


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
> 


More information about the loom-dev mailing list