Atomic operations: your thoughts are welocme

[Andrew Haley]

I've been looking at the hottest Atomic operations in HotSpot, with a view to
finding out if the default memory_order_conservative (which is very expensive
on some architectures) can be weakened to something less. It's impossible to
fix all of them, but perhaps we can fix some of the most frequent.

These are the hottest compare-and-swap uses in HotSpot, with the count
at the end of each line.

<G1ParScanThreadState::trim_queue_to_threshold(unsigned int)+7284>:     :: = 16406757

This one is already memory_order_relaxed, so no problem.

<OopOopIterateDispatch<G1CMOopClosure>::Table::oop_oop_iterate<InstanceKlass, narrowOop>(G1CMOopClosure*, oopDesc*, Klass*)+336>:       :: = 3903178

This is actually MarkBitMap::par_mark calling BitMap::par_set_bit. Does this
need to be memory_order_conservative, or would something weaker do? Even
acq_rel or seq_cst would be better.

<Symbol::decrement_refcount()+44>:      :: = 2376632
<Symbol::increment_refcount()+44>:      :: = 2003895

I can't imagine that either of these actually need memory_order_conservative,
they're just reference counts.

<OtherRegionsTable::add_reference(void*, unsigned int)+248>:    :: = 1719614

BitMap::par_set_bit again.

<G1ParScanThreadState::steal_and_trim_queue(GenericTaskQueueSet<OverflowTaskQueue<ScannerTask, (MEMFLAGS)5, 131072u>, (MEMFLAGS)5>*)+432>:      :: = 1617659

This one is GenericTaskQueue::pop_global calling cmpxchg_age().
Again, do we need conservative here?

There is, I suppose, always a possibility that some code somewhere is taking
advantage of the memory serializing properties of adjusting refcounts, I suppose.

Thanks,

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671