Loom prototype publicly available

[Dávid Karnok]

Hi.

I'd be glad if there was a Windows buildable version so I could begin
exploring interoperation possibilities with java.util.concurrent.Flow .

Martijn Verburg <martijnverburg at gmail.com> ezt írta (időpont: 2018. aug.
7., K, 17:30):

> Hi Ron et al,
>
> Would you like Project Loom builds at AdoptOpenJDK.net?  We build Amber
> (raw string literals branch).  Happy to add Loom if that suits.
>
> Cheers,
> Martijn
>
>
> On Fri, 3 Aug 2018 at 01:38, Ron Pressler <ron.pressler at oracle.com> wrote:
>
> > Yes, the current implementation is “one shot” (and a one-shot delimited
> > continuation is often also known as a coroutine), and cannot be used to
> > implement amb. However, we may make the continuations cloneable in which
> > case they can be used to implement amb.
> >
> >
> > On July 30, 2018 at 9:03:16 AM, Ryan Schmitt (rschmitt at pobox.com) wrote:
> >
> > This is a fascinating prototype. Would it be correct to describe Loom's
> > continuations as "one-shot" continuations? Should it be possible to
> > implement the `amb` operator on this prototype?
> >
> > On Fri, Jul 27, 2018 at 10:51 AM, Ron Pressler <ron.pressler at oracle.com>
> > wrote:
> > Hi.
> >
> > You can now build and try our initial Loom prototype.
> >
> >         $ hg clone http://hg.openjdk.java.net/loom/loom
> >         $ cd loom
> >         $ hg update -r fibers
> >         $ sh configure
> >         $ make images
> >
> > (Note that you must switch to the fibers branch)
> >
> > - Supported platforms: Mac and Linux on x86-64
> > - Tested GCs: Parallel and G1
> > - Supported compilers: C1, C2, Graal
> > - Missing features: JVM TI (fiber debugging), fiber/continuation
> > serialization
> >
> > Work on tail calls has not yet begun.
> >
> > Current status will be tracked in a wiki page we will set up soon.
> >
> > The fibers API is in the java.lang.Fiber class, and is minimal at this
> > stage.
> > Thread locals should work as expected (and be associated with the fiber),
> > and
> > calls to Thread.currentThread() would return a consistent result, so a
> lot
> > of
> > existing code should work. Most relevant IO operations, as well as
> > java.util.concurrent constructs, Thread.sleep etc. will now result in the
> > fiber
> > — rather than the underlying kernel thread — being blocked.
> >
> > Object.wait() would still block the underlying kernel thread, as would
> > trying to
> > park a fiber while a native monitor is held or a native method is on the
> > stack.
> >
> > The current implementation performs a full stack copy by default. To
> > experiment
> > with the lazy-copying solution I described in a previous email, add
> > `-XX:+UnlockExperimentalVMOptions -XX:+UseNewCode`, but note that in that
> > mode
> > exceptions thrown inside continuations may not work (probably crash the
> > VM) and
> > stack traces would be missing frames.
> >
> > This is an initial prototype made to be simple to implement so we could
> > experiment with different APIs, compatibility etc.. Performance,
> > therefore, is
> > far from stellar. Designing a good API and writing an implementation with
> > good
> > performance are our top priorities.
> >
> > You’re welcome to try the prototype and share your impressions here. On
> > Monday,
> > we’ll present Loom at JVMLS, and more updates will follow.
> >
> >
> > Ron
> >
> >
> >
> >
> >
>


-- 
Best regards,
David Karnok