RFR: 8198505: Remove CollectorPolicy and its subclasses

[Stefan Karlsson]

Hi all,

Please review this patch to remove CollectorPolicy and its subclasses.

https://cr.openjdk.java.net/~stefank/8198505/webrev.01/
https://bugs.openjdk.java.net/browse/JDK-8198505

 From the RFE:
==========
I'd like to propose that we get rid of the CollectorPolicy classes.

The CollectorPolicy classes contains a mix of features to support the 
CollectedHeaps. A few of them are:

* Have virtual functions that either CMS or Serial can override. This 
was important when CMS didn't have it's own CollectedHeap. But CMSHeap 
was recently added, so this isn't needed anymore.

* Has common allocation code for CMS and Serial. Can be moved to 
GenCollectedHeap.

* Deal with parts of the heap sizing and corresponding flags. A lot of 
the flag handling has been moved to the GCArguments classes. We should 
move the CollectorPolicy flag handling functions there as well.

* Keeps the state for the SoftRefPolicy. Separate this out to it's own 
class.

* Has the satisfy_failed_metadata_allocation function. No need to be 
located in CollectorPolicy.
==========

I started this work last year and have already pushed a number of sub RFEs:
  JDK-8198373: Remove CollectorPolicy::is/as functions
  JDK-8198507: Remove CollectorPolicy::create_rem_set
  JDK-8198509: Move satisfy_failed_metadata_allocation out from 
CollectorPolicy
  JDK-8198511: Move allocation functions from GenCollectorPolicy to 
GenCollectedHeap
  JDK-8198515: Extract SoftReferencePolicy code out of CollectorPolicy
  JDK-8198525: Move _size_policy out of GenCollectorPolicy into 
GenCollectedHeap
  JDK-8198528: Move GenerationSpecs from GenCollectorPolicy to 
GenCollectedHeap
  JDK-8198530: Move _gc_policy_counters from GenCollectorPolicy to 
GenCollectedHeap

This patch removes the last bits. It mainly moves flag handling and 
sizing information over to the GCArguments. Most of the gc flag handling 
has already been moved there, so it makes sense to move the rest over to 
that sub-system.

For Shenandoah I only moved the flag handling code, but left the 
ShenandoahCollectorPolicy class as a Shenandoah internal implementation 
detail.

Some GCs perform the initialization a little bit differently than 
others. For example:
- Parallel runs some initialization code twice
- Some simply uses the default initialize_heap_flags_and_sizes, while 
others override it.
- G1 and Shenandoah needs the heap size before alignments can be set up.

The last item is a bit awkward because there's a circular dependency 
between figuring out the heap size and the heap region size. We have 
this initialization sequence:

void GCArguments::initialize_before_create_heap() {
   initialize_alignments();
   initialize_heap_flags_and_sizes();
   initialize_size_info();
}

Today G1 and Shenandoah sets up the heap region sizes in 
initialize_alignments, to overcome this circular dependencies. There 
might an opportunity for further cleanups in this area.

Tested with tier1-3 and tier1-7 on Linux x64.

Thanks,
StefanK