RFR: Cleanup NumberSeq additions
Y. Srinivas Ramakrishna
ysr at openjdk.org
Thu Apr 27 16:31:23 UTC 2023
On Thu, 27 Apr 2023 15:31:58 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`
> - [ ] Linux AArch64 fastdebug `hotspot_gc_shenandoah`
> - [ ] GitFarm
src/hotspot/share/gc/shenandoah/shenandoahNumberSeq.cpp line 167:
> 165: }
> 166:
> 167: void HdrSeq::clear() {
Don't the _num, _sum, _maximum, etc. need to be cleared as well? May be extend the tests to check for clearing if not already the case.
Otherwise looks good; will take a closer look in a bit.
-------------
PR Review Comment: https://git.openjdk.org/shenandoah/pull/268#discussion_r1179414862
More information about the shenandoah-dev
mailing list