Native methods and virtual threads

[Ron Pressler]

What we were discussing here wasn't an optimisation but your suggestion to change the specification. As to Blocker, if you’re interested in the details of the technical considerations and tests involved, I’ll try to find the time to talk to the relevant people and get back to you.

— Ron

> On 14 Jul 2023, at 17:54, 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