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