[cdac] GetMethodDescData for jitted methods by lambdageek · Pull Request #109187 · dotnet/runtime

lambdageek · 2024-10-24T15:49:31Z

This is enough for !PrintException without R2R methods on the stack

There's also a ReJIT contract here which just checks whether rejit is enabled.

Most of the complexity is in validating MethodDescs

Contributes to #99302
Contributes to #108553

PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

This reverts commit bc45c00.

This reverts commit b1c7c36.

also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

it's an implementation detail

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

davidwrighton

I've read through this and it seems like you've made good progress towards our goal here. I've a few comments about formatting + a few more general comments.

I see a lot of code dedicated to MethodDesc validation. Is that really necessary, and does the behavior match our existing DAC? We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results. Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location? Is the validation logic documented in the data contract markdown?
I don't see documentation updates in the markdown yet. I see that some existing contracts look to have their implementation modified, but I don't see the corresponding documentation updates.
Would it be possible to build a bulleted list of the TODO items that are not assertions that are needed to make this contract work completely?

lambdageek · 2024-10-30T20:33:29Z

I see a lot of code dedicated to MethodDesc validation.

yes

Is that really necessary, and does the behavior match our existing DAC?

I tried to make it match the existing DAC.

Is it necessary? I'm not sure. We do need some validation - I have discovered that the !U command in SOS doesn't differentiate between a MethodDesc and an IP address and expects to be able to call GetMethodDescData with an IP address as the "method desc" argument and get E_INVALIDARG to tell it "this was not a method desc, it was an IP address"

We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results.

Understood

Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location?

There is additional validation here. The version checked in previously was an incomplete snapshot (basically just establishing the internal API for validation).

Is the validation logic documented in the data contract markdown?

No. Is it part of the contract? I've been thinking of it as an artifact of the reader

davidwrighton · 2024-10-30T20:53:33Z

Is the validation logic documented in the data contract markdown?
No. Is it part of the contract? I've been thinking of it as an artifact of the reader

I don't know. It's certainly something that the implementation of the contract depends on to some extent, so all of the dependencies of it (such as the fields it accesses, etc) should probably be in the contract, but the actual validation logic is a more interesting question. I would leave it out of the contract spec for now, so I wouldn't worry about it this week, but given that SOS actually depends on this logic doing something useful for correct functioning, its implied that something is required to make our diagnostic stack work. I would file a bug that you didn't write contract docs for this and leave it at that.

we just use GetTypeHandle now

lambdageek · 2024-10-31T19:04:11Z

I updated the RuntimeTypeSystem contract markdown with the new code and fixed up other contracts to match the implementations as necessary

Created issues:

the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

lambdageek · 2024-10-24T15:49:31Z

This is enough for !PrintException without R2R methods on the stack

There's also a ReJIT contract here which just checks whether rejit is enabled.

Most of the complexity is in validating MethodDescs

Contributes to #99302
Contributes to #108553

PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

This reverts commit bc45c00.

This reverts commit b1c7c36.

also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

it's an implementation detail

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

davidwrighton

I've read through this and it seems like you've made good progress towards our goal here. I've a few comments about formatting + a few more general comments.

I see a lot of code dedicated to MethodDesc validation. Is that really necessary, and does the behavior match our existing DAC? We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results. Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location? Is the validation logic documented in the data contract markdown?
I don't see documentation updates in the markdown yet. I see that some existing contracts look to have their implementation modified, but I don't see the corresponding documentation updates.
Would it be possible to build a bulleted list of the TODO items that are not assertions that are needed to make this contract work completely?

lambdageek · 2024-10-30T20:33:29Z

I see a lot of code dedicated to MethodDesc validation.

yes

Is that really necessary, and does the behavior match our existing DAC?

I tried to make it match the existing DAC.

Is it necessary? I'm not sure. We do need some validation - I have discovered that the !U command in SOS doesn't differentiate between a MethodDesc and an IP address and expects to be able to call GetMethodDescData with an IP address as the "method desc" argument and get E_INVALIDARG to tell it "this was not a method desc, it was an IP address"

We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results.

Understood

Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location?

There is additional validation here. The version checked in previously was an incomplete snapshot (basically just establishing the internal API for validation).

Is the validation logic documented in the data contract markdown?

No. Is it part of the contract? I've been thinking of it as an artifact of the reader

davidwrighton · 2024-10-30T20:53:33Z

Is the validation logic documented in the data contract markdown?
No. Is it part of the contract? I've been thinking of it as an artifact of the reader

I don't know. It's certainly something that the implementation of the contract depends on to some extent, so all of the dependencies of it (such as the fields it accesses, etc) should probably be in the contract, but the actual validation logic is a more interesting question. I would leave it out of the contract spec for now, so I wouldn't worry about it this week, but given that SOS actually depends on this logic doing something useful for correct functioning, its implied that something is required to make our diagnostic stack work. I would file a bug that you didn't write contract docs for this and leave it at that.

we just use GetTypeHandle now

lambdageek · 2024-10-31T19:04:11Z

I updated the RuntimeTypeSystem contract markdown with the new code and fixed up other contracts to match the implementations as necessary

Created issues:

the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

lambdageek · 2024-10-24T15:49:31Z

This is enough for !PrintException without R2R methods on the stack

There's also a ReJIT contract here which just checks whether rejit is enabled.

Most of the complexity is in validating MethodDescs

Contributes to #99302
Contributes to #108553

PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

This reverts commit bc45c00.

This reverts commit b1c7c36.

also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

it's an implementation detail

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

davidwrighton

I've read through this and it seems like you've made good progress towards our goal here. I've a few comments about formatting + a few more general comments.

I see a lot of code dedicated to MethodDesc validation. Is that really necessary, and does the behavior match our existing DAC? We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results. Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location? Is the validation logic documented in the data contract markdown?
I don't see documentation updates in the markdown yet. I see that some existing contracts look to have their implementation modified, but I don't see the corresponding documentation updates.
Would it be possible to build a bulleted list of the TODO items that are not assertions that are needed to make this contract work completely?

lambdageek · 2024-10-30T20:33:29Z

I see a lot of code dedicated to MethodDesc validation.

yes

Is that really necessary, and does the behavior match our existing DAC?

I tried to make it match the existing DAC.

Is it necessary? I'm not sure. We do need some validation - I have discovered that the !U command in SOS doesn't differentiate between a MethodDesc and an IP address and expects to be able to call GetMethodDescData with an IP address as the "method desc" argument and get E_INVALIDARG to tell it "this was not a method desc, it was an IP address"

We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results.

Understood

Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location?

