RFR: 8230661: ZGC: Stop reloading oops in load barriers

[Erik Österlund]

Oops. CR link was a bug link. For anyone that couldn't figure out what 
the CR link could possibly be, here it is:
http://cr.openjdk.java.net/~eosterlund/8230661/webrev.00/

/Erik

On 2019-10-28 17:38, Erik Österlund wrote:
> Hi,
>
> In ZGC, an oop is first loaded somewhere, by e.g. JIT compiled code. 
> Then it passes a load barrier that typically does not take a slow 
> path. But when it does take a slow path, the oop is sometimes 
> reloaded, at historically three different places, and now two places.
>
> 1) We used to do that as part of the mechanism that transferred 
> execution to the slow path because it was easier to write that stub 
> code if the original oop died. Since then, the compiler slow paths 
> have been rewritten to not reload the oop.
>
> 2) Once in the slow path, we sometimes reload weak oops during the 
> resurrection block window, because there used to be a race when it 
> closed. After concurrent class unloading integrated, there is a 
> thread-local handshake before closing the resurrection block window. 
> Therefore, that race no longer exists (when class unloading is used).
>
> 3) Once the final oop of a slow path has been determined, self-healing 
> kicks in. The self-healing CAS may fail. When it does, the oop is 
> reloaded. But this is completely unnecessary.
>
> With obstacle 1 gone, and 2 and 3 having no reason to be in the code 
> any more, I propose to get rid of all reloading of the oops in the 
> slow paths, so that it becomes easier to reason about the code. The 
> object captured by the original load, is then always the same object 
> as the object found after the load barrier completes, although 
> possibly with a new bit representation.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8230661
>
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8230661
>
> Thanks,
> /Erik