RFR (M): 7023898: Intrinsify AtomicLongFieldUpdater.getAndIncrement()
john.r.rose at oracle.com
Tue Jun 26 11:24:45 PDT 2012
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev