On Tue, 2 Nov 2021 19:02:51 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>> 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) Maybe we should not support block size in the case of a bounded arena. i.e. just allocate the whole thing upfront, and have 3 APIs: 1. arena with no bounds and default block size. 2. arena with no bounds and custom block size. 3. arena with bounds, that has no blocks size but allocates the whole thing in one go (could be modeled as block size = arena size). Right now we have 1. and 2., but instead of 3. we have a variant that allows setting both the arena size and block size. If we want to keep what we currently have, I'd suggest changing the arena size to a block count for the variant that takes both the arena size and the block size (I think in that case `Long.MAX_VALUE` should still work?). Any ways, that seems like something that could be addressed in 19 as well. ------------- PR: https://git.openjdk.java.net/jdk/pull/5907
