RFR: Mark-compact performance improvements and cleanups

[Roman Kennke]

Am 30.05.2018 um 14:17 schrieb Aleksey Shipilev:
> On 05/29/2018 09:20 PM, Aleksey Shipilev wrote:
>> http://cr.openjdk.java.net/~shade/shenandoah/mark-compact-improvs/webrev.01/
>>
>> This is the pack of mark-compact cleanups and improvements.
>>
>> *) mc-logging: More verbose profiling for phase 4 in mark-compact
>>
>> Adds a few more profiling points in "Copy object" phase of mark compact, which enables better
>> performance diagnostics.
>>
>> *) mc-liveness: Full GC always comes with liveness data
>>
>> We used to skip liveness counting for mark-compact, because the core algorithm does not require it.
>> It provided some boosts when our liveness calculation was a major performance hog. It is not
>> anymore, and having liveness data enables us to do shortcuts, like below. This also cleans up shared
>> code substantially.
>>
>> *) mc-immediate-trash: Reclaim immediate garbage after mark-compact marking
>>
>> Once we know liveness, we can reclaim immediate garbage regions right after marking. This lets
>> threads down below treat the regions as the targets for compaction immediately, instead of
>> compacting through them. This is especially important for figuring out compaction for humongous
>> regions, which is planned before the regular object moves.
>>
>> *) mc-shortcut-live: Shortcut regions that are known not to be alive
>>
>> Same here, liveness provides us with insight if we even want to walk marked objects in the region,
>> or not. For the fully-garbage region it would be futile, and it will yield no marked objects.
> 
> A few more touchups and code moves here:
>   http://cr.openjdk.java.net/~shade/shenandoah/mark-compact-improvs/webrev.02/
> 
> *) mc-recycle-once: Recycle the regions only once
> 
> There is no need to recycle before the mark, if we are recycling after mark anyway.
> 
> *) mc-prepare-mark-closure: Rename and move ShenandoahPrepareForMarkClosure
> 
> Renames and moves the closure to its only use.
> 
> Testing: hotspot_gc_shenandoah, benchmarks
> 

The change looks good to me. +1 about the liveness counting.

This does, in fact, raise the question about the interaction between
full-gc (with or without liveness counting) and traversal: next
traversal cycle after full-gc will use liveness data for heuristics
decision. Do we need to clean liveness after full-gc (which basically
resets to the initial state before first-ever cycle) ? Or should we fix
liveness data after full-gc compaction? Because the marked liveness will
not be correct. I suspect fixing it up gives us better data to base
heuristics on...

Roman