Some Review of the EA build

[Johannes Kuhn]

On 30-Jun-20 15:52, Alan Bateman wrote:
> 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.
Yes, this is windows. The data is from a different test, where I did 
debug the virtual thread.
Small nitpick about debugging: I noticed in the debugger that the 
virtual thread and carrier thread go out of sync in the thread view.
It's a bit strange to single step a field set in Thread and the virtual 
thread doesn't respond anymore. But maybe that's an eclipse issue.
Had to build a mental model for VTs first, and found that if I want to 
debug the mounting and unmounting, then stepping through the carrier works.
Not sure how the debugging story matches my current mental model. Will 
keep you in the loop.
>
>>
>> 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.

That's a good point, will look if I find something interesting to dive 
in. I know of some places in some code that could use them. Their usage 
is basically set thread local -> emit synthetic event -> do something 
different in the event handler if the thread local flag is set. Could be 
replaced by scopes.

If you want, I could try to create my own prototype for Scoped. Would 
drop a few things like bytecode generation completely.
Thing is, I don't quite understand why those design decisions were taken 
in the first place, and maybe I don't see some small but important detail.

>
>
>> :
>>
>> 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

About j.l.Continuitation, I came up with a prototype to write 
python-like generators in plain java [2].
It's not type safe - and I have no idea how I can make it type safe - 
especially with generics in mind - it's impossible to check at runtime 
if a List is a List<Foo> , a List<Object>, or a List<? extends Foo>.
Anyway, interesting possibility - just plain old java code, and not the 
old trick with using a separate thread for each generator.

- Johannes

[2]: https://gist.github.com/DasBrain/abfdaa44b44d898f5d3c3888619eb49b