Wasm: dont `RhpAssignRef` static fields

dotnet / corert

This repo contains CoreRT, an experimental .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying compiler toolchain.

http://dot.net

MIT License

2.91k stars 510 forks source link

Wasm: dont `RhpAssignRef` static fields #8352

Closed yowl closed 3 years ago

yowl commented 3 years ago

This PR changes the implementation of stsfld so that RhpAssignRef is not called when storing a gc pointer in a static field. For example, previous to this change, https://github.com/dotnet/corert/blob/145402e00724acbc9e7636739140fb84f7d64845/src/System.Private.CoreLib/shared/System/AttributeUsageAttribute.cs#L23 resulted in a call to RhpAssignRef in the cctor.

jkotas commented 3 years ago

RyuJIT codegen stores GC reference statics on the GC heap. Is wasm codegen using a different scheme?

Suchiman commented 3 years ago

@jkotas RhpAssignRef sets the card table bits which are used for incremental marking during ephemeral GCs, is my assumption wrong that this only applies to references stored into the bounds of UOH / Gen2 and not statics (which i've assumed to be always marked completely)?

jkotas commented 3 years ago

Both CoreCLR and CoreRT (w/ RyuJIT codegen at least) store statics in fake objects allocated on GC heap. It means that write barriers are needed for updates.

It is a trade-off:

Storing statics on GC heap scales better for large programs with a lot of statics. The background marking will kick in for them nicely, and Gen0 GC will scan only the ones that were written to recently.
Storing statics in non-GC heap memory and always scanning them works fine for small programs or for micro-benchmarks that were ported from C where it is common for everything to be stored in statics. Avoiding the write barriers makes them run faster.

yowl commented 3 years ago

My bad assumption, closing.