HashMap.modCount accesses should be opaque?

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

HashMap.modCount accesses should be opaque?

JSR166 Concurrency mailing list
Probably HashMap.modCount reads and writes should use VarHandle's Opaque mode, to increase chances of catching concurrent modifications in some cases.

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

Re: HashMap.modCount accesses should be opaque?

JSR166 Concurrency mailing list
Hi Roman,

It is a nice idea from the functionality point of view.
Just thinking loud (ie to be verified): using VarHandle's Opaque mode I'm expecting that would introduce some compiler barriers (depends on the CPU architecture) preventing some useful compiler optimizations (eg hoisting of range checks of arrays while loop unrolling).
In addition, I have always thought that modCount was designed to be used in a concurrent (but not parallel) scenario, but I could be wrong!

Cheers,
Franz

Il giorno gio 13 dic 2018, 20:22 Roman Leventov via Concurrency-interest <[hidden email]> ha scritto:
Probably HashMap.modCount reads and writes should use VarHandle's Opaque mode, to increase chances of catching concurrent modifications in some cases.
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

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

Re: HashMap.modCount accesses should be opaque?

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
On 12/13/18 2:20 PM, Roman Leventov via Concurrency-interest wrote:
> Probably HashMap.modCount reads and writes should use VarHandle's Opaque
> mode, to increase chances of catching concurrent modifications in some
> cases.

I don't think anyone would thank us for doing this. It would slightly
improve detection at the cost of slightly reducing optimizability
(performance).

And in any case, race detector tools are becoming usable enough to make
them routinely useful during development, making jdk heuristic detection
less of a priority.


-Doug

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest