RFR: Generation affiliation transitions for heap regions.

[Roman Kennke]

On Tue, 17 Nov 2020 10:31:20 GMT, Bernd Mathiske <bmathiske at openjdk.org> wrote:

> Preparatory renaming generation->affiliation since we will want to have a class called ShenandoahGeneration that is not an enum. The next PR will build on this. It will be a big refactoring that pulls code out of the ShenandoahHeap class and puts it into generation-specific classes that are subclasses of ShenandoahGeneration.
> 
> The Affiliation declaration still sits in AllocRequest and not in ShenandoahHeapRegion or ShenandoahGeneration for the same reason as before: it is hard to get anything to compile in other combinations of what goes where. I tried.
> 
> The card table update code in the set_affiliation() will be revised and augmented later, but seems OK as a first step.

Nice changes. A few questions too...

BTW, I'd like to bring in latest upstream changes so that we don't diverge too much. In particular, this will bring in concurrent weak reference processing. I suggest that I do this after this PR is integrated, ok?

src/hotspot/share/gc/shenandoah/shenandoahCardTable.cpp line 26:

> 24: 
> 25: #include "precompiled.hpp"
> 26: #include "gc/shared/memset_with_concurrent_readers.hpp"

What's this?

src/hotspot/share/gc/shenandoah/shenandoahCardTable.hpp line 41:

> 39:   virtual void initialize();
> 40: 
> 41:   virtual inline bool is_in_young(oop obj) const {

Why do we need virtual here? Is it overridden anywhere?

src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 550:

> 548:   bool is_in(const void* p) const;
> 549: 
> 550:   bool is_in_young(const void* p) const;

This overrides CollectedHeap method, right? So either put 'virtual' here to indicate this, or even better 'override'. I believe we can use that new C++11 specifier now...

-------------

Changes requested by rkennke (Reviewer).

PR: https://git.openjdk.java.net/shenandoah/pull/7