RFR: Re-do streamlining of read-barriers in Access API, and fix call paths that might lead to read-barriers via oop_iterate()

Aleksey Shipilev shade at redhat.com
Fri Jul 6 10:39:03 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

Thanks,
-Aleksey



More information about the shenandoah-dev mailing list