On Fri, Mar 5, 2021 at 6:41 PM Vladimir Kozlov <vladimir.koz...@oracle.com> wrote:
Vladimir, Thanks a lot for taking time to consider this! Some comments inline: > Currently it is "impossible" for JIT compiler to reliably know that value > stored by set() in hash map is the same as > read by get(). > My layman (perhaps naive?) thinking was that a JIT could cheat and infer this by definition. Since a ThreadLocal holds memory that is by definition local to the executing thread, a JIT should have exclusive access to the content of the ThreadLocal. Any back-to-back set/get (or get/get) should therefore yield the same value (because no other thread can update the contents of the ThreadLocal). However, the JMM doesn't seem to mention ThreadLocals explicitly, so perhaps a JIT would need to look at the implementation.. As a programmer I would certainly be somewhat surprised if a ThreadLocal get yielded another value than my immediately preceding set, or if my two consecutive gets would yield different values. What kind of access patterns could you see breaking this assumption? Reflective access into Thread.threadLocals internals by clever frameworks, similar to how final fields aren't really final? > Also because of ThreadLocal accessors's complex code, some calls may not > be inlined and JIT does not know what side > effect they may have - it assumes that they can modify a value. > Not sure I'm following completely. Your concern is that the added "bulk" of ThreadLocal.get could prevent inlining? But wouldn't this suggested optimization simply replace the get with a local variable access, thus removing the bulk. Or isn't this the order inlining happens in? Thanks, Eirik.
