Commit 0a9d164
[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 3711992.
* 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.1 parent a102708 commit 0a9d164
1 file changed
+1
-0
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
437 | 437 | | |
438 | 438 | | |
439 | 439 | | |
| 440 | + | |
440 | 441 | | |
441 | 442 | | |
442 | 443 | | |
| |||
0 commit comments