On some architectures, volatile reads come with the associated performance costs. We need to see if VarHandles Opaque mode fits better for "isDone" flag checks, and around the Blackholes. This might drop down the lower time bound for the measurable effects on those platforms.
Caveats:
We want to break optimizations *across* isDone checks, i.e. between separate @Benchmark calls. Right now we are somewhat saved by having the non-counted loop that would not be unrolled. As implemented now, Opaque does not suffer from this, because it just emits the CPUOrder barriers around the access. But we have to wonder if careful optimization would be able to enforce the subordering only for non-plain accesses.
Caveats:
We want to break optimizations *across* isDone checks, i.e. between separate @Benchmark calls. Right now we are somewhat saved by having the non-counted loop that would not be unrolled. As implemented now, Opaque does not suffer from this, because it just emits the CPUOrder barriers around the access. But we have to wonder if careful optimization would be able to enforce the subordering only for non-plain accesses.
- relates to
-
JDK-8046183 JEP 193: Variable Handles
-
- Closed
-