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

[Erik Österlund]

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