[flagged]
You can code in async/await style in Java too, using `CompletableFuture.supplyAsync` and `CompletableFuture.get`
Using Virtual Threads is a choice, it's not forced on to you.
We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
51–60 of 253 posts
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#52I am extremely confused. > There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier: > When it executes code inside a synchronized block or method Isn't 'synchronized' effectively sugar for taking a kind of lock? Why can't it be treated uniformly by the scheduler?
No, synchronized is a very primitive lock implementation compared to what's available in java.util.concurrent.Locks.
However, it's built directly into the JVM specification, so it's difficult to change while keeping compatibility, while j.u.c.Locks is just a library. In other words, they can't change synchronized schematic, so they created j.u.c.Locks as a replacement.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#53"Why not to use java virtual threads" -> Fundamental features of the language treated as implementation details in libraries for more than two decades cause deadlock.
[deleted]
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#54Earlier quoted context omitted.
From a relatively brief skim and past Go and Java experience: synchronized blocks the current normal thread, so that doesn't really seem any different to me. If you starve your threads, you starve your threads. It definitely leaves room to optimize by not pinning that thread, which would be great, but that shouldn't change semantics at all. Or is there something actually screwed up in the implementation of virtual th…
It’s a thread that supports n virtual threads. You want synchronized in virtual thread a and not the carrier thread which will block all the virtual threads. Been away from Java land for a while. How did something like that even get into release? That’s like a pretty big loaded shotgun to leave lying around with lots of kids playing, no?
I agree. Seems like a huge Java design error.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#55Go has a mechanism to spawn a new thread (m in ho runtime parlance) if it thinks one of its threads might be blocked in a cgo (go’s “native function” equivalent). That prevents stuff like this.
Java does the same for Object.wait(), only the number of such compensating threads is limited by default, but can be extended via config option. They have exhausted the default number of compensating threads, I think.
And they are mistaken to call this situation a "pinning"
JEP 444:
> The vast majority of blocking operations in the JDK will unmount the virtual thread, freeing its carrier and the underlying OS thread to take on new work. However, some blocking operations in the JDK do not unmount the virtual thread, and thus block both its carrier and the underlying OS thread. This is because of limitations at either the OS level (e.g., many filesystem operations) or the JDK level (e.g., Object.wait()). The implementations of these blocking operations compensate for the capture of the OS thread by temporarily expanding the parallelism of the scheduler. Consequently, the number of platform threads in the scheduler's ForkJoinPool may temporarily exceed the number of available processors. The maximum number of platform threads available to the scheduler can be tuned with the system property jdk.virtualThreadScheduler.maxPoolSize.
(In my testing the default ForkJoinPool limit was 256)
So theoretically they could have extended the jdk.virtualThreadScheduler.maxPoolSize to a number sufficient for the use case. Although their workaround with semaphores is probably more reliable - no need to guess the sufficient number.
The situation with Object.wait() is not what JEP 444 calls "pinning". The "pinning" happens, for example, when one calls `syncronized(....) {blockingQueue.take()}`, which is not sane coding, BTW. In this case the native thread is blocked and is not compensated by another thread - much worse than the Object.wait(). The number of native threads that run virtual threads is equal to the number of CPUs by default, so "pinning" immediately makes one CPU unavailable to the virtual threads of the application.
All those issues are temporarily, as I understand. The JDK team works for fix Object.wait(), synchronized, etc.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#56Totally off topic but I am getting tired of the AI generated images used on nearly all blog posts nowadays. They are instantly recognisable, it just seems low effort and lowers the feeling of quality one might otherwise have
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#57Go has a mechanism to spawn a new thread (m in ho runtime parlance) if it thinks one of its threads might be blocked in a cgo (go’s “native function” equivalent). That prevents stuff like this.
So does C# with active blocking detection (which injects threads to counteract this) and hill climbing algorithm to scale threadpool threads automatically.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#58Totally off topic but I am getting tired of the AI generated images used on nearly all blog posts nowadays. They are instantly recognisable, it just seems low effort and lowers the feeling of quality one might otherwise have
Typically it’ll be in lieu of nothing or stock photography. Doesn’t it seem better than that?
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#59Totally off topic but I am getting tired of the AI generated images used on nearly all blog posts nowadays. They are instantly recognisable, it just seems low effort and lowers the feeling of quality one might otherwise have
Typically it’ll be in lieu of nothing or stock photography. Doesn’t it seem better than that?
Not really. I wish the trend of giant generic hero images on every blog post would go away, they almost never add any value. I think it was Medium that started the trend.
Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres
#60Totally off topic but I am getting tired of the AI generated images used on nearly all blog posts nowadays. They are instantly recognisable, it just seems low effort and lowers the feeling of quality one might otherwise have
Typically it’ll be in lieu of nothing or stock photography. Doesn’t it seem better than that?
Genuinely it's a downgrade in my opinion