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

[Michael Bazos]

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
>