Hi Claes,
On 06/18/2018 03:54 PM, Claes Redestad wrote:
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.
OK, but the constructor will still need a releaseFence at the end to
prevent a potential write that unsafely publishes Properties instance to
float before the volatile writes of 'map' and 'defaults'...
You might want to use Unsafe directly for that since VarHandle could
cause bootstrap issues.
Regards, 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
