Remove unused SORT_MARK_STACK code.

[adityamandaleeka]

This PR removes the SORT_MARK_STACK feature and related rqsort1 function from the GC. These aren't used and if we need them, we can always bring them back from history.

I don't know the full history here but I assume it's not enabled because the performance benefits weren't worth the sorting cost. Plus we have prefetch in the mark phase now which should help hide memory latency.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull request overview

This PR removes the unused SORT_MARK_STACK feature from the garbage collector. The feature was designed to sort the mark stack during GC marking phases to potentially improve memory access patterns, but it was never enabled in production builds. With prefetch optimization now available in the mark phase, this sorting code is no longer needed.

Changes:

• Removed the rqsort1 function that implemented reverse quicksort for sorting mark stack entries
• Removed all SORT_MARK_STACK conditional compilation blocks from both foreground and background GC marking functions

[AaronRobinsonMSFT]

Is it possible this was a diagnostic tool used during GC development/debugging scenarios?

[VSadov]

Not sure what the history of this either, but my guess would be the same as @adityamandaleeka -
Someone hoped that sorting mark stack would speed up marking, but it did not always help.

Marks stack typically covers only a small portion of the heap and in general can contain fairly random pointers, thus it can be too sparse to benefit from sorting.

[VSadov]

LGTM