[fpc-devel] Aligned dynamic arrays / Maybe implement in mem-mgr?
lazarus at mfriebe.de
Fri Mar 29 18:21:41 CET 2019
On 29/03/2019 17:53, Ryan Joseph wrote:
> First minor snag, fpc_dynarray_insert, fpc_dynarray_concat can allocate new arrays like SetLength can. Do we need to make aligned variants for these also? Using array + operators there is no possibility to set alignment.
> 1) ignore the problem
> 2) make extra syntax like:
> a: array of integer; alignment = 64;
> 3) make another function to allocate an empty array that sets alignment
> SetAlignment(a, 64);
> 4) for insert/concat make variants like InsertAligned() and ignore + operators for aligned arrays
Question: Should the alignment be "user data" or "type info".
Does it need to be determined at runtime, and set to different values
(for the same type/variable) at runtime?
If not, i.e. if a specific variable always needs 4k alignment, would it
not be more logical to make it part of the type?
type TFoo = array [x..y] of byte aligned 4096;
Of course that does not change the above problem.
The (current or fixed) alignment needs to be stored, so concat can
retrieve it and honour it.
Stored either in the header or the RTTI type info
Would it not be more efficient, if the alignment would happen in the
Then no over-allocation would be needed. And the memory that is skipped
in front of the array could be used for other data.
The memory manager would need 2 new methods:
So the array still needs to know, it was allocated with Allignment and
call the correct FreeMemWithAllignment.
As a default for all memory manager AllocMemAtAllignment could do the
over-allocate, and return the correct pointer, with the mem-managers
Individual MemManagers can then be optimized.
pseudo code for AllocMemAtAllignment
mem := alloc(size+align+sizeof(MemMgrAlignHeader))
result := getNextAlignedAddr(mem+sizeof(MemMgrAlignHeader))
(result-sizeof(MemMgrAlignHeader)) ^.RealAllocAddr := mem;
The result looks then like
result - header:
// At least size bytes
So pretty much what would have happened in the array code. But moved to
So it can be:
a) re-used for other types or even called by usercode
b) a mem-manager that can get the aligned address without padding, can
be optimized, and return a normal block of memory
(does not even need the MemMgrAlignHeader)
More information about the fpc-devel