On 21/02/2014 10:28 AM, John Rose wrote:
On Feb 20, 2014, at 12:09 PM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@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
