RFR: Cleanup NumberSeq additions [v2]

Aleksey Shipilev shade at openjdk.org
Thu Apr 27 20:20:53 UTC 2023


> 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`
>  - [ ] GitFarm

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Clear the fields

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/268/files
  - new: https://git.openjdk.org/shenandoah/pull/268/files/f4fb3ab9..c4f81483

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah&pr=268&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah&pr=268&range=00-01

  Stats: 10 lines in 1 file changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah/pull/268.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/268/head:pull/268

PR: https://git.openjdk.org/shenandoah/pull/268


More information about the shenandoah-dev mailing list