Questions on Build 18-loom+5-274 (2021/11/15)

[Michael Bazos]

Thanks Eric,
Yeah I totally agree but when dealing with existing code I really like how
Executors.newVirtualThreadPerTaskExecutor() is like a drop-in replacement.
I am assuming this was considered in the design and is important to have as
there is lots of code in the Java ecosystem that allows you to set a custom
Executor but you might not have access to plug-in a StructuedExecutor. I
also think there will need to be some education about executors, I believe
it's pretty well known that creating an executor service is an "expensive"
operation, but when doing this with a virtual task executor it's considered
"cheap".

Assuming these features from an API perspective don't change dramatically
upon release I see Executors.newVirtualThreadPerTaskExecutor() being used a
lot immediately and then over time code authors and such will migrate to
something like StructuedExecutor.

I really like the approach loom has taken to use Executor and of course
re-use Thread class. I imagine this was a lot more challenging up front but
I am willing to bet that doing this will pay dividends in the future once
this is released. We don't always get to work on new applications so having
a pathway forward for older applications is very exciting.

Mike

On Tue, Nov 23, 2021 at 3:42 PM Eric Kolotyluk <eric at kolotyluk.net> wrote:

> Mike, as I have discovered, StructuredExecutor.open() functions like
> newVirtualThreadPerTaskExecutor(), one thread per task.
>
> While initially, I experimented with newVirtualThreadPerTaskExecutor(), I
> now only use StructuredExecutor because it's a better solution.
>
> Cheers, Eric
>
> On Tue, Nov 23, 2021 at 12:26 PM Michael Bazos <mbazos at gmail.com> wrote:
>
>> Alan,
>> Just wanted to let you know I took some high volume applications I work on
>> that rely heavily on Executors and was easily able to switch to
>> newVirtualThreadPerTaskExecutor and everything appears to be working well.
>> Looking forward to the preview feature when it's ready.
>>
>> Mike
>>
>> On Fri, Nov 19, 2021 at 3:03 PM Alan Bateman <Alan.Bateman at oracle.com>
>> wrote:
>>
>> > On 19/11/2021 19:15, Michael Bazos wrote:
>> > > I started doing some experimenting with project loom an observed a few
>> > > things and wasn't sure how to explain them or why it was happening:
>> > >
>> > >     1. I noticed when using
>> Executors.newVirtualThreadPerTaskExecutor()
>> > >     submitting tasks and then calling 'shutdown()' on the executor
>> > service, the
>> > >     virtual thread per task executor does not wait for tasks to
>> finish.
>> > This
>> > >     seems to behave a little differently than the OS based thread pool
>> > >     executors. I assume this is intended but just wanted to know why.
>> > ExecutorService::shutdown is specified to not wait so the behavior you
>> > observe is correct. You can use awaitTermination, or the new close
>> > method, to wait for termination. Are you sure you've observed the
>> > shutdown of other ExecutorService implementation wait, just curious.
>> >
>> > >     2. Playing with StructuredExecutor I can see the example of using
>> it
>> > >     with try-with-resources which is clean and looks nice. I was
>> > surprised to
>> > >     see `isShutdown()` as private on the StructuredExecutor. I am just
>> > >     wondering if a client didn't use try-with-resources there would be
>> > some
>> > >     value in allowing a client to know if the executor is shutdown or
>> > not. My
>> > >     best guess is the intention here is to minimize what is exposed
>> from
>> > the
>> > >     API.
>> > If there is a case for exposing the state then it could be done.
>> >
>> >
>> > >     3. My final question which is semi related to Question 2 I haven't
>> > done
>> > >     any benchmarking myself yet but I know creating OS based executor
>> > thread
>> > >     pools can be considered an "expensive" operation. Obviously this
>> is
>> > very
>> > >     different when doing this with virtual thread task executor. Does
>> > using
>> > >     virtual thread task executor mean this is cheap to create and
>> > shutdown?
>> > >     Typically in client code you wouldn't want to create/destroy task
>> > executors
>> > >     during the lifecycle of an application.
>> > The intention is that this should be very cheap to create and close.
>> >
>> > > Also I did some tests and I couldn't believe how many virtual threads
>> I
>> > > could spin up on my machine versus OS threads. Seems like memory
>> would be
>> > > the limit but the difference was ~3000 OS threads vs ~5 million+
>> virtual
>> > > threads.
>> > >
>> > > When I have time going to integrate the early loom builds into some
>> real
>> > > applications to see how it behaves. I very much look forward to not
>> > having
>> > > to worry about configuring thread pools in the future, very excited
>> and
>> > > keep up the good work!
>> > >
>> > Good, please let me know how you get on.
>> >
>> > -Alan
>> >
>>
>