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

[Aleksey Shipilev]

On 02/21/2018 11:14 AM, Roman Kennke 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. :-)

Please explain why do you need them precisely? I thought you only need to avoid adding newly
allocated regions to the collection set for traversal, and this is where the raciness for seqnums
probably does not matter?


-Aleksey