RFR: Adjust heuristics for running with update-refs phase

[Zhengyu Gu]

  498     size_t available =  free_capacity - free_used;
  499     uintx factor = _free_threshold;
  500     size_t cset_threshold = 0;
  501     if (!update_refs_early()) {
  502       // Count in the memory available after cset reclamation.
  503       cset_threshold = (size_t) _cset_history->davg();
  504       size_t cset_threshold = (size_t) _cset_history->davg();
  505       size_t cset = MIN2(_bytes_in_cset, (cset_threshold * 
capacity) / 100);
  506       available += cset;
  507       factor += cset_threshold;
  508     }
  509

There are two definitions of cset_threshold variables, and #503 and 504 
are dup ...

-Zhengyu

On 05/02/2017 01:31 PM, Roman Kennke wrote:
> When running with -XX:+ShenandoahUpdateRefsEarly, heuristics need to
> work differently because we're reclaiming the cset before marking, not
> after. With current settings, we're not using ~40% of the heap when
> running with update-refs. Updating refs in a separate cycle also breaks
> the funny ping-ponging of GC cycles we have seen early. We can thus skip
> over the extra handling for the expected cset-reclaimed-space, which
> also makes us use all of the heap.
>
> http://cr.openjdk.java.net/~rkennke/update-refs-heuristics/webrev.00/
> <http://cr.openjdk.java.net/%7Erkennke/update-refs-heuristics/webrev.00/>
>
> Notice that this means we now tend to run into full-gc during update
> refs phase. We need to solve this by implementing degeneration of
> update-refs just like we did with marking, i.e. if we run OOM during
> update-refs, stop the world and finish updating refs under the pause,
> instead of going into full-gc. This is not part of this patch though.
>
> We also need different thresholds when running with update-refs. Doesn't
> make much sense to fiddle with this before we have degenerated update-refs.
>
> Ok to push?
>
> Roman
>
>
>