RFR: JDK-8154343: Make SATB related code available to other GCs

[Roman Kennke]

Am 28.07.2018 um 00:44 schrieb Kim Barrett:
> I’ve started looking at this.
> 
>> On Jul 27, 2018, at 7:17 AM, Roman Kennke <rkennke at redhat.com> wrote:
>>
>> This change moves SATB related code to gc/shared from where it can be
>> used by other SATB GCs. I'm doing it in preparation for Shenandoah.
>>
>> It also includes two new interfaces in CollectedHeap to make it
>> independent from G1. One is for fetching per-thread-queue from
>> GCThreadLocalData, and the other to support filtering.
>>
>> I am not sure if the filtering is too performance sensitive to make a
>> virtual call there. If it is, we may substitute the virtual call with
>> something templated. I actually have such code in Shenandoah, but it's a
>> bit ugly (it requires knowledge about GCs that use it to drive code
>> geneneration). An alternative might be to move the whole filtering loop
>> into (e.g.) CollectedHeap, from where we know the actual type and can
>> drive a templated loop. However, I tend to think virtual call might be
>> ok, and thought I'd start with something simple and nice.
> 
> I’m very concerned about the possible performance impact here.
> Such a change really needs to come with some performance testing.
> (I’m going to run some of ours, but more would be better.)
> 
> I’m also not sure I like the proposed new interfaces generally, but
> I’m still thinking about what I might like as an alternative.  Performance
> may drive some of that.

I also don't like the new interfaces much. Especially polluting
CollectedHeap with something that GCs might not need (and in-fact, only
two known GCs currently need, and only one of them is currently in
mainline OpenJDK).

Maybe we can define an interface like SATBSupport that provides these
new methods and have GCs pass in an implementation subclass at creation
time?

With regards to performance, I think we can templatize the filter-loop:
filter() would call out to SATBSupport::filter_driver() which would call
back to SATBMarkQueue::filter_impl<SATBSupportType> with known
SATBSupportType which would then call the non-virtual and inlineable
SATBSupport::retain_entry() of the speficied type. This should solve all
performance concerns I think.

>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8154343
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/JDK-8154343/webrev.00/
>>
>> Testing: compiles and passes hotspot/jtreg:tier1
>>
>> What do you think?
>> Roman
> 
> You missed updating precompiled.hpp, which has #include “gc/g1/PtrQueue.hpp”.

Ha, oops. And here I thought I'm doing something good by always building
with --disable-precompiled-headers ;-)

Will come up with updated patch that implements the ideas above start of
next week. Feel free to suggest improvements.

Thanks for reviewing!
Roman

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