RFR: 8334060: Implementation of Late Barrier Expansion for G1 [v5]
Amit Kumar
amitkumar at openjdk.org
Mon Aug 12 08:50:35 UTC 2024
On Mon, 12 Aug 2024 08:35:57 GMT, Roberto Castañeda Lozano <rcastanedalo at openjdk.org> wrote:
> > is there issue if we replace this code:
> > ```
> > if (in_bytes(SATBMarkQueue::byte_width_of_active()) == 4) {
> > __ ldrw(rscratch1, in_progress);
> > } else {
> > assert(in_bytes(SATBMarkQueue::byte_width_of_active()) == 1, "Assumption");
> > __ ldrb(rscratch1, in_progress);
> > }
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > in method `G1BarrierSetAssembler::gen_write_ref_array_pre_barrier` with `generate_queue_test_and_insertion(masm, rthread, rscratch1)` ?
> > Though you have to move the `gen_write_ref_array_pre_barrier` on top otherwise compiler wouldn't be able to find it.
>
> Thanks for the suggestion Amit! this refactoring would work (assuming you mean `generate_pre_barrier_fast_path` instead of `generate_queue_test_and_insertion`), however I am hesitant to apply it because 1) it would further increase the size of the changelog and hence the burden of reviewing it and 2) it is not a clear maintainability win: some engineers prefer a little bit of code duplication to preserve the assembly code flow (see discussion [here](https://github.com/openjdk/jdk/pull/19746#discussion_r1645713269)).
Ha! makes sense.
Are you planning to rebase it with master ? Nothing important, but there were couple of failures which are fixed after this PR. So will make test result a bit clean for us 😊.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19746#issuecomment-2283418237
More information about the hotspot-compiler-dev
mailing list