On Tue, 2 Nov 2021 18:55:47 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> I'll have to think some more about this. I don't think this is covered >> inside the block - that is, the block tries to allocate, and then in the >> finally we throw if we realized we've allocated too much. > > What is missing, I think, is a check (size > arenaSize) at the beginning of > the method (we only check this in one of the paths). But we need to check > before and after, I think, as it is possible to allocate a segment and then > realize that we ended up overflowing the arena size. While what I said above correctly reflects what the implementation does, I think a broader issue is that the arena allocator implementation is allocating sometimes more native memory than what its contract specifies. While in some cases we can prevent that, I think in the general case (e.g. where we allocate a new block) we cannot, unless we add extra API guarantees - e.g. that the arena size should be a multiple of the block size (but then we'd have to special case `Long.MAX_VALUE`, or maybe pick a "big enough" power of two instead) ------------- PR: https://git.openjdk.java.net/jdk/pull/5907
