Skip to content

Filechannel implementation #34

@manticore-projects

Description

@manticore-projects

Greetings!

First of all, I want to apologise upfront when it looks like I have hijacked your project. This is not my intention but I have working on too much stuff in parallel and it was easier to work on this in a kind of a forked environment. My goal is to feed every bit back into the main project and make JUring successful.

Now, please have a look at https://github.com/manticore-projects/JUring/tree/filechannel
It contains a complete FileChannel based on JUring with promising benchmarks.

My goal is to provide a FileChannel implementation to the H2 Java File database in order to speed up IO operations.
So the major benchmarks simulate Database patterns. Although there is also a transferFrom and transferTo benchmark showing JUring ahead for larger blocks.

Important: All benchmarks are done for D_OPEN for both JUringFileChannel and Standard FileChannel to make it comparable. So you will need to run those benchmarks on a EXT4 or XFS filesystem (but not on TEMPFS or encrypted/compressing FS). Please set the System Environment Variable JURING_TEST_DIR=... accordingly.

What has been added:

  • added some methods to JUring to allow writing fixed buffers by buffer reference

  • added an atomic ID generator for avoiding duplicates (also faster)

  • added a special C module for encapsulating a series of libUring calls to avoid a series of Panama roundtrips with overhead

  • added a full JUringFileChannel implementation with Asynchronous Batch Read/Write (via JUring API) and Full Asynchronous Batch Read/Write (via additional C module)

  • added support for transferTo, transferFrom, lock, tryLock and force etc.

  • added comprehensive benchmarks w/ graphical output

  • added correctness tests

  • fixed the existing tests and benchmark (e.g. avoid hard coded file locations)

  • introduced a Gradle build file (sorry, I hate Maven and need to gradle scripting capabilities)

  • added Maven publishing capabilities w/ versions directly derived from GIT tags (Snaphot builds vs. Releases)

Probably some more stuff I have forgotten.
Please do let me know what you think and how you will want to move forward (but be mild on me, since it was a lot of work and I am just an accountant).

Best and cheers!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions