I guess that the cost for an array element access is more expensive than
accessing a field, regardless of volatile. The offset is computed at
runtime for an array element and might need to be checked to be in the
range of valid indices, while the offset of a field is known and can be
a
+ core-libs-dev@ I meant relation between in-loop and hoisted access. In Java 19 when we take count = 100 for volatile array and hoist it from the loop then the average time decreases from 146 to 33 ns. And if we take the same count for "plain" field and hoist it from the loop then the average
I meant relation between in-loop and hoisted access.
In Java 19 when we take count = 100 for volatile array and hoist it from the
loop then the average time decreases from 146 to 33 ns.
And if we take the same count for "plain" field and hoist it from the loop then
the average time decreases
If I read the data correctly, for the count=100 case in jdk 20 it takes
109 ns/op for the array and 74 ns/op for the field.
To me this looks like a field access is _less_ expensive.
Am I missing something?
On 2023-08-16 13:37, Сергей Цыпанов wrote:
Hello,
I was measuring costs of hoisting
Hello,
I was measuring costs of hoisting volatile access out of the loop and found
out, that there's a difference in numbers for arrays and "plain" references.
Here's the benchmark for array:
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Warmup(time = 2, iterations =
