j.u.s.Stream and Fiber

[Billy Sjöberg]

I'd like to add another question relating to this.
What's the current plan for dealing with existing code that uses
CompletableFuture.runAsync to fork out asynchronous tasks?
That's a very typical use-case in i.e. web servers which (hopefully)
in the future would default to execute inbound requests in fibers.

Trying out the early build it seems that CF's are executed on regular
threads even though the call to CF.runAsync was performed from within
a Fiber. I guess it's hard to make a decision of the intent for the CF
(computational vs IO), but this would mean that existing code that
doesn't explicitly fork out using the FiberScope.open/schedule miss
out on a potentially dramatic performance increase.
Is the current plan to rather be safe than sorry and leave existing
code executing on threads or is this something you're considering
changing/opting in on?

Example:

public static void main(String[] args) {
    try(var scope = FiberScope.open()){
        scope.schedule(() -> {
            determineThreadingModel();
            CompletableFuture.runAsync(Sample::determineThreadingModel).join();
            try (var scope1 = FiberScope.open())

scope1.schedule(Sample::determineThreadingModel).toFuture().join();
            }
        });
    }
}

private static void determineThreadingModel() {
    Fiber.current().ifPresentOrElse(
            f -> System.out.println("fiber!"),
            () -> System.out.println("thread!")
    );
}

output:
fiber!
thread!
fiber!


On Thu, Sep 19, 2019 at 2:17 PM <loom-dev-request at openjdk.java.net> wrote:
>
> Send loom-dev mailing list submissions to
>         loom-dev at openjdk.java.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.openjdk.java.net/mailman/listinfo/loom-dev
> or, via email, send a message with subject or body 'help' to
>         loom-dev-request at openjdk.java.net
>
> You can reach the person managing the list at
>         loom-dev-owner at openjdk.java.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of loom-dev digest..."
>
>
> Today's Topics:
>
>    1. j.u.s.Stream and Fiber (Arkadiusz Gasi?ski)
>    2. Re: j.u.s.Stream and Fiber (Alan Bateman)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 18 Sep 2019 22:37:31 +0200
> From: Arkadiusz Gasi?ski <jigga at jigga.pl>
> To: loom-dev <loom-dev at openjdk.java.net>
> Subject: j.u.s.Stream and Fiber
> Message-ID:
>         <CA+Jwoy3P+W6e=BaKo5JGSmXjNRrA+gHMEhB-_0Z+aTqpG4PHHg at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi,
>
> Sorry if this was asked already - looked through the mailing list, but
> couldn't find the answer... And the question is: Are JDK's j.u.s.Stream
> implementation classes Fiber-aware? For example if I trigger a terminal
> operation on a parallel stream in the context of a Fiber, would there
> possibly be new fibers scheduled to process the stream elements? If so,
> what will be the scope of these additional Fibers?
>
> Thanks,
> Arek
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 19 Sep 2019 12:25:52 +0100
> From: Alan Bateman <Alan.Bateman at oracle.com>
> To: Arkadiusz Gasi?ski <jigga at jigga.pl>, loom-dev
>         <loom-dev at openjdk.java.net>
> Subject: Re: j.u.s.Stream and Fiber
> Message-ID: <aac4b0df-b42a-fb4e-7261-e60bdf6bd360 at oracle.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 18/09/2019 21:37, Arkadiusz Gasi?ski wrote:
> > Hi,
> >
> > Sorry if this was asked already - looked through the mailing list, but
> > couldn't find the answer... And the question is: Are JDK's j.u.s.Stream
> > implementation classes Fiber-aware? For example if I trigger a terminal
> > operation on a parallel stream in the context of a Fiber, would there
> > possibly be new fibers scheduled to process the stream elements? If so,
> > what will be the scope of these additional Fibers?
> If there is parallel execution then it will use ForkJoinPool, no change.
> It's possible that the fiber executing the terminal operation may
> temporarily pin its carrier thread when joining (you might see it
> blocked in externalAwaitDone). I'm sure Doug or Martin will have ideas
> if it becomes an issue.
>
> -Alan
>
>
>
>
> End of loom-dev Digest, Vol 21, Issue 17
> ****************************************