18 ms·

JEP 442: Foreign Function and Memory API (Third Preview)

86 points by carimura 4y ago

mwcampbell 4y ago
How is the overhead of each function call in this implementation? I'm wondering if it's significantly more efficient to manipulate a struct in foreign memory directly than to call a bunch of foreign setter functions. This may influence how I eventually implement a Java binding for AccessKit [1]. [1]: https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit
naruhodo 4y ago
This is interesting and a nice thing to have built into the JVM. It seems to me though that SubstrateVM[1] makes calling native functions even easier (from page 8 of the slides): // C: struct timespec { __time_t tv_sec; __syscall_slong_t tv_nsec; }; int clock_gettime(clockid_t __clock_id, struct timespec *__tp) // Java: @CStruct interface timespec extends PointerBase { @CField long tv_sec(); @CField long tv_nsec(); } @CFunction static native int clock_gettime(int clock_id, timespec tp); [1]: https://www.complang.tuwien.ac.at/lehre/ubvo/substrate.pdf https://www.complang.tuwien.ac.at/lehre/ubvo/substrate.pdf
exabrial 4y ago
> The JEP is a Preview Feature meaning the Foreign Function & Memory API (hereafter "FFM") will not be a final feature in JDK 21. I think some of us hoped it could make it into finality in 21. However, my personal opinion is that the API is very unlikely to change in any significant way and what we are seeing in 21 will be very close to the final FMM API. One thing I really appreciate about Java and the JEP process is the careful attention to detail and avoid breaking changes. So if it takes a few extra cycles, I'm all in. It's worth getting it right the first time. FFS, stuff I downloaded from Node _5m ago_ is already deprecated.
- marginalia_nu 4y ago
  Yeah. this is one of the main reasons I use Java for most of my work. The time spent putting out fires caused by framework- and library churn is time not building something useful.
  - ye-olde-sysrq 4y ago
    My first exposure to programming, the AP CS exam (and its accompanying course), was in java. My first hobby foray into programming (Minecraft) was Java. So, I'm heavily biased here by my familiarity. However, in the years since, I've done a lot of time where my primary focus at jobs was, among others: python data stuff, "fullstack" stuff, Scala stuff, and golang stuff. And I just keep coming back to Java as my overall favorite. My personal diff against most languages goes something like: 1. Stuff rots a lot less fast than in python and js. Code keeps working for longer, dependency goofiness happens a lot less, etc. 2. It's just less clunky than golang - but this is mostly my own preferences. I often describe go as if someone designed a language, and then had this list of hard language design problems, and were I to look at this list, I would go "hmm yes these are hard problems where all the options have drawbacks", and then for EVERY SINGLE ONE OF THEM they picked the compromise I would not have picked. So it's just death by a thousand little things that annoy me. My current job is golang though so I'm wondering if I'll come around to it or something. We shall see. 3. Java just doesn't encourage such terrible cleverness that Scala (and to a lesser extent python and js) invites. This might be cultural too where Scala has this functional programming fanatics segment who love the cats library a little too much. But never have I ever before seen so much code that's just intractable to junior devs, and requires far too much brain-CPU for mids and seniors to read. Sure you can get into a lot of trouble with Java's reflection, but IME many java devs are suitably reluctant to go reflection crazy. 4. Damn is it fast by default. And can be REALLY fast if you specifically focus on a specific path. 5. The tooling is so mature. Does python or go even have anything like VisualVM? And as I understand it, even VisualVM is old hat compared to JFR, though I've not looked closely there. 6. The library ecosystem. It's even more expansive then npm but 10x less thrashy and churny. I particularly like that there's this interesting niche of academic libraries that end up out there that you might find yourself bumping into now and then. 7. Packaging. People use maven. Even people who use gradle still basically are just using maven with extra steps. Sure it's XML but aside from adding dependencies, you hardly touch it. And if your build system truly needs to be weird (like, say, android), then gradle is right there for you. 2 tools for the whole ecosystem. How many does python have again? I find I have little patience for packaging problems and I suspect some of it stems from the fact that if I were using Java, I wouldn't be having packaging problems. I'm sure I could go on, but I'll cut it here. For a million reasons, I find stuff built in Java just works and keeps working (both dev-environment and in prod) far more probably and for longer than in other languages and stacks. And it's fast enough to develop that I'd say it's well within range of python and ruby and such, for anything that bigger than a couple files.
