From 0a9d16417060fc1ae89b2f797c8811a2e81ab7e3 Mon Sep 17 00:00:00 2001
From: Radek Doulik <radekdoulik@users.noreply.github.com>
Date: Fri, 2 Feb 2018 17:13:11 +0100
Subject: [PATCH] [Xamarin.Android.Build.Tasks] aot is a valid profiler (#1253)

Mono supports an [AOT profiler][aotp]: when enabled, mono will
generate a file containing the methods that were encountered while
the AOT profiler is enabled, usually during the lifetime of the
process. AOT profiler output can then be fed into the AOT compiler,
allowing *selective AOT of assemblies*: instead of AOT'ing
*everything*, only the specified methods would be AOT'd. This would
hopefully allow for smaller `.apk` files containing AOT output.

[aotp]: https://github.com/mono/mono/blob/4a995045915dbe45918787d158485dda26660e05/man/mono-profilers.1#L325-L330

The question: How do we make use of this functionality?

We don't have an answer. We need to start *experimenting* to
determine an answer.

To help support that experimentation, set things up so that the AOT
profiler can be used:

  * *Build* and package the AOT profiler, contained within the
    `libmono-profiler-aot.so` native library. This was done in
    commit 37119924.
  * Allow the `.apk` to contain `libmono-profiler-aot.so`.
  * Profile the application.
  * Grab the profiler output.

Allow the `$(AndroidEmbedProfilers)` MSBuild property to use the
value `aot` so that the `libmono-profiler-aot.so` profiling library
will be embedded into the `.apk` file:

	msbuild /p:AndroidEmbedProfilers=aot TheApp.csproj /t:SignAndroidPackage

Once the `.apk` contains `libmono-profiler-aot.so`, then the profiler
can be used by setting the `debug.mono.profile` system property:

	adb shell setprop debug.mono.profile aot

When the application is next launched, the AOT profiler will be used.

If (see below) AOT output is produced, it can be extracted from the
device by using the `adb pull` command.

There are four known issues:

 1. The *filename* of the produced file, which changes in PR #1254.
 2. The *path* of the produced file, which will be in the
    `.__override__` directory. See also [DevelopmentTips.md][update].
 3. AOT profiler output isn't constantly written to. To ensure that
    *all* AOT profiler output is written to the output file, the
    process must currently exit. This can be done by calling
    `Environment.Exit()` at some point within the application.
 4. `Java.Interop` doesn't support cleanly shutting down.

[update]: https://github.com/xamarin/xamarin-android/blob/a10270849983aafc1d137520183b499747174e88/Documentation/DevelopmentTips.md#update-directory

Specifically, if you *do* call `Environment.Exit()`, process exit
is not cleanly performed:

	[ERROR] FATAL UNHANDLED EXCEPTION: System.ObjectDisposedException: Cannot access a disposed object.
	Object name: 'The ThreadLocal object has been disposed.'.
	  at System.Threading.ThreadLocal`1[T].GetValueSlow ()
	  at System.Threading.ThreadLocal`1[T].get_Value ()
	  at Java.Interop.JniEnvironment.get_CurrentInfo ()
	  at Java.Interop.JniEnvironment.get_Runtime ()
	  at Java.Interop.JniObjectReference.Dispose (Java.Interop.JniObjectReference& reference)
	  at Java.Interop.JniRuntime.Dispose (System.Boolean disposing)
	  at Java.Interop.JniRuntime.Finalize ()

As such, AOT profiling *does not work*.

However, we want to *permit enabling AOT profiling* so that we can
more easily test and get things to a working state.
---
 src/Xamarin.Android.Build.Tasks/Tasks/BuildApk.cs | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/Xamarin.Android.Build.Tasks/Tasks/BuildApk.cs b/src/Xamarin.Android.Build.Tasks/Tasks/BuildApk.cs
index 4971ffed6a7..06dd3965c9f 100644
--- a/src/Xamarin.Android.Build.Tasks/Tasks/BuildApk.cs
+++ b/src/Xamarin.Android.Build.Tasks/Tasks/BuildApk.cs
@@ -437,6 +437,7 @@ class LibInfo
 		};
 
 		public static readonly string[] ValidProfilers = new[]{
+			"aot",
 			"log",
 		};