Code Review Request: 7164636: (prefs) Cleanup src/macosx/classes/java/util/prefs

[David Holmes]

On 15/05/2012 2:41 AM, Brian Goetz wrote:
>  From a concurrency perspective it is also preferable to NOT initialize
> variables to their default values, as doing so can cause some weird
> problems. For example:
>
> class A {
> public int x = 0;
>
> public void increment() { ++x; }
> public int get() { return x; }
> }
>
> // Thread X
> // Assume: Thread X never touches 'a' again
> A a = new A();
>
> // Thread Y
> // Assume: No other thread than Y touches 'a'
> if (a != null) {
> a.increment();
> System.out.println(a.get());
> }
>
> With the explicit initialization, this code could print zero (because
> the set of writes to 'x' contains two writes, one by X to zero and one
> by Y to 1), whereas without the explicit initialization, it would always
> print one.

I do not agree.

The above can only print zero if program-order is violated, which I 
don't believe it can or should be.

But the "set of writes" is the same regardless of whether default or 
explicit initialization is used. The JMM explicitly states (17.4.4) that 
the write of the default value synchronizes with the first action in 
every thread and acts as-if each object were allocated and initialized 
to default values when the VM starts.

> Now, this is an example of "improper publication" of the A by Thread X,
> but this is the sort of improper publication (where an object was
> initialized by one thread and then "handed off" to another) that was
> widely thought to be safe a long time ago and was enshrined in many
> examples, particularly Swing examples.
>
> The sharing here is clearly wrong, but the approach of not unnecessarily
> initializing non-final fields eliminates a path to tickling the improper
> publication into actually producing the wrong result.

Initializing to a default value should be a no-op. I had thought javac 
already optimized these away but perhaps it is only the JIT.

David
-----

> On 5/14/2012 5:28 AM, Chris Hegarty wrote:
>> This change looks fine to me.
>>
>> Trivially, changedFiles and cachedFiles do not need to be set to null (I
>> believe this will generate a little less bytecode), as this is the
>> default reference value. Since you are in clean-up mode ;-)
>>
>> -Chris.
>>
>> On 11/05/2012 22:46, Kurchi Hazra wrote:
>>> Hi,
>>>
>>> This change aims at removing some rawtype usages in
>>> src/macosx/classes/java/util/prefs that were brought
>>> into jdk8 with the macport. I have added @Override tags too where
>>> applicable.
>>>
>>> Bug: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7164636
>>> Webrev: http://cr.openjdk.java.net/~khazra/7164636/webrev.00/
>>>
>>>
>>> Thanks,
>>> Kurchi
>>>