Runtime: What is the difference between src/gc/unix/cgroup.cpp and src/pal/src/misc/cgroup.cpp

Created on 22 Jul 2019  路  2Comments  路  Source: dotnet/runtime

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)?

area-GC-coreclr question

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_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.

All 2 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

EgorBo picture EgorBo  路  3Comments

matty-hall picture matty-hall  路  3Comments

aggieben picture aggieben  路  3Comments

chunseoklee picture chunseoklee  路  3Comments

jamesqo picture jamesqo  路  3Comments