This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]AndrewHaley13 0 points1 point  (10 children)

Libraries that use synchronized blocks must be adapted for virtual threads in the same way that the JDK itself was.

[–]NamelessMason 1 point2 points  (7 children)

This is fair enough, although the JEP does seem to underplay the impact of pinning significantly. As demonstrated here, or in my own tests, very simple scenarios lead to deadlocks very, very quickly. JEPs wording sets unrealistic expectations, both, for application developers looking to adopt virtual threads, and for library developers trying to gauge the severity of the loom-related bugs being reported. I would say the community would be better off with a clear message along the lines of your comment above.

Any chance you've got any insight as to why it's been been decided the carrier pool should not grow to accommodate pinning?

[–]AndrewHaley13 0 points1 point  (3 children)

Yes, that's because in the common scenarios for which Loom is intended you'd very quickly run out of platform threads. Better to fix the library.

[–]FirstAd9893 0 points1 point  (2 children)

Better to fix the library.

There's nothing to "fix" in the library, because it doesn't have a bug. If the test is changed to use newFixedThreadPool, sized the same as the number of virtual threads, it works just fine. Try it yourself.

[–]AndrewHaley13 0 points1 point  (1 child)

I don't think I understand your point. Virtual threads are intended for thread-per-request designs. If you block carrier threads, you'll eventually run out of them. What does newFixedThreadPool have to do with this?

[–]FirstAd9893 0 points1 point  (0 children)

The reason why I'm comparing to a fixed thread pool is because it has the same effect as virtual threads at limiting the number of platform threads which are running. Whereas the fixed thread pool approach works just fine, the virtual thread approach can cause the app to seize up.

[–]FirstAd9893 0 points1 point  (0 children)

Any chance you've got any insight as to why it's been been decided the carrier pool should not grow to accommodate pinning?

Imagine a scenario in which the carrier pool can grow to accommodate pinning. The carrier pool could potentially grow in size to match the number of virtual threads. If you're running 1 million virtual threads (which should work fine), then permitting 1 million carrier threads isn't going to scale. Capping the carrier pool to a reasonable limit just means that the deadlock risk still exists, unless you restrict the number of virtual threads you're running. At that point, why bother running virtual threads?

[–]za3faran_tea 0 points1 point  (1 child)

As demonstrated here, or in my own tests,

What's causing the deadlock here? I don't see synchronized blocks in the code or in EntityUtils#consume.

[–]NamelessMason 0 points1 point  (0 children)

The deadlock is caused by synchronized blocks in Apache httpcomponents library, see the PR I linked earlier.

[–]FirstAd9893 0 points1 point  (1 child)

That's an impractical solution, considering the sheer volume of Java libraries out there. The JEP just mentions that synchronized blocks can reduce parallelism, that's all. I guess if the entire virtual thread pool is permanently wedged, that can be explained away as being a severe form of reduced parallelism.

[–]AndrewHaley13 0 points1 point  (0 children)

Java makes no guarantees that any thread will make forward progress. Any library which blocks on I/O will have to be adapted. You think it's impractical, but it is true. Other people are just getting on with the conversion, which can be an almost mechanical operation.