On Wed, 22 Jan 2025 12:36:17 GMT, Matthias Ernst <d...@openjdk.org> wrote:
>> On another note: in principle if a Frame is not the latest returned in a >> given thread, it is not safe to allow its allocation method (and probably >> close too) to succeed. Consider this case: >> >> >> Arena arenaOuter = bufferStack.reserve(100); >> arenaOuter.allocate(16); // now offset is 16 >> ... >> Arena arenaInner = bufferStack.reserve(100); >> arenaInner.allocate(16); // now offset is 32 >> arenaOuter.allocate(16); // now offset is 48 // whooops >> ... >> arenaInner.close(); // now offset is 16 >> arenaOuter.allocate(16); // now offset is 32 >> arenaOuter.allocate(16); // now offset is 48 (overwriting!!) >> >> >> The last statement in this snippet effectively overwrites the memory that >> has been previously allocated _by the same frame_. This is because we allow >> `arenaOuter::allocate` to work even after `arenaInner` has been obtained >> (see statement with `whooops` comment). >> >> Now, I believe the linker implementation is "correct" and never attempts >> something like this - other clients might try something similar and get >> surprising result. So, in the general case, I believe we should think about >> this (although it's fine if you do not want to tackle that in this PR) > > Right. Using SlicingAllocator now. > > Which brings up one question about alignment of the stack frames. When the > linker asks for a buffer, it also has an alignment requirement. Do we > guarantee anything about the alignment of Arena.ofConfined().allocate() ? > Does the linker overallocate already? > > To accomodate for this, I added a frame alignment parameter as well => the > stack itself is well-served by using a SlicingAllocator. For this, I added > methods to query and reset the position, as well as whether it could satisfy > a certain allocation request. And yes, this requires that a client operate in stack order. I added checks for this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1925251331
