Question: Is coreclr's use of SIMD-accelerated initobj legal for ref types T? #51638
Labels
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
memory model
issues associated with memory model
question
Answer questions and provide assistance, not an issue with source code or documentation.
Milestone
This is extracted out of a discussion whose salient points are #51534 (comment) and #51534 (comment).
In a nutshell, when the JIT sees an initobj instruction, it will attempt to perform SIMD writes to the destination address, This is true whether or not the target type contains gcrefs. See the below example for a demonstration.
In this example, references to
MyStruct
are only guaranteed 8-byte aligned, not 16-byte aligned. So it's possible that the vmovdqu instruction could straddle a cache line boundary or a page boundary. The implicit assumption here is that even if the SIMD write as a whole is not atomic, each individual native word-sized element of the vector is published atomically (since the target address is native word-aligned).Per #51534 (comment), this assumption is valid for ARM64. But per #51534 (comment), this assumption might not be valid for x86 / x64 / ARM32.
So, the larger question: is the current JIT behavior legal such that no other thread will ever see a torn write to a gcref field, or is the JIT relying on undocumented behavior? And if we're relying on a potentially invalid assumption, do we need to change our behavior?
The text was updated successfully, but these errors were encountered: