Implementation of IO with Panama

[Maurizio Cimadamore]

On 16/04/2021 14:39, Radosław Smogura wrote:
> Hi Maurizio,
>
> Thanks for feedback.
>
>> On Apr 16, 2021, at 1:07 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>> 
>>> On 16/04/2021 00:37, Radosław Smogura wrote:
>>> Hi all,
>>>
>>> I hope you have a good day.
>>>
>>> I started implementing I/O for JDK using Panama (I could not find such project). I think this is natural consequence of Panama project.
>> Hey,
>> this looks like awesome work - it is true that memory segments, Panama and IO are all connected. We had to start somewhere, which is why currently, for IO, the path is to map a segment into a byte buffer and take it from there. While this is generally viable, there are also some complications, so I wouldn't be surprised to see a low-level IO layer popping up :-)
> Yes, we should not create file streams based on mapped memory, there can be some issues handling file grow.
>
> My approach is to firstly map streams: that’s mainly passing file descriptor to read / write - and solves files and sockets operations in one go. Maybe even we can re-route stdin / stdout.
>
> Byte buffers can be ported using mmap stackable and already existing Segment / Buffer connection.
>
> And finally async I/O.

Async I/O is especially interesting IMHO. While we plan to support async 
IO operations in the future with buffers obtained from all kinds of 
segments, doing an async operation on a segment that _can be closed at 
any time_ (even by a different thread), poses fundamentally new 
challenges for the JDK code.

For now, we can cope with the ResourceScope::acquire mechanism provided 
by the new API, which allows to "block off" deterministic allocation 
e.g. while executing a critical region.

But I think this is also a case where having a new API written with the 
new use cases in mind might provide more flexibility and/or better 
performances.

> Odd - which platform?
> Ubuntu Linux

It seems like on Ubuntu it's a macro:

define errno (*__errno_location ())

That said, in libc.so.6, I see this:

0000000000000010 g    D  .tbss    0000000000000004  GLIBC_PRIVATE errno
0000000000027430 g    DF .text    0000000000000015  GLIBC_2.2.5 
__errno_location

I have no idea as to where that comes from, frankly - but jextract is 
correct in the sense that it doesn't seem to be an ordinary exported 
library symbol.

>>>    *   Privately I wonder about safety of errno, as between call to Posix function and reading value we have JVM, which can meantime invoke Posix methods too and make errno dirty (low probability I think)
>> True - JDK uses errno for its own nio business - but as long as you don't mix and match you should be fine (not an expert on nio, so take what I say with a pinch of salt)
>>>    *   I wonder if we could add class LocalSegmentAllocator which will allocate memory segment on stack (I know there are some risks)
>> I mean - now that we have a SegmentAllocator, we could put many allocators underneath that interface. Is arena bounded not working for you? I know that stack allocation way faster than heap allocation, but with a fixed arena at least you pay for heap allocation only once.
>>
>> That said, it should be possible to combine the linker API with the segment allocator API and create a "custom" stack allocator (or, at least, that would be a good limit experiment for the API).
> I was thinking that blind bumping stack pointer with JVM intrinsic, and escape analyze optimizing MemorySegment object could give quite good sped up for both allocation and freeing memory.

Yeah - you'd like a memory segment view into a piece of stack in the 
current frame... that is not something I'm necessarily closing the door 
on, but for now it's outside the things we're actively exploring.

What we're trying to do in this area is to explore whether we can offer 
allocators whose performance is significantly better than "malloc" - we 
seem to have few ideas on how to do that, so I'd prefer to reasses on 
how much direct stack manipulation is needed after we see how far we are 
from there once we have the more advanced allocators.

Maurizio