System.Numerics structs are incorrect sizes

[mellinoe]

Many of the structures in the System.Numerics namespace are being padded out to an incorrectly-large size in memory. Although this was likely done as a kind of performance optimization, it has widespread side effects that break many of the main use cases for the types. This behavior is also different from .NET Core and .NET Framework.

The types affected:

Type	Expected Size	Actual Size
Vector2	8	16
Vector3	12	16
Plane	16	20

Plane is probably larger because it contains a Vector3, but I've listed it anyways.

There are some test cases in corefx which ensure that these structures are the expected physical size in memory. For example

[marek-safar]

/cc @kumpera @vargaz could you please respond

[Therzok]

Seems like the types are constrained to having at least SIMD register size.

mono/mono/metadata/class.c

Lines 1988 to 1990 in 6b58f13

	/* Make SIMD types as big as a SIMD register since they can be stored into using simd stores */
	if (klass->simd_type)
	real_size = MAX (real_size, sizeof (MonoObject) + 16);

[akoeplinger]

I remembered this Bugzilla bug where @kumpera indicated this is expected: https://bugzilla.xamarin.com/show_bug.cgi?id=56602

[kumpera]

SIMD support was originally designed to support 16bytes only types.
The new types were added without considering this. It's something we could improve for Vector2 and Vector3.

[vargaz]

We can make them have a non-16 byte size, but then we can't do SIMD operations like loads/stores on them.

[mellinoe]

The size in memory of these structures is more important than individual SIMD optimizations, because there is a lot of code in the wild that works only under the assumption that these types are tightly-packed in memory. It is not a problem if the results of intermediate operations are expanded to a 16-byte form in order to better utilize SIMD operations -- this is what CoreCLR and .NET Framework do -- but the in-memory representation cannot change.

As a comparison, if this same behavior was observed in the analogous MonoGame structures, then a lot of things using them would break.

[kumpera]

@vargaz we can emit simd load/store for Vector2. Vector3 is a bit trickier since it can live at the edge of a page.

[mellinoe]

@kumpera @vargaz Is there any workaround for this at the moment? Some way to disable the optimizations / special codegen handling, for example? This is a pretty hard blocker for my projects working on mono.