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