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

Increase the range of allowable native metadata handles #1581

Open
MichalStrehovsky opened this issue Sep 20, 2021 · 3 comments · May be fixed by dotnet/runtime#111222
Open

Increase the range of allowable native metadata handles #1581

MichalStrehovsky opened this issue Sep 20, 2021 · 3 comments · May be fixed by dotnet/runtime#111222
Labels
area-NativeAOT-coreclr .NET runtime optimized for ahead of time compilation

Comments

@MichalStrehovsky
Copy link
Member

Native metadata currently allows addressing 0xFFFFFF (16 MB) of metadata. The top 8 bits of a metadata handle are reserved for metadata handle type. I'm looking at an app that ends up with 21.7 MB of metadata (20.4 MB after picking some low hanging fruit in metadata encoding).

We can either do a more radical overhaul of what a metadata handle means, or compress the set of handle types to get a spare bit. Of course the radical overhaul is better, but realistically, an app that ends up with a need for 32 MB metadata is likely going to have other problems. .NET Native went to retirement with 16 MB and nobody ever reported a problem with it.

We might get to a more radical overhaul if we ever get to reconciling native reflection metadata with native layout metadata.

Undo the limit at #1580 once this is addressed.

@MichalStrehovsky MichalStrehovsky added the area-NativeAOT-coreclr .NET runtime optimized for ahead of time compilation label Sep 20, 2021
yowl pushed a commit to yowl/runtimelab that referenced this issue Sep 25, 2021
In case of an error aborting the connection, there is a race between a thread creating new `Http2Stream` to send a request and the thread looping in `ProcessIncomingFrames` that sets _shutdown flag and `_abortException`. If the request thread first sees `_shutdown == true`, then it won't see the `_abortException` even if it's set, so the request will be retried when it shouldn't.

This PR adds `_abortException` check just before the `_shutdown == true` check to make sure an abort exception is observed.

Fixes dotnet#1581 
Fixes #56138
Fixes #56026
@yowl
Copy link
Contributor

yowl commented Dec 10, 2024

Hit this today trying to bring up WPF/XPF. Trimming WPF is tricky due to BAML/Styles and non compiled bindings so its tempting to include everything just to get a prototype going.

@yowl
Copy link
Contributor

yowl commented Jan 8, 2025

@MichalStrehovsky Can you elaborate a bit more on "compress the set of handle types" ? I'd like to give that a go as trimming a WPF app (for NativeAOT-LLVM) is made harder by the use of xaml and styles/templates etc - it is difficult to know which styles are used at runtime. Also for MVVM, the setters in a view model are often only used be a Binding so there is another problem there. You could do something convention based like root all properties in types that end ViewModel but that wouldn't catch {Binding Model.SomeModelProperty.

MichalStrehovsky added a commit to MichalStrehovsky/runtime that referenced this issue Jan 9, 2025
Fixes dotnet/runtimelab#1581

This allows addressing up to 32 MB of metadata. This should cover all known cases where people hit this in the past.

Granted, none of the user hits are for scenarios where it would be advisable to use native AOT. If one needs to reflection-root 60+ MB of IL, it's inadvisable to use native AOT or trim in general since the possible (small) savings will never outweigh (huge) reliability/predictabillity loss caused by the 60 MB of trim unsafe code.)
@MichalStrehovsky
Copy link
Member Author

@MichalStrehovsky Can you elaborate a bit more on "compress the set of handle types" ? I'd like to give that a go as trimming a WPF app (for NativeAOT-LLVM) is made harder by the use of xaml and styles/templates etc - it is difficult to know which styles are used at runtime. Also for MVVM, the setters in a view model are often only used be a Binding so there is another problem there. You could do something convention based like root all properties in types that end ViewModel but that wouldn't catch {Binding Model.SomeModelProperty.

I have a fix out at dotnet/runtime#111222 but I can't imagine reflection rooting that much IL would lead to pleasant build times, especially with LLVM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-NativeAOT-coreclr .NET runtime optimized for ahead of time compilation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants