RFR: JDK-8154343: Make SATB related code available to other GCs
Kim Barrett
kim.barrett at oracle.com
Fri Jul 27 22:44:24 UTC 2018
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.
> 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”.
More information about the hotspot-gc-dev
mailing list