RFR: Refactor allocation seqnum handling: split mutator/GC allocs, merge with other metadata handling

[Aleksey Shipilev]

On 02/21/2018 08:52 AM, Roman Kennke wrote:
> Alright, I figured it out. The humongous handling is correct, but the
> accounting of seqnum_at_gc_start is not. We currently set it in
> ShenandoahGCPauseMark, which updates the numbers at the beginning and
> end of each *pause*, not GC cycle. However, doing it in
> ShenandoahGCSession, which would cover the whole cycle, is not safe
> because it happens from the scheduler thread while Java is running
> (and updating the counter). It needs to be done during the init- and
> final- pauses of the cycle in order to be safe and correct. 

But wait, why does it introduce bugs? Seqnums are basically the hints that heuristics can use to
select regions for collections. These hints can be racy, and heuristics should not break correctness
if hints are momentarily inconsistent.

> Also, we need to see how we deal with wrapover of the counter. We
> don't want longrunning apps to mysteriously fail after weeks ;-)

That is why uint64_t is going to be enough for everybody! (c)

-Aleksey