RFR: 8228369: Shenandoah: Refactor LRB C1 stubs
Aleksey Shipilev
shade at redhat.com
Fri Jul 19 18:32:13 UTC 2019
On 7/19/19 4:27 PM, Roman Kennke wrote:
> Please review this updated patch:
>
> http://cr.openjdk.java.net/~rkennke/JDK-8228369/webrev.01/
Brief look:
*) The comment here is inconsistent with the implementation: mentions "not_resolved", while argument
is "resolved": shenandoahBarrierSetAssembler_aarch64.cpp
485 // Generate check if object is resolved. Branch to not_resolved label, if not. Otherwise return
resolved
486 // object in obj register.
487 // obj: object, resolved object on normal return
488 // tmp1, tmp2: temp registers, trashed
489 void ShenandoahBarrierSetAssembler::gen_resolved_check(MacroAssembler* masm, Register obj,
Register tmp1, Register tmp2, Label& resolved) {
490 __ mov(tmp2, obj);
491 resolve_forward_pointer_not_null(masm, obj, tmp1);
492 __ cmp(tmp2, obj);
493 __ br(Assembler::EQ, resolved);
494 }
*) Is there any actual benefit for separating gen_cset_check and gen_resolved_check? It seems to
have only two uses, and copy-paste looks like less evil.
*) In x86 code, can't you use resolve_forward_pointer too, instead of doing decoding by hand?
-Aleksey
More information about the hotspot-gc-dev
mailing list