RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]

[Maurizio Cimadamore]

On Fri, 2 Jun 2023 08:38:36 GMT, Alan Bateman <alanb at 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