On Tue, 8 Apr 2025 19:59:09 GMT, Albert Mingkun Yang <ay...@openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a 
>> merge or a rebase. The pull request now contains 39 commits:
>> 
>>  - * missing file from merge
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq
>>  - Merge branch 'master' into submit/8342382-card-table-instead-of-dcq
>>  - * make young gen length revising independent of refinement thread
>>      * use a service task
>>      * both refinement control thread and young gen length revising use the 
>> same infrastructure to get the number of available bytes and determine the 
>> time to the next update
>>  - * fix IR code generation tests that change due to barrier cost changes
>>  - * factor out card table and refinement table merging into a single
>>      method
>>  - Merge branch 'master' into 8342382-card-table-instead-of-dcq3
>>  - * obsolete G1UpdateBufferSize
>>    
>>    G1UpdateBufferSize has previously been used to size the refinement
>>    buffers and impose a minimum limit on the number of cards per thread
>>    that need to be pending before refinement starts.
>>    
>>    The former function is now obsolete with the removal of the dirty
>>    card queues, the latter functionality has been taken over by the new
>>    diagnostic option `G1PerThreadPendingCardThreshold`.
>>    
>>    I prefer to make this a diagnostic option is better than a product option
>>    because it is something that is only necessary for some test cases to
>>    produce some otherwise unwanted behavior (continuous refinement).
>>    
>>    CSR is pending.
>>  - ... and 29 more: https://git.openjdk.org/jdk/compare/41d4a0d7...1c5a669f
>
> src/hotspot/share/gc/g1/g1ConcurrentRefineSweepTask.cpp line 83:
> 
>> 81:         break;
>> 82:       }
>> 83:       case G1RemSet::HasRefToOld : break; // Nothing special to do.
> 
> Why doesn't call `inc_cards_clean_again` in this case? The card is cleared 
> also. (In fact, I don't get why this needs to a separate case from 
> `NoInteresting`.)

"NoInteresting" means that the card contains no interesting reference at all. 
"HasRefToOld" means that there has been an interesting reference in the card.

The distinction between these groups of cards seems interesting to me. E.g. out 
of X non-clean cards, there were A with a reference to the collection set, B 
that were already marked as containing a card to the collection, C not having 
any interesting card any more (transitioned from clean -> dirty -> clean, and 
cleared by the mutator), D being non-parsable, and E having references to old 
(and no other references).

I could add a separate counter for these type of cards too - they can be 
inferred from the total number of scanned minus the others though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23739#discussion_r2035512686

Reply via email to