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

[cdac] data contract spec follow up items and open questions #100162

Open
2 of 7 tasks
Tracked by #99298
lambdageek opened this issue Mar 22, 2024 · 0 comments
Open
2 of 7 tasks
Tracked by #99298

[cdac] data contract spec follow up items and open questions #100162

lambdageek opened this issue Mar 22, 2024 · 0 comments
Assignees
Labels
area-Diagnostics-coreclr enhancement Product code improvement that does NOT require public API changes/additions
Milestone

Comments

@lambdageek
Copy link
Member

lambdageek commented Mar 22, 2024

(Part of #99298 )

This is a summary of the remaining unsettled questions from the discussion on #99936.
The intention is to merge the initial version of the spec and to address each of these in follow-up PRs or separate discussions.

@dotnet-issue-labeler dotnet-issue-labeler bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Mar 22, 2024
@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Mar 22, 2024
@lambdageek lambdageek added area-Diagnostics-coreclr and removed untriaged New issue has not been triaged by the area owner labels Mar 22, 2024
@teo-tsirpanis teo-tsirpanis removed the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Mar 23, 2024
@tommcdon tommcdon added this to the 9.0.0 milestone Mar 25, 2024
@tommcdon tommcdon added the enhancement Product code improvement that does NOT require public API changes/additions label Mar 26, 2024
lambdageek added a commit that referenced this issue Mar 29, 2024
Contributes to #100162 which is part of #99298

Follow-up to #99936 that removes "type layout" and "global value" contracts and instead replaces them with a "data descriptor" blob.

Conceptually a particular target runtime provides a pair of a logical data descriptor together with a set of algorithmic contract versions. The logical data descriptor is just a single model that defines all the globals and type layouts relevant to the set of algorithmic contract versions.

A logical data descriptor is realized by merging two physical data descriptors in a proscribed order.

The physical data descriptors provide some subset of the type layouts or global values.

The physical data descriptors come in two flavors:

- baseline descriptors that are checked into the dotnet/runtime repo and have well -known names
- in-proc descriptors that get embedded into a target runtime.

Each in-proc descriptor may refer to a baseline and represents a delta applied on top of the baseline.
The data contract model works on top of a flattened logical data descriptor.


Co-authored-by: Aaron Robinson <[email protected]>
Co-authored-by: Jan Kotas <[email protected]>
Co-authored-by: Noah Falk <[email protected]>
matouskozak pushed a commit to matouskozak/runtime that referenced this issue Apr 30, 2024
Contributes to dotnet#100162 which is part of dotnet#99298

Follow-up to dotnet#99936 that removes "type layout" and "global value" contracts and instead replaces them with a "data descriptor" blob.

Conceptually a particular target runtime provides a pair of a logical data descriptor together with a set of algorithmic contract versions. The logical data descriptor is just a single model that defines all the globals and type layouts relevant to the set of algorithmic contract versions.

A logical data descriptor is realized by merging two physical data descriptors in a proscribed order.

The physical data descriptors provide some subset of the type layouts or global values.

The physical data descriptors come in two flavors:

- baseline descriptors that are checked into the dotnet/runtime repo and have well -known names
- in-proc descriptors that get embedded into a target runtime.

Each in-proc descriptor may refer to a baseline and represents a delta applied on top of the baseline.
The data contract model works on top of a flattened logical data descriptor.


Co-authored-by: Aaron Robinson <[email protected]>
Co-authored-by: Jan Kotas <[email protected]>
Co-authored-by: Noah Falk <[email protected]>
Ruihan-Yin pushed a commit to Ruihan-Yin/runtime that referenced this issue May 30, 2024
Contributes to dotnet#100162 which is part of dotnet#99298

Follow-up to dotnet#99936 that removes "type layout" and "global value" contracts and instead replaces them with a "data descriptor" blob.

Conceptually a particular target runtime provides a pair of a logical data descriptor together with a set of algorithmic contract versions. The logical data descriptor is just a single model that defines all the globals and type layouts relevant to the set of algorithmic contract versions.

A logical data descriptor is realized by merging two physical data descriptors in a proscribed order.

The physical data descriptors provide some subset of the type layouts or global values.

The physical data descriptors come in two flavors:

- baseline descriptors that are checked into the dotnet/runtime repo and have well -known names
- in-proc descriptors that get embedded into a target runtime.

Each in-proc descriptor may refer to a baseline and represents a delta applied on top of the baseline.
The data contract model works on top of a flattened logical data descriptor.


Co-authored-by: Aaron Robinson <[email protected]>
Co-authored-by: Jan Kotas <[email protected]>
Co-authored-by: Noah Falk <[email protected]>
@tommcdon tommcdon modified the milestones: 9.0.0, 10.0.0 Jul 23, 2024
@lambdageek lambdageek assigned steveisok and unassigned lambdageek Nov 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-Diagnostics-coreclr enhancement Product code improvement that does NOT require public API changes/additions
Projects
None yet
Development

No branches or pull requests

5 participants