On Wed, 13 May 2026 15:30:47 GMT, Aleksey Shipilev <[email protected]> wrote:
>> Xiaolong Peng has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 386 commits: >> >> - Merge branch 'openjdk:master' into cas-alloc-1 >> - Document _collector_allocator_reserved ordering contract >> - Tame TestCASAllocContention: fewer threads, shorter run, smaller retention >> - Comment: pair reserve-time inflation with read-time compensation >> >> Cross-reference ShenandoahFreeSet::reserve_alloc_regions_internal at >> every 'bytes_allocated - mutator_allocator_remaining' subtraction site. >> No behavior change. >> - Include mutator allocator remaining bytes in unsafe_max_tlab_alloc >> - Reserve mutator alloc regions after abbreviated degenerated GC >> - fix: new jtreg tests miss -XX:+UnlockDiagnosticVMOptions >> - fix: sync _top before CAS in unset_active_alloc_region >> - fix: sync _top once on CAS success and reset_age after the loop in >> unset_active_alloc_region >> - Add jtreg tests for CAS allocator flag combinations and contention >> - ... and 376 more: https://git.openjdk.org/jdk/compare/ebb3d688...ce68d1fa > > No, this requires significantly more work. This is way too hard to review. > You need to drastically and mercilessly simplify. > > I believe it would be significantly simpler if you can introduce "allocator" > interface separately without any semantic changes first. _Then_ extend that > allocator with CAS allocations support. > > Additionally, I think it clashes with > https://github.com/openjdk/jdk/pull/31047, and that one probably needs to go > in first. > Agree with @shipilev that we should simplify this PR so that it is more > accessible to more reviewers and we can assimilate the changes in smaller > incremental steps. > > Makes sense to start with the ShenandoahAllocator refactoring as a separate > PR. > > A second step might be to simplify the accounting updates that are performed > immediately following each change to the freeset tallies. > > A third step might be to remove alignment requirement on PLABs given upstream > changes that have already been integrated. That way we wouldn't have to > special case the OldCollector Allocator. > > Then maybe we can integrate the CAS allocator change. > > Not sure that the order I suggest above for these incremental steps > represents the smoothest evolution of the software. If you think a different > order makes more sense, that's fine with me. Thanks! I agree with smaller PRs instead of one giant PR with all the features supporting the CAS allocator. I will break it down to multiple phases, and create PR for each phase. I think we don't need to keep this PR open, next PR will be just the new allocator interface(refactoring), I have been working on it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26171#issuecomment-4453946072
