Uwe Schindler

> > But I think it would be improved by providing some more diagnostics (LogCompilation or whatever, maybe JIT stats in the JFR output). Let it be a "canary" to...

> Hi @uschindler, > I get the following compilation errors when I build your patch (Gradle build 6.3.8) > > > Task :altJvmWarning > > NOTE: Alternative java toolchain will...

Stupid question: Why do you not open a bug report on OpenJDK? If this ThreadLocal implementation is working better than the original one AND it behaves exactly identical, why not...

> That being said, I don't have real opposition to this patch, but I want us to be careful about correctness. I am also concerned about not hurting the performance...

One suggestion: Use a `ReadWriteLock` (https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/concurrent/locks/ReadWriteLock.html) instead of synchronization around the map using an `Object lock`. This makes sure that multiple threads can read from the map in parallel. This...

Something like: ```java private final Lock readLock, writeLock; CloseableThreadLocal#ctor() { super(); var rwLock = new ReentrantReadWriteLock(); this readLock = rwLock.readLock(); this.writeLock = rwLock.writeLock(); //... more init here } // later...

I agree with both of you: - We should avoid ThreadLocal at places where it can be done in another way (like for StoredFieldsReaders, it can just create a new...

> I want to see these servers make real effort to not use 10,000 threads. Why does Elasticsearch need so many threads? They have a selector based connection handling! And...

> What is unclear is whether this is the reason why some users have been seeing this threadlocal behavior, or if it's something that can generally happen due to the...

In short: ThreadLocals in Analyzers is ok, because even with many threads (still10.000 is fine), because you have a map per thread pointing to few analyzer's threadlocals with a weak...