Native methods and virtual threads

[Gavin Ray]

Having read the thread in its entirety, my (uncalled for) $0.02 is that I
agree with
Maurizio here:

> I think API-wise, this is easy to do. Could become (as you say) a no-op
in the future (or changed to implement the best practice "du jour"), or
even be deprecated if no longer needed.

It seems beneficial to me to be able to mark methods with extra metadata
about
whether or not they are intended to block. Especially with the growth of
io_uring
on Linux and IoRing on Windows, I imagine folks might be linking to API's
which
implement a dual blocking/non-blocking IO API.

On the other hand I'm not a JDK maintainer and don't know what kind of
burden
this would add to implement and maintain.

On Fri, Jul 14, 2023 at 12:54 PM Brian S O'Neill <bronee at gmail.com> wrote:

> It's not the same process. Optimize first and then measure isn't the
> same as measure first and then optimize. Because the Blocker class
> exists and is in use, how can you measure what affect it has for real
> applications compared to it not existing? Perhaps it should be off by
> default and then be enabled with a system property?
>
> On 2023-07-14 09:37 AM, Ron Pressler wrote:
> >
> >
> >> On 14 Jul 2023, at 16:19, Brian S O'Neill <bronee at gmail.com> wrote:
> >>
> >> This sounds reasonable, but the current "wait and see" model is
> inconsistent. JEP 444 says, use JFR and we'll get back to you. Was this
> process followed when the decision was made to add the Blocker class, or is
> it a premature optimization that should be removed?
> >
> > It is the same process, and we’re still in the "wait and see” phase for
> Blocker, too, as it’s not part of any spec (and we’d love to get rid of of
> its uses eventually). It’s not a premature optimisation that’s at issue
> here at all because what you’re proposing isn’t an internal optimisation
> but a change to the specification before we know whether and how to best do
> it. If it were just an optimisation it’s conceivable we could find the time
> to do it in the near future, but what you’re talking about is a premature
> spec change.
> >
> > — Ron
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20230714/1a73e07b/attachment.htm>