-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Remove AllocLHeap
.
#33402
Remove AllocLHeap
.
#33402
Conversation
src/coreclr/src/gc/gcinterface.h
Outdated
@@ -782,7 +779,7 @@ class IGCHeap { | |||
virtual Object* AllocAlign8(gc_alloc_context* acontext, size_t size, uint32_t flags) = 0; |
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.
Do we really need AllocAlign8 ?
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.
It is substantially different from regular Alloc and needed only on certain platforms. It seems convenient to have implementation in separate methods.
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.
For LOH - we could be forced to use LOH by the caller or decide to use it ourselves based on size. So Alloc has to know about large objects anyways.
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.
The implementation can be inside a separate method in the GC. That's fine.
I am looking at it from the GC interface definition point of view. We do have GC_ALLOC_ALIGN8
flag. It is odd that you can call regular Alloc
for all other combination of flags, except when you have this specific flag - you need to call this other method.
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 see that GC_ALLOC_ALIGN8
is not used. Perhaps it was meant to be used in Alloc.
Let's unify Alloc and AllocAlign8 at API level.
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 see that GC_ALLOC_ALIGN8 is not used. Perhaps it was meant to be used in Alloc.
It has been used in .NET Native / CoreRT that has things more unified, but this unification did not make it into the master GC sources.
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.
Removed AllocAlign8
. It did reduce some duplication.
… instead of per-thread. There is no advantage in that and results in allocations under-reported in `GetAllocatedBytesForCurrentThread` This change unifies to one allocation entry point - `Alloc` (and its `AllocAlign8` variety)
src/coreclr/src/vm/gchelpers.cpp
Outdated
(GC_ALLOC_ALIGN8_BIAS | GC_ALLOC_ALIGN8) : | ||
GC_ALLOC_ALIGN8; | ||
|
||
orObject = (Object *) Alloc(baseSize, flags); |
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.
You can merge this with the else
part.
src/coreclr/src/vm/gchelpers.cpp
Outdated
@@ -754,7 +671,7 @@ OBJECTREF AllocateArrayEx(MethodTable *pArrayMT, INT32 *pArgs, DWORD dwNumArgs, | |||
// cases we care about (single and multi-dim arrays of value types) have an even number of DWORDs | |||
// in their headers so the alignment requirements for the header and the payload are the same. | |||
_ASSERTE(((pArrayMT->GetBaseSize() - SIZEOF_OBJHEADER) & 7) == 0); | |||
orArray = (ArrayBase *) AllocAlign8(totalSize, flags); | |||
orArray = (ArrayBase*)Alloc(totalSize, flags | GC_ALLOC_ALIGN8); |
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.
Same here.
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.
(and other places)
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.
This is about the 3 places where GC_ALLOC_ALIGN8
is used, right?
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.
Right
src/coreclr/src/vm/gchelpers.cpp
Outdated
{ | ||
#else // ! FEATURE_64BIT_ALIGNMENT |
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.
Two ifdefs may be more readable than #if / #else / #endif. #ifdefs around unmatched {
are hard to read.
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.
It was also causing build issues on arm.
src/coreclr/src/gc/gcinterface.h
Outdated
@@ -7,7 +7,7 @@ | |||
|
|||
// The major version of the GC/EE interface. Breaking changes to this interface | |||
// require bumps in the major version number. | |||
#define GC_INTERFACE_MAJOR_VERSION 4 | |||
#define GC_INTERFACE_MAJOR_VERSION 5 |
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 don't think you need to increase this again, it was already increased with your last checkin to this file. we just need to increase it each time we actually release something
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 see. I thought we literally have to update every time we merge breaking changes :-)
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.
Was a bit surprised the number is so low.
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.
every time we make breaking changes that are publicly visible.
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.
…ease. And we already did for this one.
Thanks!! |
Fixes:#13734
The main difference of
AllocLHeap
is that it uses per-heap allocation context instead of per-thread one. There is no advantage in that and it results in allocation under-reporting inGetAllocatedBytesForCurrentThread
.It also came up in POH code reviews as unnecessary inconsistency that we do not want to carry forward.
This change unifies to one allocation entry point -
Alloc
and uses flags to indicate special behaviors.