On Fri, 2 Jun 2023 08:38:36 GMT, Alan Bateman <al...@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 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1214174042
