-
Notifications
You must be signed in to change notification settings - Fork 533
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[XABT] Scan for JCWs for each ABI in parallel. #9215
Conversation
5bca7ef
to
c1a7daa
Compare
var generateSucceeded = true; | ||
|
||
// Generate Java sources in parallel | ||
Parallel.ForEach (allAssembliesPerArch, (kvp) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this use Mono.Cecil in parallel? We found problems using Mono.Cecil on different threads in:
- [jcw-gen] DON'T generate Java Callable Wrappers in parallel java-interop#43
- [JavaCallableWrappers] Parallel.ForEach per assembly java-interop#365
Random, weird things would happen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we are fine here. While we are using the Mono.Cecil
library in parallel, the instances running on not using the same assemblies or AssemblyResolver
.
That is, one thread is generating all JCWs for arm64
from the arm64
assemblies:
- obj\Debug\net9.0-android\android\assets\arm64-v8a\Mono.Android.dll
- obj\Debug\net9.0-android\android\assets\arm64-v8a\Mono.Android.Runtime.dll
- obj\Debug\net9.0-android\android\assets\arm64-v8a\Mono.Android.Export.dll
while another is generating all JCWs from the x86
assemblies:
- obj\Debug\net9.0-android\android\assets\x86_64\Mono.Android.dll
- obj\Debug\net9.0-android\android\assets\x86_64\Mono.Android.Runtime.dll
- obj\Debug\net9.0-android\android\assets\x86_64\Mono.Android.Export.dll
No AssemblyResolver
, AssemblyDefinition
, or TypeDefinition
instances are being accessed from more than one thread at a time.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed, we should be fine here. I designed the per-RID support so that, eventually, it can be parallelized. All the caches etc are per-arch (and if anything isn't, then it's either read-only or a bug).
@@ -220,7 +221,7 @@ static string GetMonoInitSource (string androidSdkPlatform) | |||
return builder.ToString (); | |||
} | |||
|
|||
public static void EnsureAllArchitecturesAreIdentical (TaskLoggingHelper logger, Dictionary<AndroidTargetArch, NativeCodeGenState> javaStubStates) | |||
public static void EnsureAllArchitecturesAreIdentical (TaskLoggingHelper logger, ConcurrentDictionary<AndroidTargetArch, NativeCodeGenState> javaStubStates) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you test performance with a lock
instead of using ConcurrentDictionary
? A monitor might perform better than any concurrent collection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did not. We only store a maximum of 4 items in the Dictionary
, so I'm not sure any operations on it will be measurable.
We have a unit test failure; not sure if it's related to this PR:
I've restarted the tests. |
* main: (47 commits) Bump to dotnet/sdk@5642787dac 9.0.100-rc.2.24426.2 (#9247) LEGO: Merge pull request 9246 Bump to 34.0.137 of the .NET 8 Android workload (#9243) Bump external/Java.Interop from `d30d554` to `51b784a` (#9241) Bump dotnet/android-tools@6575743 (#9235) Bump to mono/debugger-libs@d5664344 (#9238) [ci] Improve push_signed_nugets job condition (#9240) Bump to dotnet/android-tools@657574378a6 and xamarin/monodroid@8bd4bae7 (#9216) Bump to dotnet/java-interop@d30d554 (#9234) Localized file check-in by OneLocBuild Task (#9236) Bump to dotnet/sdk@e2b7b9d2b4 9.0.100-rc.2.24420.1 (#9228) $(AndroidPackVersionSuffix)=rc.2; net9 is 35.0.0-rc.2 (#9233) [Xamarin.Android.Build.Tasks] Scan for JCWs for each ABI in parallel (#9215) [Xamarin.Android.Build.Tasks] %(JavaArtifact) is a list (#9112) [native/monodroid] Fix error demangling satellite assembly names (#9166) [build] Update package metadata (#9230) [Xamarin.Android.Build.Tasks] Remove ILRepack (#9226) [Xamarin.Android.Build.Tasks] Fix an issue with incremental builds (#9183) [Xamarin.Android.Build.Tasks] remove `$XAMARIN_BUILD_ID` (#9223) [Mono.Android] Use .NET version of mdoc (#9225) ...
In order to ensure that all of our per-arch assemblies contain the same JCW types, we scan them all. We can parallelize this operation per-ABI to save time. It is ok to parallelize Cecil here, as each "set" contains completely different assemblies coming from completely different assembly resolvers.
Fresh
dotnet build
of Android template (defaults to 4 architectures), totalGenerateJavaSourcesAndMaybeClassifyMarshalMethods
takes:main