Add ee_alloc_context (NativeAOT) #104851
Add ee_alloc_context (NativeAOT) #104851
Conversation
noahfalk
force-pushed
the
combined_limit_nativeaot
branch
2 times, most recently
from
e35512a
to
f01e191
Compare
I think you can add it in this PR. Adding the extra field is going to touch a lot of the same lines as this PR. |
|
(Also, same comment as #104851 (comment).) |
noahfalk
force-pushed
the
combined_limit_nativeaot
branch
2 times, most recently
from
8d9bb20
to
01933fa
Compare
noahfalk
force-pushed
the
combined_limit_nativeaot
branch
from
01933fa
to
96af2fc
Compare
|
@jkotas @MichalStrehovsky - I've applied the feedback from the CoreCLR issue to this one as well. Is anything else needed before you can signoff? |
|
/azp run runtime-nativeaot-outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
| @@ -163,6 +163,9 @@ extern "C" void PopulateDebugHeaders() | |||
| MAKE_DEBUG_FIELD_ENTRY(dac_gc_heap, finalize_queue); | |||
| MAKE_DEBUG_FIELD_ENTRY(dac_gc_heap, generation_table); | |||
|
|
|||
| MAKE_SIZE_ENTRY(ee_alloc_context); | |||
There was a problem hiding this comment.
@mikem8361 Is this going to need matching changes in SOS for native AOT? Do we need to bump the data contract version to make it work?
There was a problem hiding this comment.
Yes, this will require changes to the DCR/NativeAOT SOS and a minor version bump is needed.
There was a problem hiding this comment.
I think we'd want a major version bump because of the change to RuntimeThreadLocals below right? Code that expect gc_alloc_context to exist at RuntimeThreadLocals.m_rgbAllocContextBuffer isn't going to find that field any longer and anything that hardcoded the offset no longer has the right offset.
|
|
This change is some preparatory refactoring for the randomized allocation sampling feature. We need to add more state onto allocation context but we don't want to do a breaking change of the GC interface. The new state only needs to be visible to the EE but we want it physically near the existing alloc context state for good cache locality. To accomplish this we created a new ee_alloc_context struct which contains an instance of gc_alloc_context within it. The new ee_alloc_context::combined_limit should be used by fast allocation helpers to determine when to go down the slow path. Most of the time combined_limit has the same value as alloc_limit, but periodically we need to emit an allocation sampling event on an object that is somewhere in the middle of an AC. Using combined_limit rather than alloc_limit as the slow path trigger allows us to keep all the sampling event logic in the slow path.
- removed unnecessary UpdateCombinedLimit() in thread detach - updated comment for workaround on 96081 - swapped to updating combined_limit inside GcEnumAllocContexts() instead of in RestartEE()
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
-update the breaking change number on the debug header -remove unneeded whitespace -adjust combined_limit -> m_CombinedLimit
noahfalk
force-pushed
the
combined_limit_nativeaot
branch
from
57dd3f5
to
bc70bf5
Compare
|
I've updated for the feedback so far. Everything is addressed except NativeAOT SOS which has to be handled out-of-band. Looking at the time I think I may need to call it quits on this for .NET 9 and instead treat it as .NET 10 on a slower cadence. At this point I don't think I have more time available right now to do a staged checkin, revalidate testing after the ongoing changes, and continue to have time in reserve to respond to potential post-checkin issues. |
This change is some preparatory refactoring for the randomized allocation sampling feature. We need to add more state onto allocation context but we don't want to do a breaking change of the GC interface. The new state only needs to be visible to the EE but we want it physically near the existing alloc context state for good cache locality. To accomplish this we created a new ee_alloc_context struct which contains an instance of gc_alloc_context within it.
The new field ee_alloc_context::combined_limit should be used by fast allocation helpers to determine when to go down the slow path. Most of the time combined_limit has the same value as alloc_limit, but periodically we need to emit an allocation sampling event on an object that is somewhere in the middle of an AC. Using combined_limit rather than alloc_limit as the slow path trigger allows us to keep all the sampling event logic in the slow path.
There is another PR for CoreCLR making the same change: #104849