- MrBuddyCasino 4y ago
  Say what you will about the evil database company which shall not be named, but under their stewardship the JVM ecosystem is moving into the right direction, and there is massive investment in foundational technologies that will take years to come to fruition, some of it unmatched (eg virtual threads or GraalVM).
  - Yoric 4y ago
    Out of curiosity, what's the difference between virtual threads, green threads and, say, goroutines?
    - MrBuddyCasino 4y ago
      Its solving the function colouring issue. Your code can run against old-school OS-threads with blocking I/O, or it can run against virtual threads with non-blocking I/O that look and behave almost exactly the same, but are multiplexed onto fewer underlying OS threads, without needing to introduce language constructs such as async/await or changing anything in your program code except maybe the executor implementation. Golang is opinionated towards its single coroutine model, there is no way to switch. Its a good model and it works well, but there are cases where it leaks, such as low-performance C interop. Green threads usually refer to single-threaded runtimes such as Node.
      - butt__hugger 4y ago
        [dead]
      - Yoric 4y ago
        So it's basically an implementation of transparent of M:N scheduling, right? I remember that early versions of Rust had that but dropped it because building a single implementation of that that scales to all platforms is hard (tm).
        nu11ptr 4y ago
        Yep, M:N cooperatively scheduled. It also requires a "runtime" which Rust didn't want to have
- deleted 4y ago
  [deleted]
- avarun 4y ago
  > FFS, stuff I downloaded from Node _5m ago_ is already deprecated. There's really no reason to use hyperbole to make your point. And besides, Node and Java aren't very different in their release policies. Node follows a standard LTS structure where every other release is an LTS, and Java follows a standard LTS structure where every third release is an LTS. If anything, that means more versions of Node are supported for longer without backwards incompatible changes.
  - rockwotj 4y ago
    The comment isn't about the language but the ecosystem, which yes it's hyperbole, but seems to generally hold true. The node ecosystem has a ton of churn
    - avarun 4y ago
      No, the comment is clearly about the language. The literal context of the submission is a new API being added to Java, and the GP is discussing how they prefer the slow pace of evolution of Java to Node's supposed breakneck pace of breaking changes. Unfortunately, they're just making up things about Node, thus my comment explaining how they're incorrect.
