I'd suggest something simple like this to ensure correctness, while
keeping the number of volatile reads to a minimum:
http://cr.openjdk.java.net/~redestad/8199435.00/
Then file a follow-up RFE to investigate if we can make these fields
non-volatile, e.g. using careful fencing as suggested
by Peter.
/Claes
On 2018-06-18 15:27, Claes Redestad wrote:
On 2018-06-18 13:06, Peter Levart wrote:
Adding a volatile read on every read through Properties is likely to
have some performance impact,
On non-Intel architectures in particular. On intel it would just
inhibit some JIT optimizations like hoisting the read of field out of
loop...
Right, and coincidentally those platforms are where I'd expect the
current implementation to cause bugs (I've not been able to provoke
any real error on my Intel-based workstations).
I'd be surprised if we'd be much slower than pre-8029891 using
volatiles (volatile read vs synchronized - even with biased locking),
and we'd still retain the scalability benefits of 8029891.
Ignore my remarks about clone - I'm just back from vacation and have
apparently forgotten how cloning works. :-)
/Claes
