The real reason appears to be that the maintainer of it is kind of crazy and appears to not be properly managed. She's actually rejected community pull requests to break it up in the past on the grounds that she just prefers it in one giant file, and doesn't believe it makes any difference to comprehension or codebase usability.
https://github.com/dotnet/runtime/issues/4024#issuecomment-7...
https://github.com/dotnet/runtime/issues/4024#issuecomment-2...
Honestly the .NET code is kind of a mess compared to the OpenJDK code. The developers really don't seem quite as sharp. It's impossible to imagine HotSpot containing a source file that's 35,000 lines long, let alone dismissing attempts to improve it with ridiculous justifications like "it'll cause merge conflicts". The lines themselves are about as high quality as you might guess from something converted from Lisp and then hacked on for a decade or so by people who prefer it all in one file - enormous amounts of #ifdefs all over the place, it starts by defining its own random number generator, a mishmash of different coding styles, dead code, lots of undocumented and untunable magic numbers ... it's really a disaster zone.
Behold:
https://raw.githubusercontent.com/dotnet/runtime/master/src/...
And compare to the HotSpot GCs:
https://github.com/openjdk/jdk/tree/master/src/hotspot/share...
(multiple algorithms for throughput vs latency, "epsilon" is the smallest GC implementation possible that doesn't actually collect anything - it's useful for learning and cases where you know your process won't last long enough to need a collection)
When the CLR was first open sourced I was very curious to see if OpenJDK might now have some stronger competition when .NET was ported to other systems and made more UNIX friendly. After reading through the code and seeing how the developers acted I concluded they'd never displace the JVM.