nice! would be interested to see the performance numbers if you have them

@Jpx3 thank you! is that before or after?

How about using guava new MapMaker().weakKeys().makeMap()? This would create a concurrent map (removes the need to compute the value for each thread) with weak keys. Just note that this technically creates a ConcurrentWeakIdentityMap - not sure if this is really relevant in this case.

yeah that's a good point. is there any advantage to keeping it thread-local? i'd imagine classes are instantiable or not regardless of thread

Having it thread-local eliminates any locking by the map. This makes it thread-safe by design while still retaining its speed. And since we are talking about some class references and a few booleans, having some extra copies per thread doesn't matter that much. It will make the problem 50 times faster, but if you want to spend 4 hours thinking how to make it 51 times faster, we can elaborate this discussion 😅

fair enough!

We're basically moving this problem behind the "plugins (or the server itself) start using virtual threads and users complain about performance again" barrier 😄

We're basically moving this problem behind the "plugins (or the server itself) start using virtual threads and users complain about performance again" barrier 😄

I would hope at that point java virtual threads have a solution to handle this.