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

[Roman Kennke]

Am 12. April 2019 07:18:41 MESZ schrieb Per Liden <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.

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

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.