Native methods and virtual threads

[Brian S O'Neill]

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? Likewise, the FFM 
API has the isTrivial option which adds even more risks. What was the 
process for deciding that this optimization was necessary?

On 2023-07-14 07:59 AM, Maurizio Cimadamore wrote:
> 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.
> 
> But the point that Alan and Ron are making is that it would be perhaps a 
> bit more cautious to wait and see how big of an issue this turns out to 
> be in practice, rather than pre-emptively changing the Linker API.
> 
> So, perhaps let's wait some time and reassess the situation? Stuff like 
> this can always be added to the FFM API compatibly, if required.
> 
> Maurizio
> 
> On 14/07/2023 15:25, Brian S O'Neill wrote:
>> One workaround is to pass messages through a special queue, where one 
>> side is driven by a pool of platform threads, but this adds complexity 
>> and overhead. I'm proposing a linker option hint. The hint might 
>> utilize the Blocker class, or might automatically set up a messaging 
>> passing queue if it makes more sense. Or it might be ignored entirely 
>> if at some point stacks with native threads can be unpinned.