Atomic operations: your thoughts are welocme

[Ioi Lam]

Just curious, which benchmark is this?

Thanks
- Ioi

On 2/8/21 10:14 AM, Andrew Haley wrote:
> 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,
>