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

don't allocate large block with MEM_TOP_DOWN by default #75

Closed
wants to merge 1 commit into from

Conversation

@gabr42
Copy link
Contributor

commented Apr 27, 2019

As it turns out (analysis here: https://www.thedelphigeek.com/2019/04/fastmm4-large-memory.html), allocating memory blocks with MEM_TOP_DOWN can bring in 5-15% penalty.

I'm proposing adding conditional symbol AllocateLargeBlocksTopDown. If it is defined, large blocks are allocated with MEM_TOP_DOWN, otherwise they are not.

By default, AllocateLargeBlocksTopDown should not be defined.

Copy link

left a comment

Please include AllocateLargeBlocksTopDown in the include file as well.

@@ -4425,7 +4425,7 @@ function AllocateLargeBlock(ASize: NativeUInt {$ifdef LogLockContention}; var AD
LLargeUsedBlockSize := (ASize + LargeBlockHeaderSize + LargeBlockGranularity - 1 + BlockHeaderSize)
and -LargeBlockGranularity;
{Get the Large block}
Result := VirtualAlloc(nil, LLargeUsedBlockSize, MEM_COMMIT or MEM_TOP_DOWN,
Result := VirtualAlloc(nil, LLargeUsedBlockSize, MEM_COMMIT {$ifdef AllocateLargeBlocksTopDown} or MEM_TOP_DOWN{$endif},

This comment has been minimized.

Copy link
@baka0815

baka0815 Apr 30, 2019

There is no entry for AllocateLargeBlocksTopDown in the FastMM4Options.inc file, so please include this also in your PR with a description why this define might be necessary.
Maybe near

{$define AlwaysAllocateTopDown}

@pleriche

This comment has been minimized.

Copy link
Owner

commented May 26, 2019

Hi Primoz,

Apologies for the long delay in responding. Things have been crazy busy.

With regards to MEM_TOP_DOWN being used for large blocks: The peformance penalty is a known factor, but there are benefits to allocating large blocks from the top down that outweigh the performance cost - at least in the tests I have done.

Segregating large and medium block pools at the two ends of the address space reduces address space fragmentation: Medium block pools are of a fixed size, so when a medium block pool is freed the space it occupied will most likely be reusable for the next medium block pool that is allocated. If large blocks were allowed to intersperse with medium blocks then fragmentation would increase. Additionally, the "segmented large block" feature would not work well if large blocks were interspersed with medium block pools.

This design decision was made before the 64-bit version was added, (under which address space fragmentation is less of a concern), but the segmented large block feature would still be less effective.

Best regards,
Pierre

@gabr42

This comment has been minimized.

Copy link
Contributor Author

commented May 29, 2019

Given the "segmented large block" problem, it is probably best to discard this pull request. Thanks for the explanation!

@gabr42 gabr42 closed this May 29, 2019
@Dave-Novo

This comment has been minimized.

Copy link

commented May 29, 2019

I think that leaving it as a compiler directive, with proper explanation of the pros and cons is still better than leaving as is. I am not sure how Pierre quantified the penalty induced by memory fragmentation vs the speed penalty of memory allocation with MEM_TOP_DOWN, but I am sure that it is situationally dependent. For those of us that do a lot of large block allocation, the speed benefit may outweigh any excess fragmentation. Fragmentation needs to be assessed in an typical usage scenario for a specific application so having the compiler define there at least allows us to easily do this profiling

@baka0815

This comment has been minimized.

Copy link

commented May 29, 2019

@gabr42
I would second @Dave-Novo. Please include the compile switch in the include file (see my comment above) and disable it by default. That way one can choose if the speed benefits weighs more than the possible fragmentation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.