There is additional validation here. The version checked in previously was an incomplete snapshot (basically just establishing the internal API for validation).

Is the validation logic documented in the data contract markdown?

No. Is it part of the contract? I've been thinking of it as an artifact of the reader

davidwrighton · 2024-10-30T20:53:33Z

Is the validation logic documented in the data contract markdown?
No. Is it part of the contract? I've been thinking of it as an artifact of the reader

I don't know. It's certainly something that the implementation of the contract depends on to some extent, so all of the dependencies of it (such as the fields it accesses, etc) should probably be in the contract, but the actual validation logic is a more interesting question. I would leave it out of the contract spec for now, so I wouldn't worry about it this week, but given that SOS actually depends on this logic doing something useful for correct functioning, its implied that something is required to make our diagnostic stack work. I would file a bug that you didn't write contract docs for this and leave it at that.

we just use GetTypeHandle now

lambdageek · 2024-10-31T19:04:11Z

I updated the RuntimeTypeSystem contract markdown with the new code and fixed up other contracts to match the implementations as necessary

Created issues:

the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

lambdageek · 2024-10-24T15:49:31Z

This is enough for !PrintException without R2R methods on the stack

There's also a ReJIT contract here which just checks whether rejit is enabled.

Most of the complexity is in validating MethodDescs

Contributes to #99302
Contributes to #108553

PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

This reverts commit bc45c00.

This reverts commit b1c7c36.

also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

it's an implementation detail

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

davidwrighton

I've read through this and it seems like you've made good progress towards our goal here. I've a few comments about formatting + a few more general comments.

I see a lot of code dedicated to MethodDesc validation. Is that really necessary, and does the behavior match our existing DAC? We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results. Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location? Is the validation logic documented in the data contract markdown?
I don't see documentation updates in the markdown yet. I see that some existing contracts look to have their implementation modified, but I don't see the corresponding documentation updates.
Would it be possible to build a bulleted list of the TODO items that are not assertions that are needed to make this contract work completely?

lambdageek · 2024-10-30T20:33:29Z

I see a lot of code dedicated to MethodDesc validation.

yes

Is that really necessary, and does the behavior match our existing DAC?

I tried to make it match the existing DAC.

Is it necessary? I'm not sure. We do need some validation - I have discovered that the !U command in SOS doesn't differentiate between a MethodDesc and an IP address and expects to be able to call GetMethodDescData with an IP address as the "method desc" argument and get E_INVALIDARG to tell it "this was not a method desc, it was an IP address"

We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results.

Understood

Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location?

There is additional validation here. The version checked in previously was an incomplete snapshot (basically just establishing the internal API for validation).

Is the validation logic documented in the data contract markdown?

No. Is it part of the contract? I've been thinking of it as an artifact of the reader

davidwrighton · 2024-10-30T20:53:33Z

Is the validation logic documented in the data contract markdown?
No. Is it part of the contract? I've been thinking of it as an artifact of the reader

I don't know. It's certainly something that the implementation of the contract depends on to some extent, so all of the dependencies of it (such as the fields it accesses, etc) should probably be in the contract, but the actual validation logic is a more interesting question. I would leave it out of the contract spec for now, so I wouldn't worry about it this week, but given that SOS actually depends on this logic doing something useful for correct functioning, its implied that something is required to make our diagnostic stack work. I would file a bug that you didn't write contract docs for this and leave it at that.

we just use GetTypeHandle now

lambdageek · 2024-10-31T19:04:11Z

I updated the RuntimeTypeSystem contract markdown with the new code and fixed up other contracts to match the implementations as necessary

Created issues:

the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

lambdageek · 2024-10-24T15:49:31Z

This is enough for !PrintException without R2R methods on the stack

There's also a ReJIT contract here which just checks whether rejit is enabled.

Most of the complexity is in validating MethodDescs

Contributes to #99302
Contributes to #108553

PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

This reverts commit bc45c00.

This reverts commit b1c7c36.

also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

it's an implementation detail

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

davidwrighton

I've read through this and it seems like you've made good progress towards our goal here. I've a few comments about formatting + a few more general comments.

I see a lot of code dedicated to MethodDesc validation. Is that really necessary, and does the behavior match our existing DAC? We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results. Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location? Is the validation logic documented in the data contract markdown?
I don't see documentation updates in the markdown yet. I see that some existing contracts look to have their implementation modified, but I don't see the corresponding documentation updates.
Would it be possible to build a bulleted list of the TODO items that are not assertions that are needed to make this contract work completely?

lambdageek · 2024-10-30T20:33:29Z

I see a lot of code dedicated to MethodDesc validation.

yes

Is that really necessary, and does the behavior match our existing DAC?

I tried to make it match the existing DAC.

Is it necessary? I'm not sure. We do need some validation - I have discovered that the !U command in SOS doesn't differentiate between a MethodDesc and an IP address and expects to be able to call GetMethodDescData with an IP address as the "method desc" argument and get E_INVALIDARG to tell it "this was not a method desc, it was an IP address"

We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results.

Understood

Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location?

There is additional validation here. The version checked in previously was an incomplete snapshot (basically just establishing the internal API for validation).

Is the validation logic documented in the data contract markdown?

No. Is it part of the contract? I've been thinking of it as an artifact of the reader

davidwrighton · 2024-10-30T20:53:33Z

Is the validation logic documented in the data contract markdown?
No. Is it part of the contract? I've been thinking of it as an artifact of the reader

I don't know. It's certainly something that the implementation of the contract depends on to some extent, so all of the dependencies of it (such as the fields it accesses, etc) should probably be in the contract, but the actual validation logic is a more interesting question. I would leave it out of the contract spec for now, so I wouldn't worry about it this week, but given that SOS actually depends on this logic doing something useful for correct functioning, its implied that something is required to make our diagnostic stack work. I would file a bug that you didn't write contract docs for this and leave it at that.

we just use GetTypeHandle now

lambdageek · 2024-10-31T19:04:11Z

I updated the RuntimeTypeSystem contract markdown with the new code and fixed up other contracts to match the implementations as necessary

Created issues:

the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

lambdageek · 2024-10-24T15:49:31Z

This is enough for !PrintException without R2R methods on the stack

There's also a ReJIT contract here which just checks whether rejit is enabled.

Most of the complexity is in validating MethodDescs

Contributes to #99302
Contributes to #108553

PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

This reverts commit bc45c00.

This reverts commit b1c7c36.

also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

it's an implementation detail

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

davidwrighton

I've read through this and it seems like you've made good progress towards our goal here. I've a few comments about formatting + a few more general comments.

I see a lot of code dedicated to MethodDesc validation. Is that really necessary, and does the behavior match our existing DAC? We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results. Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location? Is the validation logic documented in the data contract markdown?
I don't see documentation updates in the markdown yet. I see that some existing contracts look to have their implementation modified, but I don't see the corresponding documentation updates.
Would it be possible to build a bulleted list of the TODO items that are not assertions that are needed to make this contract work completely?

lambdageek · 2024-10-30T20:33:29Z

I see a lot of code dedicated to MethodDesc validation.

yes

Is that really necessary, and does the behavior match our existing DAC?

I tried to make it match the existing DAC.

Is it necessary? I'm not sure. We do need some validation - I have discovered that the !U command in SOS doesn't differentiate between a MethodDesc and an IP address and expects to be able to call GetMethodDescData with an IP address as the "method desc" argument and get E_INVALIDARG to tell it "this was not a method desc, it was an IP address"

We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results.

Understood

Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location?

There is additional validation here. The version checked in previously was an incomplete snapshot (basically just establishing the internal API for validation).

Is the validation logic documented in the data contract markdown?

No. Is it part of the contract? I've been thinking of it as an artifact of the reader

davidwrighton · 2024-10-30T20:53:33Z

Is the validation logic documented in the data contract markdown?
No. Is it part of the contract? I've been thinking of it as an artifact of the reader

I don't know. It's certainly something that the implementation of the contract depends on to some extent, so all of the dependencies of it (such as the fields it accesses, etc) should probably be in the contract, but the actual validation logic is a more interesting question. I would leave it out of the contract spec for now, so I wouldn't worry about it this week, but given that SOS actually depends on this logic doing something useful for correct functioning, its implied that something is required to make our diagnostic stack work. I would file a bug that you didn't write contract docs for this and leave it at that.

we just use GetTypeHandle now

lambdageek · 2024-10-31T19:04:11Z

I updated the RuntimeTypeSystem contract markdown with the new code and fixed up other contracts to match the implementations as necessary

Created issues:

the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

lambdageek · 2024-10-24T15:49:31Z

This is enough for !PrintException without R2R methods on the stack

There's also a ReJIT contract here which just checks whether rejit is enabled.

Most of the complexity is in validating MethodDescs

Contributes to #99302
Contributes to #108553

PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

This reverts commit bc45c00.

This reverts commit b1c7c36.

also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

it's an implementation detail

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

davidwrighton

I've read through this and it seems like you've made good progress towards our goal here. I've a few comments about formatting + a few more general comments.

I see a lot of code dedicated to MethodDesc validation. Is that really necessary, and does the behavior match our existing DAC? We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results. Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location? Is the validation logic documented in the data contract markdown?
I don't see documentation updates in the markdown yet. I see that some existing contracts look to have their implementation modified, but I don't see the corresponding documentation updates.
Would it be possible to build a bulleted list of the TODO items that are not assertions that are needed to make this contract work completely?

lambdageek · 2024-10-30T20:33:29Z

I see a lot of code dedicated to MethodDesc validation.

yes

Is that really necessary, and does the behavior match our existing DAC?

I tried to make it match the existing DAC.

Is it necessary? I'm not sure. We do need some validation - I have discovered that the !U command in SOS doesn't differentiate between a MethodDesc and an IP address and expects to be able to call GetMethodDescData with an IP address as the "method desc" argument and get E_INVALIDARG to tell it "this was not a method desc, it was an IP address"

We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results.

Understood

Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location?

There is additional validation here. The version checked in previously was an incomplete snapshot (basically just establishing the internal API for validation).

Is the validation logic documented in the data contract markdown?

No. Is it part of the contract? I've been thinking of it as an artifact of the reader

davidwrighton · 2024-10-30T20:53:33Z

Is the validation logic documented in the data contract markdown?
No. Is it part of the contract? I've been thinking of it as an artifact of the reader

I don't know. It's certainly something that the implementation of the contract depends on to some extent, so all of the dependencies of it (such as the fields it accesses, etc) should probably be in the contract, but the actual validation logic is a more interesting question. I would leave it out of the contract spec for now, so I wouldn't worry about it this week, but given that SOS actually depends on this logic doing something useful for correct functioning, its implied that something is required to make our diagnostic stack work. I would file a bug that you didn't write contract docs for this and leave it at that.

we just use GetTypeHandle now

lambdageek · 2024-10-31T19:04:11Z

I updated the RuntimeTypeSystem contract markdown with the new code and fixed up other contracts to match the implementations as necessary

Created issues:

the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

lambdageek · 2024-10-24T15:49:31Z

This is enough for !PrintException without R2R methods on the stack

There's also a ReJIT contract here which just checks whether rejit is enabled.

Most of the complexity is in validating MethodDescs

Contributes to #99302
Contributes to #108553

PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

This reverts commit bc45c00.

This reverts commit b1c7c36.

also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

it's an implementation detail

Co-authored-by: Aaron Robinson <arobins@microsoft.com>

davidwrighton

I've read through this and it seems like you've made good progress towards our goal here. I've a few comments about formatting + a few more general comments.

I see a lot of code dedicated to MethodDesc validation. Is that really necessary, and does the behavior match our existing DAC? We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results. Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location? Is the validation logic documented in the data contract markdown?
I don't see documentation updates in the markdown yet. I see that some existing contracts look to have their implementation modified, but I don't see the corresponding documentation updates.
Would it be possible to build a bulleted list of the TODO items that are not assertions that are needed to make this contract work completely?

lambdageek · 2024-10-30T20:33:29Z

I see a lot of code dedicated to MethodDesc validation.

yes

Is that really necessary, and does the behavior match our existing DAC?

I tried to make it match the existing DAC.

Is it necessary? I'm not sure. We do need some validation - I have discovered that the !U command in SOS doesn't differentiate between a MethodDesc and an IP address and expects to be able to call GetMethodDescData with an IP address as the "method desc" argument and get E_INVALIDARG to tell it "this was not a method desc, it was an IP address"

We may run this in an environment where the full heap isn't available, and we might want code to do a best effort job of producing results.

Understood

Also, are there changes to the MethodDesc validation logic here, or just refactoring to a new location?

There is additional validation here. The version checked in previously was an incomplete snapshot (basically just establishing the internal API for validation).

Is the validation logic documented in the data contract markdown?

No. Is it part of the contract? I've been thinking of it as an artifact of the reader

davidwrighton · 2024-10-30T20:53:33Z

Is the validation logic documented in the data contract markdown?
No. Is it part of the contract? I've been thinking of it as an artifact of the reader

