RFR: Guard interpreter keep alive barrier with ShenandoahKeepAliveBarrier
Roman Kennke
rkennke at redhat.com
Tue Jan 16 17:54:13 UTC 2018
Am 16.01.2018 um 18:52 schrieb Aleksey Shipilev:
> On 01/16/2018 06:49 PM, Roman Kennke wrote:
>> Am 16.01.2018 um 18:47 schrieb Aleksey Shipilev:
>>> 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?
>
> I think it does not matter at this point. We usually use Shenandoah*Barrier as the performance
> investigation tool, which means we do care about what compilers do. We are not really interested in
> what interpreters do perf-wise. So, a better move resource-wise would be to make it right once,
> after codegen interfaces arrive.
>
> Or, does it affect Traversal GC perf?
>
No, not really. It just means we keep alive more weakrefs than we need to.
Ok, let's drop it for now.
Roman
More information about the shenandoah-dev
mailing list