le-mark 4y ago
My first thought was “What about JNA?” > Over the years, numerous frameworks have emerged to fill the gaps left by JNI, including JNA, JNR and JavaCPP. These frameworks are often a marked improvement over JNI but the situation is still less than ideal — especially when compared with languages which offer first-class native interoperation. For example, Python's ctypes package can dynamically wrap functions in native libraries without any glue code. Other languages, such as Rust, provide tools which mechanically derive native wrappers from C/C++ header files.
- ape4 4y ago
  Is this JEP going to make that possible in Java?
  - kaba0 4y ago
    I believe the goal of this project is to provide a low-level API for FFI, on which other tools can build. Not sure which part of the quoted text you are asking about specifically, but it is quite likely possible to build such an abstraction on top of it (plus Java's dynamic class loading + loading dynamic libs should be able to handle pretty much any case). For an example, jextract is also in the works that will generate Java helper classes from C headers.
    - ape4 4y ago
      Thanks. Sorry for being unclear - I was talking about importing a C header.
      - mike_hearn 4y ago
        Yes it's possible. The same project developed a tool called jextract that uses clang to convert C headers to Java Panama classes: https://github.com/openjdk/jextract https://github.com/openjdk/jextract
pjmlp 4y ago
Yet another feature Android will miss out.
- exabrial 4y ago
  It's a shame. Android _should have_ from the beginning used: Linux containers, a modified JVM profile, Android libraries as regular java dependencies, etc.
  - pjmlp 4y ago
    At least they updated Android 12 to Java 11 LTS, and Android 14 will get Java 17 LTS. However it is a subset as usual, and most likely because they are already starting to feel that Kotlin also needs those Java libraries which are leaving Java 8 behind, unless they feel like rewriting Maven Central universe into Kotlin.
    - kaba0 4y ago
      You seem to be knowledgeable about the Android situation - what’s the current deal? From what I gathered, android uses a hybrid runtime that has many parts of the code AOT compiled and cached, but can JIT compile as well to suit for a particular device, is my understanding correct? But yeah, I agree with you, they really should have gone with possibly a simpler JIT compiler and an alternative GC implementation that is more conservative in memory usage.
      - saagarjha 4y ago
        What's wrong with the current one?
      - pjmlp 4y ago
        Here for the JIT/AOT, since Android 7 (5 and 6 used AOT only), https://source.android.com/docs/core/runtime/jit-compiler?hl=en https://source.android.com/docs/core/runtime/jit-compiler?hl... The issue isn't even converting JVM bytecodes into DEX, other compliant Java implementations for embedded do similar approaches, see PTC and Aicas. The issue is how they have stagnated Java support on purpose as means to push Kotlin, they aren't being innocent by using Java 8 samples against Kotlin features. And the whole but Oracle doesn't cut it, given how dependent Kotlin is on the whole JVM ecosystem.
plesner 4y ago
This is an intricate API that is likely to require an intricate implementation just to be correct. But correctness won't be enough, the JEP requires the JIT to implement some complex optimizations. I could use some reflections around: how do you implement such a large and complex feature in a JIT without potentially creating lots of vulnerabilities. It looks like a lot of new surface area in the VM with bad failure modes and VM engineers too are only human.

86 points by carimura 4y ago

How is the overhead of each function call in this implementation? I'm wondering if it's significantly more efficient to manipulate a struct in foreign memory directly than to call a bunch of foreign setter functions. This may influence how I eventually implement a Java binding for AccessKit [1]. [1]: https://github.com/AccessKit/accesskit https://github.com/AccessKit/accesskit

naruhodo 4y ago

This is interesting and a nice thing to have built into the JVM. It seems to me though that SubstrateVM[1] makes calling native functions even easier (from page 8 of the slides): // C: struct timespec { __time_t tv_sec; __syscall_slong_t tv_nsec; }; int clock_gettime(clockid_t __clock_id, struct timespec *__tp) // Java: @CStruct interface timespec extends PointerBase { @CField long tv_sec(); @CField long tv_nsec(); } @CFunction static native int clock_gettime(int clock_id, timespec tp); [1]: https://www.complang.tuwien.ac.at/lehre/ubvo/substrate.pdf https://www.complang.tuwien.ac.at/lehre/ubvo/substrate.pdf

exabrial 4y ago

> The JEP is a Preview Feature meaning the Foreign Function & Memory API (hereafter "FFM") will not be a final feature in JDK 21. I think some of us hoped it could make it into finality in 21. However, my personal opinion is that the API is very unlikely to change in any significant way and what we are seeing in 21 will be very close to the final FMM API. One thing I really appreciate about Java and the JEP process is the careful attention to detail and avoid breaking changes. So if it takes a few extra cycles, I'm all in. It's worth getting it right the first time. FFS, stuff I downloaded from Node _5m ago_ is already deprecated.

marginalia_nu 4y ago
Yeah. this is one of the main reasons I use Java for most of my work. The time spent putting out fires caused by framework- and library churn is time not building something useful.
- ye-olde-sysrq 4y ago
  My first exposure to programming, the AP CS exam (and its accompanying course), was in java. My first hobby foray into programming (Minecraft) was Java. So, I'm heavily biased here by my familiarity. However, in the years since, I've done a lot of time where my primary focus at jobs was, among others: python data stuff, "fullstack" stuff, Scala stuff, and golang stuff. And I just keep coming back to Java as my overall favorite. My personal diff against most languages goes something like: 1. Stuff rots a lot less fast than in python and js. Code keeps working for longer, dependency goofiness happens a lot less, etc. 2. It's just less clunky than golang - but this is mostly my own preferences. I often describe go as if someone designed a language, and then had this list of hard language design problems, and were I to look at this list, I would go "hmm yes these are hard problems where all the options have drawbacks", and then for EVERY SINGLE ONE OF THEM they picked the compromise I would not have picked. So it's just death by a thousand little things that annoy me. My current job is golang though so I'm wondering if I'll come around to it or something. We shall see. 3. Java just doesn't encourage such terrible cleverness that Scala (and to a lesser extent python and js) invites. This might be cultural too where Scala has this functional programming fanatics segment who love the cats library a little too much. But never have I ever before seen so much code that's just intractable to junior devs, and requires far too much brain-CPU for mids and seniors to read. Sure you can get into a lot of trouble with Java's reflection, but IME many java devs are suitably reluctant to go reflection crazy. 4. Damn is it fast by default. And can be REALLY fast if you specifically focus on a specific path. 5. The tooling is so mature. Does python or go even have anything like VisualVM? And as I understand it, even VisualVM is old hat compared to JFR, though I've not looked closely there. 6. The library ecosystem. It's even more expansive then npm but 10x less thrashy and churny. I particularly like that there's this interesting niche of academic libraries that end up out there that you might find yourself bumping into now and then. 7. Packaging. People use maven. Even people who use gradle still basically are just using maven with extra steps. Sure it's XML but aside from adding dependencies, you hardly touch it. And if your build system truly needs to be weird (like, say, android), then gradle is right there for you. 2 tools for the whole ecosystem. How many does python have again? I find I have little patience for packaging problems and I suspect some of it stems from the fact that if I were using Java, I wouldn't be having packaging problems. I'm sure I could go on, but I'll cut it here. For a million reasons, I find stuff built in Java just works and keeps working (both dev-environment and in prod) far more probably and for longer than in other languages and stacks. And it's fast enough to develop that I'd say it's well within range of python and ruby and such, for anything that bigger than a couple files.
MrBuddyCasino 4y ago
Say what you will about the evil database company which shall not be named, but under their stewardship the JVM ecosystem is moving into the right direction, and there is massive investment in foundational technologies that will take years to come to fruition, some of it unmatched (eg virtual threads or GraalVM).
- Yoric 4y ago
  Out of curiosity, what's the difference between virtual threads, green threads and, say, goroutines?
  - MrBuddyCasino 4y ago
    Its solving the function colouring issue. Your code can run against old-school OS-threads with blocking I/O, or it can run against virtual threads with non-blocking I/O that look and behave almost exactly the same, but are multiplexed onto fewer underlying OS threads, without needing to introduce language constructs such as async/await or changing anything in your program code except maybe the executor implementation. Golang is opinionated towards its single coroutine model, there is no way to switch. Its a good model and it works well, but there are cases where it leaks, such as low-performance C interop. Green threads usually refer to single-threaded runtimes such as Node.
    - butt__hugger 4y ago
      [dead]
    - Yoric 4y ago
      So it's basically an implementation of transparent of M:N scheduling, right? I remember that early versions of Rust had that but dropped it because building a single implementation of that that scales to all platforms is hard (tm).
      - nu11ptr 4y ago
        Yep, M:N cooperatively scheduled. It also requires a "runtime" which Rust didn't want to have
deleted 4y ago
[deleted]
avarun 4y ago
> FFS, stuff I downloaded from Node _5m ago_ is already deprecated. There's really no reason to use hyperbole to make your point. And besides, Node and Java aren't very different in their release policies. Node follows a standard LTS structure where every other release is an LTS, and Java follows a standard LTS structure where every third release is an LTS. If anything, that means more versions of Node are supported for longer without backwards incompatible changes.
- rockwotj 4y ago
  The comment isn't about the language but the ecosystem, which yes it's hyperbole, but seems to generally hold true. The node ecosystem has a ton of churn
  - avarun 4y ago
    No, the comment is clearly about the language. The literal context of the submission is a new API being added to Java, and the GP is discussing how they prefer the slow pace of evolution of Java to Node's supposed breakneck pace of breaking changes. Unfortunately, they're just making up things about Node, thus my comment explaining how they're incorrect.

le-mark 4y ago

My first thought was “What about JNA?” > Over the years, numerous frameworks have emerged to fill the gaps left by JNI, including JNA, JNR and JavaCPP. These frameworks are often a marked improvement over JNI but the situation is still less than ideal — especially when compared with languages which offer first-class native interoperation. For example, Python's ctypes package can dynamically wrap functions in native libraries without any glue code. Other languages, such as Rust, provide tools which mechanically derive native wrappers from C/C++ header files.

ape4 4y ago
Is this JEP going to make that possible in Java?
- kaba0 4y ago
  I believe the goal of this project is to provide a low-level API for FFI, on which other tools can build. Not sure which part of the quoted text you are asking about specifically, but it is quite likely possible to build such an abstraction on top of it (plus Java's dynamic class loading + loading dynamic libs should be able to handle pretty much any case). For an example, jextract is also in the works that will generate Java helper classes from C headers.
  - ape4 4y ago
    Thanks. Sorry for being unclear - I was talking about importing a C header.
    - mike_hearn 4y ago
      Yes it's possible. The same project developed a tool called jextract that uses clang to convert C headers to Java Panama classes: https://github.com/openjdk/jextract https://github.com/openjdk/jextract

pjmlp 4y ago

Yet another feature Android will miss out.

exabrial 4y ago
It's a shame. Android _should have_ from the beginning used: Linux containers, a modified JVM profile, Android libraries as regular java dependencies, etc.
- pjmlp 4y ago
  At least they updated Android 12 to Java 11 LTS, and Android 14 will get Java 17 LTS. However it is a subset as usual, and most likely because they are already starting to feel that Kotlin also needs those Java libraries which are leaving Java 8 behind, unless they feel like rewriting Maven Central universe into Kotlin.
  - kaba0 4y ago
    You seem to be knowledgeable about the Android situation - what’s the current deal? From what I gathered, android uses a hybrid runtime that has many parts of the code AOT compiled and cached, but can JIT compile as well to suit for a particular device, is my understanding correct? But yeah, I agree with you, they really should have gone with possibly a simpler JIT compiler and an alternative GC implementation that is more conservative in memory usage.
    - saagarjha 4y ago
      What's wrong with the current one?
    - pjmlp 4y ago
      Here for the JIT/AOT, since Android 7 (5 and 6 used AOT only), https://source.android.com/docs/core/runtime/jit-compiler?hl=en https://source.android.com/docs/core/runtime/jit-compiler?hl... The issue isn't even converting JVM bytecodes into DEX, other compliant Java implementations for embedded do similar approaches, see PTC and Aicas. The issue is how they have stagnated Java support on purpose as means to push Kotlin, they aren't being innocent by using Java 8 samples against Kotlin features. And the whole but Oracle doesn't cut it, given how dependent Kotlin is on the whole JVM ecosystem.

plesner 4y ago

This is an intricate API that is likely to require an intricate implementation just to be correct. But correctness won't be enough, the JEP requires the JIT to implement some complex optimizations. I could use some reflections around: how do you implement such a large and complex feature in a JIT without potentially creating lots of vulnerabilities. It looks like a lot of new surface area in the VM with bad failure modes and VM engineers too are only human.