Skip to content
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

[mono][ios] Drop marshal-ilgen from iOS builds if it is not needed #88903

Merged
merged 9 commits into from
Jul 24, 2023

Conversation

jandupej
Copy link
Member

@jandupej jandupej commented Jul 14, 2023

Addresses #88820 and contributes to #61685. RuntimeMarshalingScanner is used to analyze the assemblies and determine if marhsal-lightweight is sufficient for them. If so, the marshal-ilgen component is not included in the package. This should save approx. 44 KB in package size.

Additionally, the iOS HelloWorld sample is fixed so that it does not require marshal-ilgen. This was the only assembly that needed it, from the entire application.

Note: there are still some debug outputs to be removed before merging

@jandupej jandupej added this to the 8.0.0 milestone Jul 14, 2023
@jandupej jandupej self-assigned this Jul 14, 2023
@jandupej jandupej linked an issue Jul 14, 2023 that may be closed by this pull request
Comment on lines 13 to 15
private static extern void ios_set_text(string value);
unsafe private static extern void ios_set_text(byte* value);
//private static extern void ios_set_text(string value);
Copy link
Member

@ivanpovazan ivanpovazan Jul 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we have these under an #if LIGHTWEIGHT_MARSHALLER preprocessor directive, which can be controlled from the sample project file via:

<DefineConstants Condition="'$(UseLightweightMarshallingFriendlyCode)' == 'true'">LIGHTWEIGHT_MARSHALLER;$(DefineConstants)</DefineConstants>

This way the sample can still be testable for both implementations (full and lightweight) by specifying -p:UseLightweightMarshallingFriendlyCode=true during build.

NOTE: Maybe the naming I used is not the best

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is certainly doable, however I think the point is that the inclusion (or not) of marhsal-ilgen should be automatic. So whenever someone tests code in HelloWorld which requires it, it should kick in by by itself. However it could be a good idea to have a test which marshals something nonblittable to check whether the marshaller is correctly included.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

@jandupej jandupej Jul 17, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The scenario appears to be covered already, this test https://github.com/dotnet/runtime/blob/main/src/tests/FunctionalTests/iOS/Simulator/AOT-LLVM/Program.cs should fail if the marshaller is not properly included.

Comment on lines 100 to 105
<ItemGroup Condition="'@(MonoLightweightMarshallerIncompatibleAssemblies->Count())' > 0">
<RuntimeComponents Include="marshal-ilgen" />
</ItemGroup>
<ItemGroup Condition="'@(MonoLightweightMarshallerIncompatibleAssemblies->Count())' == 0">
<RuntimeComponents Remove="marshal-ilgen" />
</ItemGroup>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there an assumption here that RuntimeComponents is non-empty and can already include marshal-ilgen component before reaching this target?
If yes, wouldn't we then encounter a duplication in case <RuntimeComponents Include="marshal-ilgen" /> on line 101?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, Include does not check for duplicates?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately... no :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Apparently one can use KeepDuplicates on ItemGroups. Who knew

@@ -26,6 +26,8 @@
_InitializeCommonProperties;
_BeforeAppleBuild;
_AppleResolveReferences;
_ScanAssembliesDecideLightweightMarshaler;
_ProcessRuntimeComponents;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: I think _ProcessRuntimeComponents target could be refactored a bit, especially as it has a single condition _IsLibraryMode on an item group at https://github.com/dotnet/runtime/pull/88903/files#diff-e351a598f31c0a001f31622d9babc297dbcbe5827eabf55ab92700e1839e70f1R109

Proposed changes:

  1. Add a property depending on library mode builds
  <PropertyGroup Condition="'$(_IsLibraryMode)' == 'true'">
   <_ProcessRuntimeComponentsForLibraryMode>_ProcessRuntimeComponentsForLibraryMode</_ProcessRuntimeComponentsForLibraryMode>
  </PropertyGroup>
  1. Adjust the AppleBuildDependsOn targets
<AppleBuildDependsOn>
        _InitializeCommonProperties;
        _BeforeAppleBuild;
        _AppleResolveReferences;
        _ScanAssembliesDecideLightweightMarshaler;
        $(_ProcessRuntimeComponentsForLibraryMode);
        _AppleAotCompile;
        ...
  1. Rename the _ProcessRuntimeComponents target into _ProcessRuntimeComponentsForLibraryMode
  2. Remove the condition on the item group on line: https://github.com/dotnet/runtime/pull/88903/files#diff-e351a598f31c0a001f31622d9babc297dbcbe5827eabf55ab92700e1839e70f1R109

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated.

@kotlarmilos
Copy link
Member

/azp run runtime-maccatalyst

@azure-pipelines
Copy link

No commit pushedDate could be found for PR 88903 in repo dotnet/runtime

@kotlarmilos
Copy link
Member

/azp run runtime-maccatalyst

@azure-pipelines
Copy link

No commit pushedDate could be found for PR 88903 in repo dotnet/runtime

Copy link
Member

@kotlarmilos kotlarmilos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The maccatalyst failure seems related. It would be good to check the maccatalyst in sandbox environment as it uses dynamic linking.

Otherwise apart from Ivan's comments, it looks good!

@jandupej
Copy link
Member Author

Yes, both the iOS and catalyst failures are related. It seems that the analyzer correctly detects the need for marshal-ilgen, but RuntimeComponents is maybe modified too late into the build process. Need to investigate.

@kotlarmilos
Copy link
Member

iOS/tvOS failures could be #88909.

@jandupej
Copy link
Member Author

/azp list

@azure-pipelines
Copy link

CI/CD Pipelines for this repository:

@jandupej
Copy link
Member Author

/azp run runtime-ioslike

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@jandupej
Copy link
Member Author

All CI failures now seem to be known issues.

Copy link
Member

@ivanpovazan ivanpovazan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thank you!

Copy link
Member

@lambdageek lambdageek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@jandupej jandupej merged commit c8ad025 into dotnet:main Jul 24, 2023
94 checks passed
@ghost ghost locked as resolved and limited conversation to collaborators Aug 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[mono][aot] Disable marshal-ilgen on iOS when not needed
4 participants