Fiber try out feedback

[Ron Pressler]

Thank you for trying out our prototype, and we will fix the bug you've found ASAP.

As to the performance issues you mentioned, a couple of things:

1. Slow processing of interpreted frames shouldn’t have a significant impact, as that is only performed if the frame
is actually executed in the recent continuation session. However, that behavior was switched off by default 
(it is now on by default). Which brings me to the second point:

2. This is not yet the right time to benchmark performance. We are making constant changes that can have
big effects on both speed and footprint. Once the features and the implementation stabilize we will appreciate
Any help with benchmarking Loom on various workloads. 

For the time being we are mostly interested in reports about the API (how easy it is to use, run existing code, etc.),
and, in particular, the structured concurrency aspects, as well as bug reports (thank you, again, for that).

Ron


On July 19, 2019 at 11:59:55 AM, Lei Yu (lei.yul at alibaba-inc.com) wrote:


Hi,

Here are some feedback on our try out of loom from Alibaba.
We have written a test of the message passing between the Fibers to verify the performance under high concurrency.
1. An assertion error occurred while running the test(can be reproduced by the code in the attachment):
java.lang.AssertionError
at java.base/java.lang.Continuation.resizeStack(Continuation.java:685)
at java.base/java.lang.Continuation.maybeShrink(Continuation.java:671)
at java.base/java.lang.Continuation.postYieldCleanup(Continuation.java:465)
at java.base/java.lang.Continuation.run(Continuation.java:341)
at java.base/java.lang.Fiber.runContinuation(Fiber.java:367)
at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1425)
...

I think the deeper reason is that the value of Continuation.sp has been changed between maybeShrink() and resizeStack().

2. Thaw/Freeze interpreter frame will be slowed down by compute_oop_map significantly.
[image.png]

If a Fiber is executing as a consumer of a BlockingQueue in loop, we can frequently observe the interpreter frame exists even though compilation occurs,
thaw/freeze interpreter frame may become a performance bottleneck.

Thanks  
Lei Yu