RFR: 8270100: Fix some inaccurate GC logging

[Volker Simonis]

On Thu, 8 Jul 2021 15:19:01 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> If running with `-Xlog:gc+heap*=trace` the JVM will print the extra per thread amount which is added to the new generation on resize:
> 
> [0,105s][debug][gc,ergo,heap ] GC(0) New generation size 34112K->34176K [eden=27392K,survivor=3392K]
> [0,105s][trace][gc,ergo,heap ] GC(0) [allowed 0K extra for 0 threads]
> 
> Currently this will always print "0K extra for 0 threads" no matter how much extra space was added.
> 
> Also, the shrink factor will always be printed to be 0%, even if we run with `-XX:-ShrinkHeapInSteps` which pins the shrink factor at 100%:
> 
> [13,213s][trace][gc,heap ] GC(34) shrink_bytes: 463564,0K current_shrink_factor: 0 new shrink factor: 0 _min_heap_delta_bytes: 192,0K
> [13,239s][trace][gc,heap ] GC(34) Shrinking tenured generation from 531852K to 68288K
> 
> 
> The fix is trivial.

`threads_count` and `adjust_for_thread_increase` get computed in `adjust_for_thread_increase()`. That's why they are passed in by reference. I don't think it makes sense to duplicate the computation of `threads_count` and `adjust_for_thread_increase` before we log them because the next time somebody will change `adjust_for_thread_increase()`, the values will be wrong again. This error occurred in the first place because [JDK-8144527](https://bugs.openjdk.java.net/browse/JDK-8144527) has factored out the computation of `threads_count` and `adjust_for_thread_increase` into the new  `adjust_for_thread_increase()` function, but did not pass the values back for logging.

For the second fix, I don't see why assigning to 100 to `_shrink_factor` and `current_shrink_factor` should be any better? These values aren't used except for logging if `ShrinkHeapInSteps` is false. Also, the assignment of `current_shrink_factor` can't easily be moved into the if-branch because `_shrink_factor` has to be reset to 0 before we potentially expand the heap (see comment `But if we recompute size without shrinking, it goes back to 0%.`). But on heap expansion, we'll return from the method early, before even reaching the shrinking logic.

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

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