Comments on SegmentAllocator and ResourceScope

[Stig Rohde Døssing]

>
> I think it's a bit more than debugging, in that sense that APIs might
> depend on that to enforce correctness


That makes a lot of sense, did not consider that. Thanks for elaborating.

There's nothing preventing us from offering an overload which takes a block
> size
>

That's fair. In case you think it is likely you might want to add an
overload later, it might make sense to name the two "arenaAllocator"
methods in SegmentAllocator so their names reflect boundedness. If you want
to add an overload for the unbounded allocator that takes a chunk size, I
think you will end up conflicting with "arenaAllocator(long size,
ResourceScope scope)", which is the bounded variant (or you'd have to name
the new method something else)

Den man. 17. maj 2021 kl. 22.33 skrev Maurizio Cimadamore <
maurizio.cimadamore at oracle.com>:

>
> On 17/05/2021 19:40, Stig Rohde Døssing wrote:
> > Thanks for the explanations.
> >
> > That hardcoded default size seems reasonable enough to me as it's a
> >> trade off between various issues like system memory fragmentation,
> >> overheads, performance, and simplicity.
> >>
> >> The default size makes sense, but the SegmentAllocator example in JEP
> 412
> > says that memory allocation can be a bottleneck, and uses the unbounded
> > arena allocator in an example where many small off-heap arrays are sliced
> > off a block. This led me to believe that using an arena allocator should
> be
> > encouraged in any case where the application needs to allocate many
> > off-heap segments at once, but I am now getting the impression that this
> > was not what this example was intended to communicate, and the arena
> > allocator is only useful when the slices are very small (less than 2KB in
> > size), and there is no reason to use it when creating larger segments. Is
> > this correctly understood?
>
> I think that, as the JEP says, custom allocators (and hence arena
> allocators) are made for fine tuning memory allocation performances. As
> I said, since the API is relatively fresh, we didn't see use cases for
> providing flexibility in terms of threshold, but there's nothing
> preventing us from offering an overload which takes a block size.
>
>
> > I read that section as saying you need to use
> >> the handle methods to ensure proper behaviour, exceptions would then
> >> expose code faults
> >>
> >> Okay, so Handles are not a coordination utility, they are a guard
> > rail/debugging utility that makes the closing thread throw an exception
> if
> > "close" is called inappropriately, rather than letting the close happen,
> > and then potentially failing in an uglier way in the thread using the
> > resource, or further downstream. Right?
>
> I think it's a bit more than debugging, in that sense that APIs might
> depend on that to enforce correctness. For instance the socket
> implementation changes that were done recently to support byte buffers
> derived by shared segments make extensive use of scope handles. Without
> this use, it would be possible e.g. for an asyn IO request to cause a VM
> crash, first by requesting an async IO operation on a byte buffer backed
> by a segment, and then closing the segment _before_ (or _while) the IO
> operation has occurred.
>
>
> Maurizio
>