Replace CQuickSort with qsort in GC info encoders.

[pgavlin]

This removes another utilcode dependency from the GC info encoders.

[pgavlin]

@russellhadley @jkotas @BruceForstall @dotnet/jit-contrib PTAL

This is part of #4127.

[CarolEidt]

I suspect that the perf will be pretty much a wash, but the GC info encoding was the source of some really bad outliers throughput-wise. I would recommend doing some throughput measurements.

[BruceForstall]

Why do you bother changing the encoder code at all? Why not just extract CQuickSort into a separate file, without dependencies, and just use the code as-is? Then there would be no question about correctness or performance.

[pgavlin]

Why do you bother changing the encoder code at all? Why not just extract CQuickSort into a separate file, without dependencies, and just use the code as-is? Then there would be no question about correctness or performance.

Primarily because qsort is already used elsewhere in the encoder and the transformation is rather simple. In at least one of these uses it calls out that CQuickSort is prone to stack overflows, so standardizing on qsort seems safer and cleaner than the alternative.

As a secondary concern, CQuickSort is widely used throughout the runtime and the surgery necessary to make it dependency-free for the GC info encoder but still usable elsewhere is a bit ugly.

[BruceForstall]

Since you don't seem to be worried much about sharing source code, you could always create a clone of CQuickSort and rip out the VM-specific code (contracts) without affecting its behavior.

Your change makes two changes at once: (1) extracting dependencies from utilcode, and (2) rewriting to change algorithms/data structures in a way you argue is preferable.

These do not need to be conflated, and I believe #2 is unnecessary. Even if "general goodness", it's not clear we should spend time on this anyway.

[jkotas]

Cloning and cleaning up CQuickSort to be standalone would be more work and larger delta that just switching the two places to qsort. The approach that @pgavlin has taken for this one makes sense to me.

[jkotas]

LGTM

[pgavlin]

@CarolEidt: local testing indicates that any throughput differences are within the noise.
@BruceForstall: there were no assembly diffs (incl. GC info) with this change.

[CarolEidt]

@pgavlin - thanks for testing!