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!
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.
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
I don't think anyone would thank us for doing this. It would slightly
improve detection at the cost of slightly reducing optimizability
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.