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

[Maurizio Cimadamore]

On Fri, 2 Jun 2023 09:58:54 GMT, Maurizio Cimadamore <mcimadamore 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'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