Virtual Threads: A Short Note about Naming

[Ron Pressler]

I don’t think this is a good time to talk about cost, as the algorithms involved are in constant flux,
and the algorithms are likely to change even after the first GA. In any event, if there will be any 
noticeable costs in some ultra-performance-sensitive situations, then they will not be the result
of copying stack frames. Certainly, I do not like a name that depends on accidental implementation
features that are very likely to change over time.

Virtual threads are, indeed, recommended for tasks that block often, whether on IO or on inter-thread
communication/synchronization. But the name is meant to highlight the fact that the threads are
managed by the runtime and isn’t mapped directly to the implementation in the kernel.

- Ron


On 22 November 2019 at 21:29:23, Cay Horstmann (cay.horstmann at gmail.com) wrote:

Il 21/11/19 20:09, Brian Goetz ha scritto:  
>  
>> I agree that naming is important. Not sure "virtual" is a winner  
>> because it has connotations of increased cost.  
>  
> ... though those costs are precisely analogous to the costs incurred by  
> virtual threads.  Mounting a virtual thread on, or dismounting from, a  
> real thread requires work to copy stack frames, for example.  These are  
> a precise analog of building and tearing down page tables.  
>  

It's certainly a fair point to remind programmers that "fibers"/"virtual  
threads" are not cost free.  

When I talked to people about Loom, I didn't think they had a good frame  
of reference when "fibers" would be beneficial. They tended to follow  
"fiber = better thread", which didn't seem useful. I don't think  
"virtual thread" would save that.  

Perhaps a better angle would be to use a name that indicates why this  
cost is worth incurring? You wouldn't want to pay for lots of OS threads  
that are mostly blocking. But a "fiber" is parked when it executes a  
blocking call, and we are happy to pay the price of copying stack frames  
in return. Have you considered "BlockingTask" or "Blockable" or  
"Parkable" or some such thing?  

Cheers,  

Cay