RFR: FreeSet refactorings, cleanups, improvements (a pack of 7)

[Aleksey Shipilev]

http://cr.openjdk.java.net/~shade/shenandoah/freeset-refactor/webrev.01/

This pack is the preparation for evac-reserve and degen-evac work, but it is self-sufficient in
itself. It includes:

 *) sh-heap-refs: FreeSet and HeapRegion should have the reference to ShenandoahHeap

  Instead of polling ShenandoahHeap::heap(), we should reuse the fields already available for us.
  FreeSet needs to have the field added first.

 *) freeset-build-refactor: Refactor FreeSet rebuilding into the single source

  Instead of having the free set rebuilding loops all over the GC code, centralizes the rebuilding
  in FreeSet::rebuild.

 *) freeset-trash: FreeSet should accept responsibility over trashed regions

  Current mechanics only adds "allocatable" regions into the FreeSet, and "trash" regions are
dangling in the heap. FreeSet calls into heap to recycle some trash if allocation failed. Not only
this trips out the code that polls "free" from the heap and FreeSet, that does not count trash, it
also makes FreeSet make a few scans over. I.e. in some cases it would do scan (no free found) ->
recycle -> scan again.

 The better idea is to make FreeSet responsible for trash regions too, and recycle them as it goes
through the allocation path. Asynchronous cleanup would still assist FreeSet in recycling the
regions, and so normally FreeSet would not recycle itself.

 *) merge-trash: Drop distinction between immediate garbage and free in heuristics

 Heuristics cleanup: now that FreeSet took over responsibility over trash, we do not need any
distinction between immediate garbage and actual free. Simplifies heuristics logic.

 *) shortcut-full: Do not add non-allocatable regions to the FreeSet

 In heavily populated heap, we would add completely full regions into the FreeSet (because they are
regular!), which takes time during allocation scans. We should never put those in FreeSet for
performance reasons.

 *) pacer-poll-freeset: Pacer should poll FreeSet to figure out actually available space

 Pacer polls SH::used() to figure out the amount of free space available. Unfortunately, this
underestimates the amount of free space, because there are trashed regions that are almost
immediately allocatable, but still count as used. Let Pacer poll the FreeSet to know the available
free space.

 *) freeset-remove-add: Remove FreeSet::add_region, inline into FreeSet::rebuild

 Coalesces now-unused add_region into rebuild, optimizes it a bit.


Testing: hotspot_gc_shenandoah, allocation pressure benchmarks

Thanks,
-Aleksey