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