RFR: 8334060: Implementation of Late Barrier Expansion for G1 [v2]
Roberto Castañeda Lozano
rcastanedalo at openjdk.org
Thu Jun 20 04:39:10 UTC 2024
On Wed, 19 Jun 2024 08:45:45 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:
>> Note that if we want to optimize the barrier code layout (see the [JEP description](https://openjdk.org/jeps/475), *Candidate optimizations* sub-section), splitting the assembly of each barrier in at least two blocks is necessary, since we need to separate the inline from the out-of-line (barrier stub) code. And since the assembly code has to be split into multiple functions anyway, I think it makes sense to group the code by logical blocks (different barrier tests, queue insertion, etc.), as proposed in this changeset. This also improves code reuse, e.g. the same `generate_queue_insertion` implementation is used for the pre- and post-barriers.
>> If you still think there is value in grouping together the blocks that can be grouped together (e.g. `generate_single_region_test` + `generate_new_val_null_test` + `generate_card_young_test`), I can prototype the refactoring and let the G1 maintainers decide which alternative is more readable/maintainable.
>
>> This also improves code reuse
>
> In this area, I think code duplication is less of an issue -- it's more crucial that one can follow the asm flow as if reading real asm. (Ofc, this is subjective; feel free to keep as is.)
I personally find the current style more maintainable in that it 1) makes the high-level structure of the barriers more explicit and 2) reuses code across the pre- and post-barrier (the fact that queue insertion is an identical operation for both barriers is obscured in mainline by naming and instruction choice differences). Having said that, if there is consensus among G1 maintainers that generating the fast (inline) and slow (out of line) paths of each barrier in single functions (sacrificing reuse of the queue insertion logic) is preferable, I'm happy to change that. @tschatzl @kimbarrett what do you think?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1646925045
More information about the hotspot-gc-dev
mailing list