Implementation of IO with Panama

[Maurizio Cimadamore]

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 :-)



>
> 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 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?
>    *   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).

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