ThreadLocal lookup elimination

[Eirik Bjørsnøs]

On Fri, Mar 5, 2021 at 6:41 PM Vladimir Kozlov <vladimir.kozlov at 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.