RFR 8199435 : Unsafe publication of java.util.Properties.map
Peter Levart
peter.levart at gmail.com
Mon Jun 18 14:23:01 UTC 2018
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
>
More information about the core-libs-dev
mailing list