ConcurrentHashMap and Unsafe usage

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

ConcurrentHashMap and Unsafe usage

JSR166 Concurrency mailing list
Hi,

Now that most of the concurrent data structures in j.u.c have transitioned to using VarHandle.
I was wondering why ConcurrentHashMap still uses Unsafe for its variables?

Cheers
  Kasper

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ConcurrentHashMap and Unsafe usage

JSR166 Concurrency mailing list
On 05/23/2018 07:40 PM, Kasper Nielsen via Concurrency-interest wrote:
> Hi,
>
> Now that most of the concurrent data structures in j.u.c have
> transitioned to using VarHandle.
> I was wondering why ConcurrentHashMap still uses Unsafe for its variables?
>

Bootstrapping. The VM code to compile VarHandles relies on
ConcurrentHashMap. People have looked into somehow changing this, but
nothing seems better than just allowing this to continue.

-Doug

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: ConcurrentHashMap and Unsafe usage

JSR166 Concurrency mailing list


> On May 23, 2018, at 4:56 PM, Doug Lea via Concurrency-interest <[hidden email]> wrote:
>
> On 05/23/2018 07:40 PM, Kasper Nielsen via Concurrency-interest wrote:
>> Hi,
>>
>> Now that most of the concurrent data structures in j.u.c have
>> transitioned to using VarHandle.
>> I was wondering why ConcurrentHashMap still uses Unsafe for its variables?
>>
>
> Bootstrapping. The VM code to compile VarHandles relies on
> ConcurrentHashMap. People have looked into somehow changing this, but
> nothing seems better than just allowing this to continue.
>

Right. It seems possible and we have looked into it and other areas like in ThreadLocalRandom [*], but priority wise (for me at least) it always got bumped down in the priority queue of stuff to do.
 
Paul.

[*] One the challenge is to tease apart CMH usage from some areas of the java.lang.invoke implementation and replace with something similar but more focused. Another is to make VarHandle allocations lazy (e.g. if we could ldc a VarHandle and express that in the Java language and byte code, we can already do the latter with constant dynamic).
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest