-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
JIT: initial support for stack allocating arrays of GC type #112250
base: main
Are you sure you want to change the base?
Conversation
Add the ability to create a ClassLayout for arrays, and use this to unblock stack allocation for arrays with GC types. Replaces dotnet#111686.
Tagging subscribers to this area: @JulieLeeMSFT, @jakobbotsch |
@jakobbotsch PTAL This unblocks GC arrays of final types, but for GC arrays of non-final types many stores will use the covariant store check helper which currently causes the array to escape. So only a handful of diffs ( We need both a "only do the covariant store check" variant and a "do the covariant store check and then a checked write barrier" variant. |
} | ||
else | ||
{ | ||
elementSize = genTypeSize(type); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose if we really wanted to we could provide a constructor for a class layout for primitive types, which could be used to unify paths like these.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like that might have been the original intention since we bias the indexes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In any case we can just create them as custom layouts now, but I suppose it would be slightly less efficient than this approach.
@@ -828,7 +828,7 @@ unsigned int ObjectAllocator::MorphNewArrNodeIntoStackAlloc(GenTreeCall* | |||
blockSize = AlignUp(blockSize, 8); | |||
} | |||
|
|||
comp->lvaSetStruct(lclNum, comp->typGetBlkLayout(blockSize), /* unsafeValueClsCheck */ false); | |||
comp->lvaSetStruct(lclNum, comp->typGetArrayLayout(clsHnd, length), /* unsafe */ false); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to propagate the layout through instead of blockSize
? We could probably save a call to getChildType
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I should get rid of the redundant layout fetch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Only a small step from there to using layouts everywhere.
I think I should do that first (leaving GC arrays disabled) and verify zero diff, then come back to this and enable gc arrays.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After poking at it some, I think it might be simpler to take this change first and then revise the entire thing to be more layout centric (getting rid of the special box type, etc).
Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds fine to me.
Add the ability to create a ClassLayout for arrays, and use this to unblock stack allocation for arrays with GC types.
Replaces #111686.