Implementation of IO with Panama

[Radosław Smogura]

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.
> 
> 
>> 
>> Right now, it's done as separate Maven project, which can be found here https://github.com/rsmogura/panama-io
>> 
>> Generally, I'm happy it went so smooth.
>> 
>> Well done!
>> 
>> I created CachedAllocator (first version) which will keep memory segments cached to avoid calling alloc / free (I did not make performance tests between both versions).
> Would be interesting to play with the latest API and the allocators in there, to see if there's something that could help.
I’ll check it.
>> 
>> I created as well simple benchmarks
>> Benchmark                          Mode  Cnt        Score        Error  Units
>> SocketReadJdk.teatRead4k          thrpt   15  1202109.549 ± 127132.855  ops/s
>> SocketReadJdk.testRead16b         thrpt   15  2818334.225 ±  82209.971  ops/s
>> SocketReadJdk.testRead8bOffset    thrpt   15  2851310.595 ±  20675.631  ops/s
>> SocketReadPosix.teatRead4k        thrpt   15  1187974.868 ± 101285.497  ops/s
>> SocketReadPosix.testRead16b       thrpt   15  2963827.190 ±  62004.165  ops/s
>> SocketReadPosix.testRead8bOffset  thrpt   15  2999631.814 ±  23925.859  ops/s
> Wow - those look good numbers - the fact that your solution can be competitive with highly optimized JDK code speaks for itself. I'll have a look at your allocator.
>> 
>> From minor things and ideas:
>> 
>>   *   I could not capture errno using jextract, my script uses --include-var errno, but I had ask for this symbol manually
> Odd - which platform?
Ubuntu Linux
>>   *   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.
> 
>> 
>> If you have any questions, or ideas I'm happy to answer.
>> 
>> and I think with moving forward I can provide quite interesting feedback.
>> 
>> The goal is to make complete rewrite, together with mmap, and async I/O.
> 
> I *love* to see stuff like this happening. IMHO, this is the main point as to why the JDK is offering relatively blunt, low-level tools to manage off-heap memory/native code. But, by building on these, it should be possible to create completely new layers, like you have done (and with good results, it seems). It's all very exciting!
> 
> Maurizio
> 
>> 
>> Best regards,
>> Rado