This can optimize cases in a allocate-release loop that moves back
and forth across the end of one block and the start of another. Before
this would malloc a new block and then delete it.
It also enables reserve() in higher-level data collections w/o blocking
bytes left in the current tail block.
Change-Id: Ide16e9038384fcb188164fc9620a8295f6880b9f
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303268
Reviewed-by: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Previously, the blocks owned by a GrBlockAllocator provided block-level
metadata that users could control to track within a block. For types
like GrTAllocator (and a collection coming down the pipe), they need
to store a total count of allocations.
Since GrBlockAllocator is max-aligned, having them hold on to a single
extra int adds 4 to 12 bytes of padding for 8 and 16byte aligned
platforms. But, the old Block size already has 4 bytes of extra padding
since it was 28 bytes packed. This had been allowed to be allocation
data, for requests that were 4-byte aligned or less.
In practice, I think it's better to use that space for allocator-level
metadata so that a total count, or other high-level data, can be
packed into the data already held by GrBlockAllocator. Now GrTAllocator
instances should be 8-16 bytes smaller on those same platforms. Also
no longer writing into the struct-padded nether-realm, which is probably
just a good thing on principle.
Also cleans up how GrTAllocator's push_back() and emplace_back() are
tested to make sure all options are clearly covered.
Change-Id: If1da29132f3ec8df7a4056fcd834f760eb4693f5
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303267
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Change-Id: I5bf9470a3d7822ea1edee7abf693037322e5d4e6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/303265
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Auto-Submit: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This allows the iterator type/boilerplate to be reused for any other
data collection that sits above GrBlockAllocator, as long as its a fixed
"type" with indices into a block.
Also adds reverse iteration (which is useful for stack-like use cases).
Change-Id: Id9a205e8fb396a8558e360439240fd20c92c9700
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/302665
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Allow push_back to take an rvalue to move into the allocator, which has
the nice side effect of making the test for it a bit better.
Change-Id: I7e313cf75c1ad65fbf765b10c4717672063b5570
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/280412
Reviewed-by: Michael Ludwig <michaelludwig@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Previously, the GrAllocator header defined three types: GrAllocator,
GrTAllocator, and GrSTAllocator. GrAllocator was generic, and would
manage the blocks of memory (fixed size to hold N * sizeof(item)). It
stored an SkTArray of pointers to each block. GrTAllocator wrapped
the GrAllocator to add template support for a specific T. GrSTAllocator
extended GrTAllocator to include a template arg for inline storage.
In this CL, GrAllocator is no longer defined, and its memory functionality
is replaced with the use of GrBlockAllocator. For the most part, the
implementation of GrTAllocator on top of GrBlockAllocator remains the
same, although there is explicit array to the block pointers so indexing
is slightly different. GrSTAllocator is also removed entirely, so that
GrTAllocator's template includes initial storage size.
The iteration over the allocated items
is updated to wrap GrBlockAllocator's block iterator, and then iterate
by index within each block. Documentation on GrAllocator already recommended
using the iterator instead of random access, and these changes further
reinforce it. It turns out that many of the use cases of GrAllocator
were written to use random access, so many of the files outside of
GrAllocator.h have just been updated to use the new for-range iteration
instead of a random access for loop.
Change-Id: I28b0bc277c323fd7035d4a8442ae67f058b2b64c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/272058
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
Reviewed-by: Chris Dalton <csmartdalton@google.com>
