RFR: 8208601: Introduce native oop barriers in C2 for OopHandle

[Vladimir Kozlov]

Hi, Erik

1. is_gc_barrier_node(b) is virtual so even if it return 'false' I am 
not sure C++ will collapse new search loops in phaseX.cpp and checks in 
other cases. Can we use some static check to allow C++ collapse that 
code in case there is no load barriers?

2. Can you explain Phi case more. I would like to see an assert which 
verify cush shape of code to avoid cases when Phi come from loop, for 
example.

Thanks,
Vladimir

On 8/1/18 4:17 AM, Erik Österlund wrote:
> Hi,
> 
> There is currently no way of doing IN_NATIVE accesses in C2 using its 
> access API. These are required to properly access OopHandle, used to 
> access the Java class mirrors (because they will now start requiring 
> load barriers). In order to support (concurrent) class unloading in ZGC, 
> this support must be added.
> 
> In this patch, I add an access_load API for loading IN_NATIVE oops, and 
> use it to load class mirrors (which is logically an OopHandle::resolve, 
> which happened to have been an indirect load before as nobody had load 
> barriers on it). In the various code recognizing the shape of a mirror 
> load to optimize the code, I have added a check if a node is a GC 
> barrier and to then step over it in order to match the mirror load.
> 
> In order to recognize and step over the load barriers in ZGC properly, I 
> added support for recognizing the barrier shapes not just before macro 
> expansion (LoadBarrierNode), but also after macro expansion (as required 
> by the matching code), which involves checking for phi nodes with with 
> LoadBarrierSlowRegNode phi->in(1), and then stepping over to phi->in(2), 
> as well as recognizing projections to such shapes. 
> LoadBarrierSlowRegNode is used in all barrier expansions except for 
> atomic xchg, but that is fine as we don't use that on class mirrors.
> 
> I have checked that the shapes are recognized and that no regressions 
> are introduced with these changes through a bunch of benchmarks in 
> gc-test-suite.
> 
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8208601/webrev.00/ 
> <https://link.getmailspring.com/link/1533049674.local-48cfadc1-4a64-v1.3.0-fd741eb7@getmailspring.com/0?redirect=http%3A%2F%2Fcr.openjdk.java.net%2F%7Eeosterlund%2F8208582%2Fwebrev.00%2F&recipient=aG90c3BvdC1jb21waWxlci1kZXZAb3Blbmpkay5qYXZhLm5ldA%3D%3D> 
> 
> Bug URL:
> https://bugs.openjdk.java.net/browse/JDK-8208601 
> <https://link.getmailspring.com/link/1533049674.local-48cfadc1-4a64-v1.3.0-fd741eb7@getmailspring.com/1?redirect=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8208582&recipient=aG90c3BvdC1jb21waWxlci1kZXZAb3Blbmpkay5qYXZhLm5ldA%3D%3D> 
> 
> 
> Thanks,
> /Erik
> Open Tracking