loom ea based jdk18 feedback

[Jon Ross]

On Thu, Nov 18, 2021 at 5:31 AM Ron Pressler <ron.pressler at oracle.com> wrote:
>
>
> The frameworks can use all kinds of threads provided by the JDK however they like. What is currently missing is their ability
> to control how virtual threads are implemented internally, just as they can’t control how platform threads are implemented internally.
> We will add that extra level of control once we’ve had time to properly evaluate it.

This seems odd to me. It's a concept entirely defined and implemented
by the JVM, yet it's opaque to the JVM? I'm unaware of any OS the JVM
supports that has fibers, and even if it did, you'd likely just use
the JVM's version to avoid mapping issues you allude to. The "All Your
Blocking Are Belong to Us" section of the doc seems to imply that the
JVM itself is controlling virtual threads to do exactly what I would
like to do. Why do only the cool kids get to have fun?

How useful would Loom be if the blocking calls in the JVM didn't have
access to this feature? If you do back-end / web / network-heavy
work, then it's hard for me to see how Loom benefits you w/o the JVM's
blocking APIs' ability to suspend/.resume. Please correct me if you
think loom provides value in this context.

If you do agree, then Loom has little benefit to any app/lib that does
IO outside of the JVM's APIs. I'd put netty in this camp. Most
deployments use their native sockets implementation (also
non-socket-based things like io_uring). If netty doesn't benefit from
loom, that would be a bummer. Who's it for, if not netty?

To be myopic, my field makes extensive use of IO the JVM is not aware
of (not netty). I think this feature is a requirement for my use case,
or I'm don't understand something fundamental.

Thanks for your time,
-Jon