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

141–150 of 253 posts

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

#141

Post by davidgerard »

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 shouldn't be so hard to realise that if you make your blog post look how spam looks, it'll look like spam.

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

#142

Post by alpaca128 »

Mashimo wrote: post #137
alpaca128 wrote: post #131

Earlier quoted context omitted.

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

So that makes a signal to noise ratio of 1:5 given the text including code is just 14kB.

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

#143

Post by davidtos »

bheadmaster wrote: post #130

Why couldn't JVM detect when all carrier threads are blocked, and just spawn more of them?

That already exists luckily, you can even change the maximum number of carrier threads with:

- jdk.virtualThreadScheduler.maxPoolSize=10

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

#144

Post by anthony88 »

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…

I've written an open source library to easily replace synchronized with something more virtual thread friendly: https://github.com/japplis/Virtually

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

#145

Post by mort96 »

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.

What value does AI slop add though?

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

#146

Post by mort96 »

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

Between the shitty obviously-AI-generated square header image with floating hands everywhere, the equally shitty obviously-AI-generated image in the middle and the "Please pay for Medium" banner which takes up literally half the page, this blog post does its utmost to make a truly terrible impression.

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

#147

Post by lmm »

kaba0 wrote: post #106
lmm wrote: post #75

Earlier quoted context omitted.

> This one was a very large caveat pointed out loudly every time the feature was mentioned to the community. It really wasn't. There were people on here, including Oracle employees, claiming that the virtual thread implementation was a drop-in replacement that would work (not necessarily perform better, but work) in all cases.

If your program was prone to deadlock as is, and is just more easily happening with virt threads, it means that the problem is your code.

Having X resources and Y dedicated threads that operate on them, where Y > X, and allowing a thread to block in a way that requires the assistance of another thread to make progress but only when it's holding a resource, is a perfectly reasonable, standard, and safe design. When a change to the runtime silently reduces the number of synchronized sections a program can enter concurrently, it's not at all surprising that this breaks working code.

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

#148

Post by mort96 »

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…

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

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

#149

Post by dikei »

davidtos wrote: post #143
bheadmaster wrote: post #130

Why couldn't JVM detect when all carrier threads are blocked, and just spawn more of them?

That already exists luckily, you can even change the maximum number of carrier threads with: - jdk.virtualThreadScheduler.maxPoolSize=10

The default is 256, way higher than 10.

But of course, when you have thousands of Virtual Threads all deliberately pinning the carrier thread, you quickly run out.

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

#150

Post by tveita »

jillesvangurp wrote: post #115
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…

People always forget that things that only happen every few million times, can happen fairly frequently on a busy server. This has bitten me numerous times. The nature of a lot of these types of issues is that they are hard to detect and hard to reproduce. 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.…

There are ways to find problem sections without having to trigger a full deadlock: https://openjdk.org/jeps/444

  The system property jdk.tracePinnedThreads triggers a stack trace when a thread blocks while pinned. Running with -Djdk.tracePinnedThreads=full prints a complete stack trace when a thread blocks while pinned, highlighting native frames and frames holding monitors. Running with -Djdk.tracePinnedThreads=short limits the output to just the problematic frames.
Post reply on HN