RFR: Guard interpreter keep alive barrier with ShenandoahKeepAliveBarrier
Aleksey Shipilev
shade at redhat.com
Tue Jan 16 17:47:32 UTC 2018
On 01/16/2018 06:43 PM, Roman Kennke wrote:
> One thing that I found in traversal GC work: with -ShenandoahKeepAliveBarrier we still generate some
> code in the interpreter that is only used for the keep-alive-barrier. This patch avoids this. I
> realize that this should require some better refactoring (to move more of that code into
> keep_alive_barrier() to begin with), but I suspect that can wait until upstream codegens arrive,
> then we need to refactor it (big time) anyway.
>
> http://cr.openjdk.java.net/~rkennke/interpreter_keep_alive_barrier/webrev.00/
I think this is already handled inside MacroAssembler::keep_alive_barrier, that this block
eventually calls into:
void MacroAssembler::keep_alive_barrier(Register val,
Register thread,
Register tmp) {
if (UseG1GC) {
// Generate the G1 pre-barrier code to log the value of
// the referent field in an SATB buffer.
g1_write_barrier_pre(noreg,
rax /* pre_val */,
thread /* thread */,
tmp,
true /* tosca_live */,
true /* expand_call */);
} else if (UseShenandoahGC && ShenandoahKeepAliveBarrier) {
shenandoah_write_barrier_pre(noreg,
rax /* pre_val */,
thread /* thread */,
tmp,
true /* tosca_live */,
true /* expand_call */);
}
}
So the better fix would probably revisit all uses of keep_alive_barrier, and protect their relevant
blocks, then putting the assert(ShenandoahKeepAliveBarrier) in MacroAssembler::keep_alive_barrier?
-Aleksey
More information about the shenandoah-dev
mailing list