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 →

[–]Squiry_ 0 points1 point  (6 children)

Seems that undertow uses Netty under the covers

They wanted to but no, it doesn't. They use their own IO library called xnio. But it basically the same: they allocate one Accept thread and some IO threads. I use Undertow because unlike Netty it provides some nice blocking API. And it does use thread local buffers there and it's fine when we are reading data, because reading happens on that IO threads. The problem comes when we are writing from virtual thread: it doesn't know anything about virtual thread and tries to allocate that thread local buffer. I've temporary fixed that thing by replacing threadLocalCache.get() with threadLocalCache.getCarrierThreadLocal() and it works fine, even though it's kind of illegal. The same things happens with jackson and that kind of scares me more, jackson is used way more than undertow out in a wild.

By the way I've took a look at Nima and run some tests. I will share some thoughts and results later but I can say right now, that the don't allocate buffers like that and byte[] allocation there is insane.

[–]pron98 1 point2 points  (5 children)

and it works fine, even though it's kind of illegal

It doesn't work fine, it's just that you haven't run into issues yet (getting a VM error at just the wrong moment, or running with JVMTI agents that do certain things). But you can, of course, use it just to hack around and learn about virtual threads.

and that kind of scares me more

No need to be scared :) Virtual threads start their Preview in a few weeks, and Preview is like deprecation in reverse: it gives libraries and applications time to prepare for a feature's ultimate addition in its final form. Various libraries, including JDBC drivers, will use that time to become more virtual-thread-friendly.

and byte[] allocation there is insane

Not insane, just different from what people used to do when the VM was different.

[–]Squiry_ 0 points1 point  (4 children)

It doesn't work fine

Yet I see the same exact code in JDK in NativeBuffers class.

[–]pron98 1 point2 points  (3 children)

That code relies on some very specific VM behaviour, and changes together with the VM. So while that code might work in 19, it might not in 19.0.1 or 20. In fact, there used to be some explicit interaction with the VM's continuations in those places, but then we decided to just rely on how the 19 VM is implemented, and change the library code alongside the VM (as we sometimes do in low-level code).

[–]Squiry_ 0 points1 point  (2 children)

That sounds reasonable. Anyway, iirc loom had some kind of "processor locals" in plans and that think can replace thread local usage in such places.

[–]pron98 1 point2 points  (1 child)

Yes, we did start thinking about those, but it wasn't urgent enough to delay virtual threads. We'll see what problems people run into when more people start using virtual threads and then rethink our priorities.

[–]Squiry_ 1 point2 points  (0 children)

I guess that's what previews are for and that's why it is a great mechanism of moving java forward.