RFR: 8306334: Handle preemption of old cycle between filling and bootstrap phases [v2]

[Y. Srinivas Ramakrishna]

On Mon, 24 Apr 2023 15:36:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Thank you for your description & responses above; I am slowly getting the hang of the use of the terms and the supporting code.
>> 
>> It would be good to use the terms "cancellation" and "preemption" uniformly everywhere. Cancellibility and Pre-emptibility seem, to me, to be properties of a phase (or state) of an old collection. Here is my understanding of these two terms. Cancellation and Pre-emption are actions that may be taken on phases (states) that are respectively cancellable or pre-emptible.
>> 
>> Cancellation is stronger than pre-emption in that we transition out of the old generation state where cancellation happened, and the old generation collection is commandeered because of that cancellation (in some cases, resulting in a degenerate collection and in other cases a full collection).
>> 
>> Pre-emption, on the other hand, merely "interrupts" (or suspends) an ongoing old generation collection while leaving it in the same state, for young collection to do its work. Persumably in the happy case, the old generation collection continues from its interruption point.
>> 
>> In the odd case, a pre-emption may be followed by a cancellation.
>> 
>> Pre-emption can happen in only a subset of the states, viz. "filling" and "marking". In the non-pre-emptible cases, the pre-emption happens when the work in the state is completed and the old generation collection has proceeded to a pre-emption point, which can be at the point of transition into the next state (either pre-emptible or not).
>> Cancellation must be, and is, supported in any state of the old generation collection, and subsequent actions reset the state of the old generation collection to an initial (idle) state. 
>> 
>> The term "degeneration" applies to a collection that follows an allocation failure (either by a mutator allocating in the young generation, or a mutator or GC thread allocating in the survivor space or in the old generation but not finding any space to do that allocation), which results in the cancellation of an ongoing collection cycle which would have normally produced that space (usually an old collection cycle when the allocation failure was while servicing a young collection, but could also be a young collection cycle when a mutator was unable to allocate in the young generation), and is followed by work done to complete that cycle with the failed allocation suspended until space has been freed up by that collection.
>> 
>> If I nailed down my understanding of the use of these terms a little, I would probably understand their relationship more easily. :-)
>> 
>> I'll follow up offline with y'all to make sure these are clear in my head.
>
> This is an accurate description of preemption and cancellation. The two concepts share some code paths their representation is not as distinct as it could be. There is one other nuance to consider: a degenerated _young_ cycle does not necessarily result in the cancellation of the old cycle. Really, it is only _global_ collections (be it concurrent, degenerated or a full gc)  that cause the old collection to be entirely abandoned.

Got it, that makes sense; thanks @earthling-amzn !

-------------

PR Review Comment: https://git.openjdk.org/shenandoah/pull/262#discussion_r1175745415