Native methods and virtual threads

[Brian S O'Neill]

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