Implement Array.Initialize in C#

[reflectronic]

Implements Array.Initialize for Mono, moves most of the implementation to managed code for CoreCLR, and adds a test.

For those using C++/CLI, your arrays shall now be initialized marginally faster:

Method	Job	Toolchain	Mean	Error	StdDev	Ratio	RatioSD
Array_Initialize	Job-LCNDMK	\runtime-main	702.9 ns	5.08 ns	4.75 ns	5.79	0.05
Array_Initialize	Job-BDKEGA	\runtime	121.5 ns	0.79 ns	0.74 ns	1.00	0.00

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[danmoseley]

Are changes needed in Mono?

[jkotas]

You will need to do something about the failing tests ... Array.Initialize is implemented on CoreCLR only currently.

[vargaz]

The mono changes look ok.

[reflectronic]

Test failures were caused by a System.Reflection.MetadataLoadContext test that scans all methods on an array type. Since a local variable of function pointer type was added to a method on System.Array, MLC would fail when decoding this local variable. Fortunately, the fix is pretty trivial, since we have a convenient place to move that to.

[jkotas]

@dotnet/ilc-contrib Should Array.Initialize be marked with RequiresUnreferenceCode, or is the value type default constructor the special-cased by the trimmer and always preserved?

[vitek-karas]

I think it should:

var b = new ElementType[1];
b.Initialize();

struct ElementType
{
    public ElementType()
    {
        Console.WriteLine(".ctor called");
    }
}

dotnet run prints out ".ctor called".
But trimmed the app doesn't print out anything.

Related question - what should default do in this case, for example:

var c = new ElementType[1];
c[0] = default; // Should this call the default .ctor?

Running it seems like it will NOT call the .ctor - but what does it do?

[vitek-karas]

Same goes for AOT - published as Native AOT the app above also doesn't print out anything.

[teo-tsirpanis]

Related question - what should default do in this case, for example:

According to the specification, default ignores the parameterless constructor and generates a zeroed instance.

[jkotas]

Hmmm, adding RequiresUnreferencedCode on Array.Initialize has a ripple effect. It introduces warnings in situations where array type is passed into DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.All).

I guess it will need more careful thought.

[jkotas]

Opened #77426

[jkotas]

LGTM modulo comments. Thank you! Another 100 lines of manually managed C++ bite the dust.

[lambdageek]

@reflectronic Are you up for implementing the mono version mostly in C#, too?

I think we can add something like NativeAOT's default constructor -> function pointer icall and then most of this code could be managed.

We don't need to do it in this PR (unless you want to). Just an idea.

[reflectronic]

I would have done it like that, but I couldn't quite find the function I wanted (wasn't sure if the thing I was looking at was safe to just call with calli, whether it would try to unbox the argument, etc.). Certainly, I could address it in a follow up.

[lambdageek]

@reflectronic I don't think there's an existing icall, but it should be ok to add something like this:

MonoMethod * const method = mono_class_get_method_from_name_checked (element_class, ".ctor", 0, 0, error);
if (!method) {
	return NULL;
}
gpointer addr = mono_compile_method_checked (method, error);
if (!is_ok (error)) {
	mono_error_cleanup (error);
	return NULL;
}
return mono_create_ftnptr(addr);

on the C# side it would look pretty much like the NativeAOT version - cast the icall's IntPtr result to a function pointer type and call it.

wasn't sure if the thing I was looking at was safe to just call with calli, whether it would try to unbox the argument, etc.

I'm pretty certain that it will just work. I believe it should be expecting an unboxed argument.

[jkotas]

The failure is known nuget infrastructure issue

[reflectronic]

Thanks for the reviews and feedback