5x Slower Context Switching Between Fiber-vs-Thread

[Volkan Yazıcı]

Hey Remi,

Thanks so much for taking time to check the code.

Indeed, "next" field is initialized after spawning fibers. Though since
"waiting" is initially set to "true", each fiber at startup will pass "if
(!waiting)" block and drop into "await()".

For your effectively free logging remarks, you are absolutely right. I
don't know how far C2 can go to cover my back, but delegating the
allocation to a lambda body will definitely do the work. I will fix it in
the original fiber-test repo.

Best.

On Tue, Feb 5, 2019 at 10:39 PM Remi Forax <forax at univ-mlv.fr> wrote:

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