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

181–190 of 253 posts

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

#181

Post by nottorp »

marginalia_nu wrote: post #175
nottorp wrote: post #174

Earlier quoted context omitted.

Thanks! > Why two sentences? Maybe you should ask ChatGPT if you want explanations with specific length requirements. As you can see, people can do it better. I put a limit on it because I didn't want an explanation of what threads are, just of the difference.

The post you replied to had four sentences. (But two paragraphs).

The explanation had two sentences :)

Edit: why are some commenters on HN so literal minded anyway? This is free form chat not code specs. You could have read "2 sentences" as "concise", you know...

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

#182

Post by mrkeen »

hoseja wrote: post #152

BTW, dining philosophers is an extremely clunky example.

I was looking to see how it would be relevant, and then:

> we present a case study on how we encountered a deadlock with virtual threads in TPC-C for PostgreSQL, even without the dining philosophers problem.

I guess it was a clunky non-example!

(I was hoping to see a virtual thread solution to compare to:

  https://www.adit.io/posts/2013-05-15-Locks,-Actors,-And-STM-In-Pictures.html
  https://www.youtube.com/watch?v=aQXgW55f7cg
  https://hackage.haskell.org/package/stm
)

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

#183

Post by cesarb »

pron wrote: post #172
synthetigram wrote: post #72

This problem is not going to go away so easily. Numerous core Java classes (like BufferedInputStream) use synchronized. I count 1600+ usages in java.base. The blocking issue means it's _much_ easier to accidentally run into this, rather than waving it away as an unlikely edge case. I personally ran into this Using the built in com.sun webserver, with a virtual thread executor. My VPS only has two CPUs which means the…

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, no risk of an out-of-memory while within the lock implementation breaking things), so people can prefer to use it whenever possible.

To me, this is a deal breaker; it makes it too risky to use virtual threads in most cases. It's better to wait for a newer Java LTS which can unmount virtual threads on "synchronized" blocks before starting to use it.

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

#184

Post by simiones »

nordsieck wrote: post #180
simiones wrote: post #176

Earlier quoted context omitted.

> Virtual threads are nice for unblocking legacy code but they aren't without issues. There are better options for new code with less trade offs on the jvm as well. The designers of Project Loom would say the exact opposite. The whole push behind Project Loom and similar models (Go's oft-praised "goroutines" runtimes being another one) is motivated by Threads being a much better fit for async behavior in a fundamenta…

I don't know. My understanding is that that highest performance webserver is nginx. And it uses async internally. IMO, virtual threads is a better general purpose language feature because it avoids function coloring and is generally easier to reason about, but it may not result in the highest performance Java webserver.

NGINX is a native C implementation, so it has to be carefully written to use the OS's native high-performance IO and native OS threads.

The purpose of project Loom is to abstract that away from Java application code. The runtime can use the most efficient IO for the given platform (ideally io_uring on Linux or IOCP on Windows, for example) even if the application code calls the old blocking File.Write(). The application can then use simple APIs and code patterns, but still get massive performance.

With Loom, you can easily have 20,000 virtual threads servicing 20,000 concurrent HTTP requests and each "blocked" in IO, while only using, say, 100 OS threads that are polling an IOCP. A normal Linux box can typically only handle around maybe 1000 threads across all running processes.

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

#186

Post by ed_elliott_asc »

kelnos wrote: post #111
davidgerard wrote: post #107

Earlier quoted context omitted.

exactly. It says "I can't be bothered producing this" and I feel like, so why should I be bothered reading it?

Ah yes, let's take the most uncharitable explanation and assume that's the case. Maybe they have no artistic ability of their own? Maybe they just aren't good at finding the kinds of images (that can be freely used without infringing on anyone's copyright) that they need? If it were me, and the guidance was "never use AI generated images in your blog post", I would probably just not use any images at all. Which I gue…

It’s something I struggle with - I really can’t draw, I really really can’t draw on a computer.

In the past I’ve used lots of screenshots which seems to work well.

Where I have used images I have cut and pasted and used things like canva but nothing has ever really ended up as I would have liked it.

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

#187

Post by i000 »

pron wrote: post #172
synthetigram wrote: post #72

This problem is not going to go away so easily. Numerous core Java classes (like BufferedInputStream) use synchronized. I count 1600+ usages in java.base. The blocking issue means it's _much_ easier to accidentally run into this, rather than waving it away as an unlikely edge case. I personally ran into this Using the built in com.sun webserver, with a virtual thread executor. My VPS only has two CPUs which means the…

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.

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

#188

Post by xmcqdpt2 »

Groxx wrote: post #34
papercrane wrote: post #9

Earlier quoted context omitted.

The issue here is currently virtual threads don't work well with the 'sychronized' keyword. Right now synchronized will pin the carrier thread. The fix was to switch to a higher-level abstraction that works with virtual threads. My understanding is there is work to make synchronized not pin the carrier thread, but that's some pretty complex and important code to change.

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…

In this case the synchronized blocks are released by calls to Object.wait, so that code would not deadlock with normal threads.

The issue is that Object.wait doesn't suspend virtual threads, so you get deadlocks. The answer is to reimplement usages of the wait/notify pattern to use locks or concurrent collections (for example, using a concurrent message queue for the producer/consumer pattern, which is a common use case for synchronized/wait/notify).

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

#189

Post by mort96 »

hoseja wrote: post #156
mort96 wrote: post #148

Earlier quoted context omitted.

There's a quality spectrum of AI-generated images, sure, but they're all equally artistically void.

Not all.

Yeah they are. Art is communication. Computers don't communicate, they generate.

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

#190

Post by mort96 »

patmorgan23 wrote: post #177
mort96 wrote: post #145

Earlier quoted context omitted.

What value does AI slop add though?

What value does a random stock image add?

Very little, but it might at least have the right amount of hands and a sensible aspect ratio
Post reply on HN