Mono.Android.dll IL Size increase in .NET 7 Preview 7 & RC 1

[jonathanpeppers]

Version Used:

Happens in both:

• .NET 7.0.100-rc.1.22368.2 SDK
• .NET 7.0.100-preview.7.22370.3 SDK

Noticed this here: dotnet/android#7170

Steps to Reproduce:

1. Build xamarin-android
2. Observe the size of Mono.Android.dll. This is a C# "binding" of every Android API.

34502656 Mono.Android.net7.rc1.dll
32999936 Mono.Android.xa.main.dll

When I rain monodis --typedef, I noticed a bunch of new types generated, such as:

[CompilerGenerated]
private static class <>O
{
	public static _JniMarshal_PP_L <0>__n_Sink;

	public static _JniMarshal_PP_L <1>__n_Source;
}

I tried to use ILSpy to understand how these are used:

private static Delegate GetSinkHandler()
{
	if ((object)cb_sink == null)
	{
		cb_sink = JNINativeWrapper.CreateDelegate(new _JniMarshal_PP_L(n_Sink));
	}
	return cb_sink;
}

In this case, the above method is called once and would only allocate a _JniMarshal_PP_L once. Are we paying extra file size for something that will only be called once?

Is there some flag to turn off this feature? (at least for this assembly) Thanks!

Here is before & after, and the monodis output: Mono.Android.zip

Expected Behavior:

Updating the .NET SDK, shouldn't increase the size of Mono.Android.dll noticeably.

Actual Behavior:

Updating the .NET SDK, increases the size of Mono.Android.dll.

[Youssef1313]

This is possibly #58288, which implements #5835, which is a C# 11 feature.

[Youssef1313]

I can imagine we can get rid of the generated <>O private classes and emit the fields in the original class. This should reduce the size of the generated code.

[jonathanpeppers]

I think we might be setting LangVersion=preview in this project, let me check what the value is.

[jonathanpeppers]

@Youssef1313 yes, looks like we are setting LangVersion=latest repo-wide. I think LangVersion=10, will workaround for this one project for now.

The pattern I see above is common for Android "Java binding" projects. Is there a way to turn off this one language feature, and still use C# 11+?

I could see this being a problem for other Java libraries we bind, like AndroidX or Google Play Services -- or customers' own binding projects.

[Youssef1313]

I don't believe there is currently a way to disable specific features. I think first thing to consider is improving the generated code to be smaller, then check if the size is still problematic or not.

[jonathanpeppers]

I didn't particularly see anything in the above <>O class that could be smaller. Maybe there is?

The problem with the Mono.Android.dll assembly above is the amount of code inside -- it's literally every API from Android. In a 30+ MB assembly, we tend to notice every small change.

[jcouv]

FYI @AlekseyTs as feature champion for "Use a cached delegate for method group conversion" and FYI @jaredpar for ecosystem impact. Closing as by-design

[jonathanpeppers]

Yeah my main concern here was:

In this case, the above method is called once and would only allocate a _JniMarshal_PP_L once. Are we paying extra file size for something that will only be called once?

Is there a way to detect this case?

It doesn't sound great, but I guess we can keep Mono.Android.dll on C# 10 indefinitely?

[marek-safar]

I guess you could also rewrite your C# generator not to use method group conversion and control it that way.

[jaredpar]

It doesn't sound great, but I guess we can keep Mono.Android.dll on C# 10 indefinitely?

If you don't want implicit method group caching then you can use an explicit delegate allocation.

Action a1 = Method; // implicit conversion, subject to caching 
Action a2 = new Action(Method); // explicit allocation, never cached