-
Notifications
You must be signed in to change notification settings - Fork 562
[Xamarin.Android.Build.Tasks] Prefer supported JDK versions #5919
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -67,6 +67,8 @@ projects. | |
| AndroidSdkPath="$(AndroidSdkDirectory)" | ||
| AndroidNdkPath="$(AndroidNdkDirectory)" | ||
| JavaSdkPath="$(JavaSdkDirectory)" | ||
| MinimumSupportedJavaVersion="$(MinimumSupportedJavaVersion)" | ||
| LatestSupportedJavaVersion="$(LatestSupportedJavaVersion)" | ||
| ReferenceAssemblyPaths="$(_XATargetFrameworkDirectories)"> | ||
| <Output TaskParameter="CommandLineToolsPath" PropertyName="_AndroidToolsDirectory" /> | ||
| <Output TaskParameter="AndroidNdkPath" PropertyName="AndroidNdkDirectory" Condition=" '$(AndroidNdkDirectory)' == '' " /> | ||
|
|
@@ -82,6 +84,8 @@ projects. | |
| </ResolveSdks> | ||
| <ResolveJdkJvmPath | ||
| JavaSdkPath="$(_JavaSdkDirectory)" | ||
| MinimumSupportedJavaVersion="$(MinimumSupportedJavaVersion)" | ||
| LatestSupportedJavaVersion="$(LatestSupportedJavaVersion)" | ||
| Condition=" '$(DesignTimeBuild)' != 'True' And '$(_AndroidIsBindingProject)' != 'True' And '$(AndroidGenerateJniMarshalMethods)' == 'True' And '$(JdkJvmPath)' == '' "> | ||
|
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How was a project template even hitting this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 🤔 Maybe this also needs to be in VS as well? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can't find any place within VS that would need fixing. However, I did find a codepath wherein |
||
| <Output TaskParameter="JdkJvmPath" PropertyName="JdkJvmPath" /> | ||
| </ResolveJdkJvmPath> | ||
|
|
||
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.
This task gets called per Android project on every build. So I could see this adding incremental build time, especially in a larger solution. I think I've seen the
JdkInfolookup take 100ms before.Is there a way we could pass the min/max JDK version through here instead:
https://github.com/xamarin/xamarin-android/blob/57e1a37c443c90f3487a93a312fbfef3441d2769/src/Xamarin.Android.Build.Tasks/Utilities/MonoAndroidHelper.cs#L116
If we want something easier to backport, maybe hardcoding something in xamarin-android-tools would work, too?
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.
Here is where I saw JDK lookups taking time: e624434
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.
<ResolveJdkJvmPath/>and<ResolveSdks/>, "reverting" and also adding theBuildEngine4.RegisterTaskObject()invocations to<ResolveSdks/>?JdkInfotake 47ms to construct?! Is it theLazy<T>construction, used to parse-XshowSettings:properties -versionoutput?)Not that I'm saying you didn't see that improvement. I'm wondering about the environment of the measurement. In particular, was
msbuild /p:JavaSdkDirectory=…used to capture that timing?If
$(JavaSdkDirectory)isn't set -- which I assume is the default and more common occurrence -- then we'll almost certainly "always" hit https://github.com/xamarin/xamarin-android-tools/blob/683f37508b56c76c24b3287a5687743438625341/src/Xamarin.Android.Tools.AndroidSdk/Sdks/AndroidSdkBase.cs#L69javaSdkPathwill be null, necessitating that we first try() => PreferedJavaSdkPath.For most customer machines, this should return a valid value. This (presumably) is a net-win, and would be a reason to look into updating
AndroidSdkInfoto have version constraints.However, if
() => PreferedJavaSdkPathfails -- which presumably is the case on this CI machine -- then we hit the() => GetJavaSdkPaths()codepath, which is likely why we're finding and attempting to use an unsupported JDK version.Which I suppose leaves two questions:
BuildEngine4.RegisterTaskObject()within<ResolveSdks/>fix the problem?JdkJvmPathlookup is slow? The directory traversal?In retrospect, the "odd" thing about the pre-e624434 world order is that
ResolveSdks.GetJvmPath()even existed in the first place, as constructed; once we have a JDK path, why wouldGetJvmPath()need to callJdkInfo.GetKnownSystemJdkInfos()again?Looks like that was always the case, though:
1a2eb95#diff-ec49e6de47ef6cb5b59095d242a56acce5830d39402bf075722fce7dd1326612R105
Also odd that I kinda/sorta mentioned the "oddness" of having a
JdkInfo.GetKnownSystemJdkInfos()invocation, then forgot about how odd that was: #2153 (comment)I don't see why, given a valid JDK path,
JdkJvmPathlookup should be so slow; viacsharp:So maybe
JdkJvmPathis slow, because of JIT overheads (ugh), and no amount of caching can fix things when we're concerned about design-time builds on the first build. It doesn't matter if subsequent builds are faster (yay JIT!), when we care about the Design-Time build, which won't needJdkJvmPath…But what about the JDK itself?
This is "differently fun"; if I edit
$HOME/.config/xbuild/monodroid-config.xmland remove the<java-sdk/>element -- removing the "preferred JDK" location -- then the above takes 81ms to run, while if I have a<java-sdk/>element -- providing a "preferred JDK" location -- then the above takes 55ms to run, a savings of 26ms when the preferred JDK location is set and exists.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.
When I was testing e624434, I probably didn't have
JavaSdkDirectoryset at all and was testing from the command-line.Let me just test this change tomorrow on Windows/.NET framework with a Release build and see how long it takes.
Were your numbers above a
Releasebuild?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.
My numbers above were for a Debug build of
Xamarin.Android.Tools.AndroidSdk.dll, run at the command-line viacsharp:I then pasted the commands above, hence the
Stopwatchuse. I avoided thecsharp>"prefix" in the above pastes so that you could copy & paste the commands into the terminal.