[tarantool-patches] Re: [PATCH 1/1] small: introduce static allocator

[Vladislav Shpilevoy <v.shpilevoy@tarantool.org>]

On 04/05/2019 00:36, Konstantin Osipov wrote:
> * Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [19/05/04 00:34]:
>>> OK to push.
>>>
>>> Shouldn't you align the address or provide an aligned alloc along
>>> with the basic one?
>>
>> I thought about a function like static_aligned_alloc just like we
>> have for region, but was not sure if we need it now. There are no
>> code uses old tt_static_buf for data needed alignment. I hoped we
>> could implement it on demand.
>>
>> But if you think we should implement it now, I can do that.
>> Should I?
> 
> Previously tt_static_buf allocations were always aligned, since
> the next alloc would always allocate at position 0 in the buffer.
> Now you provide a general purpose alloc more or less, which can
> start at any position in the buffer. I would simple ensure that
> static_alloc() is intptr_t aligned. We can add an aligned alloc
> later.
If we align reserve() or alloc() by default, we would break the
pattern, when we do big reserve of maximal size and then lots of
small allocs of exact sizes. Works when we do not know how many
bytes a big complex object will occupy.

We use that for mpstream with obuf, ibuf, region, and somewhere in
SQL for pure region without mpstream. All our allocators guarantee
now, that if you succeed at a big reserve(), you can consume this
memory in multiple allocs, without gaps.

Additionally it contradicts with region API (the only allocator,
providing aligned allocations) - it has separate reserve + alloc, and
aligned_reserve + aligned_alloc.

I would rather implement separately normal static_alloc/reserve +
static_aligned_alloc/aligned_reserve.

Are you okay with that?

> 
> 
> -- 
> Konstantin Osipov, Moscow, Russia, +7 903 626 22 32
>