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

111–120 of 253 posts

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

#111

Post by kelnos »

davidgerard wrote: post #107
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

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 guess for some people would probably be best. But personally I prefer walls of text to be broken up by... something.

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

#112

Post by samus »

bcrosby95 wrote: post #16
Jtsummers wrote: post #13

Earlier quoted context omitted.

The adoption guide tells you not to switch to virtual threads just for their own sake. They're not meant as a straight replacement for OS threads. https://docs.oracle.com/en/java/javase/21/core/virtual-threa...

No mentions of deadlocks. Just this: > Pinning does not make an application incorrect, but it might hinder its scalability. The documentation is wrong.

The workaround is to increase the carrier thread pool size.

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

#113

Post by kelnos »

cyberax wrote: post #69
dboreham wrote: post #63

Earlier quoted context omitted.

My long held belief: green/user-level/M:N threading schemes never work at first, and only work reliably after extreme effort has been put into fixing all the cases where blocking code gets called underneath. afaik there are only two modern working implementations: golang and erlang. This article is consistent with that belief.

There are many other implementations, although in less popular languages. The trick is to include the green threads from the start, so there are no libraries that depend on real threading. That's why Go and Erlang are so successful.

The funny thing is that Java did have green threads back in v1.1, but they were dropped in v1.3.

That doesn't invalidate your point; more than 20 years of Java practice has focused on making things work well for platform threads.

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

#114

Post by nerdponx »

dboreham wrote: post #63
Groxx wrote: post #39

Earlier quoted context omitted.

Is that all that's happening here? There's an implicit limit on real threads, where before it was unlimited by virtue of not using the virtual thread's limited pool? If it doesn't spawn threads when all of them are blocked, that seems kinda dumb. And a severe change in semantics. It can be conservative and try running unpinned ones on fewer threads and shuffle them around and slowly spawn more to ensure eventual prog…

My long held belief: green/user-level/M:N threading schemes never work at first, and only work reliably after extreme effort has been put into fixing all the cases where blocking code gets called underneath. afaik there are only two modern working implementations: golang and erlang. This article is consistent with that belief.

It works well enough in Python and NodeJS.

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

#115

Post by jillesvangurp »

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. I've recently been experimenting with jasync-postgresql (there's a mysql variant as well) as an alternative to JDBC in Kotlin. It's a nice library. It does have some limitations and is a bit on the primitive side. But it appears to be somewhat widely used in various database frameworks for Scala, Java, and Kotlin.

Databases and database frameworks are an area on the JVM where there just is a huge amount of legacy code built on threads and blocking IO. It's probably one of the reasons Oracle worked on virtual threads as migrating away from these frameworks is unlikely to ever happen in a lot of code bases. So, waving a magic wand and making all that code non blocking is very attractive. But of course that magic has some hard limitations and synchronize blocks are one of those. I imagine they are working on improving that further.

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

#116

Post by kelnos »

samus wrote: post #103
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.

And it indeed does in common usage scenarios. And also in this case once the issue with `synchronized` is resolved. After all, this is a benchmark and it's not surprising that one of the limitations of the design was hit.

"common usage scenarios" != "in all cases".

I don't know if those Oracle employees actually did outright say -- or even imply -- "in all cases" as the GP asserted, but if they did, then "only" working in "common usage scenarios" would definitely be overselling the feature.

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

#117

Post by samus »

FridgeSeal wrote: post #25
hn_throwaway_99 wrote: post #11

[flagged]

I’ve come to see a lot of ai generated images as a proxy for effort, or care, and whenever I see them, my first thought is mostly “the author doesn’t care enough to make an effort about the presentation of their post”. Same reason I stopped using GitHub copilot to write PR bodies, I had a teammate say “I know you didn’t put any effort or thought into writing it,so why should I bother reading it?” Which I resonate wit…

I agree with your second point. But in this case, the AI art is a pure decoration.

Unless the author has some actual artistic talent, to me it feels like waste of time to spend more than a few minutes coming up with this. Some philosophers drinking Java coffee and playing with the PostgreSQL elefant. It doesn't even illustrate anything specific about the issue at hand.

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

#118

Post by spintin »

NovaX wrote: post #105
spintin wrote: post #101

Earlier quoted context omitted.

https://www.youtube.com/watch?v=WoQJnnMIlFY&t=260s To get the whole context, so virtual threads are unusable? What holds a monitor by default and is there a workaround? Found more: A virtual thread cannot be unmounted during blocking operations when it is pinned to its carrier. A virtual thread is pinned in the following situations: The virtual thread runs code inside a synchronized block or method The virtual thread…

Perhaps it’s better to say that they are not yet general purpose. There are many caveats which need to be resolved and are being actively worked on. I would not use them broadly yet, but that could change rapidly. A monitor will pin the VT to the carrier thread. That can have surprising incompatibility in the current jdk. Soon these footguns will be fixed and you can use them worry free. https://www.reddit.com/r/java…

Well see, if Patricio Chilano hasn't fixed this in a year I would start to get VERY worried.

Moving monitors into Java is not a good solution, like the long solution they are working on.

Java should be the API not the implementation!

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

#119

Post by danielovichdk »

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

Kinda like when someone pulls in FOSS code or a package without contributing or at least email the authors.

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

#120

Post by kaba0 »

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.…

Synchronized blocks are not a problem. Synchronized blocks that later don’t unblock the thread may sometimes be.
Post reply on HN