Skip to content

Commit 50c7500

Browse files
committed
AAL: introduce capptr_size_round, use w/ metadata
1 parent 2ee522c commit 50c7500

File tree

4 files changed

+55
-0
lines changed

4 files changed

+55
-0
lines changed

src/snmalloc/aal/aal.h

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -215,6 +215,11 @@ namespace snmalloc
215215
return CapPtr<T, BOut>::unsafe_from(
216216
a.template as_static<T>().unsafe_ptr());
217217
}
218+
219+
static SNMALLOC_FAST_PATH size_t capptr_size_round(size_t sz) noexcept
220+
{
221+
return sz;
222+
}
218223
};
219224
} // namespace snmalloc
220225

src/snmalloc/aal/aal_cheri.h

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -88,5 +88,29 @@ namespace snmalloc
8888
void* pb = __builtin_cheri_bounds_set_exact(a.unsafe_ptr(), size);
8989
return CapPtr<T, BOut>::unsafe_from(static_cast<T*>(pb));
9090
}
91+
92+
static SNMALLOC_FAST_PATH size_t capptr_size_round(size_t sz) noexcept
93+
{
94+
/*
95+
* Round up sz to the next representable value for the target
96+
* architecture's choice of CHERI Concentrate T/B mantissa width.
97+
*
98+
* On Morello specifically, this intrinsic will (soon, as of this text
99+
* being written) expand to a multi-instruction sequence to work around a
100+
* bug in which sz values satisfying $\exists_E sz = ((1 << 12) - 1) <<
101+
* (E + 3)$ are incorrectly increased. If for some reason this ends up
102+
* being at all hot, there will also be a
103+
* __builtin_morello_round_representable_length_inexact, which will just
104+
* return too big of a size for those values (by rounding up to $1 << (E
105+
* + 15)$). While technically incorrect, this behavior is probably fine
106+
* for snmalloc: we already slot metadata allocations into NAPOT holes
107+
* and then return any unused space at the top, so the over-reach would,
108+
* at the worst, just prevent said return, and our sizeclasses never run
109+
* into this issue. That is, we're clear to use the __builtin_morello_*
110+
* intrinsic if the multi-instruction sequence proves slow. See
111+
* https://git.morello-project.org/morello/llvm-project/-/merge_requests/199
112+
*/
113+
return __builtin_cheri_round_representable_length(sz);
114+
}
91115
};
92116
} // namespace snmalloc

src/snmalloc/aal/aal_concept.h

Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -59,6 +59,28 @@ namespace snmalloc
5959
AAL::template capptr_bound<void, capptr::bounds::Chunk>(auth, sz)
6060
}
6161
noexcept->ConceptSame<capptr::Chunk<void>>;
62+
63+
/**
64+
* Round up an allocation size to a size this architecture can represent.
65+
* While there may also, in general, be alignment requirements for
66+
* representability, in snmalloc so far we have not had reason to consider
67+
* these explicitly: when we use our...
68+
*
69+
* - sizeclass machinery (for user-facing data), we assume that all
70+
* sizeclasses describe architecturally representable aligned-and-sized
71+
* regions
72+
*
73+
* - Range machinery (for internal meta-data), we always choose NAPOT
74+
* regions big enough for the requested size (returning space above the
75+
* allocation within such regions for use as smaller NAPOT regions).
76+
*
77+
* That is, capptr_size_round is not needed on the user-facing fast paths,
78+
* merely internally for bootstrap and metadata management.
79+
*/
80+
{
81+
AAL::capptr_size_round(sz)
82+
}
83+
noexcept->ConceptSame<size_t>;
6284
};
6385

6486
template<typename AAL>

src/snmalloc/backend/backend.h

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -43,6 +43,10 @@ namespace snmalloc
4343
alloc_meta_data(LocalState* local_state, size_t size)
4444
{
4545
capptr::Arena<void> p;
46+
47+
// Meta-data does not use our sizeclass machinery, so have Aal round up
48+
size = Aal::capptr_size_round(size);
49+
4650
if (local_state != nullptr)
4751
{
4852
p = local_state->get_meta_range().alloc_range_with_leftover(size);

0 commit comments

Comments
 (0)