loom ea based jdk18 feedback

[Eric Kolotyluk]

Please ship Loom ASAP. In its current form, it may not be perfect, but it's
truly valuable.

On Thu, Nov 18, 2021 at 10:02 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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
>
>