On Fri, May 5, 2023 at 5:28 PM Mark Thomas <ma...@apache.org> wrote: > > Hi all, > > I've started to review the use of ThreadLocal within the Tomcat code > base given that using virtual threads will soon be an option. > > The first usage I came to raised a few questions. The usage is in > ApplicationContext: > > https://github.com/apache/tomcat/blob/main/java/org/apache/catalina/core/ApplicationContext.java#L418 > > My first question - mostly for Rémy - is can you remember why this is a > ThreadLocal. I admit that is a bit of an ask since the use of > ThreadLocal dates back almost 20 years to this commit: > > https://svn.apache.org/viewvc/tomcat/archive/tc5.5.x/trunk/container/catalina/src/share/org/apache/catalina/core/ApplicationContext.java?r1=301883&r2=301884&; > > My guess, is that a ThreadLocal was used as a way to cache instances of > MappingData and MessageBytes between requests - recycle and reuse rather > than GC. Is that right?
Yes, that's it. > 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 > SynchropnizedStack. 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. Rémy > > Thoughts? > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
