Project

General

Profile

Feature #9684

migrate from libffi (and C heap functions) to the built-in JDK FFM support

Added by Greg Shah over 1 year ago. Updated 2 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:
Native API Calls

Related issues

Related to Runtime Infrastructure - Support #6340: move JNI and native dependencies into the jar New
Related to Base Language - Feature #1634: implement full native library (.so or DLL) support Closed 01/14/2013 06/06/2013
Related to Runtime Infrastructure - Feature #9685: move FWD to Java 21 WIP
Related to Runtime Infrastructure - Feature #9686: move FWD to Java 25 WIP

History

#1 Updated by Greg Shah over 1 year ago

  • Related to Support #6340: move JNI and native dependencies into the jar added

#2 Updated by Greg Shah over 1 year ago

  • Related to Feature #1634: implement full native library (.so or DLL) support added

#3 Updated by Greg Shah over 1 year ago

In Java 21, there is a 3rd preview of the Foreign Function and Memory (FFM) API which has been officially made available in JDK 22 (which is not an LTS release). Once JDK 25 is available (September 2025), then this will be a potential solution in which we can migrate away from external dependencies:

  • We have JNI code that implements low level memory access (allocation, read, write, deallocation). This is used to implement MEMPTR support. The new FFM provides an architected way to implement the same thing directly from Java code.
  • We use libffi to implement 4GL native library access. The new FFM provides the same feature set accessible directly from Java code.

The design of the FFM API looks like it will require that both features are migrated at the same time. This is because MEMPTRs are heavily used for parameter passing to native APIs and so they must be compatible with the FFM when function calls are made.

Once libffi is no longer a dependency, it will simplify our installation process.

#4 Updated by Greg Shah over 1 year ago

#5 Updated by Greg Shah over 1 year ago

#6 Updated by Teodor Gorghe 5 months ago

Created task branch 9684a.

Committed revision 16430 on task branch 9684a:
- Initial alternative implementation of MEMPTR using new JDK Memory API.

Committed revision 16431 on task branch 9684a:
- Added missing file.

Currently, this branch does not compile under JDK22 because the new JDK API is not available on these versions. Compilation on JDK 25 requires changes from #9686.
We will need to think about a strategy for backward compatibility for older JDK versions like 17. On solution might be changing the build script to include that file in a separate JAR.

I will continue changing usage of libffi with modern JDK replacement.

#7 Updated by Greg Shah 5 months ago

I don't want to work on this until after we no longer support JDK 17. This is not a priority right now.

#8 Updated by Alexandru Lungu 2 months ago

  • Is there any downside of FFM? Or is it simply a built-in way of using native memory without working it around JNI?
  • Can we have a performance check for FFM?

#9 Updated by Greg Shah 2 months ago

The value of this task is low since it just replaces something that is already working well. I was planning to defer the work.

#10 Updated by Greg Shah 2 months ago

  • topics Native API Calls added

Also available in: Atom PDF