RFR: 8334060: Implementation of Late Barrier Expansion for G1 [v3]

Roberto Castañeda Lozano rcastanedalo at openjdk.org
Thu Aug 8 14:23:36 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'm back from vacation now and resuming my work in this JEP. After some offline discussions, I have pushed a new version (commit 20ef68c81e) without helper functions, except for `generate_queue_insertion()` which is still included. @albertnetymk please have a look and let me know if you find the new style more readable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1709618766


More information about the hotspot-compiler-dev mailing list