I don't know. It's certainly something that the implementation of the contract depends on to some extent, so all of the dependencies of it (such as the fields it accesses, etc) should probably be in the contract, but the actual validation logic is a more interesting question. I would leave it out of the contract spec for now, so I wouldn't worry about it this week, but given that SOS actually depends on this logic doing something useful for correct functioning, its implied that something is required to make our diagnostic stack work. I would file a bug that you didn't write contract docs for this and leave it at that.

we just use GetTypeHandle now

lambdageek · 2024-10-31T19:04:11Z

I updated the RuntimeTypeSystem contract markdown with the new code and fixed up other contracts to match the implementations as necessary

Created issues:

the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

lambdageekand others added 30 commits August 19, 2024 10:14

remove instance field initialization from PrecodeMachineDescriptor
04f41f6
PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

suggestion from code review make m_IsCollectible a const BYTE
abf9df0

fixup
71dee34

Revert "fixup"
2fbc89e
This reverts commit bc45c00.

Revert "suggestion from code review make m_IsCollectible a const BYTE"
2e3b938
This reverts commit b1c7c36.

move PrecodeStubs to a separate contract
1776abe

ExecutionManager contract
099b5fa

rename contract NativeCodePointers => CodeVersions
50046b8

ReJIT contract
e2d637b

formatting, comments and whitespace
7724fa8

cleanup
a53b3ae

"NDirect" -> "PInvoke" in descriptor and contracts
124ee6a

WIP: contract writeups
fb1676b

fix build
f1d757e

placeholder ExecutionManager contract
f1d7be8

placeholder ExecutionManager contract; updates to RTS and Loader
ebb4a67

refactor ExecutionManager
aac3faf

remove dead method from contract
ef51f0e

fix typo
92764a2

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
4e1a620

Apply suggestions from code review
037c349

Add PrecodeStubs contract writeup
25d8343

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
ac0165a

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
8f5e98b

checkpoint: Abstractions
81fe51b

checkpoint begin moving contracts to Abstractions
c376c4c

rationalize IContractFactory
9c3f010

move IObject contract
7ec2f79

fixup interfaces
efaff82

move IRuntimeTypeSystem contract
c8b5c3f

lambdageek added 3 commits October 30, 2024 13:33

checkpoint GetMethodToken test passes
babbe44

fixup merge
a6bce83

move MethodValidation to a separate class
c74390f
also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

lambdageek marked this pull request as ready for review October 30, 2024 18:40

lambdageek requested review from AaronRobinsonMSFT, davidwrighton, elinor-fung and max-charlamb October 30, 2024 18:40

AaronRobinsonMSFT reviewed Oct 30, 2024
View reviewed changes

Comment thread...managed/cdacreader/Microsoft.Diagnostics.DataContractReader.Contracts/Legacy/ICorProfiler.cs Outdated
Comment threadsrc/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs Outdated

lambdageekand others added 3 commits October 30, 2024 15:30

move COR_PRF_MONITOR into ReJIT_1
292101b
it's an implementation detail

Update src/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs
ab16aa8
Co-authored-by: Aaron Robinson <arobins@microsoft.com>

assert the expected slot number
caee264

davidwrighton reviewed Oct 30, 2024
View reviewed changes

Comment thread...acreader/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/RuntimeTypeSystem_1.cs Outdated
Comment thread...rosoft.Diagnostics.DataContractReader.Contracts/RuntimeTypeSystemHelpers/MethodValidation.cs Outdated

Exercise a few more easy properties of MethodDesc
564c7e4

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] System.Net.Http.Functional.Tests failure ("Why are we setting the target on an unoccupied slot?") #104524
Open

lambdageek added 2 commits October 31, 2024 10:15

whitespace
a54db74

remove TypeHandleFromAddress from contract
bdc6479
we just use GetTypeHandle now

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] MutexTests - operation does not support unaligned accesses #96191
Open

lambdageek added 4 commits October 31, 2024 14:55

clean up MethodClassification -> size lookups
0867c68

document RuntimeTypeSystem contract additions
f0603e3

update the CodeVersions contract to match implementation
4ff2f72

remove some TODO comments
3d342f6

lambdageek added 2 commits October 31, 2024 15:56

fix build
3bacf70

add sizes for method desc subclasses
9f8adeb
the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

davidwrighton approved these changes Nov 1, 2024
View reviewed changes

lambdageek merged commit 65d6ef6 into dotnet:mainNov 1, 2024

github-actionsBot locked and limited conversation to collaborators Dec 2, 2024

lambdageekand others added 30 commits August 19, 2024 10:14

remove instance field initialization from PrecodeMachineDescriptor
04f41f6
PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

suggestion from code review make m_IsCollectible a const BYTE
abf9df0

fixup
71dee34

Revert "fixup"
2fbc89e
This reverts commit bc45c00.

Revert "suggestion from code review make m_IsCollectible a const BYTE"
2e3b938
This reverts commit b1c7c36.

move PrecodeStubs to a separate contract
1776abe

ExecutionManager contract
099b5fa

rename contract NativeCodePointers => CodeVersions
50046b8

ReJIT contract
e2d637b

formatting, comments and whitespace
7724fa8

cleanup
a53b3ae

"NDirect" -> "PInvoke" in descriptor and contracts
124ee6a

WIP: contract writeups
fb1676b

fix build
f1d757e

placeholder ExecutionManager contract
f1d7be8

placeholder ExecutionManager contract; updates to RTS and Loader
ebb4a67

refactor ExecutionManager
aac3faf

remove dead method from contract
ef51f0e

fix typo
92764a2

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
4e1a620

Apply suggestions from code review
037c349

Add PrecodeStubs contract writeup
25d8343

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
ac0165a

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
8f5e98b

checkpoint: Abstractions
81fe51b

checkpoint begin moving contracts to Abstractions
c376c4c

rationalize IContractFactory
9c3f010

move IObject contract
7ec2f79

fixup interfaces
efaff82

move IRuntimeTypeSystem contract
c8b5c3f

lambdageek added 3 commits October 30, 2024 13:33

checkpoint GetMethodToken test passes
babbe44

fixup merge
a6bce83

move MethodValidation to a separate class
c74390f
also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

lambdageek marked this pull request as ready for review October 30, 2024 18:40

lambdageek requested review from AaronRobinsonMSFT, davidwrighton, elinor-fung and max-charlamb October 30, 2024 18:40

AaronRobinsonMSFT reviewed Oct 30, 2024
View reviewed changes

Comment thread...managed/cdacreader/Microsoft.Diagnostics.DataContractReader.Contracts/Legacy/ICorProfiler.cs Outdated
Comment threadsrc/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs Outdated

lambdageekand others added 3 commits October 30, 2024 15:30

