RFR (M): 7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement()

[Vladimir Kozlov]

OK, I think we should stop here. Roland, use what you think is best.

Vladimir

John Rose wrote:
> On Jun 26, 2012, at 7:27 AM, Vladimir Kozlov wrote:
> 
>> I first thought about LoadStoreAdd, LoadStoreSet, LoadStoreCmpXchg. I 
>> don't like abbreviation (LS).
>>
>> On 6/26/12 12:55 AM, Roland Westrelin wrote:
>>>> Even so John said you can use LS I would suggest to use full name. 
>>>> Why not use nodes names? For a example: GetAndAdd, GetAndSet, 
>>>> CompareAndSwap. It is easier to understand the meaning.
>>>
>>> Are you suggesting I drop the LS prefix as well?
>>> I would expect it to be good for readability that the name contains a 
>>> hint that all those constants are related to each other.
>>
>> They are used in the same method so one can see that they are related. 
>> I don't like abbreviation (LS) but I am not strongly against it. It is 
>> up to you.
>>
>> Vladimir
> 
> Here's another $0.02 on the subject.
> 
> To me the important thing is that enums (like all manifest constants) 
> should be easy to distinguish from other names (variables, classes), and 
> easy to relate to their definition site and meaning.
> 
> There are several ways we do this in the source base.  A common 
> prefix or suffix is one way, a common theme word is another way.  I just 
> tried the following grep and found the output instructive:
>   grep -A2 '^  enum[^;]*$' $(hg loc -I 'src/share/**/*.hpp')
> 
> Leading underscores and/or all-caps spellings can reinforce the status 
> of enum names as manifest constants.
> 
> The bare operation names above (in either lower case or camel-case) do 
> not look like manifest constants to me; that is why I suggested some 
> extra decoration.  But it is just a suggestion. I like Vladimir's idea 
> of adapting pre-existing names (GetAndSet), but without adjustment they 
> look too much like C++ class names.  Note that our Node type enums have 
> an Op_ prefix, so they can be recognized as constants more easily.
> 
> — John