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

[Roman Kennke]

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. I've done
it in traversal using this patch:

https://paste.fedoraproject.org/paste/SZ2tqntg4l5T3TAIdtQ2uw

The only other user of that counter seems to be the generational and
LRU heuristics, and I'm wondering if they work by accident, or not
really at all, but a complete fix would do what I did to traversal
also to partial GC. Something for tomorrow.

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

Cheers, Roman

On Tue, Feb 20, 2018 at 9:07 PM, Roman Kennke <rkennke at redhat.com> wrote:
> FWIW, with the traversal-no-new-traversal patch adapted to it, I get
> failures in AllocHumongousFragment which also failed when I did not
> handle humongous allocations correctly ;-)
>
> On Tue, Feb 20, 2018 at 8:41 PM, Roman Kennke <rkennke at redhat.com> wrote:
>> Does it also do the correct thing for humongous object allocs? And if yes, how?
>>
>> Roman
>>
>> On Tue, Feb 20, 2018 at 7:30 PM, Zhengyu Gu <zgu at redhat.com> wrote:
>>> Good to me.
>>>
>>> -Zhengyu
>>>
>>>
>>> On 02/20/2018 01:06 PM, Roman Kennke wrote:
>>>>
>>>> Looks good to me.
>>>>
>>>> On Tue, Feb 20, 2018 at 6:59 PM, Aleksey Shipilev <shade at redhat.com>
>>>> wrote:
>>>>>
>>>>> http://cr.openjdk.java.net/~shade/shenandoah/alloc-seqnums/webrev.01/
>>>>>
>>>>> This refactors allocation seqnum machinery, so that we have more data to
>>>>> feed the heuristics with.
>>>>> Notably, this should help Roman's work on Traversal GC that wants to
>>>>> ignore some of the newly
>>>>> allocated regions.
>>>>>
>>>>> Testing: hotspot_gc_shenandoah {fastdebug|release}
>>>>>
>>>>> Thanks,
>>>>> -Aleksey
>>>>>
>>>