-
Notifications
You must be signed in to change notification settings - Fork 4k
GH-37739: [Java] Add experimental arrow-memory-ffm module #38016
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An Arena controls the lifecycle of native (off-heap) memory segments. The Shared Arena has a bounded lifetime, is explicitly closeable, and is accessible by multiple threads.[1]
[1]https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/foreign/Arena.html
bb22994 to
c8b78bc
Compare
|
Java newbie here, can you give a pointer to the FFM docs? |
Added the JEP and docs to the description! |
Wow, that looks really promising. What are the implications of using a preview API? Can the API change in later versions? Does it impact downstream users? |
Yes, the APIs can still change, but it is approaching stability now that its been in development for a few years. I plan to mark this module as experimental and only enabled for Java 21+, but I expect the JEP to be finalized for the next Arrow Java LTS (Long Term Support) release Java 24. The benefit of adding it now is that we can trial it and potentially provide late feedback to the JEP implementation if needed. Adding the module itself won't impact users unless they choose to use it. Arrow Java provides an abstract interface to off-heap memory called |
|
Do you think we'll also ditch our JNI interfaces at some point? I suppose we must keep them until FFM becomes mainstream, but would it be beneficial to use FFM as an alternative on supported setups? |
Eventually, yes! I think there is a lot that needs to happen before then. Besides the Java support fiasco holding many users back (Java 8 has extended support until 2030) and needing to wait until Java 24+, the JIT implementations will also most likely require work to improve optimizations of FFM APIs to meet similar performance numbers as the existing alternatives. Long term, this definitely looks like the preferred approach over JNI to me. |
c8b78bc to
609e7ef
Compare
| FfmAllocationManager(BufferAllocator accountingAllocator, long requestedSize) { | ||
| super(accountingAllocator); | ||
| arena = Arena.ofShared(); | ||
| allocatedMemorySegment = arena.allocate(requestedSize, /*byteAlignment*/ 8); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that FFM requires byteAlignment to be specified within the allocation manager, while netty/unsafe do not.
java/pom.xml
Outdated
| <jdk>[21,]</jdk> | ||
| </activation> | ||
| <modules> | ||
| <module>memory/memory-ffm</module> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the best way to enable developers to build arrow-memory-ffm? I haven't come up with a better alternative, but I'm also not a POM expert.
CI does not build this module, but a developer can build from source with mvn clean install -pl :arrow-memory-ffm --am
|
@github-actions crossbow submit -g java |
|
Revision: 0cd7939 Submitted crossbow builds: ursacomputing/crossbow @ actions-0fc32fc5ee |
|
One tidbit passed on from the Trino team was that once we have FFI then we'd also want to figure out how to move past any uses of ByteBuffer in the rest of the code to the FFI classes, as (reportedly) some mistakes were made with ByteBuffer which means it isn't very friendly to inlining and the new stuff is much much faster once inlining has time to kick in. |
| try { | ||
| return getFactory("org.apache.arrow.memory.FfmAllocationManager"); | ||
| } catch (RuntimeException e) { | ||
| if (majorVersion < 21) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we also have to detect that preview features are actually turned on and the underlying FFM libraries are available in that specific Java 21+ VM instance?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good catch. More helpful checks would be nice.
...memory/memory-core/src/main/java/org/apache/arrow/memory/DefaultAllocationManagerOption.java
Outdated
Show resolved
Hide resolved
Thank you! I envision this refactor, plus supporting |
|
I'm going to put this on hold for now. The next steps are to refactor out the usage of |
| @@ -0,0 +1,77 @@ | |||
| /* | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file was added as a hack to test the memory-core module with the FFM APIs. It will be useful for testing later, but can be ignored otherwise.
|
Since FFM is GA since JDK 22, is there a plan to move forward with FFM-based allocator for Arrow? |
|
@wendigo Yes we are planning to. |
|
Closing for now due to staleness. |
|
|
WIP
Rationale for this change
The FFM APIs had their 3rd preview release in Java 21. Let's start integrating them with Arrow to see how effective they are. The FFM APIs will presumably be finalized in the next Java LTS release (24).
JEP 442: https://openjdk.org/jeps/442
java.lang.foreign: https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/foreign/package-summary.html
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?
Yes.