Why does Marshal.SizeOf<T>() require non-generic types, but Marshal.SizeOf<T>(T) doesn't?

[colejohnson66]

I wanted to use Marshal.SizeOf<T>() to get the size of an object, but it apparently throws an ArgumentException (undocumented if I may add) if T is a generic type:

runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/Marshal.cs

Lines 122 to 131 in 0d8fadd

	public static int SizeOf<T>()
	{
	RuntimeType t = (RuntimeType)typeof(T);
	if (t.IsGenericType)
	{
	throw new ArgumentException(SR.Argument_NeedNonGenericType, nameof(T));
	}
	return SizeOfHelper(t, throwIfNotMarshalable: true);
	}

However, curiously, the overload that takes an object of type T (Marshal.SizeOf<T>(T)) doesn't throw for generic types:

runtime/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/Marshal.cs

Lines 97 to 102 in 0d8fadd

	public static int SizeOf<T>(T structure)
	{
	ArgumentNullException.ThrowIfNull(structure);
	return SizeOfHelper((RuntimeType)structure.GetType(), throwIfNotMarshalable: true);
	}

A simple example using nullable value types (Nullable<T>):

using System;
using System.Runtime.InteropServices;

Console.WriteLine(Marshal.SizeOf<int?>());     // throws `ArgumentException`
Console.WriteLine(Marhsal.SizeOf<int?>(42));   // prints "4" (not "8" as `sizeof(int?)` would, but ignore that)
Console.WriteLine(Marshal.SizeOf<int?>(new()); // ditto

Is there a reason for this restriction?

[tannergooding]

Marshal.SizeOf<T>() is intended to get the size of the object after it's been marshalled and so is effectively the number of bytes that native sees.

sizeof(T) (and Unsafe.SizeOf<T>() is the size of the object in managed, which will match the size for blittable types.

Historically, generics were not supported in marshalling and so could not be passed across the P/Invoke boundary, this was changed around .NET Core 3.1, but many of the Marshal APIs were not updated to account for that as the built-in marshalling was already being considered "legacy" and was being looked at getting replaced (see https://learn.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.disableruntimemarshallingattribute, https://learn.microsoft.com/en-us/dotnet/standard/native-interop/pinvoke-source-generation, etc)

Nullable<T> is additionally a special type and doesn't always behave like a normal generic, has specialized type system support/handling, and doesn't have a clear 1-to-1 with any native types. It is explicitly blocked from use in marshalling scenarios and so is not supported:

runtime/src/coreclr/vm/mlinfo.cpp

Lines 1084 to 1101 in 04afbf7

	// Generics (blittable when built-in is enabled) are allowed to be marshalled with the following exceptions:
	// * Nullable<T>: We don't want to be locked into the default behavior as we may want special handling later
	// * Span<T>: Not supported by built-in marshalling
	// * ReadOnlySpan<T>: Not supported by built-in marshalling
	// * Vector64<T>: Represents the __m64 ABI primitive which requires currently unimplemented handling
	// * Vector128<T>: Represents the __m128 ABI primitive which requires currently unimplemented handling
	// * Vector256<T>: Represents the __m256 ABI primitive which requires currently unimplemented handling
	// * Vector512<T>: Represents the __m512 ABI primitive which requires currently unimplemented handling
	// * Vector<T>: Has a variable size (either __m128 or __m256) and isn't readily usable for interop scenarios
	return !pMT->HasSameTypeDefAs(g_pNullableClass)
	&& !pMT->HasSameTypeDefAs(CoreLibBinder::GetClass(CLASS__SPAN))
	&& !pMT->HasSameTypeDefAs(CoreLibBinder::GetClass(CLASS__READONLY_SPAN))
	&& !pMT->HasSameTypeDefAs(CoreLibBinder::GetClass(CLASS__VECTOR64T))
	&& !pMT->HasSameTypeDefAs(CoreLibBinder::GetClass(CLASS__VECTOR128T))
	&& !pMT->HasSameTypeDefAs(CoreLibBinder::GetClass(CLASS__VECTOR256T))
	&& !pMT->HasSameTypeDefAs(CoreLibBinder::GetClass(CLASS__VECTOR512T))
	&& !pMT->HasSameTypeDefAs(CoreLibBinder::GetClass(CLASS__VECTORT));
	}

CC. @AaronRobinsonMSFT, @jkoritzinsky who may be able to provide additional context/info

[AaronRobinsonMSFT]

I don't have much to add to @tannergooding's comprehensive response above. As mentioned the Marshal.SizeOf<T>() series of APIs don't really do what most people want them to do and if they really do need them they are expensive in general and not the best way to address interop scenarios.

I wanted to use Marshal.SizeOf() to get the size of an object

I would look at #24200 for more details. The interop scenario is complicated for instances of type object and that is what the Marshal APIs are for, interop. That means that size queries on arbitrary objects are not what is expected. For scenarios involving allocation schemes of managed objects the above issue is a more appropriate place to look for guidance and where we are likely to invest.

[colejohnson66]

So the answer is that the limitation is just a historical accident, not necessarily a valid one?

[huoyaoyuan]

I'm not sure about the limitation, but Marshal.SizeOf isn't the size of the object. It's the size of native counterpart under effective marshaling rule. Use Unsafe.SizeOf or sizeof operator for managed object size.