move COR_PRF_MONITOR into ReJIT_1
292101b
it's an implementation detail

Update src/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs
ab16aa8
Co-authored-by: Aaron Robinson <arobins@microsoft.com>

assert the expected slot number
caee264

davidwrighton reviewed Oct 30, 2024
View reviewed changes

Comment thread...acreader/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/RuntimeTypeSystem_1.cs Outdated
Comment thread...rosoft.Diagnostics.DataContractReader.Contracts/RuntimeTypeSystemHelpers/MethodValidation.cs Outdated

Exercise a few more easy properties of MethodDesc
564c7e4

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] System.Net.Http.Functional.Tests failure ("Why are we setting the target on an unoccupied slot?") #104524
Open

lambdageek added 2 commits October 31, 2024 10:15

whitespace
a54db74

remove TypeHandleFromAddress from contract
bdc6479
we just use GetTypeHandle now

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] MutexTests - operation does not support unaligned accesses #96191
Open

lambdageek added 4 commits October 31, 2024 14:55

clean up MethodClassification -> size lookups
0867c68

document RuntimeTypeSystem contract additions
f0603e3

update the CodeVersions contract to match implementation
4ff2f72

remove some TODO comments
3d342f6

lambdageek added 2 commits October 31, 2024 15:56

fix build
3bacf70

add sizes for method desc subclasses
9f8adeb
the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

davidwrighton approved these changes Nov 1, 2024
View reviewed changes

lambdageek merged commit 65d6ef6 into dotnet:mainNov 1, 2024

github-actionsBot locked and limited conversation to collaborators Dec 2, 2024

lambdageekand others added 30 commits August 19, 2024 10:14

remove instance field initialization from PrecodeMachineDescriptor
04f41f6
PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

suggestion from code review make m_IsCollectible a const BYTE
abf9df0

fixup
71dee34

Revert "fixup"
2fbc89e
This reverts commit bc45c00.

Revert "suggestion from code review make m_IsCollectible a const BYTE"
2e3b938
This reverts commit b1c7c36.

move PrecodeStubs to a separate contract
1776abe

ExecutionManager contract
099b5fa

rename contract NativeCodePointers => CodeVersions
50046b8

ReJIT contract
e2d637b

formatting, comments and whitespace
7724fa8

cleanup
a53b3ae

"NDirect" -> "PInvoke" in descriptor and contracts
124ee6a

WIP: contract writeups
fb1676b

fix build
f1d757e

placeholder ExecutionManager contract
f1d7be8

placeholder ExecutionManager contract; updates to RTS and Loader
ebb4a67

refactor ExecutionManager
aac3faf

remove dead method from contract
ef51f0e

fix typo
92764a2

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
4e1a620

Apply suggestions from code review
037c349

Add PrecodeStubs contract writeup
25d8343

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
ac0165a

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
8f5e98b

checkpoint: Abstractions
81fe51b

checkpoint begin moving contracts to Abstractions
c376c4c

rationalize IContractFactory
9c3f010

move IObject contract
7ec2f79

fixup interfaces
efaff82

move IRuntimeTypeSystem contract
c8b5c3f

lambdageek added 3 commits October 30, 2024 13:33

checkpoint GetMethodToken test passes
babbe44

fixup merge
a6bce83

move MethodValidation to a separate class
c74390f
also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

lambdageek marked this pull request as ready for review October 30, 2024 18:40

lambdageek requested review from AaronRobinsonMSFT, davidwrighton, elinor-fung and max-charlamb October 30, 2024 18:40

AaronRobinsonMSFT reviewed Oct 30, 2024
View reviewed changes

Comment thread...managed/cdacreader/Microsoft.Diagnostics.DataContractReader.Contracts/Legacy/ICorProfiler.cs Outdated
Comment threadsrc/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs Outdated

lambdageekand others added 3 commits October 30, 2024 15:30

move COR_PRF_MONITOR into ReJIT_1
292101b
it's an implementation detail

Update src/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs
ab16aa8
Co-authored-by: Aaron Robinson <arobins@microsoft.com>

assert the expected slot number
caee264

davidwrighton reviewed Oct 30, 2024
View reviewed changes

Comment thread...acreader/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/RuntimeTypeSystem_1.cs Outdated
Comment thread...rosoft.Diagnostics.DataContractReader.Contracts/RuntimeTypeSystemHelpers/MethodValidation.cs Outdated

Exercise a few more easy properties of MethodDesc
564c7e4

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] System.Net.Http.Functional.Tests failure ("Why are we setting the target on an unoccupied slot?") #104524
Open

lambdageek added 2 commits October 31, 2024 10:15

whitespace
a54db74

remove TypeHandleFromAddress from contract
bdc6479
we just use GetTypeHandle now

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] MutexTests - operation does not support unaligned accesses #96191
Open

lambdageek added 4 commits October 31, 2024 14:55

clean up MethodClassification -> size lookups
0867c68

document RuntimeTypeSystem contract additions
f0603e3

update the CodeVersions contract to match implementation
4ff2f72

remove some TODO comments
3d342f6

lambdageek added 2 commits October 31, 2024 15:56

fix build
3bacf70

add sizes for method desc subclasses
9f8adeb
the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

davidwrighton approved these changes Nov 1, 2024
View reviewed changes

lambdageek merged commit 65d6ef6 into dotnet:mainNov 1, 2024

github-actionsBot locked and limited conversation to collaborators Dec 2, 2024

lambdageekand others added 30 commits August 19, 2024 10:14

remove instance field initialization from PrecodeMachineDescriptor
04f41f6
PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

suggestion from code review make m_IsCollectible a const BYTE
abf9df0

fixup
71dee34

Revert "fixup"
2fbc89e
This reverts commit bc45c00.

Revert "suggestion from code review make m_IsCollectible a const BYTE"
2e3b938
This reverts commit b1c7c36.

move PrecodeStubs to a separate contract
1776abe

ExecutionManager contract
099b5fa

rename contract NativeCodePointers => CodeVersions
50046b8

ReJIT contract
e2d637b

formatting, comments and whitespace
7724fa8

cleanup
a53b3ae

"NDirect" -> "PInvoke" in descriptor and contracts
124ee6a

WIP: contract writeups
fb1676b

fix build
f1d757e

placeholder ExecutionManager contract
f1d7be8

placeholder ExecutionManager contract; updates to RTS and Loader
ebb4a67

refactor ExecutionManager
aac3faf

remove dead method from contract
ef51f0e

fix typo
92764a2

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
4e1a620

Apply suggestions from code review
037c349

Add PrecodeStubs contract writeup
25d8343

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
ac0165a

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
8f5e98b

