Temporal coupling in Fibers and Fibers vs State Machines.

[Ron Pressler]

I am not sure what Martin’s and Vaughn’s concerns, as you explain them,
have much to do with Loom, though. 

You want to write hand-roll your own state-machines, rather than use the 
state-machine abstraction provided by the platform and known to all tool, 
i.e. the method — go ahead. But people who do like organising code into 
subroutines have suffered from a scalability issue that Loom intends to resolve.

JMM concerns apply to anything concurrent, and while Loom doesn’t make
them go away, it also doesn’t solve global warming. I think there is some
misunderstanding there about what Loom is. Things generally addressed by
reactive frameworks are, however, also addressed by Loom. The composition
offered by Loom is any composition offered by the Java language (or any other
Java-platform language), and it is easy to show it is superior to the limited
composition offered by the reactive style (it subsumes it, and the compositon
it offers is essentially that of process-calculi — the state-of-the-art algebraic,
compositional formalisations of concurrency).

As to performance concerns, what Loom has always been about is achieving
the same (or virtually the same) scalability benefits that the reactive style
enjoys to a programming style that’s more harmonious with the Java platform.
I do not why suspension should dominate costs (although your wording is
a bit unclear to me; if suspension is your only overhead, then however cheap
it is, it will dominate). The cost of suspension has dropped by a factor of about
ten recently (with a flag that’s currently disabled by default), but I would be very 
interested in benchmarks that show that show it is any cause for concern.

My feeling is, therefore, that those concerns, as you expressed them, do not
apply to Loom as I see it, so I think there is some broken communication.

Ron

On 19 February 2020 at 19:43:00, Dávid Karnok (akarnokd at gmail.com) wrote:

Rafael's concerns are mostly related how the functional and declarative  
nature of the reactive libraries are difficult to learn for some people.  
Yet, these people happily code in SQL and use Java Streams. Maybe it's time  
to go back to reading database files with InputStream and use for loops as  
well.  

Martin's concerns are, if by composition he means what I think he means, if  
you could set up pieces of computation and functionality and combine them  
into larger components. If so, these components can have state and those  
state could change in response to stimuli from other components. Reactive  
is one of such approach that has individual pieces - operators chained up  
on a dataflow have internal state tracking when and how their peers can  
send data and commands to each other. Loom's, and Kotlin's Coroutines  
instead say you compose via the source code itself, by writing larger and  
larger methods encompassing a lot of imperative operations. If you have  
such a method, but for some uses need some retry code, you may be out of  
luck and have to code yet another set of methods to include that  
functionality.  

Vaughn's concerns are that there aren't many helping hands with Fibers and  
concurrency. In fact, you have to consider the Java Memory Model again the  
moment two routines in separate fibers have to communicate: blocking  
structures, atomics, locks and their effects on visibility. In reactive,  
from an user's perspective, you don't have to worry about most of these as  
the libraries can hide many of the intricacies of the JMM and provide you  
with an API and callback surface. Want to create an item and hand it over  
to another thread for processing? There are operators for that and you have  
only to specify how to create the item, what thread it should end up and  
what processing there should be for it. Want to generate many items?  
Replace the front of the flow and the rest will still be the same.  

Also note that Loom's sales pitch has shifted over the years. It started as  
the solution that will outperform reactive and having users code in easy to  
understand imperative fashion as the JVM will do the heavy lifting behind  
the scenes. However, we have pointed out that a) suspension is more costly  
and may dominate the overheads, b) composition (see above) is limited so  
people, individually and over and over, may end up with DIY solutions and  
c) you have to make sure locks/blocking happen in a virtual thread for  
which you may have to inject virtual thread-based executors all over the  
place.  

Ron Pressler <ron.pressler at oracle.com> ezt írta (időpont: 2020. febr. 19.,  
Sze, 19:48):  

>  
> Hi.  
>  
> I don’t think I really understand what the concerns are, and believe they  
> might  
> be tied to a misunderstanding of Loom’s goals and design.  
>  
> Anyone who has concerns is welcome to explain them here, without  
> character-count limits.  
>  
> Ron  
>  
>  
>  
> On 19 February 2020 at 18:37:53, Rahul Khandelwal (rahulnewai at gmail.com  
> (mailto:rahulnewai at gmail.com)) wrote:  
>  
> > Hi All,  
> >  
> > I have been following Project Loom for quite some time now and I find it  
> > really exciting.  
> > This is my first post in the mailing list.  
> >  
> > I went through the following twitter discussion -  
> > https://twitter.com/rafaelcodes/status/1176229314112741377  
> > However I could not understand the final gist/conclusion of the  
> discussion.  
> >  
> > 1. Here In the discussion Martin Thompson had the view that Fibers don't  
> > compose and cannot escape temporal coupling.  
> > He also advocated about the use of explicit state machines instead of  
> > Fibers.  
> > https://twitter.com/mjpt777/status/1176231250308325376  
> >  
> > 2. Vaughn Vernon had opinions around the Java memory model and the  
> > complexity of the effects of predictive execution.  
> > https://twitter.com/VaughnVernon/status/1176299015849136128  
> >  
> >  
> > Could someone explain what were the concerns and suggestions they  
> expressed  
> > and how Fibers handle said concerns.  
> >  
> > It would be great if someone could suggest some resources to better  
> > understand above twitter discussion.  
> >  
> >  
> > Thanks,  
> > Rahul  
>  
>  

--  
Best regards,  
David Karnok