RFR: 8051680: (ref) unnecessary process_soft_ref_reconsider

[Albert Mingkun Yang]

On Fri, 2 Jul 2021 12:59:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR consists of 3 commits:
> 
> 1. Removes the soft-ref reconsideration phase because the soft-ref policy is set before marking (JDK-8269596) and stays the same across the GC cycle. Reconsideration phase should not find anything interesting. That being said, there might be some benefit of using more precise heap usage after marking for soft-ref processing, created JDK-8269798 for exploring that.
> 
> 2. Removes reloading of `_soft_ref_timestamp_clock` from `java_lang_ref_SoftReference::clock();` because the master clock should only be changed by GC.
> 
> 3. Rename phase{2,3,4} to phase{1,2,3}.
> 
> Test: hotspot_gc

Names and responsibility of various phases:


  enum RefProcSubPhases {
    SoftRefSubPhase1,
    WeakRefSubPhase1,
    FinalRefSubPhase1,
    FinalRefSubPhase2,
    PhantomRefSubPhase3,
    RefSubPhaseMax
  };

  enum RefProcPhases {
    RefPhase1,
    RefPhase2,
    RefPhase3,
    RefPhaseMax
  };
  
  // Phase 1: Drop Soft/Weak/Final references with a NULL or live referent, and clear
  // and enqueue non-Final references.
  void process_soft_weak_final_refs(RefProcProxyTask& proxy_task,
                                    ReferenceProcessorPhaseTimes& phase_times);

  // Phase 2: Keep alive followers of Final references, and enqueue.
  void process_final_keep_alive(RefProcProxyTask& proxy_task,
                                ReferenceProcessorPhaseTimes& phase_times);

  // Phase 3: Drop and keep alive live Phantom references, or clear and enqueue if dead.
  void process_phantom_refs(RefProcProxyTask& proxy_task,
                            ReferenceProcessorPhaseTimes& phase_times);


Kim's suggestion:


Process{Soft,Weak,Final}RefsSubPhase, KeepAliveFinalRefsSubPhase, ProcessPhantomRefsSubPhase

SoftWeakFinalRefsPhase, KeepAliveFinalRefsPhase, PhantomRefsPhase


Given such renaming is quite invasive, maybe it can be done in a separate PR. So which option do reviewers think is the best to take?

1. create a revert for the third commit, leaving renaming to another PR. (The phases will start from "2" in the logs.)
2. make semantic renaming in this PR. (Mixing real changes with large renaming.)

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

PR: https://git.openjdk.java.net/jdk/pull/4667