On 3/5/21 7:13 PM, Eirik Bjørsnøs wrote:
> 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. A
>
> But before that. Alan Bateman said to me that Loom project has much
> simpler implementation to what you want.
>
Ahh! Another good reason why I'm seriously considering just going to the
beach and returning once Loom is shipped! :-)
Can't do that. JIT have to update underlying hash table to co
Eirik
See my answers bellow.
But before that. Alan Bateman said to me that Loom project has much simpler
implementation to what you want.
Thread local scopedCache which is Object[] array referenced from current thread:
https://github.com/openjdk/loom/blob/fibers/src/java.base/share/classes/jav
On Fri, Mar 5, 2021 at 6:41 PM Vladimir Kozlov
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 n
Hi Erik,
The implementation of ThreadLocal is based on HashMap:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ThreadLocal.java#L76
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(
Hello,
ThreadLocals are commonly used to transfer state across method boundaries
in situations where passing them as method parameters is impractical.
Examples include crossing APIs you don't own, or instrumenting code you
don't own.
Consider the following pseudo-instrumented code (where the orig
