RFR: 8231672: Simplify the reference processing parallelization framework

[Leo Korinth]

On Thu, 4 Mar 2021 09:25:26 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> With the change of parallel gc to use the same workgang implementation that other gcs uses, it is possible to remove the abstraction used to hide different worker thread management implementations (TaskExecutor).
>> 
>> At the same time as removing the TaskExecutor, also remove part of the special casing (mostly code duplication), for single threaded execution. 
>> 
>> I consider the new method `prepare_run_task` that modifies the state of the context a step backwards from what was. However, I think removing the Executor with its proxy-tasks and removing separate code paths for serial execution makes the change worth this step back. We also removes ~270 lines of code.
>> 
>> Some comments:
>> 1) I use references in some places where they can replace pointers. I could go much further here, but I did not want to bloat the pull request, maybe later change all closures to be references as well? Should I create enhancements for this?
>> 
>> 2) I added an enum class ThreadModel instead of using a boolean, this could also be used in many more places. I dislike sending lots of bools with a comment like `true /* _is_mt */`. It also adds type safety if a method takes many bools. However, with this limited change, and not many hard-coded bools, it feels a bit overkill and I am willing to remove the enum, what do you think?
>> 
>> Testing:
>> hotspot_gc  and tier 1-3 has passed earlier versions before minor cleanups. I intend to re-run tests after review changes.
>
> src/hotspot/share/gc/parallel/psScavenge.cpp line 183:
> 
>> 181:  private:
>> 182:   PSPromotionManager* _promotion_manager;
>> 183:   TaskTerminator* _maybe_terminator;
> 
> What does the `_maybe` in `_maybe_terminator` indicate? Just naming it `_terminator` seems as fine as a `nullptr` seems like a valid value.
> It is explained in `PSRefProcClosureContext`, but it seems too much to add this everywhere where a pointer could be a valid `nullptr`.

Maybe indicates (Just a valid pointer) or (Nothing nullptr), optional might be a better prefix? 

I would agree to remove the prefix if we would consistently use references where nullptr is not a valid state. If we are going to use pointers instead of references because it visualizes that we take the address at call site (something I disagree with), I think adding `maybe` or `optional` is a (visual) safeguard for not de-referencing the pointer without verifying it can safely be de-referenced.

I will remove the prefix if you do not buy my explanation.

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

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