[HN Gopher] OpenJDK Proposes Project Galahad to Merge GraalVM Na...
___________________________________________________________________
OpenJDK Proposes Project Galahad to Merge GraalVM Native
Compilation
Author : mfiguiere
Score : 95 points
Date : 2022-12-21 19:56 UTC (3 hours ago)
(HTM) web link (www.infoq.com)
(TXT) w3m dump (www.infoq.com)
| adra wrote:
| I don't see too many immediate term improvements from what we
| have today, but I do see GraalVM to be just different enough from
| mainline OpenJDK releases to question exploring the features of
| that build (in JVM or native modes). I poked at the release from
| time to time between 19 and 22 but always ended up going back. If
| this can improve that story, I'd say it's a win for all. Of
| course I'm not sure what this changes in regards to Oracle's
| extended paid version of the GraalVM runtime.
| Alupis wrote:
| GraalVM will mostly benefit those who are building and
| deploying Function/Serverless and Microservices most - the
| native compilation really shines in that space (for near-
| instant start times and footprint reduction).
|
| For anyone else, the normal JVM is likely a better choice for
| now - the tech built in there is very mature and battle tested.
|
| With that said - baking a bunch of GraalVM features into the
| normal JVM is nothing but good for everyone. Native AOT
| compilation does have it's uses outside
| microservices/serverless, and some cross-pollination of VM
| ideas is a great idea.
| cogman10 wrote:
| There are a lot of other neat parts for graal that will
| likely be beneficial. One of the big benefits of graal is
| that it makes implementing guest languages a snap (via the
| truffle framework).
|
| So you can get all the operational benefits of the JVM + a
| nice set of languages to play with along with interopt cross
| language (python calling java calling ruby calling perl,
| etc).
|
| Here's the languages they already have.
|
| https://github.com/oracle/graal/blob/master/truffle/docs/Lan.
| ..
| kasperni wrote:
| There are no plans to move Truffle to OpenJDK.
| Alupis wrote:
| That particular claim/goal used to get me excited (run any
| language on GraalVM), but the reality seems to have worked
| out to be a very large asterisk next to that claim.
|
| From what I can tell, the effort to get any particular
| language running on Graal is non-trivial, leading to that
| relatively small list of supported languages - most of
| which seem to be custom dialects in one fashion or another.
| Perhaps I'm wrong though...
| mike_hearn wrote:
| Is it a small list? Especially if you count ILs like LLVM
| bitcode or WASM, it probably includes most of them.
|
| Many of the languages people use in the real world are
| really large, really old, really hairy and rely heavily
| on native extensions that poke arbitrary interpreter
| internals. Truffle at least makes these implementable
| with higher performance, and the team size needed to get
| that done isn't infeasible. But implementing a Ruby or
| Python will never be a five minute job regardless of what
| tech you use.
| Alupis wrote:
| It's small in that nearly half of the published list is
| academic languages and dialects, and the other half seems
| to be custom dialects of languages.
|
| While LLVM or WASM support is nice, most modern languages
| are not compiling to either one by default, and likely
| means it's not "turn key" to get your system running on
| Graal anyway.
| kaba0 wrote:
| It can run Javascript with similar peak performance than
| V8 with a tiny tiny fraction of development than what
| went into the latter. (Of course it is possible only due
| to it leveraging the many many dev-hours spent on the
| JVM), it is the fastest Ruby implementation by an integer
| factor and it can run C dependencies (often used by
| Python/Ruby) as well, and even optimize across language
| boundaries.
|
| The smallish list of languages is just due to lack of
| effort, plus lack of immediate benefits -- it is not hard
| to create an alternative language implementation. It is
| very hard to create one that is 100% drop-in replaceable
| with the real thing as every sufficiently complex program
| will depend on implementation quirks as well.
| mukel wrote:
| GraalVM team member here. Implementing any mainstream
| language is indeed a challenge, more so if you have to
| maintain bug-compatibility and cope with all the bits of
| bad design that went through the cracks in the de-facto
| implementation. Truffle is not for beginners, but knowing
| the basic set of features e.g. partial evaluation,
| deoptimization... can get you very far already e.g. you
| can easily speedup any interpreter by 10X or more with
| minimal changes.
|
| How long does take to implement a programming language?
| Well, from hours to years... depending on the language.
| To make my point; how long would it take to implement a
| JVM? A JVM is a complex beast, so I would myself guess
| from years to a decade probably, what if I told you, that
| Espresso was written in just 6 months by an intern and a
| seasoned engineer... in just 6 months it was able to
| Minecraft and even run itself. I assure you there's no
| magic here, and certainly no blinding talent either; the
| only reason for this unheard productivity was
| Graal/Truffle. So, whenever I talk about Espresso I
| always give all credit to Graal/Truffle, it is a sublime
| platform for implementing fast languages and runtimes, of
| which Espresso is just a byproduct.
| threeseed wrote:
| > building and deploying Function/Serverless and
| Microservices most
|
| For those you may be better with IBM OpenJ9:
|
| https://www.eclipse.org/openj9/
|
| It also integrates with CRIU so you can almost instantly
| start/stop the JVM:
|
| https://blog.openj9.org/2022/09/26/getting-started-with-
| open...
| mdaniel wrote:
| I keep forgetting about J9 but they're not doing themselves
| any branding favors since there actually is J17 on J9 :-/
| https://github.com/eclipse-
| openj9/openj9/blob/openj9-0.35.0/... (Also that 0.35
| versioning ...)
|
| As best I can tell, these are the docker images:
| https://hub.docker.com/_/ibm-semeru-runtimes
| $ docker run --rm ibm-semeru-runtimes:open-11-jdk java
| -version openjdk version "11.0.17" 2022-10-18
| IBM Semeru Runtime Open Edition 11.0.17.0 (build 11.0.17+8)
| Eclipse OpenJ9 VM 11.0.17.0 (build openj9-0.35.0, JRE 11
| Linux amd64-64-Bit Compressed References 20221031_559 (JIT
| enabled, AOT enabled) OpenJ9 - e04a7f6c1
| OMR - 85a21674f JCL - a94c231303 based on
| jdk-11.0.17+8)
| thangalin wrote:
| It'll help build cross-platform desktop applications. In
| theory, it'll streamline using GitHub Actions to produce
| platform-specific binaries, such as my FOSS Markdown editor
| KeenWrite[0], without having to have a copy of every target
| operating system.
|
| To my knowledge, cross-compiling "native" Linux and Windows
| binaries using Java requires duct tape, chewing gum, and warp-
| packer.[1][2] If there's another way to cross-compile a Java
| application into a standalone binary for multiple target
| platforms, do tell!
|
| GraalVM isn't a panacea. For example, GraalVM cannot compile
| Renjin[3], a pure Java R interpreter, which means switching
| from Renjin to FastR. Not trivial. Other sinkholes likely lurk
| that'll only reveal themselves when walking through the weeds.
|
| [0]: https://github.com/DaveJarvis/keenwrite
|
| [1]: https://dave.autonoma.ca/blog/2020/06/29/write-once-build-
| an...
|
| [2]: https://github.com/dgiagio/warp
|
| [3]: https://github.com/bedatadriven/renjin/issues/564
| hrpnk wrote:
| The challenge with GraalVM runtime is that there are
| differences in licensing. What was great about Java is that
| only for specialized use cases, one had to invest in a paid
| runtime. GraalVM moves essential features known from Java
| Runtime into an Enterprise Edition.
|
| From GraalVM docs [1] on memory management: "The G1 GC (only
| available with GraalVM Enterprise Edition) is a multi-threaded
| GC that is optimized to reduce stop-the-world pauses and
| therefore improve latency, while achieving high throughput.
| Currently, G1 can only be used in native images that are built
| on Linux for AMD64."
|
| [1] https://www.graalvm.org/22.2/reference-manual/native-
| image/o...
| aseipp wrote:
| GraalVM is a bunch of components, but the most important one
| are 1) Graal, a library in Java that is a code generator and
| optimizer for compiler authors, 2) Native Image, a tool which
| turns Java programs into native executables via Graal, and 3)
| Truffle, a tool for implementing languages in Java that then
| get code generated, again by Graal
|
| "GraalVM" is the umbrella name of all these things packaged
| together, together with a couple languages implemented in
| Truffle. That's what you download when you go to the website.
|
| Galahad is a proposal to merge the Graal code generator library
| in Java, into OpenJDK's codebase, so that it is developed in
| tandem and comes with first-class support. And none of the
| other things, for now (Native Image will come later.) But you
| can also do this today: you can instead configure a stable LTS
| release of Java to use Graal as the code generator for the
| HotSpot VM, as an alternative to C2. It's a little bit of work
| to do so, but you can use any compliant OpenJDK build and test
| it out. Galahad will just make this an "out of the box" option
| rather than having to get Graal from Maven or whatever.
|
| So, you can just test things incrementally and see if Graal
| gives performance improvements over C2. You don't need to throw
| out your whole existing JVM, it's mostly just a new maven
| dependency. That's a much simpler and more targeted change, if
| you haven't given it a try (mostly by fiddling with some JVM
| -XX flags, as usual.)
| kasperni wrote:
| The title of the article is a bit misleading. The goal is first
| to merge GraalVMs JIT compiler (as an alternative to C2). Then
| later to bring in the AOT compiler.
| pulse7 wrote:
| After this merge we will have JVM implemented mostly in Java (aka
| "self hosted"). Currently about 1% of the JVM runtime is
| implemented in C and this will be replaced with instrumented Java
| code (including garbage collectors). This means that only one
| runtime will be maintained in the future and Java developers will
| do it (and not C/C++ developers which are harder to get). It will
| be much easier to implement and test new memory management
| mechanisms than it is today.
|
| If they also decide to merge support for other languages
| (including WASM and LLVM) we will be able to run everything that
| compiles to WASM and to LLVM on the same runtime - in the same
| JVM. So we will get another "Docker Without Containers"...
|
| EDIT: It seems that I am wrong with the above 1% statement. I
| meant that about 1% of the Java standard library is written in
| C/C++. Regarding JVM: I guess that the whole HotSpot VM will be
| replaced with GraalVM in the future and when this happens,
| majority of the JVM code will be in Java.
| morelisp wrote:
| It's surprising to me that effective knowledge of C and/or C++
| is the stumbling block for contributing to the core of the JVM.
|
| I work at a company with one large C++ codebase, and also many
| Go projects where C and C++ knowledge are helpful. _We_ have
| trouble hiring good C++ developers, because our candidate pool
| starts as "people who want to write web applications".
|
| But if you're already restricted to people who want to work on
| an extremely mature compiler, VM, and JIT - is lack of C
| knowledge really what's making it hard to hire people? These
| are people who are likely to end up reading kernel code and
| C-defined ABI documentation and etc. etc. even if the codebase
| is 100% Java...
| kaba0 wrote:
| > It's surprising to me that effective knowledge of C and/or
| C++ is the stumbling block for contributing to the core of
| the JVM.
|
| Parent is just talking out of his/her ass.
| lmm wrote:
| The people who believe in and care about Java tend to be Java
| people; C-oriented people tend to be rather anti-Java.
| kaba0 wrote:
| Writing state-of-the art runtimes is probably one of the
| hardest CS fields. They are way above this "your language
| sucks" category.
| lmm wrote:
| People are human; we get petty and tribal at every level.
| And ever putting all that aside, if you genuinely believe
| that one kind of programming or another is the way
| forward then of course you're going to be more interested
| in working on technologies that support that.
| wiseowise wrote:
| > We have trouble hiring good C++ developers, because our
| candidate pool starts as "people who want to write web
| applications".
|
| You have trouble hiring good C++ developers, because you
| don't pay enough.
| morelisp wrote:
| Also true, but not the only reason nor a particularly
| relevant response.
| moralestapia wrote:
| Now that you touch on that and since I'm considering a role
| in C/C++ that came up to me.
|
| How much is a good salary for that if you're remote (but US
| based) and have about 10 years of decent experience (plus a
| PhD in CS).
| kasperni wrote:
| > Currently about 1% of the JVM runtime is implemented in C
|
| The JIT is probably half of the VM and is written in C++.
|
| Github [1] says (for the whole JDK, not just the VM): Java
| 75.1% C++ 13.4% C 7.4% Assembly 2.3% Objective-C 0.4%
|
| [1] https://github.com/openjdk/jdk
| Alifatisk wrote:
| Is C devs really hard to get?
| Alupis wrote:
| C devs? No. Competent systems-level C devs - yes.
|
| The embedded and systems space are hard and require special
| talent and knowledge. You can't just take some front-end
| React developer and get them writing quality systems C code
| in a weekend... people spend entire careers in that space,
| and the number of people interested in that work shrinks by
| the year (look at all developer surveys).
| Yoric wrote:
| Incidentally, that's one of the reasons for which Rust is
| so successful in this space. Rust won't magically make you
| productive in a week-end, but the Rust compiler (with its
| error messages) is pedagogic enough that it is going to
| help you learn from your mistakes.
|
| That's the extreme opposite of raw C (or raw JavaScript,
| etc.) in which it's very easy to believe that you have
| solved an issue, only to realize much later that you've
| been entirely misunderstanding some constructions of the
| language and (if your code somehow managed to land) you
| have made the entire product unstable or insecure without
| realizing it.
|
| Of course, there are tradeoffs to each approach. But I
| believe that investing in Rust was a great initiative from
| Mozilla.
| delusional wrote:
| But can you take some JavaEE backend developer, shove them
| into the compiler, and expect them to do well?
|
| I think the language difference is a red herring.
| yakak wrote:
| It's certainly very interesting since Java was among the
| few high level languages that had unlimited access to C
| OS devs in theory, but it doesn't show this in practice.
|
| I always felt they were hostile to understanding OSes and
| problems/solutions they provide and thereby limiting
| themselves to mostly junior C devs who didn't rock the
| boat by making real OS features for the JVM.
| pyuser583 wrote:
| How does embedded programming pay?
| jalcazar wrote:
| not _really hard_ just _harder_ than Java
| mike_hearn wrote:
| Where did you get the 1% figure from? HotSpot has millions of
| lines of C++, that seems far too low.
|
| Graal doesn't affect memory management. It's a JIT compiler,
| not a GC. Although there's a relatively simple GC written in
| SystemJava for native images, G1, ZGC and Parallel will
| continue to be the standard GCs in the regular JVM for the
| foreseeable future and they are all written in C++.
| taeric wrote:
| To add to your question, assuming the tooling at github is
| ok, it has ~20% as c/c++ for https://github.com/openjdk/jdk.
| I would think most of that would be concentrated in the
| hotspot code, but I don't know. Would be delighted to know
| what the original post was referring to.
| fathyb wrote:
| I think the entirety of Hotspot is written in C++ [0]? The
| standard library in the JDK is mostly written in Java, but
| the VM itself with the GC and JIT code is in C++, which
| makes sense.
|
| If you do not count the standard library as part of the JVM
| (but part of the JDK), then the JVM is written mostly in
| C++.
|
| [0]: https://github.com/openjdk/jdk/tree/master/src/hotspot
| Alifatisk wrote:
| I've had thoughts about trying GraalVM with a old Ruby project
| using (truffleruby) but I found the docs to be a bit rough.
___________________________________________________________________
(page generated 2022-12-21 23:00 UTC)