Primitive boolean array packing
shade at redhat.com
Sun Oct 7 15:13:11 UTC 2018
On 10/07/2018 02:38 PM, B. Blaser wrote:
> Thanks Aleksey, you're absolutely right but a programmer can still
> disable this feature and use regular boolean arrays if necessary.
I fully expect the JVM feature/flag what optionally breaks the Java specification will be flat out
rejected. You can have the optional feature that makes the behavior tighter than required by spec,
but it is a hard stop to make the behaviors weaker than required by spec. So, the work on packed
boolean arrays has to demonstrate good performance with along with work tearing guarantees.
On 10/07/2018 01:47 PM, Andrew Haley wrote:
> But you get a lot of performance conflicts between cores having to share
> cache lines anyway. Maybe we should do some performance experiments: we
> wouldn't need to do all of the C2 work, just write a little C++ and asm
> code and measure what happens under some plausible conditions. We'd have
> to try both contended and uncontended situations.
My educated guess from the subword atomic operations over VarHandles: the local latency of
uncontended CAS would still be too significant to ignore. Over years, we hoped CAS overhead would
become negligible, but it still isn't (see Biased Locking as another example that depends on this).
More information about the jdk-dev