RFR: Re-do streamlining of read-barriers in Access API, and fix call paths that might lead to read-barriers via oop_iterate()
Roman Kennke
rkennke at redhat.com
Fri Jul 6 12:09:07 UTC 2018
> On 07/05/2018 08:43 PM, Roman Kennke wrote:
>> The previous patch to use SBS::resolve_forwarded() directly from Access
>> API impl failed because some fricking code paths get to read-barriers
>> via oop_iterate() and make full-GC fail because fwd-ptr is temporarily
>> pointing to nirvana.
>>
>> This fixes all those code paths to avoid read-barriers. Some use
>> explicit *_raw() accessor variants now, and metadata is now accessed via
>> raw call wholesale.
>>
>> the non-Shenandoah stuff will have to be upstreamed soon. Want to bake
>> it a little more in Shenandoah though, who knows, maybe we find more
>> such off-the-rails code paths?
>>
>> http://cr.openjdk.java.net/~rkennke/fix-rbs/webrev.00/
>
> OK for sh/jdk.
>
>> Testing: tier3_gc_shenandoah
>
> This seems to improve Serial:
> before: 19535.551 ± 225.129 ops/s
> after: 20120.271 ± 103.193 ops/s
>
FYI, I created:
https://bugs.openjdk.java.net/browse/JDK-8206457
to track upstreaming those shared code changes.
Roman
More information about the shenandoah-dev
mailing list