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