Tarantool development patches archive
 help / color / mirror / Atom feed
From: Konstantin Osipov <kostja@tarantool.org>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [PATCH 1/1] small: introduce static allocator
Date: Sat, 4 May 2019 09:53:36 +0300	[thread overview]
Message-ID: <20190504065336.GC16696@atlas> (raw)
In-Reply-To: <b34f6cdf-3e39-237f-1ba1-b50b06e89acc@tarantool.org>

* Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [19/05/04 09:38]:
> >>>
> >>> 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.

On this argument... to use static alloc in mpstream, not aligning 
the return value is not enough.
You actually need something a batch alloc API, something 
like:
- static_alloc_begin_batch() - resets the buffer and sets the
position to 0,
- static_alloc_alloc_batch() - alloc memory, but return error if
  allocation would wrap around, since we need to make sure all
  allocation in a batch stay valid
- static_alloc_end_batch() - finish allocating memory within 
  a batch

Otherwise, how do you guarantee that a subsequent alloc used by
mpstream doesn't wrap the static buffer around and begins
overwriting it?


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

      parent reply	other threads:[~2019-05-04  6:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-28 18:41 [tarantool-patches] " Vladislav Shpilevoy
2019-05-02 15:43 ` [tarantool-patches] " Vladislav Shpilevoy
2019-05-03 21:26 ` Konstantin Osipov
2019-05-03 21:32   ` Vladislav Shpilevoy
2019-05-03 21:36     ` Konstantin Osipov
2019-05-03 23:49       ` Vladislav Shpilevoy
2019-05-04  6:50         ` Konstantin Osipov
2019-05-04 18:09           ` Vladislav Shpilevoy
2019-05-04  6:53         ` Konstantin Osipov [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190504065336.GC16696@atlas \
    --to=kostja@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --cc=v.shpilevoy@tarantool.org \
    --subject='[tarantool-patches] Re: [PATCH 1/1] small: introduce static allocator' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox