On 05/05/2023 21:49, Rémy Maucherat wrote:
The second question is what do we want to do about usages such as this.
With virtual threads the end result will be, effectively, a new object
for every request. Do we:
a) Leave the code as-is. It will work as currently with a thread pool
and virtual threads will effectively create new objects for each request.
b) Drop the ThreadLocal and always create new objects.
c) Switch to some other form of caching. My starting point would be
SynchronizedStack. That may see some contention as it will be global
rather than per thread. Then again, ThreadLocal some overhead too.
Given these optimization decisions were made 20 years ago and JVMs,
especially GC, have moved on since then, I'm leaning towards option b)
with c) as the fall-back if performance issues are discovered.
Usually, it's now a lot better to do b) if you want to drop a), and I
would say c) is the worst.
Thanks for confirming the reasoning for the ThreadLocal use. Impressive
memory!
I wrote a simple test case to examine this for MappingData and
MessageBytes. I tried to include the costs of object creation, object
recycling and GC as appropriate.
The results so far with Java 21 indicate that creating a new object is
always the better option. My working assumption is that time saved not
having to construct a new object with a ThreadLocal cache is out-weighed
by the overhead of looking up the ThreadLocal.
The next best option is the ThreadLocal cache which is always better
than SynchronizedStack with a thread pool. Even single threaded.
If using virtual threads, under high concurrency SynchronizedStack
starts to do better than ThreadLocal. My working assumption here is that
the overhead of having to create the ThreadLocal every time exceeds the
overhead of waiting for the sync.
My current thinking is that I'd like to:
- confirm my working assumptions with a profiler
- generalise the test case for any object type
- start reviewing the use of ThreadLocal cache and SynchronizedStack
throughout the code base, replacing it with simple construction where
performance figures indicate it makes sense
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
