RFR: JDK-8222281: GC interface for load-klass: runtime part

[Per Liden]

Hi Roman,

On 04/11/2019 10:58 PM, Roman Kennke wrote:
> An upcoming feature in Shenandoah requires that GC can intercept loading
> the Klass* of an object. I'd like to introduce a GC interface for that.

Could you please give some more insight into what this feature is and 
why it needs to intercept these loads?

thanks,
Per

> This change covers the runtime part.
> 
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8222281
> Webrev:
> http://cr.openjdk.java.net/~rkennke/JDK-8222281/webrev.00/
> 
> The change takes the 3 variants of oopDesc::klass() and funnels them
> through the Access API to be intercepted by the GC in any way it wants.
> Behaviour- and performance-wise it should be identical (assuming the
> compiler can make sense of the Access API).
> 
> I see that there might be an opportunity here to make the if
> (UseCompressedClassPointers) check pre-resolved, but I don't know how to
> do that. I also don't really see how that is supposed to work for loads
> and stores wrt UseCompressedOops either: in order to select the proper
> functions on first call, and subsequently go through that selected
> function, it would have to be done in the *_init() functions. But I
> don't see any selection code there. Instead, it seems to be in
> PreRuntimeDispatch? I must be missing something. I left the selection in
> the raw implementation. Maybe we want to sort this out?
> 
> <rant>
> I must say that I fought with myself whether or not I should add to the
> madness that is the Access API. What should have been a 1-line-addition
> to an API (e.g. BarrierSet) turned out to become:
> 
>   7 files changed, 86 insertions(+), 20 deletions(-)
> 
> and two days of work. And god forbid we ever have to change or even fix
> anything there.
> 
> I was about to just not do it in Access API at all, but somewhere else
> instead, but then I did not want to introduce a schism there, so I bit
> the bullet. Maybe we should consider to turn this into a proper C++
> interface instead? This is just unmaintainable madness.
> </rant>
> 
> Testing: tier1 fine. Will submit into jdk/submit shortly, works with the
> Shenandoah prototype that I have here (iow, the API is good)
> 
> Can I please get a review?
> 
> Thanks,
> Roman
>