checkpoint: Abstractions
81fe51b

checkpoint begin moving contracts to Abstractions
c376c4c

rationalize IContractFactory
9c3f010

move IObject contract
7ec2f79

fixup interfaces
efaff82

move IRuntimeTypeSystem contract
c8b5c3f

lambdageek added 3 commits October 30, 2024 13:33

checkpoint GetMethodToken test passes
babbe44

fixup merge
a6bce83

move MethodValidation to a separate class
c74390f
also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

lambdageek marked this pull request as ready for review October 30, 2024 18:40

lambdageek requested review from AaronRobinsonMSFT, davidwrighton, elinor-fung and max-charlamb October 30, 2024 18:40

AaronRobinsonMSFT reviewed Oct 30, 2024
View reviewed changes

Comment thread...managed/cdacreader/Microsoft.Diagnostics.DataContractReader.Contracts/Legacy/ICorProfiler.cs Outdated
Comment threadsrc/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs Outdated

lambdageekand others added 3 commits October 30, 2024 15:30

move COR_PRF_MONITOR into ReJIT_1
292101b
it's an implementation detail

Update src/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs
ab16aa8
Co-authored-by: Aaron Robinson <arobins@microsoft.com>

assert the expected slot number
caee264

davidwrighton reviewed Oct 30, 2024
View reviewed changes

Comment thread...acreader/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/RuntimeTypeSystem_1.cs Outdated
Comment thread...rosoft.Diagnostics.DataContractReader.Contracts/RuntimeTypeSystemHelpers/MethodValidation.cs Outdated

Exercise a few more easy properties of MethodDesc
564c7e4

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] System.Net.Http.Functional.Tests failure ("Why are we setting the target on an unoccupied slot?") #104524
Open

lambdageek added 2 commits October 31, 2024 10:15

whitespace
a54db74

remove TypeHandleFromAddress from contract
bdc6479
we just use GetTypeHandle now

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] MutexTests - operation does not support unaligned accesses #96191
Open

lambdageek added 4 commits October 31, 2024 14:55

clean up MethodClassification -> size lookups
0867c68

document RuntimeTypeSystem contract additions
f0603e3

update the CodeVersions contract to match implementation
4ff2f72

remove some TODO comments
3d342f6

lambdageek added 2 commits October 31, 2024 15:56

fix build
3bacf70

add sizes for method desc subclasses
9f8adeb
the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

davidwrighton approved these changes Nov 1, 2024
View reviewed changes

lambdageek merged commit 65d6ef6 into dotnet:mainNov 1, 2024

github-actionsBot locked and limited conversation to collaborators Dec 2, 2024

lambdageekand others added 30 commits August 19, 2024 10:14

remove instance field initialization from PrecodeMachineDescriptor
04f41f6
PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

suggestion from code review make m_IsCollectible a const BYTE
abf9df0

fixup
71dee34

Revert "fixup"
2fbc89e
This reverts commit bc45c00.

Revert "suggestion from code review make m_IsCollectible a const BYTE"
2e3b938
This reverts commit b1c7c36.

move PrecodeStubs to a separate contract
1776abe

ExecutionManager contract
099b5fa

rename contract NativeCodePointers => CodeVersions
50046b8

ReJIT contract
e2d637b

formatting, comments and whitespace
7724fa8

cleanup
a53b3ae

"NDirect" -> "PInvoke" in descriptor and contracts
124ee6a

WIP: contract writeups
fb1676b

fix build
f1d757e

placeholder ExecutionManager contract
f1d7be8

placeholder ExecutionManager contract; updates to RTS and Loader
ebb4a67

refactor ExecutionManager
aac3faf

remove dead method from contract
ef51f0e

fix typo
92764a2

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
4e1a620

Apply suggestions from code review
037c349

Add PrecodeStubs contract writeup
25d8343

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
ac0165a

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
8f5e98b

checkpoint: Abstractions
81fe51b

checkpoint begin moving contracts to Abstractions
c376c4c

rationalize IContractFactory
9c3f010

move IObject contract
7ec2f79

fixup interfaces
efaff82

move IRuntimeTypeSystem contract
c8b5c3f

lambdageek added 3 commits October 30, 2024 13:33

checkpoint GetMethodToken test passes
babbe44

fixup merge
a6bce83

move MethodValidation to a separate class
c74390f
also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

lambdageek marked this pull request as ready for review October 30, 2024 18:40

lambdageek requested review from AaronRobinsonMSFT, davidwrighton, elinor-fung and max-charlamb October 30, 2024 18:40

AaronRobinsonMSFT reviewed Oct 30, 2024
View reviewed changes

Comment thread...managed/cdacreader/Microsoft.Diagnostics.DataContractReader.Contracts/Legacy/ICorProfiler.cs Outdated
Comment threadsrc/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs Outdated

lambdageekand others added 3 commits October 30, 2024 15:30

move COR_PRF_MONITOR into ReJIT_1
292101b
it's an implementation detail

Update src/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs
ab16aa8
Co-authored-by: Aaron Robinson <arobins@microsoft.com>

assert the expected slot number
caee264

davidwrighton reviewed Oct 30, 2024
View reviewed changes

Comment thread...acreader/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/RuntimeTypeSystem_1.cs Outdated
Comment thread...rosoft.Diagnostics.DataContractReader.Contracts/RuntimeTypeSystemHelpers/MethodValidation.cs Outdated

Exercise a few more easy properties of MethodDesc
564c7e4

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] System.Net.Http.Functional.Tests failure ("Why are we setting the target on an unoccupied slot?") #104524
Open

lambdageek added 2 commits October 31, 2024 10:15

whitespace
a54db74

remove TypeHandleFromAddress from contract
bdc6479
we just use GetTypeHandle now

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] MutexTests - operation does not support unaligned accesses #96191
Open

lambdageek added 4 commits October 31, 2024 14:55

clean up MethodClassification -> size lookups
0867c68

document RuntimeTypeSystem contract additions
f0603e3

update the CodeVersions contract to match implementation
4ff2f72

remove some TODO comments
3d342f6

lambdageek added 2 commits October 31, 2024 15:56

fix build
3bacf70

add sizes for method desc subclasses
9f8adeb
the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

davidwrighton approved these changes Nov 1, 2024
View reviewed changes

lambdageek merged commit 65d6ef6 into dotnet:mainNov 1, 2024

github-actionsBot locked and limited conversation to collaborators Dec 2, 2024

lambdageekand others added 30 commits August 19, 2024 10:14

remove instance field initialization from PrecodeMachineDescriptor
04f41f6
PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

suggestion from code review make m_IsCollectible a const BYTE
abf9df0

fixup
71dee34

Revert "fixup"
2fbc89e
This reverts commit bc45c00.

Revert "suggestion from code review make m_IsCollectible a const BYTE"
2e3b938
This reverts commit b1c7c36.

move PrecodeStubs to a separate contract
1776abe

ExecutionManager contract
099b5fa

rename contract NativeCodePointers => CodeVersions
50046b8

ReJIT contract
e2d637b

formatting, comments and whitespace
7724fa8

cleanup
a53b3ae

"NDirect" -> "PInvoke" in descriptor and contracts
124ee6a

WIP: contract writeups
fb1676b

fix build
f1d757e

placeholder ExecutionManager contract
f1d7be8

placeholder ExecutionManager contract; updates to RTS and Loader
ebb4a67

refactor ExecutionManager
aac3faf

remove dead method from contract
ef51f0e

fix typo
92764a2

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
4e1a620

Apply suggestions from code review
037c349

Add PrecodeStubs contract writeup
25d8343

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
ac0165a

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
8f5e98b

checkpoint: Abstractions
81fe51b

checkpoint begin moving contracts to Abstractions
c376c4c

rationalize IContractFactory
9c3f010

move IObject contract
7ec2f79

fixup interfaces
efaff82

move IRuntimeTypeSystem contract
c8b5c3f

lambdageek added 3 commits October 30, 2024 13:33

checkpoint GetMethodToken test passes
babbe44

fixup merge
a6bce83

move MethodValidation to a separate class
c74390f
also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

lambdageek marked this pull request as ready for review October 30, 2024 18:40

lambdageek requested review from AaronRobinsonMSFT, davidwrighton, elinor-fung and max-charlamb October 30, 2024 18:40

AaronRobinsonMSFT reviewed Oct 30, 2024
View reviewed changes

Comment thread...managed/cdacreader/Microsoft.Diagnostics.DataContractReader.Contracts/Legacy/ICorProfiler.cs Outdated
Comment threadsrc/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs Outdated

lambdageekand others added 3 commits October 30, 2024 15:30

move COR_PRF_MONITOR into ReJIT_1
292101b
it's an implementation detail

Update src/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs
ab16aa8
Co-authored-by: Aaron Robinson <arobins@microsoft.com>

assert the expected slot number
caee264

davidwrighton reviewed Oct 30, 2024
View reviewed changes

Comment thread...acreader/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/RuntimeTypeSystem_1.cs Outdated
Comment thread...rosoft.Diagnostics.DataContractReader.Contracts/RuntimeTypeSystemHelpers/MethodValidation.cs Outdated

Exercise a few more easy properties of MethodDesc
564c7e4

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] System.Net.Http.Functional.Tests failure ("Why are we setting the target on an unoccupied slot?") #104524
Open

lambdageek added 2 commits October 31, 2024 10:15

whitespace
a54db74

remove TypeHandleFromAddress from contract
bdc6479
we just use GetTypeHandle now

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] MutexTests - operation does not support unaligned accesses #96191
Open

lambdageek added 4 commits October 31, 2024 14:55

clean up MethodClassification -> size lookups
0867c68

document RuntimeTypeSystem contract additions
f0603e3

update the CodeVersions contract to match implementation
4ff2f72

remove some TODO comments
3d342f6

lambdageek added 2 commits October 31, 2024 15:56

fix build
3bacf70

add sizes for method desc subclasses
9f8adeb
the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

davidwrighton approved these changes Nov 1, 2024
View reviewed changes

lambdageek merged commit 65d6ef6 into dotnet:mainNov 1, 2024

github-actionsBot locked and limited conversation to collaborators Dec 2, 2024

lambdageekand others added 30 commits August 19, 2024 10:14

remove instance field initialization from PrecodeMachineDescriptor
04f41f6
PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

suggestion from code review make m_IsCollectible a const BYTE
abf9df0

fixup
71dee34

Revert "fixup"
2fbc89e
This reverts commit bc45c00.

Revert "suggestion from code review make m_IsCollectible a const BYTE"
2e3b938
This reverts commit b1c7c36.

move PrecodeStubs to a separate contract
1776abe

ExecutionManager contract
099b5fa

rename contract NativeCodePointers => CodeVersions
50046b8

ReJIT contract
e2d637b

formatting, comments and whitespace
7724fa8

cleanup
a53b3ae

"NDirect" -> "PInvoke" in descriptor and contracts
124ee6a

WIP: contract writeups
fb1676b

fix build
f1d757e

placeholder ExecutionManager contract
f1d7be8

placeholder ExecutionManager contract; updates to RTS and Loader
ebb4a67

refactor ExecutionManager
aac3faf

remove dead method from contract
ef51f0e

fix typo
92764a2

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
4e1a620

Apply suggestions from code review
037c349

Add PrecodeStubs contract writeup
25d8343

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
ac0165a

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
8f5e98b

checkpoint: Abstractions
81fe51b

checkpoint begin moving contracts to Abstractions
c376c4c

rationalize IContractFactory
9c3f010

move IObject contract
7ec2f79

fixup interfaces
efaff82

move IRuntimeTypeSystem contract
c8b5c3f

lambdageek added 3 commits October 30, 2024 13:33

checkpoint GetMethodToken test passes
babbe44

fixup merge
a6bce83

move MethodValidation to a separate class
c74390f
also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

lambdageek marked this pull request as ready for review October 30, 2024 18:40

lambdageek requested review from AaronRobinsonMSFT, davidwrighton, elinor-fung and max-charlamb October 30, 2024 18:40

AaronRobinsonMSFT reviewed Oct 30, 2024
View reviewed changes

Comment thread...managed/cdacreader/Microsoft.Diagnostics.DataContractReader.Contracts/Legacy/ICorProfiler.cs Outdated
Comment threadsrc/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs Outdated

lambdageekand others added 3 commits October 30, 2024 15:30

move COR_PRF_MONITOR into ReJIT_1
292101b
it's an implementation detail

Update src/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs
ab16aa8
Co-authored-by: Aaron Robinson <arobins@microsoft.com>

assert the expected slot number
caee264

davidwrighton reviewed Oct 30, 2024
View reviewed changes

Comment thread...acreader/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/RuntimeTypeSystem_1.cs Outdated
Comment thread...rosoft.Diagnostics.DataContractReader.Contracts/RuntimeTypeSystemHelpers/MethodValidation.cs Outdated

Exercise a few more easy properties of MethodDesc
564c7e4

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] System.Net.Http.Functional.Tests failure ("Why are we setting the target on an unoccupied slot?") #104524
Open

