Jettison vxsort support in the GC when optimizing for size #85036
Conversation
Vxsort comes with precomputed tables that are more than 100 kB in size. Jettison them when optimizing for size. Hello world with optimize for size + invariant globalization is now 1.08 MB. Fixes dotnet#84749.
ghost
assigned 
|
Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas Issue DetailsVxsort comes with precomputed tables that are more than 100 kB in size. Jettison them when optimizing for size. Selfcontained hello world with optimize for size + invariant globalization is now 1.08 MB (a 10% saving). Fixes #84749. Cc @dotnet/ilc-contrib @dotnet/gc
|
| @@ -22,6 +22,8 @@ The .NET Foundation licenses this file to you under the MIT license. | |||
| <FullRuntimeName Condition="'$(ServerGarbageCollection)' == 'true' or '$(ControlFlowGuard)' == 'Guard'">Runtime.ServerGC</FullRuntimeName> | |||
| <BootstrapperName>bootstrapper</BootstrapperName> | |||
| <BootstrapperName Condition="'$(NativeLib)' != '' or '$(CustomNativeMain)' == 'true'">bootstrapperdll</BootstrapperName> | |||
| <VxSortSupportName>Runtime.VxsortSupport</VxSortSupportName> | |||
There was a problem hiding this comment.
We use -enabled / -disabled suffixes for eventpipe a few lines down. Can we use the similar pattern here?
|
Build breaks on arm64 |
|
"in the GC" in general or only when it's compiled for WKS GC? how does one get these disabled by default things enabled in NativeAoT? is there a page that explains that? |
In general, both server and wks GC. Note that will be done only when the user says they're willing to trade throughput for size (i.e. it will require a gesture from the user that spells out optimization preference is size). Disabled VXSORT will not be the default.
There will be a doc page on the optimization preference setting, but it will probably not document the exact mechanism. It will only say we'll do whatever's reasonable to get size down at the cost of throughput. E.g. we align method bodies differently with this setting as well. |
|
Instead of just turning it off, can we build the table at runtime (maybe after startup, outside of GC pause) instead? |
IIRC, the vxsort static footprint is dominated by code. The supporting data tables are relatively small. |
|
If I need a server GC, since I expect lots of concurrency and some short-lived allocations, but overall do not expect an enormous heap, then I can pass It looks so from the change, but a bit hard to follow, - the 100 kB of vxsort stuff will not even be linked into the app, right? |
This change doesn't depend on whether we're building with server/workstation GC. That approach was rejected based on discussion in #84749. We key off of two things: are we optimizing for size? (the (planned to be) publicly documented switch), or someone specified Then there's a bunch of extra conditions because vxsort only works on x64 Windows and bifurcating the build further based on whether control flow guard is enabled on not didn't seem worth it so we don't disable it if control flow guard is enabled. |
Vxsort comes with precomputed tables that are more than 100 kB in size.
Jettison them when optimizing for size. Selfcontained hello world with optimize for size + invariant globalization is now 1.08 MB (a 10% saving).
Fixes #84749.
Cc @dotnet/ilc-contrib @dotnet/gc