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

131–140 of 253 posts

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

#131

Post by alpaca128 »

kelnos wrote: post #108
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 dislike the style this particular author chose, but don't object in general. Assuming the images are actually somewhat relevant (or at least funny), I think I'd prefer an AI-generated image over a big wall of text. To each their own, though, of course.

The text is the only reason to visit the blog, so why waste bandwidth with images of four-handed people?

At least they could try and generate something where I can't see malformed bodies within seconds. Or create a nice diagram that actually adds something to the text.

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

#132

Post by kaba0 »

jake_morrison wrote: post #19

Erlang is based on virtual threads (confusingly called processes). The Erlang virtual machine schedules them on OS threads. Erlang processes communicate using message passing, preventing deadlocks. You can use millions of Erlang processes without problems, e.g., to handle millions of Elixir LiveView sessions.

It all has the cost of a significantly lower throughput in case of Erlang.

Also, this is more of a user error, than a fundamental issue.

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

#133

Post by kaba0 »

eivanov89 wrote: post #6
oldgradstudent wrote: post #2

Java virtual threads did not cause a deadlock here. The deadlock was a usage error. A better title would be: Naively switching to Java virtual threads caused a deadlock in TPC-C for Progress SQL.

I would like to reply with a quote of sir Tony Hoare's 1980 ACM Turing Award Lecture: "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies".

Concurrency plus parallelism is complicated. There is no going around that.

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

#134

Post by kaba0 »

extractionmech wrote: post #43
Groxx wrote: post #34

Earlier 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?

It spawns a new carrier thread in place, up to a certain, configurable limit. But starving carrier threads will also result in effectively live locks, so that’s not a solution.

So I don’t see the big fuss about it - don’t spawn a million virtual thread that all just spams synchronized?

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

#135

Post by Someone »

minimaxir wrote: post #68
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

There's a quality spectrum of AI-generated header images. Some are just random DALL-E output which aren't intrinsically relevant to the article (like the one used in this article), but you can have a little fun with it and do something distinct. This may require more control than just using Bing Image Creator. Also, a thumbnail tip: square thumbnails are bad. If you have to use a square 1024x1024 AI generation, crop…

> since figuring out what to crop requires human intervention.

I don’t know how good they are, but people have trained models on that problem. Googling “autocrop tool” gives me multiple options.

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

#136

Post by kaba0 »

schizofunky wrote: post #33

I think i have a more elegant solution for this deadlock: "Switch to haskell".

Every language with sufficient concurrency and parallelism primitives are prone to dead locks/live locks and any other kind of race conditions.

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

#137

Post by Mashimo »

alpaca128 wrote: post #131
kelnos wrote: post #108

Earlier quoted context omitted.

I dislike the style this particular author chose, but don't object in general. Assuming the images are actually somewhat relevant (or at least funny), I think I'd prefer an AI-generated image over a big wall of text. To each their own, though, of course.

The text is the only reason to visit the blog, so why waste bandwidth with images of four-handed people? At least they could try and generate something where I can't see malformed bodies within seconds. Or create a nice diagram that actually adds something to the text.

> why waste bandwidth with images of four-handed people?

In the end it's just 2x 40kb

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

#138

Post by alpaca128 »

iknowstuff wrote: post #62
dmart wrote: post #59

Earlier quoted context omitted.

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.

They do add value, they make clicks more likely.

The question is: do you actually want to attract people who only click because of an image? And if you AI-generate it, are you fine with parts of the target audience not clicking on obvious AI thumbnails because they assume the entire content is low-effort?

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

#139

Post by alpaca128 »

MrBuddyCasino wrote: post #121
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

Someone (not me) put it like this: "to the trained eye you can already see that every single ai generated image is a picture of the same thing"

That applies to every generative AI, not just images. Generate a bunch of text with LLMs and you'll also see patterns emerging that it won't ever break out of.

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

#140

Post by MrBuddyCasino »

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…

> they chose to implement the scheduler in Java instead of C(++) and you're set for performance problems

The JDK has historically used some native implementations in its stdlib (zip, imageio and others), back when the runtime wasn't as fast as it is today. But today's runtime would often be faster in Java than those native implementations.

Post reply on HN