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

[Roman Kennke]

> > per.liden at oracle.com>:
> > > 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?
> > 
> > Oh yeah, apparently it was late last night. ;-) We want to
> > eliminate Shenandoah's extra word for the forwarding pointer and
> > stick it in the Klass* word for forwarded objects, with a little
> > bit of encoding to distinguish a forward pointer from a Klass*.
> > Therefore we need to see Klass* loads to check that encoding and
> > possibly load the Klass* from the forwardee instead.
> 
> Maybe I'm missing something, but didn't you just switch to having a 
> to-space invariant? What runtime code can get hold of a an oop
> pointing 
> into from-space and then try load its klass?

Ha! Right.. The prototype actually predates the to-space-invariant
change, and then I only 'adapted' it to the new situation without
giving it much thought, but you're right, we might not actually need
any GC interface changes. That should simplify everything, and perhaps
speed it up too.

I withdraw the RFR for now.

Thanks,
Roman


> cheers,
> Per
> 
> > Roman
> > 
> > > 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
> > > > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20190412/00058624/signature.asc>