Some Review of the EA build

Alan Bateman Alan.Bateman at oracle.com
Tue Jun 30 13:52:49 UTC 2020


On 30/06/2020 04:38, Johannes Kuhn wrote:
> :
>
> I only used a few toy examples, one that did help me understand the 
> working of virtual threads better is at [1].
> I did not get yielding to work with System.in, as it still uses 
> synchronized blocks.
Is this Windows? For now, reading from System.in will pin the thread 
when running on Windows. This is related to multiplexing the handle to 
the console rather than a synchronized block. Not an issue on Linux and 
macOS. We'll come back to the Windows issue at some point but in the 
mean-time it will use the FJ managed blocker mechanism to increase 
parallelism when reading from System.in. I see your test uses a custom 
scheduler with a single thread so aren't seeing that.

>
> Looks very WIP-ish.
> I don't quite understand why this design was chosen for Scoped. I can 
> make some assumptions:
> * As only one (static final) Scoped is used at a particular call site, 
> the JIT should be able to inline that mono-morphic call.
> * Which would make the instanceof check cheap. The same effect might 
> be archived with two @Stable fields?
>
> I would love to hear more about what the background of the Scoped 
> design was/is.
The scope variables are very much as a prototype at this time. It's 
unlikely that they will be in the initial preview but they are in the EA 
builds because they interact with other features so are in the same 
branch and same builds.

I think good feedback for the scope variables prototype is data from 
real world libraries or applications on how many ThreadLocal usages it 
could replace and whether it is helps with performance.


> :
>
> Did I miss any particular thing in the EA that I might take a look at?
There are several people kicking the tyres right now (which is great). 
We are also hoping that some people will have the time to take it 
further and change an existing framework or application to use virtual 
threads, maybe go back to the "thread per request" model. This would 
help with validating (or not) whether the simple programming model (the 
one we all know!) will scale, it could help identify shortcomings in 
existing APIs, and maybe provide feedback on the performance and 
reliability.

-Alan


More information about the loom-dev mailing list