JDK 9 RFR of JDK-8035279: Clean up internal deprecations in BigInteger

[David Holmes]

On 21/02/2014 10:28 AM, John Rose wrote:
> On Feb 20, 2014, at 12:09 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>> If the sentinel values were the default zero values there would be no
>> issue
>
> This is an instance of the "stable value" pattern; see the javadoc for
> java/lang/invoke/Stable.
>
> Using zero for the sentinel in this pattern is the safest option.

By the definition of the "pattern" it seems to be the only option.

  * <p>
  * Since all fields begin with a default value of null for references
  * (resp., zero for primitives), it follows that this annotation indicates
  * that the first non-null (resp., non-zero) value stored in the field
  * will never be changed.


> If I'm reading the JMM argument right, using a non-default value
> (perhaps even an explicitly set zero value) relies on accidental effects
> from nearby final variables, which is fragile even if correct on HotSpot
> or in a future JMM.

A zero would be fine, even if explicitly set. The basic issue is that 
under the JMM, given that over time there will be three potential values 
for these fields, in the absence of any synchronization actions, the 
initial read of the field by any thread is allowed to return any of the 
values written up to that point in time. In practice the final-field 
related storestore barrier will reduce the set of potential values to 
two (dropping the default zero value).

> If zero is also a valid result, and the "+1" values everywhere are
> odious, make a wrapper method that returns the corrected value, and
> applies the correction in just one place.  That is much preferable to
> risking an initial race condition on your stable value.

Not clear what you mean by this.

David
-----

> — John