> 3. Discussed HDDS-10385 ... a high GC pressure is also observed if ThreadLocal is replaced with create object for each OMClientRequest. ...
In HDDS-10385 (https://github.com/apache/ozone/pull/6234), it claims that "Instance object is having thread local object, which can have memory leak as thread local is not explicitly released. ...". ThreadLocal variables, like non-thread-local variables, are garbage collected. We don't have to release resources explicitly. Below is quoted from https://docs.oracle.com/javase/8/docs/api/java/lang/ThreadLocal.html "Each thread holds an implicit reference to its copy of a thread-local variable as long as the thread is alive and the ThreadLocal instance is accessible; after a thread goes away, all of its copies of thread-local instances are subject to garbage collection (unless other references to these copies exist)." It may not be clear whether "after a thread goes away" is a required condition. Checked the ThreadLocal code, it has a ThreadLocalMap whose Entry extends WeakReference<ThreadLocal<?>>. Therefore, if there are no external references, a ThreadLocal variable is weakly reachable and will be garbage collected. Again, no resources need to be explicitly released. Note that the code before HDDS-10385 was ineffective since the ThreadLocal variable omLockDetails in OMClientRequest was non-static. Then, a new ThreadLocal will be allocated when creating a new OMClientRequest object, and the ThreadLocal will be garbage collected when the OMClientRequest object is unreachable. The intention of using ThreadLocal probably was to reuse the same omLockDetails object across different OMClientRequest objects. As described above, since the ThreadLocal was non-static, the omLockDetails object was never reused. Although HDDS-10385 did not fix memory leak (since there was no leakage), it did reduce memory usage and improve performance since it has avoided the ThreadLocal overhead. The observed high GC pressure may be due to the performance improvement because it can process more requests. Not sure if it is the case. Regards, Tsz-Wo On Tue, Feb 27, 2024 at 5:13 AM Sammi Chen <sammic...@apache.org> wrote: > Attenders: Yiyang, Ivan, Sumit, Siddhant, Tejaskriya, Wei-Chiu, Sammi > Agender: > 1. Disk Balancer feature(HDDS-5713), the major code development is > finished. Next Yiyang will test the function locally. > 2. Native ACL discussion > a. Discussed whether directory native ACL will be checked when > accessing a file in FSO bucket. The answer is clear. Need further check the > implementation. > b. Discussed prefix ACL, if multiple prefixes are matched, what's the > expected behavior of ACL check, which prefix ACL rule will be used. The > prefix ACL which matches the most will be used. > c. Shared the prefix ACL usage. It's used to control the access from > different users to different hive tables. > 3. Discussed HDDS-10385 "Memory leak for thread local usages in > OMClientRequest". It's mentioned that there is no memory leak observed in > the production cluster with previous ThreadLocal implementation, and a high > GC pressure is also observed if ThreadLocal is replaced with create object > for each OMClientRequest. A new proposal is made and its feasibility needs > further check. >
