This repository has been archived by the owner on Jan 23, 2023. It is now read-only.
Lazily generate native type layout information #27620
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ything except require extra categories.
…ations out of the type loader. (Blittability is needed in the type loader, so we need to calculate it early).
…track blittability.
…metadata (since if it is blittable, we'll never load the native type and do validation there).
…and the type is non-blittable.
… WinRT is non-generic.
…hal data initalization was in the type loader.
Get runtime and dac building with it. Crossgen needs some more updates to get fragile NGen working with the new design.
…native layout logic. The new logic doesn't support being run as part of type-load.
…interop-data-generation
jkotas
reviewed
Nov 1, 2019
jkotas
reviewed
Nov 1, 2019
jkotas
reviewed
Nov 1, 2019
jkotas
reviewed
Nov 1, 2019
jkotas
reviewed
Nov 1, 2019
jkotas
reviewed
Nov 1, 2019
…sNativeLayoutInfo to a new classlayoutinfo.cpp file.
jkotas
reviewed
Nov 1, 2019
jkotas
reviewed
Nov 2, 2019
|
Thank you for your contribution. As announced in dotnet/coreclr#27549 this repository will be moving to dotnet/runtime on November 13. If you would like to continue working on this PR after this date, the easiest way to move the change to dotnet/runtime is:
|
jkoritzinsky
added
the
post-consolidation
…interop-data-generation
…interop-data-generation
…, which itself has fields that would disqualify it from managed-sequential.
…interop-data-generation
…lating the SystemV eightbyte classification.
…ntract violation.
|
Thank you for your contribution. As announced in #27549 the dotnet/runtime repository will be used going forward for changes to this code base. Closing this PR as no more changes will be accepted into master for this repository. If you’d like to continue working on this change please move it to dotnet/runtime. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, the native layout information for every non-auto-layout type is generated at type-load time, even if managed code never uses the native type. This design has lead to a few limitations in our field marshaling validation, as well as forced field marshalling initialization code to run during method-table building, causing some odd initialization ordering designs because of what data is available at what time.
This PR changes native layout information to only ever be initialized when user code or runtime code requests the native layout of a type and the type is non-blittable. To enable this, the function
IsFieldBlittabledoes a fast, metadata-based blittability check that doesn't need to run all of the marshaler classification logic. When the runtime requests native layout information from a MethodTable that is blittable, it falls back to the managed information. In other cases, it generates the native information and stores it in itsLayoutEEClassfor later use.