Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

blog.ydb.tech

Post reply on HN
Print view View original

201–210 of 253 posts

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#201

Post by kaba0 »

i000 wrote: post #187
pron wrote: post #172

Earlier quoted context omitted.

As the JEP states, pinning due to synchronized is a temporary issue. We didn't want to hold off releasing virtual threads until that matter is resolved (because users can resolve it themselves with additional work), but a fix already exists in the Loom repository, EA builds will be offered shortly for testing, and it will be delivered in a GA release soon. Those who run into this issue and are unable or unwilling to…

Wow, I would love to be in the meeting where this decision was made. Let's ship this with a foot gun, but lets not mention in the JEP that it may hang - let them figure it out.

You might accidentally write an infinite loop as well - should we not use Turing-complete languages or what?

It’s not like multithreaded computing wasn’t full of footguns anyway.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#202

Post by bigbillheck »

blindriver wrote: post #66
mrintegrity wrote: post #56

Totally 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

I prefer AI generated images over stock photos though. You can tell that both are phony, but at least the AI can be a bit more creative.

People in stock photos can generally be counted on to have no more than a traditional number of hands.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#204

Post by spintin »

bitcharmer wrote: post #127
spintin wrote: post #87

The warning shots across the bow where heard with this statement from the devs: "Don't replace platform/native threads with virtual ones, replace tasks (without further explanation) instead"?! Combine that with the fact that they chose to implement the scheduler in Java instead of C(++) and you're set for performance problems. Remember that NIO took from 1.5 to 1.7 to be usable/performant and that was native! Edit: F…

> Combine that with the fact that they chose to implement the scheduler in Java instead of C(++) and you're set for performance problems. Ah yes, the argument from the 1990s. It would make sense to understand where the JVM and its compiler are these days before making incorrect statements about performance. From your link: > Blocking network TCP IO needs a sychronized block to work This is utterly false.

So how do you implement a TCP socket?

I have always had to do synchronized(something) { socketInputStream.read(); }

And the dude himself says that reading from a socket is a problem if you listen to the interview.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#205

Post by josefx »

cesarb wrote: post #183
pron wrote: post #172

Earlier quoted context omitted.

As the JEP states, pinning due to synchronized is a temporary issue. We didn't want to hold off releasing virtual threads until that matter is resolved (because users can resolve it themselves with additional work), but a fix already exists in the Loom repository, EA builds will be offered shortly for testing, and it will be delivered in a GA release soon. Those who run into this issue and are unable or unwilling to…

> unable or unwilling to do the work to avoid it The problem is that it's rare to write code which uses no third-party libraries, and these third-party libraries (most written before Java virtual threads ever existed) have a good chance of using "synchronized" instead of other kinds of locks; and "synchronized" can be more robust than other kinds of locks (no risk of forgetting to release the lock, and on older JVMs,…

> have a good chance of using "synchronized" instead of other kinds of locks; and "synchronized" can be more robust than other kinds of locks (no risk of forgetting to release the lock, and on older JVMs, no risk of an out-of-memory while within the lock implementation breaking things),

I haven't professionally written Java in years, however from what I remember synchronized was considered evil from day one. You can't forget to release it, but you better got out of your way to allocate an internal object just for locking because you have no control who else might synchronize on your object and at that point you are only a bit of syntactic sugar away from a try { lock.lock();}finally{lock.unlock();} .

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#206

Post by eklavya »

i000 wrote: post #187
pron wrote: post #172

Earlier quoted context omitted.

As the JEP states, pinning due to synchronized is a temporary issue. We didn't want to hold off releasing virtual threads until that matter is resolved (because users can resolve it themselves with additional work), but a fix already exists in the Loom repository, EA builds will be offered shortly for testing, and it will be delivered in a GA release soon. Those who run into this issue and are unable or unwilling to…

Wow, I would love to be in the meeting where this decision was made. Let's ship this with a foot gun, but lets not mention in the JEP that it may hang - let them figure it out.

I would like to take this opportunity to thank pron and the amazing jdk developers for working on a state of the art runtime and language ecosystem and providing it for free. Please ignore the entitled, there are many many happy Dev's who can't thank you all enough.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#207

Post by delusional »

xmcqdpt2 wrote: post #193
delusional wrote: post #80

Earlier quoted context omitted.

> The situation with Object.wait() is not what JEP 444 calls "pinning". The "pinning" happens, for example, when one calls `syncronized(....) {blockingQueue.take()}` [...] To call Object.wait() you need to own the objects monitor, which would imply that your code would actually look like `synchronized(....) {Object.wait()}` in which case you would indeed be pinned.

Object.wait() releases the monitor lock though. This specific case doesn't have to do with synchronized at all, but with wait() being a native call.

That makes sense to me. I'll agree to not call Object.wait() pinning.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#208

Post by hashmash »

josefx wrote: post #205
cesarb wrote: post #183

Earlier quoted context omitted.

> unable or unwilling to do the work to avoid it The problem is that it's rare to write code which uses no third-party libraries, and these third-party libraries (most written before Java virtual threads ever existed) have a good chance of using "synchronized" instead of other kinds of locks; and "synchronized" can be more robust than other kinds of locks (no risk of forgetting to release the lock, and on older JVMs,…

> have a good chance of using "synchronized" instead of other kinds of locks; and "synchronized" can be more robust than other kinds of locks (no risk of forgetting to release the lock, and on older JVMs, no risk of an out-of-memory while within the lock implementation breaking things), I haven't professionally written Java in years, however from what I remember synchronized was considered evil from day one. You can'…

The fact that the monitor is public rarely causes issues, and in those cases where it's used on internal objects, it's not really public anyhow.

There's an additional benefit to using the built in monitors, and that has to do with heap allocation. The data structure for managing it is allocated lazily, only when contention is actually encountered. This means that "synchronized" can be used as a relatively low cost defensive coding practice in case an object which isn't intended to be used by multiple threads actually is.

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#209

Post by neonsunset »

Rapzid wrote: post #158
neonsunset wrote: post #57

Earlier quoted context omitted.

So does C# with active blocking detection (which injects threads to counteract this) and hill climbing algorithm to scale threadpool threads automatically.

Which is very handy sometimes. The default throttling is a bit conservative though and perhaps based on Windows thread costs.

It used to be the case - before .NET 6 there was only hill climbing so poorly written blocking code could starve threadpool very quickly (for + Task.Run + Thread.Sleep and the like), but since 6 blocking threads in such a way makes threadpool inject more threads without going through hill climbing mitigating the impact much more effectively. This does not mean such code should not be fixed however :)

Re: We switched to Java 21 virtual threads and got a deadlock in TPC-C for Postgres

#210

Post by bunderbunder »

josefx wrote: post #205
cesarb wrote: post #183

Earlier quoted context omitted.

> unable or unwilling to do the work to avoid it The problem is that it's rare to write code which uses no third-party libraries, and these third-party libraries (most written before Java virtual threads ever existed) have a good chance of using "synchronized" instead of other kinds of locks; and "synchronized" can be more robust than other kinds of locks (no risk of forgetting to release the lock, and on older JVMs,…

> have a good chance of using "synchronized" instead of other kinds of locks; and "synchronized" can be more robust than other kinds of locks (no risk of forgetting to release the lock, and on older JVMs, no risk of an out-of-memory while within the lock implementation breaking things), I haven't professionally written Java in years, however from what I remember synchronized was considered evil from day one. You can'…

Is there a similarly low-level synchronization mechanism that doesn't work this way? .NET's does the same thing.

I guess I might have preferred if both Java and .NET had chosen to use a dedicated mutex object instead of hanging the whole thing off of just any old instance of Object. But that would have its own downsides, and the designers might have good reason to decide that they were worse. Not being able to just reuse an existing object, for example, would increase heap allocations and the number of pointers to juggle, which might seriously limit the performance of multithreaded code that uses a very fine-grained locking scheme.

Post reply on HN