jaisonbi commented on PR #816:
URL: https://github.com/apache/lucene/pull/816#issuecomment-1110743533
> 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 ask OpenJDK people to replace theirs?
Thanks for the comment.
Different TheadLocal instances are mixed stored in one ThreadLocalMap, it's
the current JDK implementation.
The problem is that ThreadLocal instances cannot be removed immediately in
CloseableThreadLocal, so making the problem worse. I added one comment in
LUCENE-10519, just copying it here:
```
Each read thread should has own StoredFieldsReader, I think that's why
CloseableThreadLocal/ThreadLocal is used.
When one CloseableThreadLocal instance is created, it can be used by
multiple threads.
Suppose threads {Thread-1, Thread-2, Thread-3, Thread-4} are using same
CloseableThreadLocal instance, each thread set own value.
So each thread will store the ThreadLocal instance(t) into it's
ThreadLocalMap:
Thread-1: {ThreadLocalMap: [t]}
Thread-2: {ThreadLocalMap: [t]}
Thread-3: {ThreadLocalMap: [t]}
Thread-4: {ThreadLocalMap: [t]}
Suppose CloseableThreadLocal instance got closed by Thread-1. Only Thread-1
removed the ThreadLocal instance from ThreadLocalMap.
Thread-1: {ThreadLocalMap: []}
Thread-2: {ThreadLocalMap: [t]}
Thread-3: {ThreadLocalMap: [t]}
Thread-4: {ThreadLocalMap: [t]}
The other 3 threads only rely on GC reclaim them. Under G1 GC, the problem
gets worse, since each mixed GC only collect partial old regions.
So ThreadLocalMap entries table may get very huge. That's why
"ReentrantReadWriteLock$ReadLock.unlock" took long time(It need to take long
time to expunge stale entries from a huge table)
Regarding on the patch, we keep the similar behavior to ThreadLocal, but
avoid use ThreadLocal anymore.
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
