Implementation of IO with Panama

[Radosław Smogura]

Hi,

> On Apr 16, 2021, at 4:01 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
>> 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.
I could grab address for it just looking for symbol from CLinker.

But, AFIK, errno is thread local variable so maybe I should double check how this should be handled.

>>>>   *   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