loom ea based jdk18 feedback

[Brian Goetz]

Let me see if I can put this in context.  

There’s a sub-feature that we all can imagine, and which seems broadly reasonable, that is not available yet.  

This sub-feature will take additional time to develop, beyond that of getting virtual threads and related to a ship-ready state.  Therefore, our choices are:

 - Ship the first version of Loom without it, or
 - Delay the first version of Loom until we can support it.  

You’re arguing that Loom is useless, at least to you, if it doesn’t include this feature.  That seems like a bit of an overstatement, but you do get to have your own opinion about what’s useful to you.  But it seems a dramatic overstatement to say “Loom is useless to *everybody* if it doesn’t have this feature.”  And yet, that seems exactly what you are saying — that the only reasonable choice is to hold Loom until this sub-feature is ready.  

What Ron is saying is that this sub-feature is indeed useful, and that we’d like to deliver it, but we’re not in a position to deliver it immediately, and we’d rather deliver the rest of Loom in the meantime, because Loom *is* broadly useful even without it.  





> On Nov 18, 2021, at 12:51 PM, Jon Ross <jonross at gmail.com> wrote:
> 
> 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