…d_first_object when finding the start of objects for marking interior pointers.

…t in find_first_object when finding the start of objects for marking interior pointers."

This reverts commit 9d53ff9.

… but call its function pointer arg fn on another heap to keep things straight.

Example: thread 3 (associated with heap 3) helps out marking through cards on heap 5. The way I set things up the this pointer for mark_through_cards_for_xxx will get heap 5 as its this pointer. And that's fine as far comparisons against gc_low, gc_high, etc. go. However, it needs to call mark_object_simple with heap 3 as its this pointer, because otherwise multiple threads may use heap 5's mark_stack etc., which would cause trouble.

So, mark_through_cards_helper gets passed two heaps, one implicitly as the this pointer, the other ("hpt") explicitly - this is the heap associated with the gc thread.

…f an object straddles a chunk boundary. Added stress log instrumentation for card and card bundle clearing

…t one card bundle bit for each chunk.

In card_bundle_clear, use Interlocked::And because now several threads may clear bits in the same card bundle dword.

In relocate_phase, move other relocations *before* relocation of older generations, so the latter can make up for imbalances in the former.

Fix issue where mark_through_cards_for_segments was setting bricks incorrectly, causing too much time being spent in find_first_object. Fix is to distinguis the "next object" in the heap walk from the "continuation object" where we continue the scan.

… into card_mark_steal

…steal

…partially address code review feedback.

…wing Maoni's suggestion.

In the situation where there was a large byte array at the end of a segment, mark_through_cards_for_large_objects moved to the next segment, but the card_mark_enumerator was still in the previous segment and got stuck there.

Fix is to explicitly exhaust the current segment in mark_through_cards_xxx before moving on to the next one. This will keep the card_mark_enumerator and its callers in mark_through_cards_xxx in sync.

Make sure we can optionally use STRESS_LOG for situations where that's advantageous.

…e in mark_through_cards_xxx.

…ansition.

As card_word_end is updated by find_next_chunk, moving the call to find_next_chunk into card_transition means card_word_end needs to be a reference parameter in card_transition, otherwise card_word_end in mark_through_cards_xxx would not get updated.

I found there is significant overhead to enabling FEATURE_CARD_MARKING_STEALING for workstation GC in the case of low card density, and of course there is no benefit, so it makes sense to enable it only for server GC where the additional overhead will be made up by better work balancing in most cases.

I fixed an off-by-one issue in find_card, and when I switched workstation GC back to no card marking stealing, this assert at the end of card_transition fired in the case where limit, end and card_address(end_card) all coincide, because we access the card for the end address which we really shouldn't look at.

The fix is simply to compare limit to end instead of card_address(end_card).

Pass card_word_end as a value parameter to card transition, when FEATURE_CARD_MARKING_STEALING is enabled, also pass it as a ref parameter. This gets rid of a perf regression in workstation GC.

Set CARD_MARKING_STEALING_GRANULARITY to a higher value - picked 2 MB in 64-bits (1 MB in 32-bits). Perhaps this is a reasonable compromise.