Resource Constrained Thread Per Task Executor

[Attila Kelemen]

I do happen to have an executor framework in which all this is trivial to
implement, because you just need to implement a single submit method, and
the rest you can get for free (as in you don't have to implement it) using
a single call: `TaskExecutors.upgradeToStoppable(executor)` (though this
returns an instance of my `TaskExecutorService` interface, but I have
bridge methods to convert that to `ExecutorService` with minimal overhead).
See
https://javadoc.io/doc/org.jtrim2/jtrim-executor/latest/jtrim.executor/org/jtrim2/executor/package-summary.html
If
you want to give it a try, you can send me a personal email, and I can
answer API specific questions.

Colin Redmond <Colin.Redmond at outlook.com> ezt írta (időpont: 2024. máj.
13., H, 23:54):

> If it is safe to keep virtual threads and pool them, there is still a net
> benefit to pooling virtual threads. I agree a major benefits of virtual
> threads is that they are cheap to create, so there is no *need *to pool
> them. But the memory and performance increase even pooling is no small
> matter.
>
> In my case I have 500 platform threads I am limited because my container
> is small and they start to use a significant portion of the memory. I
> switch them for 1000 virtual threads, this saves me ~ 500 mb of RAM (maybe
> less i didn't do the math). Between less need for context switching and
> more memory for garbage, I am still seeing a 20 - 30% improvements. Which
> even with pooled virtual threads is a big improvement.
>
> Firstly I was hoping there was an existing solution, I googled it a while
> but couldn't find any specific open source packages if anyone knows any let
> me know, I would prefer to import something. If not I may continue my
> journey of writing a new ExecutorService for my use case.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20240514/ba35dc8c/attachment.htm>