How to change malloc memory alignment, 64-bits system must align 16-bytes, 32-bits system must align 8-bytes.

[jianjunjiang]

The memory address allocated by the malloc function must be aligned twice void *, which means that for 64-bit system, 16-byte alignment is required, and for 32-bit system requires 8-byte alignment.

If you simply modify the macro definition, TLSF will crash directly. How to do this modification?

diff --git a/tlsf.c b/tlsf.c
index af57573..6e87539 100644
--- a/tlsf.c
+++ b/tlsf.c
@@ -211,15 +211,15 @@ enum tlsf_public
        SL_INDEX_COUNT_LOG2 = 5,
 };

-/* Private constants: do not modify. */
+/* Private constants: do not modify. why ??? */
 enum tlsf_private
 {
 #if defined (TLSF_64BIT)

-       /* All allocation sizes and addresses are aligned to 8 bytes. */
-       ALIGN_SIZE_LOG2 = 3,

+       /* All allocation sizes and addresses are aligned to 8(->16) bytes. */
+       ALIGN_SIZE_LOG2 = 4,
         #else

-       /* All allocation sizes and addresses are aligned to 4 bytes. */
-       ALIGN_SIZE_LOG2 = 2,

+       /* All allocation sizes and addresses are aligned to 4(->8) bytes. */
+       ALIGN_SIZE_LOG2 = 3,
         #endif
        ALIGN_SIZE = (1 << ALIGN_SIZE_LOG2),
        

[pavel-kirienko]

Consider o1heap perhaps. It is also a constant-complexity, well-characterized allocator, but it doesn't make nontrivial assumptions about the target platform (such as limiting the memory alignment to the pointer size). I am obviously biased though because I am the author of that library, so beware.

[gulmezmerve]

@pavel-kirienko I am wondering if 01heap can work with 16-byte alignment on 64 bits targets?

[pavel-kirienko]

@gulmezmerve Yes.

[lfnoise]

I was interested to check out o1heap. One discovery is that worst case memory consumption occurs exactly in the case where you are making power of 2 sized allocation requests, which would seem to be a common case. This is because the consumed size is the next power of two of (the requested size + the fragment header size). This will nearly double all power of two sized allocations.

…

On Thu, Oct 28, 2021 at 7:10 PM Pavel Kirienko ***@***.***> wrote: Consider o1heap <https://github.com/pavel-kirienko/o1heap> perhaps. It is also a constant-complexity, well-characterized allocator, but it doesn't make nontrivial assumptions about the target platform (such as limiting the memory alignment to the pointer size). I am obviously biased though because I am the author of that library, so beware. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAJZTZF7ED5LTQGFU65RDLUJIGB7ANCNFSM4UAJCVJQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

-- --- james mccartney

[pavel-kirienko]

@lfnoise The worst case occurs at the power of two minus the overhead size plus one; on a 32-bit platform that would be the power of two minus 15 bytes. The statement about the consumed size is correct though.

The point of o1heap is that its worst-case memory consumption in the case of the worst-case heap fragmentation is lower than that of TLSF due to its more favorable placement of used blocks. There is an overview of this matter in the README; the most relevant part is quoted below:

[lfnoise]

On Thu, Aug 15, 2024 at 3:25 PM Pavel Kirienko ***@***.***> wrote: @lfnoise <https://github.com/lfnoise> The worst case occurs at the power of two plus the overhead size minus one; on a 32-bit platform that would be the power of two plus 15 bytes.

OK, is it true that if I am allocating 1024 bytes, for example, that a fragment of size 2048 bytes will be consumed because of this line?: const size_t fragment_size = roundUpToPowerOf2(amount + O1HEAP_ALIGNMENT); And for any other power of two size, it also will consume twice the requested amount? So, if my use case is that I will almost always be allocating exact powers of two, that this allocator will consume at very near worst case?

…

The point of o1heap is that its worst-case memory consumption in the case of the worst-case heap fragmentation is lower than that of TLSF due to its more favorable placement of used blocks. There is an overview of this matter in the README; the most relevant part is quoted below: image.png (view on web) <https://github.com/user-attachments/assets/b215c7d8-54af-4d68-bb3e-c09781bb4a9e> — Reply to this email directly, view it on GitHub <#16 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACAJZT7VDJY72CVR57I7WK3ZRUTF5AVCNFSM6AAAAABMKDONNSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJSGM4TGNZWGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- --- james mccartney

[pavel-kirienko]

OK, is it true that if I am allocating 1024 bytes, for example, that a
fragment of size 2048 bytes will be consumed because of this line?:

Yes. Power-of-two allocation is close to the worst case of the inner fragmentation indeed. The inner fragmentation would be zero if you were allocating, say, 1008 bytes, just to illustrate the point.

And for any other power of two size, it also will consume twice the
requested amount?

This is accurate.

So, if my use case is that I will almost always be allocating exact powers
of two, that this allocator will consume [a lot of memory]?

Yes (for the edited quote). In general, if you care about the average-case performance rather than worst-case performance, then o1heap is unlikely to suit your application. It is intended for mission-critical real-time systems (like embedded systems, incl. safety-critical ones), where the worst case is of the primary concern while the average-case performance is often irrelevant.

Keep in mind the difference between the inner fragmentation and the outer fragmentation. Half-fit allocators (which o1heap is one example of) do have a much higher inner fragmentation due to the power-of-2 rounding, but the upshot is that the worst-case outer fragmentation has a much tighter bound compared to best-fit allocators like TLSF. The result is that the worst-case total memory consumption is lower for half-fit allocators than best-fit ones. If you're curious about the background, there are excellent articles linked from the README I mentioned earlier.

It is not correct nor useful to gauge the worst-case memory consumption of an allocator without considering the outer fragmentation.