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

[Roman Kennke]

I'm not counting liveness for allocations. Therefore alloc-regions
look like completely empty. But we must not thrash them after GC.
Therefore I need a check for is_alloc_region() (however the
implementation) to prevent thrashing of those regions. If this is not
precise, we're doomed.

However, I just realized, I may compare TAMS < r->top() to identify
such regions? Notice I am setting TAMS before cycle, to prevent
marking through new objects, but update TAMS for evac-allocations.

Roman

On Wed, Feb 21, 2018 at 11:14 AM, Roman Kennke <rkennke at redhat.com> wrote:
> Am 21.02.2018 um 11:11 schrieb 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.
>
> Yes, but as you suggested I am using it in traversal to distinguish
> allocation regions, and this must be precise, otherwise it's incorrect. :-)
>
>>> 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)
>
> Ha.
>
> Might be good enough for heuristics that can live with once in few weeks
> hiccups, but the intended use in traversal better be correct :-)
> In fact, thinking about it, may be safer to go back to the original
> explicit (and easy to verify correct) flag?
>
> Roman