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

Remove AllocLHeap. #33402

Merged
merged 5 commits into from
Mar 11, 2020
Merged

Remove AllocLHeap. #33402

merged 5 commits into from
Mar 11, 2020

Conversation

VSadov
Copy link
Member

@VSadov VSadov commented Mar 9, 2020

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 in GetAllocatedBytesForCurrentThread.

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.

@@ -782,7 +779,7 @@ class IGCHeap {
virtual Object* AllocAlign8(gc_alloc_context* acontext, size_t size, uint32_t flags) = 0;
Copy link
Member

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 ?

Copy link
Member Author

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.

Copy link
Member Author

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.

Copy link
Member

@jkotas jkotas Mar 10, 2020

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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)
@VSadov VSadov changed the title [WIP] Remove AllocLHeap. Remove AllocLHeap. Mar 10, 2020
@VSadov VSadov marked this pull request as ready for review March 10, 2020 04:48
@VSadov VSadov requested a review from Maoni0 March 10, 2020 04:48
(GC_ALLOC_ALIGN8_BIAS | GC_ALLOC_ALIGN8) :
GC_ALLOC_ALIGN8;

orObject = (Object *) Alloc(baseSize, flags);
Copy link
Member

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.

@@ -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);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(and other places)

Copy link
Member Author

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right

{
#else // ! FEATURE_64BIT_ALIGNMENT
Copy link
Member

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.

Copy link
Member Author

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.

@@ -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
Copy link
Member

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

Copy link
Member Author

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 :-)

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member

@Maoni0 Maoni0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:shipit:

@VSadov
Copy link
Member Author

VSadov commented Mar 11, 2020

Thanks!!

@VSadov VSadov merged commit e4d01e3 into dotnet:master Mar 11, 2020
@VSadov VSadov deleted the alloclheap branch March 11, 2020 01:09
@ghost ghost locked as resolved and limited conversation to collaborators Dec 10, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants