RFR: Guard interpreter keep alive barrier with ShenandoahKeepAliveBarrier

Roman Kennke rkennke at redhat.com
Tue Jan 16 17:49:41 UTC 2018


Am 16.01.2018 um 18:47 schrieb Aleksey Shipilev:
> 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
> 

Yes, that is what I mean with 'this should need more refactoring' ;-) 
Only the code that I touched uses it, so we should infact move all that 
code under keep_alive_barrier() instead. Want me to do that now? Or wait 
until codegen for interpreter arrives and do it really properly?

Roman



More information about the shenandoah-dev mailing list