[Wasm][AOT] Methods containing a try/catch block are 30x slower because of the interpreter

[jeromelaban]

Description

Methods containing a try/catch/finally are 30x slower in recent builds because they are now run through the interpreter.

For example:

private static void TestTryCatch()
{
	int InvokeMethod(int a)
	{
		try
		{
			return a++;
		}
		catch
		{
			Console.WriteLine("catch");
			return 0;
		}
	}

	var sw = Stopwatch.StartNew();
	for (int i = 0; i < 10000000; i++)
	{
		InvokeMethod(i);
	}
	sw.Stop();
	Console.WriteLine($"TestTryCatch: {sw.ElapsedMilliseconds}");
}

Runs in 45ms with df6e956, and 1140ms with e983168

Here's a profiler trace screenshot:

Configuration

Working commit: df6e956
Failing commit: e983168 (it probably started doing this before this commit)

Regression?

Yes

Other information

[dotnet-issue-labeler]

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

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Methods containing a try/catch/finally are 30x slower in recent builds because they are now run through the interpreter.

For example:

private static void TestTryCatch()
{
	int InvokeMethod(int a)
	{
		try
		{
			return a++;
		}
		catch
		{
			Console.WriteLine("catch");
			return 0;
		}
	}

	var sw = Stopwatch.StartNew();
	for (int i = 0; i < 10000000; i++)
	{
		InvokeMethod(i);
	}
	sw.Stop();
	Console.WriteLine($"TestTryCatch: {sw.ElapsedMilliseconds}");
}

Runs in 45ms with df6e956, and 1140ms with e983168

Here's a profiler trace screenshot:

Configuration

Working commit: df6e956
Failing commit: e983168 (it probably started doing this before this commit)

Regression?

Yes

Other information

Author:	jeromelaban
Assignees:	-
Labels:	arch-wasm, area-Codegen-AOT-mono, untriaged
Milestone:	-

[jeromelaban]

Related to #53815 and #52883

[jeromelaban]

Applying this patch to the runtime reverts original behavior, knowing that the original exception handling scenario will be a problem.

[roonius]

@jeromelaban , when exactly was this change introduced? What is the max version before this change? Thanks.

[jeromelaban]

@roonius there is no stable version of the runtime that does not have this change. Each interim build had a different set of issues, and removing the interpreter restriction causes failures when handling exceptions, which is why the restriction is present in Uno.Wasm.Bootstrap builds of the runtime.

[vargaz]

With this PR: #63065
methods which contain only finally/fault clauses (foreach, iterators, etc.) will be AOTed.

[vargaz]

This is fixed now.