RFR: Cleanup NumberSeq additions [v3]

[Roman Kennke]

On Fri, 28 Apr 2023 08:20:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I have been looking into how to decrease our upstream exposure for `NumberSeq` changes, and it seems to be not solvable in an easy way. Normally, I would add `AbsSeq::add(AbsSeq& other)` methods and get to that from `HdrSeq::add(HdrSeq& other)`, and that almost works. The remaining bit is figuring out the decaying average/variance thingie. 
>> 
>> I spent an hour trying to come up with easily provable equations for _combining_ the decaying average/variance. The decaying average is somewhat easy, although there are boundary problems (decaying average treats 0-th element without adjustments, which requires remembering the `_last` element to compensate). Decaying variance looks remarkably scary in the few of my approaches.
>> 
>> If we enter with current code upstream, it would be the uphill battle to implemented decays and prove they work. So instead, I took the alternative approach of doing everything inside Shenandoah code, except the decays. This reverts `numberSeq.*` to upstream state.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug `hotspot_gc_shenandoah`
>>  - [x] Linux AArch64 fastdebug `hotspot_gc_shenandoah`
>>  - [x] GitFarm
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Looks good to me. Maybe rename that variable. ;-)

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp line 969:

> 967:   HdrSeq* worker_stats, HdrSeq* cum_stats) {
> 968:   for (int i = 0; i < MAX_CARD_STAT_TYPE; i++) {
> 969:     cum_stats[i].add(worker_stats[i]);

While you are here, maybe rename the cum_stats variable to something else ;-)

-------------

Marked as reviewed by rkennke (Lead).

PR Review: https://git.openjdk.org/shenandoah/pull/268#pullrequestreview-1406471471
PR Review Comment: https://git.openjdk.org/shenandoah/pull/268#discussion_r1180736421