Exposing concrete types of segments and addresses

[Quân Anh Mai]

Hi,

Currently, we can only access MemorySegments and MemoryAddresses through
the respective interface. While this provides a nice interface for all
kinds of memory segments, the lack of ability to use the concrete types
leads to a lot of performance caveats.

Firstly, polymorphism disables scalarization. While a non-escaped object
can be scalarized in most cases, there are still circumstances that scalar
replacement fails (e.g when we want to continuously slice a segment in a
loop). Furthermore, this makes us become dependent on the inlining ability
of the compiler, which is unpredictable and limits the use of segments and
addresses for desired performance. On the other hand, scalarization of
polymorphic types in fields and calling convention seems to be really
really complicated. With primitive classes, we could make the performance
of foreign API become much more predictable with the elimination of
allocations as well as pointer chasings where we can and want to limit the
kind of segment we operate on.

The above caveats lead to possible usage of foreign API to pass around the
naked addresses as long values and only construct segments where it is
needed. This approach, while being an ugly hack, is still not ideal cause
multiple methods may fail to be inlined.

Secondly, polymorphism limits specialisation. With JEP 218, we may have
multiple specialisations of the same methods operating on different kinds
of segments. While it is still possible, to some extent, to have
specialisation with a polymorphic type MemorySegment, it would likely be a
fragile optimisation that relies on inlining and a lot of type checks.

Furthermore, while having common aspects, MemorySegments expose different
behaviours on the others. E.g. HeapMemorySegment is not Addressable,
MappedMemorySegment has various additional specific methods. While this is
not an argument for the design of foreign API, it is a small bonus point
over those above.

Overall, the current status of foreign API seems to put us in a position
that relies too much on the compiler to get the desired performance.
Exposing the concrete types would enable us to write more predictable codes
where it needs to and flexible code (i.e using polymorphic MemotySegment,
MemoryAddress, etc) where it is more desirable.

My apologies if this question has been addressed before. Thank you very
much.
Quan Anh