Live data from Hacker News

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

blog.ydb.tech

61–70 of 253 posts

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

#61

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

To me, its more about the style than the use of an AI. But I agree.

I enjoyed this writeup by Michael Lynch on finding an illustrator [1], for their blog. In doing some of my own writing, I've really found it enlightening how much secondary work goes into publishing your own work. I often think its so nice to be able to _just_ plug in what I want on a site and get a (more or less) free illustration. But as someone selling their own work / time, it feels wrong. I'd rather pay a real human and build a relationship and have something more quality. On the other hand, though, it can be expensive, time consuming, and I've been screwed over. Often it seems like a bigger risk than its worth.

So idk, you're trading some hardship and risk for an ethical dilemma but ease of use.

[1] https://mtlynch.io/how-to-hire-a-cartoonist/

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

#62
post #59

Earlier quoted context omitted.

Typically it’ll be in lieu of nothing or stock photography. Doesn’t it seem better than that?

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.

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

#63
post #39

This is a common problem when migrating a system from threads to virtual threads. In general, using primitives which block the current thread and prevent forward progress can quickly lead to deadlocks. It’s a hard issue to catch because in the past usually this would get “solved” by spawning a new thread to complete the task but in a world with virtual threads the runtime is usually reluctant to spawn more threads, s…

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.

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

#64

I am extremely confused. > There are two scenarios in which a virtual thread cannot be unmounted during blocking operations because it is pinned to its carrier: > When it executes code inside a synchronized block or method Isn't 'synchronized' effectively sugar for taking a kind of lock? Why can't it be treated uniformly by the scheduler?

The `synchronized` by itself does not cause any problems for virtual threads.

Only when one calls a blocking operation from synchronized, the thread is not unmounted. E.g. `synchronized (...) {blockingQueue.take()}`. Note that this is not a sane coding practice. (Calling a potentially long operation from within synchronized. The blockingQueue.take() does not need to be wrapped into synchronized. It has synchronization inside and plays well with virtual threads. Only when wrapped into the synchronized, the current implementation can not unmount the virtual thread.).

The JDK team works to remove quirks like pinning in the future versions.

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

#65

Curious if you considered switching to a different connection pooling library. These days I usually use HikariCP which is fast an actively maintained. c3p0 hasn't had any activity for years, I'm not sure if it's still maintained.

Been ages since I’ve touched it but back in 2017-2018 I had some fun integrating HikariCP in place of c3p0 in some Clojure projects and it was more performant.

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

#66

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.

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

#67
post #59

Earlier quoted context omitted.

Typically it’ll be in lieu of nothing or stock photography. Doesn’t it seem better than that?

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.

Unfortunately all social media sharing requires a thumbnail for easy clicking, no real way around it. (with Hacker News as the lone exception of course)

The default thumbnails in lieu of your own aren't good.

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

#68

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 it to something like 1024x575, which incidentally can make things difficult if using AI generation since figuring out what to crop requires human intervention.

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

#69
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.

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.

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

#70

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

Honestly, the images attached to the article seemed great to me; they were colorful and fun. I don't see any reason to care who or what created them.
Post reply on HN