Separate GC WKS and SVR compilation units

[janvorli]

Move the GC sources away from the wrapper-file model that text-included gc.cpp and gcee.cpp under SERVER_GC and instead compile the shared sources directly as separate WKS and SVR objects.

This change introduces gcinternal.h as the shared compilation context for the gc.cpp split, converts the former tail-included GC implementation fragments into separately compiled translation units, and updates the GC, VM, NativeAOT, and GC sample build surfaces to consume the new object layout.

It also removes the gcsvr.cpp/gcwks.cpp and gceesvr.cpp/gceewks.cpp wrappers, compiles gcee.cpp through the same dual-build WKS/SVR source lists as gc.cpp, deduplicates the repeated WKS/SVR source lists in the relevant CMake files, and renames the shared GC header from gc_common.h to gcinternal.h to avoid confusion with gccommon.cpp.

During the split, cross-translation-unit declarations and inline helpers needed by multiple GC source files were moved into the shared header, while local-only inline helpers were moved back into their owning .cpp files to avoid keeping unnecessary bodies in the shared header.

I've made size comparison between the new clrgc.dll, clrgcexp.dll and coreclr.dll and the changes in the gc dlls were very minor, around ~1.5kB growth due to little different decisions of the linker / compiler w.r.t. cold / hot code. The coreclr even became ~1.5kB smaller.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR refactors CoreCLR GC build plumbing to stop using wrapper translation units (gcwks.cpp/gcsvr.cpp and gceewks.cpp/gceesvr.cpp) and instead compile the shared GC implementation sources directly into separate WKS/SVR object sets, using a new shared compilation-context header gcinternal.h.

Changes:

• Introduces gcinternal.h and updates many GC .cpp files to include it and wrap code in WKS/SVR namespaces based on SERVER_GC.
• Updates CoreCLR VM and standalone GC CMake build graphs to build GC sources as object libraries for WKS/SVR and consume them from coreclr/clrgc targets.
• Updates NativeAOT runtime and the GC sample project build surfaces to consume the new GC source layout.

Reviewed changes

