Repository navigation
Remove CORINFO_HELP_ASSIGN_BYREF ? #128227
Description
#128225 reminded me - can we delete this version of write barrier and use normal checked/unchecked? Maybe long-term even just leave the unchecked one and inline checks in JIT for the checked one?
Currently, we have 5 flavors:
CORINFO_HELP_ASSIGN_REF,
CORINFO_HELP_CHECKED_ASSIGN_REF,
CORINFO_HELP_ASSIGN_REF_ENSURE_NONHEAP, // Debug only, do we use it?
CORINFO_HELP_ASSIGN_BYREF,
CORINFO_HELP_BULK_WRITEBARRIER,
CORINFO_HELP_ASSIGN_BYREF was beneficial for large struct copies with GC fields due to custom calling convention that bumps pointer, but it's no longer that important with the introduction of CORINFO_HELP_BULK_WRITEBARRIER
Opinions @jkotas @dotnet/jit-contrib?
Activity
dotnet-policy-service commentedon May 14, 2026
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch
See info in area-owners.md if you want to be subscribed.
EgorBo commentedon May 14, 2026
Also, shouldn't JIT prefer unchecked WB here (it's in a class).
PS: if that makes sense, we can also introduce an unchecked version of the bulk barrier as well.
jkotas commentedon May 14, 2026
IIRC, it was used by JIT stress at some point. If we are not using it anymore, it is fine to delete it.
If the codediff numbers show that it is not a meaningful improvement anymore, deleting it is fine with me.
This is code bloating optimization. We may do it for very hot code. I do not think we would want to do that by default, or for AOT where these checks would have to go through indirections.
I doubt that it is worth it. The extra work in checked bulk write barrier is fairly small compared to the work that it needs to do to perform the bulk update.
EgorBo commentedon Jun 2, 2026
Removed in main now.