RFR(L): 8195142: Refactor out card table from CardTableModRefBS to flatten the BarrierSet hierarchy

Erik Österlund erik.osterlund at oracle.com
Thu Feb 15 09:31:34 UTC 2018


Hi,

Here is an updated revision of this webrev after internal feedback from 
StefanK who helped looking through my changes - thanks a lot for the 
help with that.

The changes to the new revision are a bunch of minor clean up changes, 
e.g. copy right headers, indentation issues, sorting includes, 
adding/removing newlines, reverting an assert error message, fixing 
constructor initialization orders, and things like that.

The problem I mentioned last time about the version number of our repo 
not yet being bumped to 11 and resulting awkwardness in JVMCI has been 
resolved by simply waiting. So now I changed the JVMCI logic to get the 
card values from the new location in the corresponding card tables when 
observing JDK version 11 or above.

New full webrev (rebased onto a month fresher jdk-hs):
http://cr.openjdk.java.net/~eosterlund/8195142/webrev.01/

Incremental webrev (over the rebase):
http://cr.openjdk.java.net/~eosterlund/8195142/webrev.00_01/

This new version has run through hs-tier1-5 and jdk-tier1-3 without any 
issues.

Thanks,
/Erik

On 2018-01-17 13:54, Erik Österlund wrote:
> Hi,
>
> Today, both Parallel, CMS and Serial share the same code for its card 
> marking barrier. However, they have different requirements how to 
> manage its card tables by the GC. And as the card table itself is 
> embedded as a part of the CardTableModRefBS barrier set, this has led 
> to an unnecessary inheritance hierarchy for CardTableModRefBS, where 
> for example CardTableModRefBSForCTRS and CardTableExtension are 
> CardTableModRefBS subclasses that do not change anything to do with 
> the barriers.
>
> To clean up the code, there should really be a separate CardTable 
> hierarchy that contains the differences how to manage the card table 
> from the GC point of view, and simply let CardTableModRefBS have a 
> CardTable. This would allow removing CardTableModRefBSForCTRS and 
> CardTableExtension and their references from shared code (that really 
> have nothing to do with the barriers, despite being barrier sets), and 
> significantly simplify the barrier set code.
>
> This patch mechanically performs this refactoring. A new CardTable 
> class has been created with a PSCardTable subclass for Parallel, a 
> CardTableRS for CMS and Serial, and a G1CardTable for G1. All 
> references to card tables and their values have been updated accordingly.
>
> This touches a lot of platform specific code, so would be fantastic if 
> port maintainers could have a look that I have not broken anything.
>
> There is a slight problem that should be pointed out. There is an 
> unfortunate interaction between Graal and hotspot. Graal needs to know 
> the values of g1 young cards and dirty cards. This is queried in 
> different ways in different versions of the JDK in the 
> ||GraalHotSpotVMConfig.java file. Now these values will move from 
> their barrier set class to their card table class. That means we have 
> at least three cases how to find the correct values. There is one for 
> JDK8, one for JDK9, and now a new one for JDK11. Except, we have not 
> yet bumped the version number to 11 in the repo, and therefore it has 
> to be from JDK10 - 11 for now and updated after incrementing the 
> version number. But that means that it will be temporarily 
> incompatible with JDK10. That is okay for our own copy of Graal, but 
> can not be used by upstream Graal as they are given the choice whether 
> to support the public JDK10 or the JDK11 that does not quite admit to 
> being 11 yet. I chose the solution that works in our repository. I 
> will notify Graal folks of this issue. In the long run, it would be 
> nice if we could have a more solid interface here.
>
> However, as an added benefit, this changeset brings about a hundred 
> copyright headers up to date, so others do not have to update them for 
> a while.
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8195142
>
> Webrev:
> http://cr.openjdk.java.net/~eosterlund/8195142/webrev.00/
>
> Testing: mach5 hs-tier1-5 plus local AoT testing.
>
> Thanks,
> /Erik



More information about the hotspot-dev mailing list