RFR (S/M): 8202017: Merge Reference Enqueuing phase with phase 3 of Reference processing

[Kim Barrett]

> On Apr 19, 2018, at 3:14 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  can I have reviews for this change that merges the Reference
> Enqueuing phase of reference processing with the respective phase 3 of
> actual Reference Processing?
> 
> This is enabled by JDK-8202018 where we moved some work that cleared
> card tables from inbetween Reference Processing and Reference Enqueuing
> because we could (and likely always could), so the issue that cards
> dirtied by Reference Processing are not cleared any more.
> 
> This saves one time spinning up and synchronizing worker threads at
> least, if not more due to locality (i.e. completely saving one linked
> list traversal).
> 
> This change affects all collectors using the reference processing
> framework - I assume that Shenandoah, if it is using it, does not need
> a split reference enqueuing phase either. Afaik Z does not use this
> framework... :)
> 
> CR:
> https://bugs.openjdk.java.net/browse/JDK-8202017
> Webrev:
> http://cr.openjdk.java.net/~tschatzl/8202017/webrev/
> Testing:
> hs-tier1-4
> 
> Thanks,
>  Thomas

Looks good.  Just a couple very minor things.

------------------------------------------------------------------------------ 
src/hotspot/share/gc/shared/referenceProcessor.cpp
 607     _refs_lists[i].set_head(NULL);
 608     _refs_lists[i].set_length(0);

 790        refs_lists[i].set_head(NULL);
 791        refs_lists[i].set_length(0);

Maybe move these into process_phase3?

------------------------------------------------------------------------------ 
src/hotspot/share/gc/g1/g1CollectedHeap.hpp
 515   // If during an initial mark pause we install a pending list head which is not otherwise reachable

Perhaps s/install/may install/

------------------------------------------------------------------------------ 
src/hotspot/share/gc/shared/genCollectedHeap.cpp
 518       rp->disable_discovery();

Ick!  This whole little dance around discovery_is_atomic,
enqueueing_is_done, &etc looks like it is related to CMS and the
distinction between CMS and Serial.  See also the TODO-ish block
comment at line 489.

This looks ripe for refactoring as part of the cleanup of CMS-specific
intrusions.  Probably should have a followup RFE for this.

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