Why ReadOnlyMemory<T> is not passed by in modifier?

[unsafePtr]

According to this answer it's advised to use in for readonly structs if it's more than the size of IntPtr.

As well as here https://devblogs.microsoft.com/premier-developer/the-in-modifier-and-the-readonly-structs-in-c/

If the size of a readonly struct is bigger than IntPtr.Size you should pass it as an in-parameter for performance reasons.

ReadOnlyMemory<T> is 16 bytes — an object reference (8 bytes) + two integer fields (8 bytes) — which is larger than IntPtr on x64. Yet it's never passed with in anywhere in the runtime.

Does JIT has a speacial treatment for Guid, ReadOnlyMemory, decimal structs?

BenchmarkDotNet v0.15.8, Windows 11 (10.0.26200.8037/25H2/2025Update/HudsonValley2)
13th Gen Intel Core i7-13700KF 3.40GHz, 1 CPU, 24 logical and 16 physical cores
.NET SDK 10.0.200-preview.0.26103.119
  [Host]     : .NET 10.0.4 (10.0.4, 10.0.426.12010), X64 RyuJIT x86-64-v3
  DefaultJob : .NET 10.0.4 (10.0.4, 10.0.426.12010), X64 RyuJIT x86-64-v3

Method	Categories	N	Mean	Ratio	Allocated	Alloc Ratio
RomDeepChain_ByValue	RomDeepChain	1000	3.538 ns	1.00	-	NA
RomDeepChain_ByIn	RomDeepChain	1000	3.207 ns	0.91	-	NA
RomLoopCompare_ByValue	RomLoopCompare	1000	5,879.746 ns	1.05	-	NA
RomLoopCompare_ByIn	RomLoopCompare	1000	5,907.967 ns	1.06	-	NA
RomSingleCall_ByValue	RomSingleCall	1000	5.243 ns	1.00	-	NA
RomSingleCall_ByIn	RomSingleCall	1000	4.389 ns	0.84	-	NA

[unsafePtr]

Here is is the only two places where ReadOnlyMemory is passed by in
https://github.com/search?q=repo%3Adotnet%2Fruntime+%22in+ReadOnlyMemory%22&type=code

[huoyaoyuan]

According to this answer it's advised to use in for readonly structs if it's more than the size of IntPtr.

As well as here https://devblogs.microsoft.com/premier-developer/the-in-modifier-and-the-readonly-structs-in-c/

If the size of a readonly struct is bigger than IntPtr.Size you should pass it as an in-parameter for performance reasons.

The statement and answers are incorrect. The latest version of the referenced documentation has removed the statement.
Passing the same unmodified struct in deep calls is not a common scenario. Memory<T> is usually constructed as a intermediate structure.

Moreover, passing by in has significant risk for atomicity. It's also unfriendly for struct decomposition.

Does JIT has a speacial treatment for Guid, ReadOnlyMemory, decimal structs?

No. They should NOT be passed by in for usual cases.

[unsafePtr]

@huoyaoyuan Thank you for the response. A couple of follow-ups:

1. Atomicity ReadOnlyMemory<T> is a readonly struct — its fields are immutable after construction. The only way the value changes is if the caller reassigns the variable itself, but that's a race on the variable, not the struct contents. What specific atomicity scenario does in introduce that by-value avoids for a readonly struct? Even for a single method call there is a benefit. And if it's a readonly struct, seems to me there is no way it can be modified, unless it's a field/property.
2. Can the JIT actually decompose readonly structs, like ReadOnlyMemory<T> in practice?
3. The old docs said "if bigger than IntPtr.Size, use in." You mention it was removed — was it removed because it was wrong, or because it was too nuanced? In that case what's the new guidence for using in? Since the link you've shared is breifly touching in.

[huoyaoyuan]

The only way the value changes is if the caller reassigns the variable itself, but that's a race on the variable, not the struct contents. What specific atomicity scenario does in introduce that by-value avoids for a readonly struct?

When the source location is a field, not local variable. Consider the following:

class Container
{
    public ReadOnlyMemory<byte> memory;
}

void Thread1(Container c)
{
    c.memory = GetNewMemory();
}

void Thread2(Container c)
{
    Process(in c.memory); // Can read teared value in Process
}

void Thread3(Container c)
{
    Process2(c.memory); // Only the caller need to worry about atomicity, not the callee
}

The race on the full struct is a strong consideration.

Can the JIT actually decompose readonly structs, like ReadOnlyMemory<T> in practice?

Yes and not limited to readonly struct, especially when the called method is inlined.

The old docs said "if bigger than IntPtr.Size, use in." You mention it was removed — was it removed because it was wrong, or because it was too nuanced? In that case what's the new guidence for using in? Since the link you've shared is breifly touching in.

I don't think there is a simple guidance instead of complex consideration, but IntPtr.Size is definitely a too small threshold. Even guidance from 20 years ago uses 16 bytes as the threshold.

[tannergooding]

Atomicity ReadOnlyMemory is a readonly struct — its fields are immutable after construction. The only way the value changes is if the caller reassigns the variable itself, but that's a race on the variable, not the struct contents. What specific atomicity scenario does in introduce that by-value avoids for a readonly struct? Even for a single method call there is a benefit. And if it's a readonly struct, seems to me there is no way it can be modified, unless it's a field/property.

readonly does not mean immutable, consider the following trivial and safe example:

MyStruct tmp = new MyStruct(1);
tmp.M(ref tmp);

readonly struct MyStruct
{
    private readonly int _x;

    public MyStruct(int x)
    {
        _x = x;
    }

    public void M(ref MyStruct m)
    {
        Console.WriteLine(_x);
        m = new MyStruct(2);
        Console.WriteLine(_x);
    }
}

Which is to say, readonly only means "this particular view cannot be written". Other views may exist and some of those views may be writeable. This is also how readonly works for spans, files, general memory pages, etc. It's effectively how all computers have always used "readonly". It's also how const works in C++.

The old docs said "if bigger than IntPtr.Size, use in." You mention it was removed — was it removed because it was wrong, or because it was too nuanced? In that case what's the new guidence for using in? Since the link you've shared is breifly touching in.

There's a lot of nuance and in general it can depend on the platform and other considerations. Generally the "base" guidance is that if its more than 2 * sizeof(void*) then it cannot be passed in register and so must be passed by shadow copy instead. But even that has nuance and is dependent on OS+architecture (which define an ABI, or Application Binary Interface). In some cases values up to 64 bytes can be passed in register, but that's an extreme case. In some cases values as small as 3 bytes won't be passed in register, but that's also an extreme case.

The general recommendation is to not make structs larger than 16-24 bytes in the first place and to not pass them around using in unless you really know what you're doing. This should particularly be avoided in public surface area if possible.

[unsafePtr]

Would it be correct to assume that if I copy on stack before submitting to method with in is a correct way to avoid problems, unless it's readonly? Does the below example will apply to ReadOnlyMemory, or it's more nuanced?

public class Example
{
    public decimal Field1;
    public readonly decimal Field2;

    public void A()
    {
        B(Field1); // potential problem if another thread will modify Field1 in between

        // correct way?
        var local = Field1; // copy on stack
        B(local); // now safe since it's copied on stack and there is no way there is another thread


        // when it's readonly it's safe
        B(Field2);
    }

    private void B(in decimal value)
    {
        // do something with value
    }
}

[tannergooding]

What is correct or not entirely depends on your code and other considerations.

Passing a copy of the value is exactly how normal value semantics work, so is one of the many reasons why you should likely just do void B(decimal value) instead and not use in at all, since then it can at least be properly optimized for the runtime in question and not be presumed to be address exposed (which can limit optimizations).

In general you should not be using in for most code, especially not primitive structs that are exposed by the core libraries.