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

[Michael Bazos]

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.
   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.
   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.

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!

Mike