Hi! This is really just a question. I see that the two files src/gc/unix/cgroup.cpp and src/pal/src/misc/cgroup.cpp look really like the same file. Is that intentional? Any reason we can't share the code (or even generate one file from another at build time)?
The GC is written to have OS operations (virtual memory management, thread management, etc.) abstracted away by the GCToOSInterface. That interface is traditionally implemented by the VM (virtual machine, or the runtime side). The CoreCLR VM was written for windows, so, to bring it cross platform quick, the PAL was introduced, which emulates windows API calls, so that the VM does not need to be changed (mostly, if you see #ifdef FEATURE_PAL around, then there's some special casing for non windows platforms directly in the VM). As part of the local gc work, which allows compiling the GC as a loadable standalone shared library, the GCToOSInterface implementation was extracted from the VM and copied into the windows or unix directories. Ideally, CoreCLR would be using the gc provided environment (without regressing) at some point but right now it's only used for when the GC is compiled as standalone. CoreRT on the other hand recently made the switch to using the GC provided environment.
I'm closing this issue as the question was answered. thanks @Suchiman.
if you are not satisfied with the answer please feel free to reopen.
Most helpful comment
The GC is written to have OS operations (virtual memory management, thread management, etc.) abstracted away by the
GCToOSInterface. That interface is traditionally implemented by the VM (virtual machine, or the runtime side). The CoreCLR VM was written for windows, so, to bring it cross platform quick, the PAL was introduced, which emulates windows API calls, so that the VM does not need to be changed (mostly, if you see#ifdef FEATURE_PALaround, then there's some special casing for non windows platforms directly in the VM). As part of the local gc work, which allows compiling the GC as a loadable standalone shared library, theGCToOSInterfaceimplementation was extracted from the VM and copied into thewindowsorunixdirectories. Ideally, CoreCLR would be using the gc provided environment (without regressing) at some point but right now it's only used for when the GC is compiled as standalone. CoreRT on the other hand recently made the switch to using the GC provided environment.