Copilot reviewed 31 out of 33 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/coreclr/vm/wks/CMakeLists.txt	Adds GC object files into cee_wks_core build inputs.
src/coreclr/vm/CMakeLists.txt	Defines shared GC source list and builds vm_gc_wks/vm_gc_svr object libraries.
src/coreclr/dlls/mscoree/coreclr/CMakeLists.txt	Links vm_gc_wks/vm_gc_svr into coreclr and coreclr_static.
src/coreclr/nativeaot/Runtime/CMakeLists.txt	Replaces wrapper sources with direct GC .cpp compilation for NativeAOT.
src/coreclr/gc/gcinternal.h	New shared GC compilation-context header; centralizes includes and inlines.
src/coreclr/gc/*.cpp	Switches individual GC implementation files to include gcinternal.h and wrap in WKS/SVR namespaces.
src/coreclr/gc/CMakeLists.txt	Builds standalone GC (clrgc/clrgcexp) with WKS/SVR object libraries.
src/coreclr/gc/sample/*	Updates GC sample to compile split GC .cpp files directly.

[mangod9]

what is the motivation for this change? Does it improve build times?

[janvorli]

what is the motivation for this change? Does it improve build times?

It doesn't affect build time in any way. The main reason is code editing experience. The individual files into which the gc.cpp was split in my recent change didn't include the headers for symbols they use, so when editing one of those e.g. in VS code, it was showing a lot of red squiggles and code navigation didn't work well.

[jkotas]

Build breaks....

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[VSadov]

LGTM!

[MichalStrehovsky]

2% size savings on Hello World on Linux, nice!

Size statistics

Pull request #126720

Project	Size before	Size after	Difference
TodosApi-linux	24545416	24488072	-57344
TodosApi-windows	25923584	25909760	-13824
avalonia.app-linux	18912136	18887560	-24576
avalonia.app-windows	19439616	19433472	-6144
hello-linux	1246088	1221512	-24576
hello-minimal-linux	1098528	1073952	-24576
hello-minimal-windows	773632	766464	-7168
hello-windows	933376	927232	-6144
kestrel-minimal-linux	5354976	5293536	-61440
kestrel-minimal-windows	4854784	4840960	-13824
reflection-linux	1832784	1808208	-24576
reflection-windows	1696256	1689600	-6656
webapiaot-linux	9721456	9660016	-61440
webapiaot-windows	10246144	10232320	-13824
winrt-component-minimal-windows	721408	714240	-7168

[jkotas]

2% size savings on Hello World on Linux, nice!

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

This type of refactoring tends to depend on good PGO data and whole program optimizations for good perf:

• On Windows, we do not use LGCG and PGO for NAOT to avoid compiler version fragility
• On Linux, the infrastructure for collecting PGO data is broken for libcoreclr.so. It is one of the check boxes in Startup time of small workloads #120407 and there was a chat on Teams about that. We may want to frontload fixing it to avoid regressing GC perf on Linux.

[janvorli]

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

I definitely want to run the GC perf runs and understand where the size improvement comes from before we merge this.
There were two large functions that were inlined before and that I stopped marking as inlined because I felt like they were too large to make sense inlining them and wanted to verify a perf impact of that. Those were gc_heap::mark_through_cards_helper and gc_heap::set_region_gen_num. Edit: And gc_heap::get_promoted_bytes

[janvorli]

@jkotas performance and functionality tests didn't show any regressions.

[jkotas]

Have you measured it on a binary that showed the large code size reduction?

(Also, there is a merge conflict that needs to be resolved.)

[janvorli]

So on my machine, the diff when really running the NativeAOT version was 0,9%.

[jkotas]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

Alternatively, use the low-tech equivalent (e.g. https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html) that merges all .cpp files together during the build so that the C++ compiler can still see all code together.

Otherwise, we will likely end up with thousands paper cut perf regression over time.

[janvorli]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

I don't think that's possible. Static libraries are just bags of object files. Since they are not combined in any way, it seems LTO would not be able to do anything. It seems that the unity build would be the only option for this case.

[am11]

I don't think that's possible. Static libraries are just bags of object files.

Technically, it is possible. By using -flto -ffat-lto-objects during compilation, we can generate a static library archive that bundles LTO bytecode alongside standard object code (in .a file). I tested this on the main branch; as expected, it increased the size of each static library and the resulting NuGet package. However, the final linked binary size remained the same (a "Hello World" sample actually increased by a few bytes). The real dealbreaker is the toolchain dependency: shipping bytecode requires consumers to use the exact same compiler version to link successfully. For all practical purposes, that makes it a no-go for our distribution.

The CMake Unity Build approach sounds interesting.

[jkotas]

Since they are not combined in any way, it seems LTO would not be able to do anything.

You can combine the object files in a custom way to produce the library. We have started doing a few days ago to deal with libunwind symbol conflicts. The same technique may be used for LTO too #128927 (review) . This technique is compiler-toolchain specific. I do not think there is a publicly documented way to do this with MSVC. Unity build is more portable.

[janvorli]

@jkotas I've enabled unity build for the GC stuff and also changed the two functions I've mentioned above back to inline. That got rid of all the difference in the test you've shared.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 2 comments.

[janvorli]

@jkotas, @VSadov can you please review this again?

[janvorli]

/ba-g timeouts on win-64 arm are occurring on many PRs and are unrelated to this change.

[janvorli]

Move the GC sources away from the wrapper-file model that text-included gc.cpp and gcee.cpp under SERVER_GC and instead compile the shared sources directly as separate WKS and SVR objects.

This change introduces gcinternal.h as the shared compilation context for the gc.cpp split, converts the former tail-included GC implementation fragments into separately compiled translation units, and updates the GC, VM, NativeAOT, and GC sample build surfaces to consume the new object layout.

It also removes the gcsvr.cpp/gcwks.cpp and gceesvr.cpp/gceewks.cpp wrappers, compiles gcee.cpp through the same dual-build WKS/SVR source lists as gc.cpp, deduplicates the repeated WKS/SVR source lists in the relevant CMake files, and renames the shared GC header from gc_common.h to gcinternal.h to avoid confusion with gccommon.cpp.

During the split, cross-translation-unit declarations and inline helpers needed by multiple GC source files were moved into the shared header, while local-only inline helpers were moved back into their owning .cpp files to avoid keeping unnecessary bodies in the shared header.

I've made size comparison between the new clrgc.dll, clrgcexp.dll and coreclr.dll and the changes in the gc dlls were very minor, around ~1.5kB growth due to little different decisions of the linker / compiler w.r.t. cold / hot code. The coreclr even became ~1.5kB smaller.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR refactors CoreCLR GC build plumbing to stop using wrapper translation units (gcwks.cpp/gcsvr.cpp and gceewks.cpp/gceesvr.cpp) and instead compile the shared GC implementation sources directly into separate WKS/SVR object sets, using a new shared compilation-context header gcinternal.h.

Changes:

• Introduces gcinternal.h and updates many GC .cpp files to include it and wrap code in WKS/SVR namespaces based on SERVER_GC.
• Updates CoreCLR VM and standalone GC CMake build graphs to build GC sources as object libraries for WKS/SVR and consume them from coreclr/clrgc targets.
• Updates NativeAOT runtime and the GC sample project build surfaces to consume the new GC source layout.

Reviewed changes

Copilot reviewed 31 out of 33 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/coreclr/vm/wks/CMakeLists.txt	Adds GC object files into cee_wks_core build inputs.
src/coreclr/vm/CMakeLists.txt	Defines shared GC source list and builds vm_gc_wks/vm_gc_svr object libraries.
src/coreclr/dlls/mscoree/coreclr/CMakeLists.txt	Links vm_gc_wks/vm_gc_svr into coreclr and coreclr_static.
src/coreclr/nativeaot/Runtime/CMakeLists.txt	Replaces wrapper sources with direct GC .cpp compilation for NativeAOT.
src/coreclr/gc/gcinternal.h	New shared GC compilation-context header; centralizes includes and inlines.
src/coreclr/gc/*.cpp	Switches individual GC implementation files to include gcinternal.h and wrap in WKS/SVR namespaces.
src/coreclr/gc/CMakeLists.txt	Builds standalone GC (clrgc/clrgcexp) with WKS/SVR object libraries.
src/coreclr/gc/sample/*	Updates GC sample to compile split GC .cpp files directly.

[mangod9]

what is the motivation for this change? Does it improve build times?

[janvorli]

what is the motivation for this change? Does it improve build times?

It doesn't affect build time in any way. The main reason is code editing experience. The individual files into which the gc.cpp was split in my recent change didn't include the headers for symbols they use, so when editing one of those e.g. in VS code, it was showing a lot of red squiggles and code navigation didn't work well.

[jkotas]

Build breaks....

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[VSadov]

LGTM!

[MichalStrehovsky]

2% size savings on Hello World on Linux, nice!

Size statistics

Pull request #126720

Project	Size before	Size after	Difference
TodosApi-linux	24545416	24488072	-57344
TodosApi-windows	25923584	25909760	-13824
avalonia.app-linux	18912136	18887560	-24576
avalonia.app-windows	19439616	19433472	-6144
hello-linux	1246088	1221512	-24576
hello-minimal-linux	1098528	1073952	-24576
hello-minimal-windows	773632	766464	-7168
hello-windows	933376	927232	-6144
kestrel-minimal-linux	5354976	5293536	-61440
kestrel-minimal-windows	4854784	4840960	-13824
reflection-linux	1832784	1808208	-24576
reflection-windows	1696256	1689600	-6656
webapiaot-linux	9721456	9660016	-61440
webapiaot-windows	10246144	10232320	-13824
winrt-component-minimal-windows	721408	714240	-7168

[jkotas]

2% size savings on Hello World on Linux, nice!

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

This type of refactoring tends to depend on good PGO data and whole program optimizations for good perf:

• On Windows, we do not use LGCG and PGO for NAOT to avoid compiler version fragility
• On Linux, the infrastructure for collecting PGO data is broken for libcoreclr.so. It is one of the check boxes in Startup time of small workloads #120407 and there was a chat on Teams about that. We may want to frontload fixing it to avoid regressing GC perf on Linux.

[janvorli]

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

I definitely want to run the GC perf runs and understand where the size improvement comes from before we merge this.
There were two large functions that were inlined before and that I stopped marking as inlined because I felt like they were too large to make sense inlining them and wanted to verify a perf impact of that. Those were gc_heap::mark_through_cards_helper and gc_heap::set_region_gen_num. Edit: And gc_heap::get_promoted_bytes

[janvorli]

@jkotas performance and functionality tests didn't show any regressions.

[jkotas]

Have you measured it on a binary that showed the large code size reduction?

(Also, there is a merge conflict that needs to be resolved.)

[janvorli]

So on my machine, the diff when really running the NativeAOT version was 0,9%.

[jkotas]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

Alternatively, use the low-tech equivalent (e.g. https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html) that merges all .cpp files together during the build so that the C++ compiler can still see all code together.

Otherwise, we will likely end up with thousands paper cut perf regression over time.

[janvorli]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

I don't think that's possible. Static libraries are just bags of object files. Since they are not combined in any way, it seems LTO would not be able to do anything. It seems that the unity build would be the only option for this case.

[am11]

I don't think that's possible. Static libraries are just bags of object files.

Technically, it is possible. By using -flto -ffat-lto-objects during compilation, we can generate a static library archive that bundles LTO bytecode alongside standard object code (in .a file). I tested this on the main branch; as expected, it increased the size of each static library and the resulting NuGet package. However, the final linked binary size remained the same (a "Hello World" sample actually increased by a few bytes). The real dealbreaker is the toolchain dependency: shipping bytecode requires consumers to use the exact same compiler version to link successfully. For all practical purposes, that makes it a no-go for our distribution.

The CMake Unity Build approach sounds interesting.

[jkotas]

Since they are not combined in any way, it seems LTO would not be able to do anything.

You can combine the object files in a custom way to produce the library. We have started doing a few days ago to deal with libunwind symbol conflicts. The same technique may be used for LTO too #128927 (review) . This technique is compiler-toolchain specific. I do not think there is a publicly documented way to do this with MSVC. Unity build is more portable.

[janvorli]

@jkotas I've enabled unity build for the GC stuff and also changed the two functions I've mentioned above back to inline. That got rid of all the difference in the test you've shared.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 2 comments.

[janvorli]

@jkotas, @VSadov can you please review this again?

[janvorli]

/ba-g timeouts on win-64 arm are occurring on many PRs and are unrelated to this change.

[janvorli]

Move the GC sources away from the wrapper-file model that text-included gc.cpp and gcee.cpp under SERVER_GC and instead compile the shared sources directly as separate WKS and SVR objects.

This change introduces gcinternal.h as the shared compilation context for the gc.cpp split, converts the former tail-included GC implementation fragments into separately compiled translation units, and updates the GC, VM, NativeAOT, and GC sample build surfaces to consume the new object layout.

It also removes the gcsvr.cpp/gcwks.cpp and gceesvr.cpp/gceewks.cpp wrappers, compiles gcee.cpp through the same dual-build WKS/SVR source lists as gc.cpp, deduplicates the repeated WKS/SVR source lists in the relevant CMake files, and renames the shared GC header from gc_common.h to gcinternal.h to avoid confusion with gccommon.cpp.

During the split, cross-translation-unit declarations and inline helpers needed by multiple GC source files were moved into the shared header, while local-only inline helpers were moved back into their owning .cpp files to avoid keeping unnecessary bodies in the shared header.

I've made size comparison between the new clrgc.dll, clrgcexp.dll and coreclr.dll and the changes in the gc dlls were very minor, around ~1.5kB growth due to little different decisions of the linker / compiler w.r.t. cold / hot code. The coreclr even became ~1.5kB smaller.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR refactors CoreCLR GC build plumbing to stop using wrapper translation units (gcwks.cpp/gcsvr.cpp and gceewks.cpp/gceesvr.cpp) and instead compile the shared GC implementation sources directly into separate WKS/SVR object sets, using a new shared compilation-context header gcinternal.h.

Changes:

• Introduces gcinternal.h and updates many GC .cpp files to include it and wrap code in WKS/SVR namespaces based on SERVER_GC.
• Updates CoreCLR VM and standalone GC CMake build graphs to build GC sources as object libraries for WKS/SVR and consume them from coreclr/clrgc targets.
• Updates NativeAOT runtime and the GC sample project build surfaces to consume the new GC source layout.

Reviewed changes

Copilot reviewed 31 out of 33 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/coreclr/vm/wks/CMakeLists.txt	Adds GC object files into cee_wks_core build inputs.
src/coreclr/vm/CMakeLists.txt	Defines shared GC source list and builds vm_gc_wks/vm_gc_svr object libraries.
src/coreclr/dlls/mscoree/coreclr/CMakeLists.txt	Links vm_gc_wks/vm_gc_svr into coreclr and coreclr_static.
src/coreclr/nativeaot/Runtime/CMakeLists.txt	Replaces wrapper sources with direct GC .cpp compilation for NativeAOT.
src/coreclr/gc/gcinternal.h	New shared GC compilation-context header; centralizes includes and inlines.
src/coreclr/gc/*.cpp	Switches individual GC implementation files to include gcinternal.h and wrap in WKS/SVR namespaces.
src/coreclr/gc/CMakeLists.txt	Builds standalone GC (clrgc/clrgcexp) with WKS/SVR object libraries.
src/coreclr/gc/sample/*	Updates GC sample to compile split GC .cpp files directly.

[mangod9]

what is the motivation for this change? Does it improve build times?

[janvorli]

what is the motivation for this change? Does it improve build times?

It doesn't affect build time in any way. The main reason is code editing experience. The individual files into which the gc.cpp was split in my recent change didn't include the headers for symbols they use, so when editing one of those e.g. in VS code, it was showing a lot of red squiggles and code navigation didn't work well.

[jkotas]

Build breaks....

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[VSadov]

LGTM!

[MichalStrehovsky]

2% size savings on Hello World on Linux, nice!

Size statistics

Pull request #126720

Project	Size before	Size after	Difference
TodosApi-linux	24545416	24488072	-57344
TodosApi-windows	25923584	25909760	-13824
avalonia.app-linux	18912136	18887560	-24576
avalonia.app-windows	19439616	19433472	-6144
hello-linux	1246088	1221512	-24576
hello-minimal-linux	1098528	1073952	-24576
hello-minimal-windows	773632	766464	-7168
hello-windows	933376	927232	-6144
kestrel-minimal-linux	5354976	5293536	-61440
kestrel-minimal-windows	4854784	4840960	-13824
reflection-linux	1832784	1808208	-24576
reflection-windows	1696256	1689600	-6656
webapiaot-linux	9721456	9660016	-61440
webapiaot-windows	10246144	10232320	-13824
winrt-component-minimal-windows	721408	714240	-7168

[jkotas]

2% size savings on Hello World on Linux, nice!

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

This type of refactoring tends to depend on good PGO data and whole program optimizations for good perf:

• On Windows, we do not use LGCG and PGO for NAOT to avoid compiler version fragility
• On Linux, the infrastructure for collecting PGO data is broken for libcoreclr.so. It is one of the check boxes in Startup time of small workloads #120407 and there was a chat on Teams about that. We may want to frontload fixing it to avoid regressing GC perf on Linux.

[janvorli]

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

I definitely want to run the GC perf runs and understand where the size improvement comes from before we merge this.
There were two large functions that were inlined before and that I stopped marking as inlined because I felt like they were too large to make sense inlining them and wanted to verify a perf impact of that. Those were gc_heap::mark_through_cards_helper and gc_heap::set_region_gen_num. Edit: And gc_heap::get_promoted_bytes

[janvorli]

@jkotas performance and functionality tests didn't show any regressions.

[jkotas]

Have you measured it on a binary that showed the large code size reduction?

(Also, there is a merge conflict that needs to be resolved.)

[janvorli]

So on my machine, the diff when really running the NativeAOT version was 0,9%.

[jkotas]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

Alternatively, use the low-tech equivalent (e.g. https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html) that merges all .cpp files together during the build so that the C++ compiler can still see all code together.

Otherwise, we will likely end up with thousands paper cut perf regression over time.

[janvorli]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

I don't think that's possible. Static libraries are just bags of object files. Since they are not combined in any way, it seems LTO would not be able to do anything. It seems that the unity build would be the only option for this case.

[am11]

I don't think that's possible. Static libraries are just bags of object files.

Technically, it is possible. By using -flto -ffat-lto-objects during compilation, we can generate a static library archive that bundles LTO bytecode alongside standard object code (in .a file). I tested this on the main branch; as expected, it increased the size of each static library and the resulting NuGet package. However, the final linked binary size remained the same (a "Hello World" sample actually increased by a few bytes). The real dealbreaker is the toolchain dependency: shipping bytecode requires consumers to use the exact same compiler version to link successfully. For all practical purposes, that makes it a no-go for our distribution.

The CMake Unity Build approach sounds interesting.

[jkotas]

Since they are not combined in any way, it seems LTO would not be able to do anything.

You can combine the object files in a custom way to produce the library. We have started doing a few days ago to deal with libunwind symbol conflicts. The same technique may be used for LTO too #128927 (review) . This technique is compiler-toolchain specific. I do not think there is a publicly documented way to do this with MSVC. Unity build is more portable.

[janvorli]

@jkotas I've enabled unity build for the GC stuff and also changed the two functions I've mentioned above back to inline. That got rid of all the difference in the test you've shared.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 2 comments.

[janvorli]

@jkotas, @VSadov can you please review this again?

[janvorli]

/ba-g timeouts on win-64 arm are occurring on many PRs and are unrelated to this change.

[janvorli]

Move the GC sources away from the wrapper-file model that text-included gc.cpp and gcee.cpp under SERVER_GC and instead compile the shared sources directly as separate WKS and SVR objects.

This change introduces gcinternal.h as the shared compilation context for the gc.cpp split, converts the former tail-included GC implementation fragments into separately compiled translation units, and updates the GC, VM, NativeAOT, and GC sample build surfaces to consume the new object layout.

It also removes the gcsvr.cpp/gcwks.cpp and gceesvr.cpp/gceewks.cpp wrappers, compiles gcee.cpp through the same dual-build WKS/SVR source lists as gc.cpp, deduplicates the repeated WKS/SVR source lists in the relevant CMake files, and renames the shared GC header from gc_common.h to gcinternal.h to avoid confusion with gccommon.cpp.

During the split, cross-translation-unit declarations and inline helpers needed by multiple GC source files were moved into the shared header, while local-only inline helpers were moved back into their owning .cpp files to avoid keeping unnecessary bodies in the shared header.

I've made size comparison between the new clrgc.dll, clrgcexp.dll and coreclr.dll and the changes in the gc dlls were very minor, around ~1.5kB growth due to little different decisions of the linker / compiler w.r.t. cold / hot code. The coreclr even became ~1.5kB smaller.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR refactors CoreCLR GC build plumbing to stop using wrapper translation units (gcwks.cpp/gcsvr.cpp and gceewks.cpp/gceesvr.cpp) and instead compile the shared GC implementation sources directly into separate WKS/SVR object sets, using a new shared compilation-context header gcinternal.h.

Changes:

• Introduces gcinternal.h and updates many GC .cpp files to include it and wrap code in WKS/SVR namespaces based on SERVER_GC.
• Updates CoreCLR VM and standalone GC CMake build graphs to build GC sources as object libraries for WKS/SVR and consume them from coreclr/clrgc targets.
• Updates NativeAOT runtime and the GC sample project build surfaces to consume the new GC source layout.

Reviewed changes

Copilot reviewed 31 out of 33 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/coreclr/vm/wks/CMakeLists.txt	Adds GC object files into cee_wks_core build inputs.
src/coreclr/vm/CMakeLists.txt	Defines shared GC source list and builds vm_gc_wks/vm_gc_svr object libraries.
src/coreclr/dlls/mscoree/coreclr/CMakeLists.txt	Links vm_gc_wks/vm_gc_svr into coreclr and coreclr_static.
src/coreclr/nativeaot/Runtime/CMakeLists.txt	Replaces wrapper sources with direct GC .cpp compilation for NativeAOT.
src/coreclr/gc/gcinternal.h	New shared GC compilation-context header; centralizes includes and inlines.
src/coreclr/gc/*.cpp	Switches individual GC implementation files to include gcinternal.h and wrap in WKS/SVR namespaces.
src/coreclr/gc/CMakeLists.txt	Builds standalone GC (clrgc/clrgcexp) with WKS/SVR object libraries.
src/coreclr/gc/sample/*	Updates GC sample to compile split GC .cpp files directly.

[mangod9]

what is the motivation for this change? Does it improve build times?

[janvorli]

what is the motivation for this change? Does it improve build times?

It doesn't affect build time in any way. The main reason is code editing experience. The individual files into which the gc.cpp was split in my recent change didn't include the headers for symbols they use, so when editing one of those e.g. in VS code, it was showing a lot of red squiggles and code navigation didn't work well.

[jkotas]

Build breaks....

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[VSadov]

LGTM!

[MichalStrehovsky]

2% size savings on Hello World on Linux, nice!

Size statistics

Pull request #126720

Project	Size before	Size after	Difference
TodosApi-linux	24545416	24488072	-57344
TodosApi-windows	25923584	25909760	-13824
avalonia.app-linux	18912136	18887560	-24576
avalonia.app-windows	19439616	19433472	-6144
hello-linux	1246088	1221512	-24576
hello-minimal-linux	1098528	1073952	-24576
hello-minimal-windows	773632	766464	-7168
hello-windows	933376	927232	-6144
kestrel-minimal-linux	5354976	5293536	-61440
kestrel-minimal-windows	4854784	4840960	-13824
reflection-linux	1832784	1808208	-24576
reflection-windows	1696256	1689600	-6656
webapiaot-linux	9721456	9660016	-61440
webapiaot-windows	10246144	10232320	-13824
winrt-component-minimal-windows	721408	714240	-7168

[jkotas]

2% size savings on Hello World on Linux, nice!

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

This type of refactoring tends to depend on good PGO data and whole program optimizations for good perf:

• On Windows, we do not use LGCG and PGO for NAOT to avoid compiler version fragility
• On Linux, the infrastructure for collecting PGO data is broken for libcoreclr.so. It is one of the check boxes in Startup time of small workloads #120407 and there was a chat on Teams about that. We may want to frontload fixing it to avoid regressing GC perf on Linux.

[janvorli]

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

I definitely want to run the GC perf runs and understand where the size improvement comes from before we merge this.
There were two large functions that were inlined before and that I stopped marking as inlined because I felt like they were too large to make sense inlining them and wanted to verify a perf impact of that. Those were gc_heap::mark_through_cards_helper and gc_heap::set_region_gen_num. Edit: And gc_heap::get_promoted_bytes

[janvorli]

@jkotas performance and functionality tests didn't show any regressions.

[jkotas]

Have you measured it on a binary that showed the large code size reduction?

(Also, there is a merge conflict that needs to be resolved.)

[janvorli]

So on my machine, the diff when really running the NativeAOT version was 0,9%.

[jkotas]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

Alternatively, use the low-tech equivalent (e.g. https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html) that merges all .cpp files together during the build so that the C++ compiler can still see all code together.

Otherwise, we will likely end up with thousands paper cut perf regression over time.

[janvorli]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

I don't think that's possible. Static libraries are just bags of object files. Since they are not combined in any way, it seems LTO would not be able to do anything. It seems that the unity build would be the only option for this case.

[am11]

I don't think that's possible. Static libraries are just bags of object files.

Technically, it is possible. By using -flto -ffat-lto-objects during compilation, we can generate a static library archive that bundles LTO bytecode alongside standard object code (in .a file). I tested this on the main branch; as expected, it increased the size of each static library and the resulting NuGet package. However, the final linked binary size remained the same (a "Hello World" sample actually increased by a few bytes). The real dealbreaker is the toolchain dependency: shipping bytecode requires consumers to use the exact same compiler version to link successfully. For all practical purposes, that makes it a no-go for our distribution.

The CMake Unity Build approach sounds interesting.

[jkotas]

Since they are not combined in any way, it seems LTO would not be able to do anything.

You can combine the object files in a custom way to produce the library. We have started doing a few days ago to deal with libunwind symbol conflicts. The same technique may be used for LTO too #128927 (review) . This technique is compiler-toolchain specific. I do not think there is a publicly documented way to do this with MSVC. Unity build is more portable.

[janvorli]

@jkotas I've enabled unity build for the GC stuff and also changed the two functions I've mentioned above back to inline. That got rid of all the difference in the test you've shared.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 2 comments.

[janvorli]

@jkotas, @VSadov can you please review this again?

[janvorli]

/ba-g timeouts on win-64 arm are occurring on many PRs and are unrelated to this change.

[janvorli]

Move the GC sources away from the wrapper-file model that text-included gc.cpp and gcee.cpp under SERVER_GC and instead compile the shared sources directly as separate WKS and SVR objects.

This change introduces gcinternal.h as the shared compilation context for the gc.cpp split, converts the former tail-included GC implementation fragments into separately compiled translation units, and updates the GC, VM, NativeAOT, and GC sample build surfaces to consume the new object layout.

It also removes the gcsvr.cpp/gcwks.cpp and gceesvr.cpp/gceewks.cpp wrappers, compiles gcee.cpp through the same dual-build WKS/SVR source lists as gc.cpp, deduplicates the repeated WKS/SVR source lists in the relevant CMake files, and renames the shared GC header from gc_common.h to gcinternal.h to avoid confusion with gccommon.cpp.

During the split, cross-translation-unit declarations and inline helpers needed by multiple GC source files were moved into the shared header, while local-only inline helpers were moved back into their owning .cpp files to avoid keeping unnecessary bodies in the shared header.

I've made size comparison between the new clrgc.dll, clrgcexp.dll and coreclr.dll and the changes in the gc dlls were very minor, around ~1.5kB growth due to little different decisions of the linker / compiler w.r.t. cold / hot code. The coreclr even became ~1.5kB smaller.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR refactors CoreCLR GC build plumbing to stop using wrapper translation units (gcwks.cpp/gcsvr.cpp and gceewks.cpp/gceesvr.cpp) and instead compile the shared GC implementation sources directly into separate WKS/SVR object sets, using a new shared compilation-context header gcinternal.h.

Changes:

• Introduces gcinternal.h and updates many GC .cpp files to include it and wrap code in WKS/SVR namespaces based on SERVER_GC.
• Updates CoreCLR VM and standalone GC CMake build graphs to build GC sources as object libraries for WKS/SVR and consume them from coreclr/clrgc targets.
• Updates NativeAOT runtime and the GC sample project build surfaces to consume the new GC source layout.

Reviewed changes

Copilot reviewed 31 out of 33 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/coreclr/vm/wks/CMakeLists.txt	Adds GC object files into cee_wks_core build inputs.
src/coreclr/vm/CMakeLists.txt	Defines shared GC source list and builds vm_gc_wks/vm_gc_svr object libraries.
src/coreclr/dlls/mscoree/coreclr/CMakeLists.txt	Links vm_gc_wks/vm_gc_svr into coreclr and coreclr_static.
src/coreclr/nativeaot/Runtime/CMakeLists.txt	Replaces wrapper sources with direct GC .cpp compilation for NativeAOT.
src/coreclr/gc/gcinternal.h	New shared GC compilation-context header; centralizes includes and inlines.
src/coreclr/gc/*.cpp	Switches individual GC implementation files to include gcinternal.h and wrap in WKS/SVR namespaces.
src/coreclr/gc/CMakeLists.txt	Builds standalone GC (clrgc/clrgcexp) with WKS/SVR object libraries.
src/coreclr/gc/sample/*	Updates GC sample to compile split GC .cpp files directly.

[mangod9]

what is the motivation for this change? Does it improve build times?

[janvorli]

what is the motivation for this change? Does it improve build times?

It doesn't affect build time in any way. The main reason is code editing experience. The individual files into which the gc.cpp was split in my recent change didn't include the headers for symbols they use, so when editing one of those e.g. in VS code, it was showing a lot of red squiggles and code navigation didn't work well.

[jkotas]

Build breaks....

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[VSadov]

LGTM!

[MichalStrehovsky]

2% size savings on Hello World on Linux, nice!

Size statistics

Pull request #126720

Project	Size before	Size after	Difference
TodosApi-linux	24545416	24488072	-57344
TodosApi-windows	25923584	25909760	-13824
avalonia.app-linux	18912136	18887560	-24576
avalonia.app-windows	19439616	19433472	-6144
hello-linux	1246088	1221512	-24576
hello-minimal-linux	1098528	1073952	-24576
hello-minimal-windows	773632	766464	-7168
hello-windows	933376	927232	-6144
kestrel-minimal-linux	5354976	5293536	-61440
kestrel-minimal-windows	4854784	4840960	-13824
reflection-linux	1832784	1808208	-24576
reflection-windows	1696256	1689600	-6656
webapiaot-linux	9721456	9660016	-61440
webapiaot-windows	10246144	10232320	-13824
winrt-component-minimal-windows	721408	714240	-7168

[jkotas]

2% size savings on Hello World on Linux, nice!

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

This type of refactoring tends to depend on good PGO data and whole program optimizations for good perf:

• On Windows, we do not use LGCG and PGO for NAOT to avoid compiler version fragility
• On Linux, the infrastructure for collecting PGO data is broken for libcoreclr.so. It is one of the check boxes in Startup time of small workloads #120407 and there was a chat on Teams about that. We may want to frontload fixing it to avoid regressing GC perf on Linux.

[janvorli]

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

I definitely want to run the GC perf runs and understand where the size improvement comes from before we merge this.
There were two large functions that were inlined before and that I stopped marking as inlined because I felt like they were too large to make sense inlining them and wanted to verify a perf impact of that. Those were gc_heap::mark_through_cards_helper and gc_heap::set_region_gen_num. Edit: And gc_heap::get_promoted_bytes

[janvorli]

@jkotas performance and functionality tests didn't show any regressions.

[jkotas]

Have you measured it on a binary that showed the large code size reduction?

(Also, there is a merge conflict that needs to be resolved.)

[janvorli]

So on my machine, the diff when really running the NativeAOT version was 0,9%.

[jkotas]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

Alternatively, use the low-tech equivalent (e.g. https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html) that merges all .cpp files together during the build so that the C++ compiler can still see all code together.

Otherwise, we will likely end up with thousands paper cut perf regression over time.

[janvorli]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

I don't think that's possible. Static libraries are just bags of object files. Since they are not combined in any way, it seems LTO would not be able to do anything. It seems that the unity build would be the only option for this case.

[am11]

I don't think that's possible. Static libraries are just bags of object files.

Technically, it is possible. By using -flto -ffat-lto-objects during compilation, we can generate a static library archive that bundles LTO bytecode alongside standard object code (in .a file). I tested this on the main branch; as expected, it increased the size of each static library and the resulting NuGet package. However, the final linked binary size remained the same (a "Hello World" sample actually increased by a few bytes). The real dealbreaker is the toolchain dependency: shipping bytecode requires consumers to use the exact same compiler version to link successfully. For all practical purposes, that makes it a no-go for our distribution.

The CMake Unity Build approach sounds interesting.

[jkotas]

Since they are not combined in any way, it seems LTO would not be able to do anything.

You can combine the object files in a custom way to produce the library. We have started doing a few days ago to deal with libunwind symbol conflicts. The same technique may be used for LTO too #128927 (review) . This technique is compiler-toolchain specific. I do not think there is a publicly documented way to do this with MSVC. Unity build is more portable.

[janvorli]

@jkotas I've enabled unity build for the GC stuff and also changed the two functions I've mentioned above back to inline. That got rid of all the difference in the test you've shared.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 2 comments.

[janvorli]

@jkotas, @VSadov can you please review this again?

[janvorli]

/ba-g timeouts on win-64 arm are occurring on many PRs and are unrelated to this change.

[janvorli]

Move the GC sources away from the wrapper-file model that text-included gc.cpp and gcee.cpp under SERVER_GC and instead compile the shared sources directly as separate WKS and SVR objects.

This change introduces gcinternal.h as the shared compilation context for the gc.cpp split, converts the former tail-included GC implementation fragments into separately compiled translation units, and updates the GC, VM, NativeAOT, and GC sample build surfaces to consume the new object layout.

It also removes the gcsvr.cpp/gcwks.cpp and gceesvr.cpp/gceewks.cpp wrappers, compiles gcee.cpp through the same dual-build WKS/SVR source lists as gc.cpp, deduplicates the repeated WKS/SVR source lists in the relevant CMake files, and renames the shared GC header from gc_common.h to gcinternal.h to avoid confusion with gccommon.cpp.

During the split, cross-translation-unit declarations and inline helpers needed by multiple GC source files were moved into the shared header, while local-only inline helpers were moved back into their owning .cpp files to avoid keeping unnecessary bodies in the shared header.

I've made size comparison between the new clrgc.dll, clrgcexp.dll and coreclr.dll and the changes in the gc dlls were very minor, around ~1.5kB growth due to little different decisions of the linker / compiler w.r.t. cold / hot code. The coreclr even became ~1.5kB smaller.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR refactors CoreCLR GC build plumbing to stop using wrapper translation units (gcwks.cpp/gcsvr.cpp and gceewks.cpp/gceesvr.cpp) and instead compile the shared GC implementation sources directly into separate WKS/SVR object sets, using a new shared compilation-context header gcinternal.h.

Changes:

• Introduces gcinternal.h and updates many GC .cpp files to include it and wrap code in WKS/SVR namespaces based on SERVER_GC.
• Updates CoreCLR VM and standalone GC CMake build graphs to build GC sources as object libraries for WKS/SVR and consume them from coreclr/clrgc targets.
• Updates NativeAOT runtime and the GC sample project build surfaces to consume the new GC source layout.

Reviewed changes

Copilot reviewed 31 out of 33 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/coreclr/vm/wks/CMakeLists.txt	Adds GC object files into cee_wks_core build inputs.
src/coreclr/vm/CMakeLists.txt	Defines shared GC source list and builds vm_gc_wks/vm_gc_svr object libraries.
src/coreclr/dlls/mscoree/coreclr/CMakeLists.txt	Links vm_gc_wks/vm_gc_svr into coreclr and coreclr_static.
src/coreclr/nativeaot/Runtime/CMakeLists.txt	Replaces wrapper sources with direct GC .cpp compilation for NativeAOT.
src/coreclr/gc/gcinternal.h	New shared GC compilation-context header; centralizes includes and inlines.
src/coreclr/gc/*.cpp	Switches individual GC implementation files to include gcinternal.h and wrap in WKS/SVR namespaces.
src/coreclr/gc/CMakeLists.txt	Builds standalone GC (clrgc/clrgcexp) with WKS/SVR object libraries.
src/coreclr/gc/sample/*	Updates GC sample to compile split GC .cpp files directly.

[mangod9]

what is the motivation for this change? Does it improve build times?

[janvorli]

what is the motivation for this change? Does it improve build times?

It doesn't affect build time in any way. The main reason is code editing experience. The individual files into which the gc.cpp was split in my recent change didn't include the headers for symbols they use, so when editing one of those e.g. in VS code, it was showing a lot of red squiggles and code navigation didn't work well.

[jkotas]

Build breaks....

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[VSadov]

LGTM!

[MichalStrehovsky]

2% size savings on Hello World on Linux, nice!

Size statistics

Pull request #126720

Project	Size before	Size after	Difference
TodosApi-linux	24545416	24488072	-57344
TodosApi-windows	25923584	25909760	-13824
avalonia.app-linux	18912136	18887560	-24576
avalonia.app-windows	19439616	19433472	-6144
hello-linux	1246088	1221512	-24576
hello-minimal-linux	1098528	1073952	-24576
hello-minimal-windows	773632	766464	-7168
hello-windows	933376	927232	-6144
kestrel-minimal-linux	5354976	5293536	-61440
kestrel-minimal-windows	4854784	4840960	-13824
reflection-linux	1832784	1808208	-24576
reflection-windows	1696256	1689600	-6656
webapiaot-linux	9721456	9660016	-61440
webapiaot-windows	10246144	10232320	-13824
winrt-component-minimal-windows	721408	714240	-7168

[jkotas]

2% size savings on Hello World on Linux, nice!

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

This type of refactoring tends to depend on good PGO data and whole program optimizations for good perf:

• On Windows, we do not use LGCG and PGO for NAOT to avoid compiler version fragility
• On Linux, the infrastructure for collecting PGO data is broken for libcoreclr.so. It is one of the check boxes in Startup time of small workloads #120407 and there was a chat on Teams about that. We may want to frontload fixing it to avoid regressing GC perf on Linux.

[janvorli]

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

I definitely want to run the GC perf runs and understand where the size improvement comes from before we merge this.
There were two large functions that were inlined before and that I stopped marking as inlined because I felt like they were too large to make sense inlining them and wanted to verify a perf impact of that. Those were gc_heap::mark_through_cards_helper and gc_heap::set_region_gen_num. Edit: And gc_heap::get_promoted_bytes

[janvorli]

@jkotas performance and functionality tests didn't show any regressions.

[jkotas]

Have you measured it on a binary that showed the large code size reduction?

(Also, there is a merge conflict that needs to be resolved.)

[janvorli]

So on my machine, the diff when really running the NativeAOT version was 0,9%.

[jkotas]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

Alternatively, use the low-tech equivalent (e.g. https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html) that merges all .cpp files together during the build so that the C++ compiler can still see all code together.

Otherwise, we will likely end up with thousands paper cut perf regression over time.

[janvorli]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

I don't think that's possible. Static libraries are just bags of object files. Since they are not combined in any way, it seems LTO would not be able to do anything. It seems that the unity build would be the only option for this case.

[am11]

I don't think that's possible. Static libraries are just bags of object files.

Technically, it is possible. By using -flto -ffat-lto-objects during compilation, we can generate a static library archive that bundles LTO bytecode alongside standard object code (in .a file). I tested this on the main branch; as expected, it increased the size of each static library and the resulting NuGet package. However, the final linked binary size remained the same (a "Hello World" sample actually increased by a few bytes). The real dealbreaker is the toolchain dependency: shipping bytecode requires consumers to use the exact same compiler version to link successfully. For all practical purposes, that makes it a no-go for our distribution.

The CMake Unity Build approach sounds interesting.

[jkotas]

Since they are not combined in any way, it seems LTO would not be able to do anything.

You can combine the object files in a custom way to produce the library. We have started doing a few days ago to deal with libunwind symbol conflicts. The same technique may be used for LTO too #128927 (review) . This technique is compiler-toolchain specific. I do not think there is a publicly documented way to do this with MSVC. Unity build is more portable.

[janvorli]

@jkotas I've enabled unity build for the GC stuff and also changed the two functions I've mentioned above back to inline. That got rid of all the difference in the test you've shared.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 2 comments.

[janvorli]

@jkotas, @VSadov can you please review this again?

[janvorli]

/ba-g timeouts on win-64 arm are occurring on many PRs and are unrelated to this change.

[janvorli]

Move the GC sources away from the wrapper-file model that text-included gc.cpp and gcee.cpp under SERVER_GC and instead compile the shared sources directly as separate WKS and SVR objects.

This change introduces gcinternal.h as the shared compilation context for the gc.cpp split, converts the former tail-included GC implementation fragments into separately compiled translation units, and updates the GC, VM, NativeAOT, and GC sample build surfaces to consume the new object layout.

It also removes the gcsvr.cpp/gcwks.cpp and gceesvr.cpp/gceewks.cpp wrappers, compiles gcee.cpp through the same dual-build WKS/SVR source lists as gc.cpp, deduplicates the repeated WKS/SVR source lists in the relevant CMake files, and renames the shared GC header from gc_common.h to gcinternal.h to avoid confusion with gccommon.cpp.

During the split, cross-translation-unit declarations and inline helpers needed by multiple GC source files were moved into the shared header, while local-only inline helpers were moved back into their owning .cpp files to avoid keeping unnecessary bodies in the shared header.

I've made size comparison between the new clrgc.dll, clrgcexp.dll and coreclr.dll and the changes in the gc dlls were very minor, around ~1.5kB growth due to little different decisions of the linker / compiler w.r.t. cold / hot code. The coreclr even became ~1.5kB smaller.

[dotnet-policy-service]

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

[Copilot]

Pull request overview

This PR refactors CoreCLR GC build plumbing to stop using wrapper translation units (gcwks.cpp/gcsvr.cpp and gceewks.cpp/gceesvr.cpp) and instead compile the shared GC implementation sources directly into separate WKS/SVR object sets, using a new shared compilation-context header gcinternal.h.

Changes:

• Introduces gcinternal.h and updates many GC .cpp files to include it and wrap code in WKS/SVR namespaces based on SERVER_GC.
• Updates CoreCLR VM and standalone GC CMake build graphs to build GC sources as object libraries for WKS/SVR and consume them from coreclr/clrgc targets.
• Updates NativeAOT runtime and the GC sample project build surfaces to consume the new GC source layout.

Reviewed changes

Copilot reviewed 31 out of 33 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/coreclr/vm/wks/CMakeLists.txt	Adds GC object files into cee_wks_core build inputs.
src/coreclr/vm/CMakeLists.txt	Defines shared GC source list and builds vm_gc_wks/vm_gc_svr object libraries.
src/coreclr/dlls/mscoree/coreclr/CMakeLists.txt	Links vm_gc_wks/vm_gc_svr into coreclr and coreclr_static.
src/coreclr/nativeaot/Runtime/CMakeLists.txt	Replaces wrapper sources with direct GC .cpp compilation for NativeAOT.
src/coreclr/gc/gcinternal.h	New shared GC compilation-context header; centralizes includes and inlines.
src/coreclr/gc/*.cpp	Switches individual GC implementation files to include gcinternal.h and wrap in WKS/SVR namespaces.
src/coreclr/gc/CMakeLists.txt	Builds standalone GC (clrgc/clrgcexp) with WKS/SVR object libraries.
src/coreclr/gc/sample/*	Updates GC sample to compile split GC .cpp files directly.

[mangod9]

what is the motivation for this change? Does it improve build times?

[janvorli]

what is the motivation for this change? Does it improve build times?

It doesn't affect build time in any way. The main reason is code editing experience. The individual files into which the gc.cpp was split in my recent change didn't include the headers for symbols they use, so when editing one of those e.g. in VS code, it was showing a lot of red squiggles and code navigation didn't work well.

[jkotas]

Build breaks....

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 31 out of 33 changed files in this pull request and generated 1 comment.

[VSadov]

LGTM!

[MichalStrehovsky]

2% size savings on Hello World on Linux, nice!

Size statistics

Pull request #126720

Project	Size before	Size after	Difference
TodosApi-linux	24545416	24488072	-57344
TodosApi-windows	25923584	25909760	-13824
avalonia.app-linux	18912136	18887560	-24576
avalonia.app-windows	19439616	19433472	-6144
hello-linux	1246088	1221512	-24576
hello-minimal-linux	1098528	1073952	-24576
hello-minimal-windows	773632	766464	-7168
hello-windows	933376	927232	-6144
kestrel-minimal-linux	5354976	5293536	-61440
kestrel-minimal-windows	4854784	4840960	-13824
reflection-linux	1832784	1808208	-24576
reflection-windows	1696256	1689600	-6656
webapiaot-linux	9721456	9660016	-61440
webapiaot-windows	10246144	10232320	-13824
winrt-component-minimal-windows	721408	714240	-7168

[jkotas]

2% size savings on Hello World on Linux, nice!

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

This type of refactoring tends to depend on good PGO data and whole program optimizations for good perf:

• On Windows, we do not use LGCG and PGO for NAOT to avoid compiler version fragility
• On Linux, the infrastructure for collecting PGO data is broken for libcoreclr.so. It is one of the check boxes in Startup time of small workloads #120407 and there was a chat on Teams about that. We may want to frontload fixing it to avoid regressing GC perf on Linux.

[janvorli]

Do we understand why this makes the code smaller? It is likely making it both smaller and slower (less inlining) ... not something we necessarily want for the GC. It may be a good idea to measure the impact on GC throughput, on both Windows and Linux.

I definitely want to run the GC perf runs and understand where the size improvement comes from before we merge this.
There were two large functions that were inlined before and that I stopped marking as inlined because I felt like they were too large to make sense inlining them and wanted to verify a perf impact of that. Those were gc_heap::mark_through_cards_helper and gc_heap::set_region_gen_num. Edit: And gc_heap::get_promoted_bytes

[janvorli]

@jkotas performance and functionality tests didn't show any regressions.

[jkotas]

Have you measured it on a binary that showed the large code size reduction?

(Also, there is a merge conflict that needs to be resolved.)

[janvorli]

So on my machine, the diff when really running the NativeAOT version was 0,9%.

[jkotas]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

Alternatively, use the low-tech equivalent (e.g. https://cmake.org/cmake/help/latest/prop_tgt/UNITY_BUILD.html) that merges all .cpp files together during the build so that the C++ compiler can still see all code together.

Otherwise, we will likely end up with thousands paper cut perf regression over time.

[janvorli]

It would be best to figure out how to enable lto for the code in static libraries that we ship by applying the lto when we produce the static library.

I don't think that's possible. Static libraries are just bags of object files. Since they are not combined in any way, it seems LTO would not be able to do anything. It seems that the unity build would be the only option for this case.

[am11]

I don't think that's possible. Static libraries are just bags of object files.

Technically, it is possible. By using -flto -ffat-lto-objects during compilation, we can generate a static library archive that bundles LTO bytecode alongside standard object code (in .a file). I tested this on the main branch; as expected, it increased the size of each static library and the resulting NuGet package. However, the final linked binary size remained the same (a "Hello World" sample actually increased by a few bytes). The real dealbreaker is the toolchain dependency: shipping bytecode requires consumers to use the exact same compiler version to link successfully. For all practical purposes, that makes it a no-go for our distribution.

The CMake Unity Build approach sounds interesting.

[jkotas]

Since they are not combined in any way, it seems LTO would not be able to do anything.

You can combine the object files in a custom way to produce the library. We have started doing a few days ago to deal with libunwind symbol conflicts. The same technique may be used for LTO too #128927 (review) . This technique is compiler-toolchain specific. I do not think there is a publicly documented way to do this with MSVC. Unity build is more portable.

[janvorli]

@jkotas I've enabled unity build for the GC stuff and also changed the two functions I've mentioned above back to inline. That got rid of all the difference in the test you've shared.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 32 out of 34 changed files in this pull request and generated 2 comments.

[janvorli]

@jkotas, @VSadov can you please review this again?

[janvorli]

/ba-g timeouts on win-64 arm are occurring on many PRs and are unrelated to this change.