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

[Roman Kennke]

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.
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190411/74573889/signature.asc>