5x Slower Context Switching Between Fiber-vs-Thread

[Remi Forax]

Hi Volkan,
i've taken a look to your code,
i believe the fiber part of the code is not thread safe,
in https://gist.github.com/vy/c5031a54d42f9e5b855463c838fed6a9#file-slowfiberreport-java-L170
you're asking the fibers to be scheduled but the field next is not yet initialized.

I also believe (even if i've not taken a look to the generated code so i may be wrong) that the logging code may still generate some assembly codes when disabled because you're calling a varargs which will box values even if the values are not used (because the VM doesn't know that a boxing op has no side effect). Using a lambda instead of a Object... is usually safer.

Anyway, thanks for the test :)

regards,
Rémi

----- Mail original -----
> De: "Remi Forax" <forax at univ-mlv.fr>
> À: "Volkan Yazıcı" <volkan.yazici at gmail.com>
> Cc: "loom-dev" <loom-dev at openjdk.java.net>
> Envoyé: Mardi 5 Février 2019 10:49:08
> Objet: Re: 5x Slower Context Switching Between Fiber-vs-Thread

> Hi Volkan,
> i will take a look this evening.
> 
> Rémi
> 
> ----- Mail original -----
>> De: "Volkan Yazıcı" <volkan.yazici at gmail.com>
>> À: "Alan Bateman" <Alan.Bateman at oracle.com>
>> Cc: "loom-dev" <loom-dev at openjdk.java.net>
>> Envoyé: Mardi 5 Février 2019 09:41:17
>> Objet: Re: 5x Slower Context Switching Between Fiber-vs-Thread
> 
>> It was my pleasure to meet with you all.
>> I have created a GiST:
>> https://gist.github.com/vy/c5031a54d42f9e5b855463c838fed6a9
>> You can just run the file as follows: *java SlowFiberReport.java*
>> 
>> On Tue, Feb 5, 2019 at 9:33 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>> 
>>> Nice to meet you at FOSDEM and the OCW.
>>>
>>> Can you send me the benchmark, I think the attachment is being stripped
>>> by the mail servers.
>>>
>>> -Alan
>>>
>>> On 04/02/2019 21:16, Volkan Yazıcı wrote:
>>> > Hello,
>>> >
>>> > In the attached SlowFiberReport.java, main() calls runThreads() and
>>> > runFibers() methods and measures the total time it takes. The former,
>>> > runThreads(), creates 50 threads and passes a token sequentially 1e6
>>> times.
>>> > Whereas the latter, runFibers(), creates 50 fibers running on a
>>> > single-threaded scheduler and again passes a token sequentially 1e6
>>> times.
>>> > For synchronization purposes, both approaches use a dedicated Lock and
>>> > Condition pair for each thread and fiber, respectively. While I am aware
>>> > that it is still early to assess the performance of Loom, I am surprised
>>> to
>>> > see threads performing ~5x better (6s-vs-30s) compared to fibers in terms
>>> > of basic unmount/mount costs. Would anybody mind helping me to understand
>>> > the cause of the slowness, please? (I hope I am not doing something brain
>>> > dead.)
>>> >
>>> > Best.
>>> >
>>> > *Note:* Using a JDK compiled from 2019-01-20 sources.