RFR: 8334060: Implementation of Late Barrier Expansion for G1 [v2]
Albert Mingkun Yang
ayang at openjdk.org
Thu Aug 29 08:40:21 UTC 2024
On Wed, 28 Aug 2024 15:46:57 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:
>> Thanks for trying! I like your refactored version. I prefer moving stuff out of the .ad files. The complexity of the barrier code is not significantly higher. Note that you could use `decode_heap_oop_not_null(Register dst, Register src)` with `tmp2` as dst (`generate_post_barrier_fast_path` can deal with new_val == tmp2). That would save a move instruction in some cases.
>> I haven't looked into the aarch64 code. I leave you free to decide.
>
> Thanks, I prototyped the refactored version for both x64 and aarch64 [here](https://github.com/robcasloz/jdk/commit/c1ae871eadac0d44981b7892ac8f7b64e8734283). I do not have a strong opinion for or against this refactoring. @albertnetymk @kimbarrett what do you think about it? (asking since you have recently looked at this code).
I find the use of default-arg-value `bool decode_new_val = false` a bit confusing. (I tend to think default-arg-value makes the code less readable in general.)
If not using default-arg-value, I suspect the diff will be larger, and I don't see the immediate benefit of this refactoring. Maybe this can be deferred to its own PR if it's really desirable?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19746#discussion_r1735806805
More information about the hotspot-compiler-dev
mailing list