> No pinning virtual threads is huge. Finally you can virtual thread with near-wild abandon, as God intended.
I see that formerly it pinned virtual threads "when it executes code inside a synchronized block or method", and "frequent pinning for long durations can harm the scalability of an application by capturing carriers". You were supposed to "avoid frequent and long-lived pinning by revising synchronized blocks or methods that run frequently and guard potentially long I/O operations to use java.util.concurrent.locks.ReentrantLock instead."
How big a problem was this in practice? On the one hand, I think "harm the scalability" is putting it mildly—if you have a whole bunch of virtual threads doing IO, only running num_cores of them at once is devastating. On the other hand, holding a lock while doing IO smells wrong. Is this really common?
It can deadlock and cause crashes if you do use a library impacted. It's sometimes hard to tell and you'd have to dig into the source. Sometimes the library maintainer wouldn't update the code to a different method for <reasons>.
> Is this really common?
Yes, maybe not in obvious ways e.g. many developers use Spring, which is backed by a large organization and you'd assume to have things covered but under the hood Spring itself uses many libraries and some often open source without much support (can be a personal project by a single developer).
I think in practice it has to do with some libs (eg jdbc drivers) that would be relying on synchronized. If the performance with vthreads was much worse for some cases it would be a bit of failure
> I think in practice it has to do with some libs (eg jdbc drivers) that would be relying on synchronized.
Those usually have company / community backing that gets it fixed. The irony is you patch the ORM and you patch the JDBC driver only to realize the database pooling library in-between is the 1 that's broken and the author refuses to fix it.
Switching `synchronized` for `ReentrantLock` is possible in principle, but it makes the code harder to read and opens the door to subtle concurrency bugs.
Library authors really don't want this kind of code churn for an issue that is not their fault, not their responsibility to solve, and that will get a bugfix before long that maybe even qualifies for a backport to LTS 21.
I see that formerly it pinned virtual threads "when it executes code inside a synchronized block or method", and "frequent pinning for long durations can harm the scalability of an application by capturing carriers". You were supposed to "avoid frequent and long-lived pinning by revising synchronized blocks or methods that run frequently and guard potentially long I/O operations to use java.util.concurrent.locks.ReentrantLock instead."
How big a problem was this in practice? On the one hand, I think "harm the scalability" is putting it mildly—if you have a whole bunch of virtual threads doing IO, only running num_cores of them at once is devastating. On the other hand, holding a lock while doing IO smells wrong. Is this really common?