On Fri, 2 Jun 2023 09:58:54 GMT, Maurizio Cimadamore <mcimadam...@openjdk.org> wrote:
>>> I think SegmentAllocator should be agnostic re. thread safety. Allocation >>> is a world of compromises, where if you give up (thread) safety you can >>> gain more performance (and viceversa). So I think having a "one size fits >>> all" thread-safety blanket might not work very well. >> >> I'm just trying to think about the practical implications of this. Arena is >> specified to be thread-safe so I can allocate from a non-confined Arena, and >> from concurrent threads, without needing to coordinate. However, if you >> hand me a SegmentAllocator that is not an Arena then I don't know if I need >> to coordinate allocation with other parties. I'm not too concerned about the >> slicingAllocator and prefixAllocator factory methods as the result >> SegmentAllocators will likely be wrapped. > > In practice, SegmentAllocator will be used in two cases: > * as a parameter to a downcall method handle which returns a by-value struct > * as a building block to construct a custom arena > > In both cases, I think it's up to the client to decide how thread-safe > allocation should be. For instance, if you use a SegmentAllocator in a custom > arena, and the allocator is not thread-safe, well, you can always attach it > to a custom _confined_ arena (so that thread-unsafety is not a problem). I > think using a SegmentAllocator in isolation will be quite rare. Note that, beside thread-safety, there are other things that are inconvenient about a segment allocator: * an allocator is not constrained to return segments with the same lifetime; * an allocator does not provide any guarantee re. aliasing memory. Same memory region could be written over and over (this is what prefixAllocator does); These facts make it hard for clients SegmentAllocator to interact with a SegmentAllocator they don't own (unless they have to allocate precisely _one_ segment, on behalf of the client, and return it to them - which, not surprisingly is also what the Linker does). So, with SegmentAllocators there's always an element of trust: a client gave me an allocator to obtain a slab of memory, I trust the client to have done what it needed to do so that my operation can be safe. If I happen to allocate garbage (as a result of a race) it's on them. If you need to allocate multiple segments in a single "session", and have some lifetime guarantees of the segments that have been allocated and/or you want to make sure that what you get is not garbage (e.g. thread-safety, aliasing, etc.), then you need Arena. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214183868
