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