RFR: 8130931: refactor CardTableModRefBS[ForCTRS]

Thomas Schatzl thomas.schatzl at oracle.com
Mon Jul 13 08:47:04 UTC 2015


Hi,

On Fri, 2015-07-10 at 20:23 -0400, Kim Barrett wrote:
> Please review this refactoring of CardTableModRefBS and
> CardTableModRefBSForCTRS.  The changes are in two stages, with
> separate webrevs to make it easier to review.
> 
> The first stage eliminates some friend declarations from
> CardTableModRefBS.
> 
> - BytecodeInterpreter doesn't need to be a friend.
> - CheckForUnmarkedOops changed to use public byte_for_const().

Actually the whole member _unmarked_card can be removed.

> - SharkBuilder changed to use public dirty_card_val().
> - GuaranteeNotModClosure does not exist.
> - CardTableRS changed to be a friend of CardTableModRefBSForCTRS. 
>   Changed some references to static members of CardTableModRefBS
>   to work around bugs in clang and Visual Studio [1].
> 
> Only the VMStructs friend declaration is retained.
> 
> The second stage moves some functionality that is specific to or only
> used with the ForCTRS class from the base class to the ForCTRS
> subclass. It also moves the ForCTRS class into its own files, separate
> from the base class.

I would prefer if the parCardTableModRefBS.cpp file would be removed,
its contents moved to the new CardTableModRefBSForCTRS.cpp as it only
contains CardTableModRefBSForCTRS methods (and both seem only used for
CMS).
Iow, is there some reason to keep this file, or is this part of the
"left for later" task?

> We could further split below CardTableModRefBSForCTRS, with support
> for parallel card scanning (used only by CMS) being in another class.
> That split already partially exists in the source code structure, with
> some relevant functions being defined in CMS-specific
> parCardTableModRefBS.cpp. That restructuring is being left for later.

Looks good otherwise. Thanks for the cleanup.

Thanks,
  Thomas




More information about the hotspot-gc-dev mailing list