State of Loom

[Mike Rettig]

The UI code I've seen will have problems with out of order executions.

Consider this psuedocode and how it could execute with loom vs a
single threaded executor:

ui.execute(()->{
  log.info("disabling user input");
  lockUserInput("Please Wait. Calculating totals");
});

final Totals totals = calculations();

ui.execute(()->{
   refresh(totals);
   unlockUserInput();
});

Loom will ensure the UI is reponsive when blocked, but at the
complexity of out of order executions. In my experience, any design
that has the potential to reorder changes to some shared state is best
avoided.  IMO, backing virtual threads with a single thread is an
anti-pattern. The thread is still susceptible to pinning, but now out
of order executions are added to the mix. The code needs to be written
as if it is multi-threaded, but at runtime it doesn't get the benefits
of parallel execution.

Mike



On Tue, May 19, 2020 at 4:36 PM Ron Pressler <ron.pressler at oracle.com> wrote:
>
>
> I added this example to show the power of custom schedulers. But it doesn't currently
> work without some changes in AOT (which we haven't done) to assertions on the thread
> identity. Given that, I realised it would be too confusing, adding further explanations
> would only be a distraction, and so I removed it.
>
> The order of execution shouldn’t pose a problem.
>
> — Ron
>
>
> On 19 May 2020 at 21:19:10, Mike Rettig (mike.rettig at gmail.com(mailto:mike.rettig at gmail.com)) wrote:
>
> > I was intrigued by this example:
> >
> > var uiVirtualThreadFactory = Thread.builder()
> > .virtual(java.awt.EventQueue::invokeLater).factory();
> >
> > I noticed it was removed in the latest version. Was this example
> > removed due to the risk of out of order executions? The document still
> > mentions the pinning risk of using a single carrier thread. However,
> > it doesn't mention the potential for out of order executions even
> > though a single thread is used. Single threaded UI design typically
> > guarantees thread safe access to UI components and ordered executions.
> > As I understand it, virtual threads by design will execute out of
> > order and that might lead to some very surprising UI behavior.
> >
> > Mike
> >
> > On Fri, May 15, 2020 at 9:56 AM Ron Pressler wrote:
> > >
> > > Hello.
> > >
> > > I’ve posted a document describing the project’s goals and current progress:
> > >
> > > http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html
> > >
> > > It is accompanied by a new EA build, based on jdk-15+21.
> > >
> > > https://urldefense.com/v3/__http://jdk.java.net/loom/__;!!GqivPVa7Brio!K6CYKUP1sk0TDnR0HVtMQUeXq9vyFwisNu0kgWGAMRyY6DKya8pXrkgceUrlgUmtIw$
> > >
> > > The new continuations algorithm is now switched on by default, so if you haven’t
> > > explicitly turned it on before, you may see some performance improvements.
> > > You can switch it off with -XX:-UseContinuationChunks.
> > >
> > > — Ron
> > >
> > >
> > >
>