lambdageek added 2 commits October 31, 2024 10:15

whitespace
a54db74

remove TypeHandleFromAddress from contract
bdc6479
we just use GetTypeHandle now

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] MutexTests - operation does not support unaligned accesses #96191
Open

lambdageek added 4 commits October 31, 2024 14:55

clean up MethodClassification -> size lookups
0867c68

document RuntimeTypeSystem contract additions
f0603e3

update the CodeVersions contract to match implementation
4ff2f72

remove some TODO comments
3d342f6

lambdageek added 2 commits October 31, 2024 15:56

fix build
3bacf70

add sizes for method desc subclasses
9f8adeb
the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

davidwrighton approved these changes Nov 1, 2024
View reviewed changes

lambdageek merged commit 65d6ef6 into dotnet:mainNov 1, 2024

github-actionsBot locked and limited conversation to collaborators Dec 2, 2024

lambdageekand others added 30 commits August 19, 2024 10:14

remove instance field initialization from PrecodeMachineDescriptor
04f41f6
PrecodeMachineDescriptor::Init() will initialize g_PrecodeMachineDescriptor

suggestion from code review make m_IsCollectible a const BYTE
abf9df0

fixup
71dee34

Revert "fixup"
2fbc89e
This reverts commit bc45c00.

Revert "suggestion from code review make m_IsCollectible a const BYTE"
2e3b938
This reverts commit b1c7c36.

move PrecodeStubs to a separate contract
1776abe

ExecutionManager contract
099b5fa

rename contract NativeCodePointers => CodeVersions
50046b8

ReJIT contract
e2d637b

formatting, comments and whitespace
7724fa8

cleanup
a53b3ae

"NDirect" -> "PInvoke" in descriptor and contracts
124ee6a

WIP: contract writeups
fb1676b

fix build
f1d757e

placeholder ExecutionManager contract
f1d7be8

placeholder ExecutionManager contract; updates to RTS and Loader
ebb4a67

refactor ExecutionManager
aac3faf

remove dead method from contract
ef51f0e

fix typo
92764a2

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
4e1a620

Apply suggestions from code review
037c349

Add PrecodeStubs contract writeup
25d8343

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
ac0165a

Merge remote-tracking branch 'origin/main' into cdac-nativecodeptr
8f5e98b

checkpoint: Abstractions
81fe51b

checkpoint begin moving contracts to Abstractions
c376c4c

rationalize IContractFactory
9c3f010

move IObject contract
7ec2f79

fixup interfaces
efaff82

move IRuntimeTypeSystem contract
c8b5c3f

lambdageek added 3 commits October 30, 2024 13:33

checkpoint GetMethodToken test passes
babbe44

fixup merge
a6bce83

move MethodValidation to a separate class
c74390f
also move method flags out of the RuntimeTypeSystem_1 contract for the cases where the method validation needs to call back to type validation, go via the contract

lambdageek marked this pull request as ready for review October 30, 2024 18:40

lambdageek requested review from AaronRobinsonMSFT, davidwrighton, elinor-fung and max-charlamb October 30, 2024 18:40

AaronRobinsonMSFT reviewed Oct 30, 2024
View reviewed changes

Comment thread...managed/cdacreader/Microsoft.Diagnostics.DataContractReader.Contracts/Legacy/ICorProfiler.cs Outdated
Comment threadsrc/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs Outdated

lambdageekand others added 3 commits October 30, 2024 15:30

move COR_PRF_MONITOR into ReJIT_1
292101b
it's an implementation detail

Update src/native/managed/cdacreader/src/Legacy/SOSDacImpl.cs
ab16aa8
Co-authored-by: Aaron Robinson <arobins@microsoft.com>

assert the expected slot number
caee264

davidwrighton reviewed Oct 30, 2024
View reviewed changes

Comment thread...acreader/Microsoft.Diagnostics.DataContractReader.Contracts/Contracts/RuntimeTypeSystem_1.cs Outdated
Comment thread...rosoft.Diagnostics.DataContractReader.Contracts/RuntimeTypeSystemHelpers/MethodValidation.cs Outdated

Exercise a few more easy properties of MethodDesc
564c7e4

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] System.Net.Http.Functional.Tests failure ("Why are we setting the target on an unoccupied slot?") #104524
Open

lambdageek added 2 commits October 31, 2024 10:15

whitespace
a54db74

remove TypeHandleFromAddress from contract
bdc6479
we just use GetTypeHandle now

build-analysisBot mentioned this pull request Oct 31, 2024
[browser][MT] MutexTests - operation does not support unaligned accesses #96191
Open

lambdageek added 4 commits October 31, 2024 14:55

clean up MethodClassification -> size lookups
0867c68

document RuntimeTypeSystem contract additions
f0603e3

update the CodeVersions contract to match implementation
4ff2f72

remove some TODO comments
3d342f6

lambdageek added 2 commits October 31, 2024 15:56

fix build
3bacf70

add sizes for method desc subclasses
9f8adeb
the "additional pointers" logic in RuntimeTypeSystem_1 depends on the sizes

davidwrighton approved these changes Nov 1, 2024
View reviewed changes

lambdageek merged commit 65d6ef6 into dotnet:mainNov 1, 2024

github-actionsBot locked and limited conversation to collaborators Dec 2, 2024

Uh oh!

Conversation

lambdageek commented Oct 24, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

davidwrighton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

lambdageek commented Oct 30, 2024

Uh oh!

davidwrighton commented Oct 30, 2024

Uh oh!

lambdageek commented Oct 31, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

lambdageek commented Oct 24, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

davidwrighton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

lambdageek commented Oct 30, 2024

Uh oh!

davidwrighton commented Oct 30, 2024

Uh oh!

lambdageek commented Oct 31, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

lambdageek commented Oct 24, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

davidwrighton left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

lambdageek commented Oct 30, 2024

Uh oh!

davidwrighton commented Oct 30, 2024

Uh oh!

lambdageek commented Oct 31, 2024• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

lambdageek commented Oct 24, 2024•
edited
Loading

lambdageek commented Oct 31, 2024•
edited
Loading

lambdageek commented Oct 24, 2024•
edited
Loading

lambdageek commented Oct 31, 2024•
edited
Loading

lambdageek commented Oct 24, 2024•
edited
Loading

lambdageek commented Oct 31, 2024•
edited
Loading

lambdageek commented Oct 24, 2024•
edited
Loading

lambdageek commented Oct 31, 2024•
edited
Loading

lambdageek commented Oct 24, 2024•
edited
Loading

lambdageek commented Oct 31, 2024•
edited
Loading