RFR/RFC: Make OOM-during-evacuation race-free

Roman Kennke rkennke at redhat.com
Mon Oct 23 15:59:09 UTC 2017


Am 23.10.2017 um 17:49 schrieb Aleksey Shipilev:
> On 10/23/2017 02:44 PM, Roman Kennke wrote:
>> I would like to get your comments on the patch, and approvals from everybody (Christine, Aleksey,
>> Zhengyu and Roland) before pushing. In particular, I'd be happy if Aleksey could run some
>> read-barrier heavy gc-benchmarks to measure the (worst-case) impact of masking in the read-barriers.
>>
>> http://cr.openjdk.java.net/~rkennke/safe-oom-during-evac/webrev.02/
> While the trick is interesting, I don't like it very much that we are extending the read barriers.
> It *should* have the non-zero performance impact -- because even adding the NOPs had -- and I can
> run the tests after Roland's change lands and makes RBs more frequent.
>
> The performance data you have is very noisy to capture <10% regressions. I think it makes sense to
> discuss the change only when we have accurate performance data on hand. Otherwise, we have to
> consider alternatives that do not touch the RBs.
>
> Thanks,
> -Aleksey
>
Yes I see all that. But we have found out that this is a correctness 
issue, and that trumps performance, even if it's just a very miniscule 
case. Roland's read-barriers is a good example: we give up an 
optimization that does have a performance impact for correctness, and it 
can even be argued if it's strictly correctness because according to the 
JVM spec we're even correct *if* we optimize finals. And I'd venture a 
guess that this optimization has more performance impact than what I am 
proposing. And a similar rarity factor too.

If we can come up with another solution that makes running 
OOM-during-evac 100% I'm all for it.  I'm not fixed on my proposal, I 
just wanted to throw it out for discussion and bring something on the 
table that we can do some performance tests with.

Cheers, Roman



More information about the shenandoah-dev mailing list