12 ms·

Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

290 points by ludovicianul 4y ago

pulse7 4y ago
Maybe we will soon see the Java Virtual Machine implemented wholly in (a subset of) Java...
- Thaxll 4y ago
  It's a good point, after so long why the JVM is not written in Java actually? For example the Go runtime and I think C# as well are written in their respective language. https://github.com/golang/go/tree/master/src/runtime https://github.com/golang/go/tree/master/src/runtime https://github.com/dotnet/runtime https://github.com/dotnet/runtime
  - simias 4y ago
    Maybe it's my ignorance of the Java ecosystem or a lack of imagination but how could a language that requires a heavy runtime be written in itself? Wouldn't you need a runtime for the runtime, and then a runtime for the runtime for the runtime and then...? I can't quite imagine how you'd bootstrap something like that.
    - chrisseaton 4y ago
      You implement the runtime itself in Java, and you use that runtime to run your runtime.
      - stingraycharles 4y ago
        Exactly, implementing the runtime is the bootstrapping (apart from the compilation of course). There is no implementing the runtime that implements the runtime that implements the runtime.
      - throwaway894345 4y ago
        The missing detail is that you have to AOT compile the outermost runtime.
    - acedTrex 4y ago
      Graal supports AOT compilation, so you can write the runtime in java and AOT compile it to a given arch. thats what the thread is talking about
    - jlouis 4y ago
      No. See Scheme48 or Go. There are some ways around that bootstrap problem.
      - throwaway894345 4y ago
        Not sure about Scheme48, but Go's solution is AOT compiling the runtime, which is essentially what the parent is asking about.
    - crustycoder 4y ago
      It's no different to writing any other compiler for Language X in Language X, and that's a really common thing to do. The Java compiler emits files containing Java Bytecode which are subsequently run by a different invocation of the JVM.
      - Taywee 4y ago
        It's different in that the JVM is not a compiler. It's a bit like suggesting writing CPython in Python. It's possible only if the interpreter's Python source can be compiled ahead of time, like PyPy.
        chrisseaton 4y ago
        > It's possible only if the interpreter's Python source can be compiled ahead of time, like PyPy. That's what it does.
        Taywee 4y ago
        Oh, I know, I'm just pointing out that a self-hosted compiler is a different ballgame than a runtime being written in the language that runs on it. Without some degree of AOT compilation (usually of a subset or dialect of the language compiled in a different fashion), it's not really possible. The GP seemed to miss that the discussion was about the JVM, not javac. With Graal, it's possible to write a JVM in Java, but the JVM doesn't depend on another JVM to run, and the way it runs bytecode isn't the way it was compiled in the first place. It's not really self-hosted in the same way that a compiler can be.
    - stonemetal12 4y ago
      You can write a C compiler in Java. The output of the C compiler doesn't depend on the JVM, it would be a regular old program written in C. Writing a Java runtime would be similar, the output would be an executable that doesn't depend on the JVM.
      - Macha 4y ago
        A runtime is not a compiler. The process of bootstrapping a compiler is understood, but if the runtime itself requires a runtime at runtime, that is much more of a turtles all the way down problem than with a runtime less language. It's like how PyPy is Python but with the asterisk that it's bootstrapped with RPython which is an almost-subset of python so that it doesn't require a runtime. You could define a statically compilable Java subset (like that which gcj used to accept) and build a runtime in that which would mean omitting features such as reflection but a lot of defacto standard java tooling like Spring Framework would not be compatible.
        chrisseaton 4y ago
        > You could define a statically compilable Java subset (like that which gcj used to accept) and build a runtime in that which would mean omitting features such as reflection but a lot of defacto standard java tooling like Spring Framework would not be compatible. But the JVM you build using your statically compilable Java subset can then run the Spring Framework or whatever.
        Macha 4y ago
        Sure, but that subset is only "kind of Java" just like RPython or CPython code is only "kind of Python". It's like calling a C compiler a C++ or Objective-C compiler because C is a subset of those languages.
        chrisseaton 4y ago
        > Sure, but that subset is only "kind of Java" How restrictive do you think the subset is? It only doesn't support some features you probably never wanted to use anyway, and arbitrary reflection. I maintain 125k lines of Java that conforms to the subset rules, and to be honest I never even think twice about the fact that it's a subset.
    - twic 4y ago
      Some people at IBM did it in the '90s and wrote a paper about it: https://dl.acm.org/doi/10.1145/320385.320418 https://dl.acm.org/doi/10.1145/320385.320418
    - pjmlp 4y ago
      By using an existing implementation, and having intrisics. There are a couple of Java implementations written in Java, Jikes RVM being one of the first ones, almost 15 years ago.
    - DeathArrow 4y ago
      Just imagine a Python interpreter written in Python. Then the interpreter could interpret its own code while interpreting its own code.
      - sitkack 4y ago
        https://www.pypy.org/ https://www.pypy.org/
  - maxloh 4y ago
    Java isn't as performant as C++. BTW, how do you implement a garbage collector with a garbage-collected language?
    - chrisseaton 4y ago
      > BTW, how do you implement a garbage collector with a garbage-collected language? You write it carefully so the garbage collector itself doesn't also need to allocate objects. Here's a GC for Java written in Java https://github.com/oracle/graal/tree/master/substratevm/src/com.oracle.svm.core.genscavenge/src/com/oracle/svm/core/genscavenge https://github.com/oracle/graal/tree/master/substratevm/src/....
      - quelltext 4y ago
        Digging through that code might be a bit challenging. Do you happen to have a link to a paper/documentation on this? Or maybe some rough explanation how it works (that goes beyond the short summary you provided) Java doesn't provide a primitive to deallocate memory. So while I can see how for instance allocation a huge chunk / big array could be allocated and you represent objects in there don't you end up with a situation where your process will always occupy a fixed amount memory? Might not need to be fixed. You might also be able to extend more but how would you free that again?
        chrisseaton 4y ago
        Not being facetious - but it works exactly like any other GC. There's nothing magic about writing code in Java instead of C that makes a huge difference. But you might find this interesting as a specific example - this is where it actually obtains memory from the OS. https://github.com/oracle/graal/blob/44e68777b130c8ee781c72b0e24dfec922712d85/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/PosixVirtualMemoryProvider.java#L126 https://github.com/oracle/graal/blob/44e68777b130c8ee781c72b... Note the @Uninterruptible annotation - that's saying that this code is safe to use within the GC itself. Notice how the file doesn't contain even a single 'new! (Outside of PosixVirtualMemoryProviderFeature, which is something else.)
  - mike_hearn 4y ago
    Parts of it are written in Java. Over time, more of the JVM has been rewritten in Java. For example recently parts of the reflection subsystem were rewritten in Java. Of course many libraries have been ported over time too. By the way, the .NET CLR is AFAIK written in C++, like with Hotspot. It's not fully self-hosting. It's a tricky process because HotSpot is highly performance sensitive code. People won't accept regressions just to convenience the JDK maintainers. Java meanwhile is deliberately a simple language to make it accessible for people, so you lose some low level techniques that are useful for performance. Nonetheless, GraalVM native image has proven that you can achieve HotSpot like performance with a JVM written in Java. However it requires a big change in the compilation model that isn't always appropriate.
    - pjmlp 4y ago
      In each CLR release there are little pieces that transition from C++ to C#, as C# currently is getting quite a few low level features for systems programing.
  - vips7L 4y ago
    The core CLR is written in C++ just like HotSpot.
    - pjmlp 4y ago
      Mostly, since the .NET Core got introduced, the C++ surface area gets reduced with each release, there are occasionally references to it when a new release comes out on MSDN blogs.
  - pron 4y ago
    The Java runtime contains ~8MLOC; of them, about 1.5M are C++ (and Assembly generated by a C++ DSL), and more and more of the runtime is being written in Java (e.g. the virtual thread scheduler is written in Java). The two main pieces that aren't are the bytecode interpreter, the JITs, and the GCs (although the Graal JIT is written in Java). Interestingly, the more latency-critical stuff is written in Java (the JITs and GCs work mostly in the background nowadays, and the interpreter is used only at startup and on deoptimisation slow-paths). Some of the reason is historical, and some has to do with warmup. Project Leyden and Graal's Native Image will help compile more Java AOT, allowing even more of the runtime to gradually be written in Java. It will take some time as it's not a top priority: it won't immediately deliver user-facing functionality, and most of the work on the JDK is already done in Java code anyway.
  - pjmlp 4y ago
    There are a couple of Java implementations written in Java, Jikes RVM being one of the first ones, almost 15 years ago. GraalVM is the evolution of MaximeVM, originally developed at SunLabs, also about 15 years ago.
- treffer 4y ago
  There was a java implementation of a JVM, jikes rvm. I haven't looked at it for ages and looking at Wikipedia it seems dead, so curious if there is any newer attempts....
  - chrisseaton 4y ago
    > so curious if there is any newer attempts.... You're commenting on an article about a newer attempt?
- agilob 4y ago
  This is what it is. GraalVM is implemented in Java, there is a Truffle framework that compiles Java, Ruby, JS, Python to Java Truffle, which then runs on GraalVM JIT compiler.
  - e12e 4y ago
    Unfortunately from tfa: > Oracle plans to contribute the most applicable portions of the GraalVM just-in-time (JIT) compiler and Native Image. Oracle does not currently intend to contribute the polyglot technologies supporting other languages such as Python, Ruby, R, and JavaScript. Additional details will follow in the coming months as we move forward through this process. It would appear this is about making native image artifacts / distribution a first class citizen across all of Java - making it an alternative to uberjars + jvm for running/distribution. Ie native desktop apps and native binaries for servers?
  - pencilguin 4y ago
    Wait, GraalVM is implemented in Java? Does that mean to run it you need another JVM to run it on top of? That sounds stupid... Maybe you need another VM just to run it on once, so it can translate itself to native code on the target?
    - dragonwriter 4y ago
      > Does that mean to run it you need another JVM to run it on top of? GraalVM is the regular HotspotVM integrated with the GraalVM compiler (which is normally AOT compiled as a native library, but can be run as a JAR); it also supports tooling with the ability to compile code targeting the JVM to a native executable, as well as leveraging AOT compilation itself. https://www.graalvm.org/22.3/reference-manual/native-image/ https://www.graalvm.org/22.3/reference-manual/native-image/
    - kaba0 4y ago
      https://news.ycombinator.com/item?id=33341760 https://news.ycombinator.com/item?id=33341760 Graal reuses all the insanely good GC implementations, observability tools etc already present in OpenJDK (as throwing all that away would be stupid).
- dig1 4y ago
  Check for Maxine VM [1][2] project. [1] https://en.wikipedia.org/wiki/Maxine_Virtual_Machine https://en.wikipedia.org/wiki/Maxine_Virtual_Machine [2] https://maxine-vm.readthedocs.io/en/latest/ https://maxine-vm.readthedocs.io/en/latest/
- mike_hearn 4y ago
  A component of the GraalVM project is called native-image. The native-image tool compiles a Java app to machine code ahead of time and combines it with a small JVM called SubstrateVM. That JVM is written in Java, just like the rest of your app. As pointed out by other comments, this concept of a "meta-circular VM" isn't new. It's been done before by two other projects, Maxine and Jikes. What's different about SubstrateVM is that this is a production tool rather than a research project, and it's not just a JVM, it's also a way to pre-initialize the app. Therefore programs compiled with native-image can start as fast as programs written in C. Actually, slightly faster in some cases. You may wonder how that's possible given that Java apps normally start slowly, but it's because there's no JIT compilation and the state of the heap is snapshotted, with classes pre-initialized including the JVM itself. So the program can literally just start executing at main() in machine code with no VM startup overhead, because it's done already. The downside is that snapshotting and AOT consume a lot of disk space. There are some questions below asking how this works. It sounds initially "impossible", like a lot of stuff GraalVM/Truffle does, but it's quite easy to understand really. You start with a bytecode compiler written in Java. This is a normal program written in the normal way, because a compiler is ultimately just a function that converts one stream of bytes to another. Then you write the runtime and GC in Java too, and compile that as well. This code is a bit special. It's still syntactically Java, but, some classes and methods are given special meanings and some extra rules apply. They aren't compiled in the same way as normal Java code. For example you can write code like this: UnsignedWord value = Pointer.readUnsignedWord(address) This doesn't allocate an object or call a static method. Instead it will be compiled down to a single mov instruction. Likewise for writing to memory - there are magic methods that are taken to mean "emit this assembly" instead of doing normal method calls. Several other tricks are required. GC code can't allocate because it would mess up the heap it's working with, so you can use annotations to mark methods as "never access the heap". But then, GC code is written in Java and Java must allocate for almost anything non trivial, so how does that work? The answer is, the GC code is initialized at build time and all the objects it needs are snapshotted into the default heap that's mapped into memory at startup. There are lots of other tricks, mostly annotations that control the compiler so that e.g. methods are guaranteed to be inlined and removed, objects are guaranteed to be stack allocated. This isn't available to normal Java but when you control the compiler it's not a problem. The advantage of this Java-superset (or subset) is that you can use all the normal tools that understand source code, like IntelliJ, JavaDoc etc.
Lapsa 4y ago
somehow I'm in disbelief. as in - why is this news #1?
- deleted 4y ago
  [deleted]
- tyho 4y ago
  Java isn't cool and most HN'ers aren't interested in it.
  - Alupis 4y ago
    Even though majority of HN'ers write Java code (judging by the numerous developer surveys from various companies). It may not be hot and cool like some hip new language, but Java work is very important and quite literally makes the world work.
  - jjtheblunt 4y ago
    Isn't this more about the GraalVM, as an alternate runtime to the JVM, than it is about Java, since the other JVM-target languages can leverage it also?
ccleve 4y ago
I don't say nice things about Oracle very often, but they deserve some praise here. Graal is a very, very ambitious project, and Oracle has been funding it for years. It's still rough around the edges, but it promises to enable new programming languages to run on a high-performance JVM, compiled to native code. Write-once, run anywhere, at native speed. And now they're donating it. It's very decent of them.
- bluejekyll 4y ago
  It may not only be benevolence though. The JVM and Graal are not the only game in town anymore. Webassembly is growing in various areas, clienside, edge, backend. WASM fills much of the same needs as Graal, and then some since it’s embedded in every major browser. This move is good for Graal, as it will help it compete, but there’s still a big question in my mind at least about if Graal is going to be able to compete long-term. Yes, I know Graal can also execute WASM generated binaries, so it may have a space in this environment, but will it outperform native WASM VMs? And will WASM become the de facto binary format for shipping things where JVM bytecode has been used in the past? What’s Graal’s place in the future?
  - dopidopHN 4y ago
    Yeah. I see that as a way to position the JVM for cloud-function and other highly available and disposable compute.
  - lostmsu 4y ago
    WASM is not really a replacement for Graal. Graal is more of a language implementation framework, while WASM is a compilation target.
    - lostmsu 4y ago
      I think down in the comments people mentioned, that the language part of Graal is not actually included in the contribution.
  - vips7L 4y ago
dig1 4y ago
Wonderful news! I was always scared that Oracle could slap some $$$ licensing scheme for GraalVM, but this proves me wrong. I'm not following other parts of GraalVM development, except Native Image capability, but I must say that, IMHO, GraalVM/native-image is one of the best things after sliced bread and JVM out there. Native Image shows true power when it has to compile higher-level languages than Java, like Scala, Clojure, or Kotlin, and it compiles them pretty darn well.
rafaelturk 4y ago
Unexpected move from such an evil company like Oracle
sroussey 4y ago
TL;DR Oracle plans to contribute the most applicable portions of the GraalVM just-in-time (JIT) compiler and Native Image. Oracle does not currently intend to contribute the polyglot technologies supporting other languages such as Python, Ruby, R, and JavaScript.
- cutler 4y ago
  Hmmmm, aren't the latter one of the big reasons for adopting GraalVM?
  - niwinz 4y ago
    The later one is just a library and you can already use it in the standard JVM ( with the disadvantage of not having the same performance as if you run it with graalvm), but if the JIT and other internal stuff is already on standard JVM, that will run the same way
w10-1 4y ago
GraalVM is truly great stuff. GraalVM native compilation helps Java in the data center to avoid being a cost sink and to reduce start-up latency. Oracle needs Java to sell enterprise software. Oracle contributing to OpenJDK may be required for Amazon cooperation (since Amazon is pushing its own JDK build) and probably helps the library ecosystem work towards native compatibility. Native support for reflection (used in many libraries) requires "reachability metadata", maps of reflective API usage, at build time. Anyone can do it, but enterprise requires authoritative sources. Until authoritative reachability metadata covers the transitive graph of library+version dependencies in enterprise software, GraalVM native AOT builds are a PITA. - https://github.com/oracle/graalvm-reachability-metadata https://github.com/oracle/graalvm-reachability-metadata - latest release: https://medium.com/graalvm/graalvm-22-3-is-here-jdk-19-builds-jlink-support-new-monitoring-features-and-more-f6e2b2eeff95 https://medium.com/graalvm/graalvm-22-3-is-here-jdk-19-build... - graalvm "community" roadmap: https://github.com/orgs/oracle/projects/6 https://github.com/orgs/oracle/projects/6 (As a side note: Mark Reinhold has run the JDK team since 1997: is there any comparable example of such stellar leadership for broadly-adopted software across multiple technical and organizational eras?)
- whartung 4y ago
  Java has been on a freight train run for the past 5 years. It is exhausting to keep up with. From the demonic release pace, to the dramatic changes to the platform, it's been a rough ride for some. But at the same time, it's also smooth sailing, and it's getting better all the time. It's still Java, for a bazillion applications it still "Just Works". It's still (IMHO) far more manageable and stable than many other platforms. I think the combination of Oracle and the entire community around it have been marshaling it really well with little drama. Change, sure. But not Drama. The Enterprise Edition departure was a big deal, but even that transitioned pretty well. That was no small task, and I think the vendors and framework folks have been handling that pretty well. GraalVM is just another step forward for the entire community, and it is kind of Oracle (however motivated) to release it. In truth, I think, overall, Java has been mostly (mostly) Oracle free, despite their monster investments into the technology and community. They could have been a much less benevolent dictator.
- mapme 4y ago
dopidopHN 4y ago
I’m surprising myself writing that but I’m looking with excitement at upcoming version of java. With Loom and GraavVM, I can have cheap treads on fast booting JVM.
axelfontaine 4y ago
Makes total sense to avoid wasteful duplication of effort between Native Image and Leyden!
alberth 4y ago
Does this have any impact on Truffle to speed up Ruby on Rails?
- mike_hearn 4y ago
  Nothing technical is changing. It's just a change in the development process used by Oracle. A lot of this announcement will be opaque if you don't know the history of Sun, but suffice it to say that the core Java development process has a lot of oddness in it that exists to make Java more open and less controlled by Sun-then-Oracle, for example if you go look at their mailing lists you'll see they "vote" on whether their own new colleagues should be allowed to commit to the source tree. This is basically legacy stuff these days but if I understand correctly was written into various legal agreements. Anyway, OpenJDK is its own project with its own processes and culture, GraalVM was historically from a totally separate part of Oracle and adopted its own processes and development culture. This announcement doesn't change what tech is available, it's more about re-organizing how development is done. It doesn't really affect Java developers much, except that maybe now more stuff will come out of the box with a 'regular' JDK. Currently to get Graal technology you need to use their own custom spin of the JDK.
  - sitkack 4y ago
    The part I like is that it basically _forces_ GraalVM on everyone who is currently using a JVM with Oracle lineage. It would be not unlike PyPy and CPython agreeing to ship together, not really but kinda. GraalVM is going to see adoption go up > 100x.
MichaelCollins 4y ago
Always look a gift horse from Larry Ellison in the mouth. Very carefully.
firstSpeaker 4y ago
Very likely with direct connection with project Leyden. https://openjdk.org/projects/leyden/ https://openjdk.org/projects/leyden/
PedroBatista 4y ago
I refuse to praise Oracle for anything. But I could make an exception if they put Isolates in the CE version of Graal and not only the Enterprise one. :) Also, obviously Oracle didn't do this out of the kindness of their hearts, if they didn't contribute Graal into the OpenJDK the would risk to Graal never become anything other than a niche VM because most people, specially big clients don't want to change VMs and the CE version will be their new gateway drug to their Enterprise version of Graal.
- pron 4y ago
  Linux, Chromium and V8, Java, .NET, and Go, and most other large open source projects these days are developed by for-profit corporations, none of them do it out of kindness. Frankly, if corporations were to bestow gifts worth hundreds of millions of dollars on society, I'd rather those gifts not be free software that is largely enjoyed by other for-profit corporations.
  - PedroBatista 4y ago
    I agree, I was just pointing that this is not a "donation" because Larry is Santa Claus but just a business move. Which I have no problem with.
- grashalm 4y ago
  Which isolates do you mean? Support for Native image isolates is included in CE. There are some features like polyglot isolates that are currently EE, but they are just a use of native image isolates.
deleted 4y ago
[deleted]

290 points by ludovicianul 4y ago

pulse7 4y ago

Maybe we will soon see the Java Virtual Machine implemented wholly in (a subset of) Java...

Thaxll 4y ago
It's a good point, after so long why the JVM is not written in Java actually? For example the Go runtime and I think C# as well are written in their respective language. https://github.com/golang/go/tree/master/src/runtime https://github.com/golang/go/tree/master/src/runtime https://github.com/dotnet/runtime https://github.com/dotnet/runtime
- simias 4y ago
  Maybe it's my ignorance of the Java ecosystem or a lack of imagination but how could a language that requires a heavy runtime be written in itself? Wouldn't you need a runtime for the runtime, and then a runtime for the runtime for the runtime and then...? I can't quite imagine how you'd bootstrap something like that.
  - chrisseaton 4y ago
    You implement the runtime itself in Java, and you use that runtime to run your runtime.
    - stingraycharles 4y ago
      Exactly, implementing the runtime is the bootstrapping (apart from the compilation of course). There is no implementing the runtime that implements the runtime that implements the runtime.
    - throwaway894345 4y ago
      The missing detail is that you have to AOT compile the outermost runtime.
  - acedTrex 4y ago
    Graal supports AOT compilation, so you can write the runtime in java and AOT compile it to a given arch. thats what the thread is talking about
  - jlouis 4y ago
    No. See Scheme48 or Go. There are some ways around that bootstrap problem.
    - throwaway894345 4y ago
      Not sure about Scheme48, but Go's solution is AOT compiling the runtime, which is essentially what the parent is asking about.
  - crustycoder 4y ago
    It's no different to writing any other compiler for Language X in Language X, and that's a really common thing to do. The Java compiler emits files containing Java Bytecode which are subsequently run by a different invocation of the JVM.
    - Taywee 4y ago
      It's different in that the JVM is not a compiler. It's a bit like suggesting writing CPython in Python. It's possible only if the interpreter's Python source can be compiled ahead of time, like PyPy.
      - chrisseaton 4y ago
        > It's possible only if the interpreter's Python source can be compiled ahead of time, like PyPy. That's what it does.
        Taywee 4y ago
        Oh, I know, I'm just pointing out that a self-hosted compiler is a different ballgame than a runtime being written in the language that runs on it. Without some degree of AOT compilation (usually of a subset or dialect of the language compiled in a different fashion), it's not really possible. The GP seemed to miss that the discussion was about the JVM, not javac. With Graal, it's possible to write a JVM in Java, but the JVM doesn't depend on another JVM to run, and the way it runs bytecode isn't the way it was compiled in the first place. It's not really self-hosted in the same way that a compiler can be.
  - stonemetal12 4y ago
    You can write a C compiler in Java. The output of the C compiler doesn't depend on the JVM, it would be a regular old program written in C. Writing a Java runtime would be similar, the output would be an executable that doesn't depend on the JVM.
    - Macha 4y ago
      A runtime is not a compiler. The process of bootstrapping a compiler is understood, but if the runtime itself requires a runtime at runtime, that is much more of a turtles all the way down problem than with a runtime less language. It's like how PyPy is Python but with the asterisk that it's bootstrapped with RPython which is an almost-subset of python so that it doesn't require a runtime. You could define a statically compilable Java subset (like that which gcj used to accept) and build a runtime in that which would mean omitting features such as reflection but a lot of defacto standard java tooling like Spring Framework would not be compatible.
      - chrisseaton 4y ago
        > You could define a statically compilable Java subset (like that which gcj used to accept) and build a runtime in that which would mean omitting features such as reflection but a lot of defacto standard java tooling like Spring Framework would not be compatible. But the JVM you build using your statically compilable Java subset can then run the Spring Framework or whatever.
        Macha 4y ago
        Sure, but that subset is only "kind of Java" just like RPython or CPython code is only "kind of Python". It's like calling a C compiler a C++ or Objective-C compiler because C is a subset of those languages.
        chrisseaton 4y ago
        > Sure, but that subset is only "kind of Java" How restrictive do you think the subset is? It only doesn't support some features you probably never wanted to use anyway, and arbitrary reflection. I maintain 125k lines of Java that conforms to the subset rules, and to be honest I never even think twice about the fact that it's a subset.
  - twic 4y ago
    Some people at IBM did it in the '90s and wrote a paper about it: https://dl.acm.org/doi/10.1145/320385.320418 https://dl.acm.org/doi/10.1145/320385.320418
  - pjmlp 4y ago
    By using an existing implementation, and having intrisics. There are a couple of Java implementations written in Java, Jikes RVM being one of the first ones, almost 15 years ago.
  - DeathArrow 4y ago
    Just imagine a Python interpreter written in Python. Then the interpreter could interpret its own code while interpreting its own code.
    - sitkack 4y ago
      https://www.pypy.org/ https://www.pypy.org/
- maxloh 4y ago
  Java isn't as performant as C++. BTW, how do you implement a garbage collector with a garbage-collected language?
  - chrisseaton 4y ago
    > BTW, how do you implement a garbage collector with a garbage-collected language? You write it carefully so the garbage collector itself doesn't also need to allocate objects. Here's a GC for Java written in Java https://github.com/oracle/graal/tree/master/substratevm/src/com.oracle.svm.core.genscavenge/src/com/oracle/svm/core/genscavenge https://github.com/oracle/graal/tree/master/substratevm/src/....
    - quelltext 4y ago
      Digging through that code might be a bit challenging. Do you happen to have a link to a paper/documentation on this? Or maybe some rough explanation how it works (that goes beyond the short summary you provided) Java doesn't provide a primitive to deallocate memory. So while I can see how for instance allocation a huge chunk / big array could be allocated and you represent objects in there don't you end up with a situation where your process will always occupy a fixed amount memory? Might not need to be fixed. You might also be able to extend more but how would you free that again?
      - chrisseaton 4y ago
        Not being facetious - but it works exactly like any other GC. There's nothing magic about writing code in Java instead of C that makes a huge difference. But you might find this interesting as a specific example - this is where it actually obtains memory from the OS. https://github.com/oracle/graal/blob/44e68777b130c8ee781c72b0e24dfec922712d85/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/PosixVirtualMemoryProvider.java#L126 https://github.com/oracle/graal/blob/44e68777b130c8ee781c72b... Note the @Uninterruptible annotation - that's saying that this code is safe to use within the GC itself. Notice how the file doesn't contain even a single 'new! (Outside of PosixVirtualMemoryProviderFeature, which is something else.)
- mike_hearn 4y ago
  Parts of it are written in Java. Over time, more of the JVM has been rewritten in Java. For example recently parts of the reflection subsystem were rewritten in Java. Of course many libraries have been ported over time too. By the way, the .NET CLR is AFAIK written in C++, like with Hotspot. It's not fully self-hosting. It's a tricky process because HotSpot is highly performance sensitive code. People won't accept regressions just to convenience the JDK maintainers. Java meanwhile is deliberately a simple language to make it accessible for people, so you lose some low level techniques that are useful for performance. Nonetheless, GraalVM native image has proven that you can achieve HotSpot like performance with a JVM written in Java. However it requires a big change in the compilation model that isn't always appropriate.
  - pjmlp 4y ago
    In each CLR release there are little pieces that transition from C++ to C#, as C# currently is getting quite a few low level features for systems programing.
- vips7L 4y ago
  The core CLR is written in C++ just like HotSpot.
  - pjmlp 4y ago
    Mostly, since the .NET Core got introduced, the C++ surface area gets reduced with each release, there are occasionally references to it when a new release comes out on MSDN blogs.
- pron 4y ago
  The Java runtime contains ~8MLOC; of them, about 1.5M are C++ (and Assembly generated by a C++ DSL), and more and more of the runtime is being written in Java (e.g. the virtual thread scheduler is written in Java). The two main pieces that aren't are the bytecode interpreter, the JITs, and the GCs (although the Graal JIT is written in Java). Interestingly, the more latency-critical stuff is written in Java (the JITs and GCs work mostly in the background nowadays, and the interpreter is used only at startup and on deoptimisation slow-paths). Some of the reason is historical, and some has to do with warmup. Project Leyden and Graal's Native Image will help compile more Java AOT, allowing even more of the runtime to gradually be written in Java. It will take some time as it's not a top priority: it won't immediately deliver user-facing functionality, and most of the work on the JDK is already done in Java code anyway.
- pjmlp 4y ago
  There are a couple of Java implementations written in Java, Jikes RVM being one of the first ones, almost 15 years ago. GraalVM is the evolution of MaximeVM, originally developed at SunLabs, also about 15 years ago.
treffer 4y ago
There was a java implementation of a JVM, jikes rvm. I haven't looked at it for ages and looking at Wikipedia it seems dead, so curious if there is any newer attempts....
- chrisseaton 4y ago
  > so curious if there is any newer attempts.... You're commenting on an article about a newer attempt?
agilob 4y ago
This is what it is. GraalVM is implemented in Java, there is a Truffle framework that compiles Java, Ruby, JS, Python to Java Truffle, which then runs on GraalVM JIT compiler.
- e12e 4y ago
  Unfortunately from tfa: > Oracle plans to contribute the most applicable portions of the GraalVM just-in-time (JIT) compiler and Native Image. Oracle does not currently intend to contribute the polyglot technologies supporting other languages such as Python, Ruby, R, and JavaScript. Additional details will follow in the coming months as we move forward through this process. It would appear this is about making native image artifacts / distribution a first class citizen across all of Java - making it an alternative to uberjars + jvm for running/distribution. Ie native desktop apps and native binaries for servers?
- pencilguin 4y ago
  Wait, GraalVM is implemented in Java? Does that mean to run it you need another JVM to run it on top of? That sounds stupid... Maybe you need another VM just to run it on once, so it can translate itself to native code on the target?
  - dragonwriter 4y ago
    > Does that mean to run it you need another JVM to run it on top of? GraalVM is the regular HotspotVM integrated with the GraalVM compiler (which is normally AOT compiled as a native library, but can be run as a JAR); it also supports tooling with the ability to compile code targeting the JVM to a native executable, as well as leveraging AOT compilation itself. https://www.graalvm.org/22.3/reference-manual/native-image/ https://www.graalvm.org/22.3/reference-manual/native-image/
  - kaba0 4y ago
    https://news.ycombinator.com/item?id=33341760 https://news.ycombinator.com/item?id=33341760 Graal reuses all the insanely good GC implementations, observability tools etc already present in OpenJDK (as throwing all that away would be stupid).
dig1 4y ago
Check for Maxine VM [1][2] project. [1] https://en.wikipedia.org/wiki/Maxine_Virtual_Machine https://en.wikipedia.org/wiki/Maxine_Virtual_Machine [2] https://maxine-vm.readthedocs.io/en/latest/ https://maxine-vm.readthedocs.io/en/latest/
mike_hearn 4y ago
A component of the GraalVM project is called native-image. The native-image tool compiles a Java app to machine code ahead of time and combines it with a small JVM called SubstrateVM. That JVM is written in Java, just like the rest of your app. As pointed out by other comments, this concept of a "meta-circular VM" isn't new. It's been done before by two other projects, Maxine and Jikes. What's different about SubstrateVM is that this is a production tool rather than a research project, and it's not just a JVM, it's also a way to pre-initialize the app. Therefore programs compiled with native-image can start as fast as programs written in C. Actually, slightly faster in some cases. You may wonder how that's possible given that Java apps normally start slowly, but it's because there's no JIT compilation and the state of the heap is snapshotted, with classes pre-initialized including the JVM itself. So the program can literally just start executing at main() in machine code with no VM startup overhead, because it's done already. The downside is that snapshotting and AOT consume a lot of disk space. There are some questions below asking how this works. It sounds initially "impossible", like a lot of stuff GraalVM/Truffle does, but it's quite easy to understand really. You start with a bytecode compiler written in Java. This is a normal program written in the normal way, because a compiler is ultimately just a function that converts one stream of bytes to another. Then you write the runtime and GC in Java too, and compile that as well. This code is a bit special. It's still syntactically Java, but, some classes and methods are given special meanings and some extra rules apply. They aren't compiled in the same way as normal Java code. For example you can write code like this: UnsignedWord value = Pointer.readUnsignedWord(address) This doesn't allocate an object or call a static method. Instead it will be compiled down to a single mov instruction. Likewise for writing to memory - there are magic methods that are taken to mean "emit this assembly" instead of doing normal method calls. Several other tricks are required. GC code can't allocate because it would mess up the heap it's working with, so you can use annotations to mark methods as "never access the heap". But then, GC code is written in Java and Java must allocate for almost anything non trivial, so how does that work? The answer is, the GC code is initialized at build time and all the objects it needs are snapshotted into the default heap that's mapped into memory at startup. There are lots of other tricks, mostly annotations that control the compiler so that e.g. methods are guaranteed to be inlined and removed, objects are guaranteed to be stack allocated. This isn't available to normal Java but when you control the compiler it's not a problem. The advantage of this Java-superset (or subset) is that you can use all the normal tools that understand source code, like IntelliJ, JavaDoc etc.

Lapsa 4y ago

somehow I'm in disbelief. as in - why is this news #1?

deleted 4y ago
[deleted]
tyho 4y ago
Java isn't cool and most HN'ers aren't interested in it.
- Alupis 4y ago
  Even though majority of HN'ers write Java code (judging by the numerous developer surveys from various companies). It may not be hot and cool like some hip new language, but Java work is very important and quite literally makes the world work.
- jjtheblunt 4y ago
  Isn't this more about the GraalVM, as an alternate runtime to the JVM, than it is about Java, since the other JVM-target languages can leverage it also?

ccleve 4y ago

I don't say nice things about Oracle very often, but they deserve some praise here. Graal is a very, very ambitious project, and Oracle has been funding it for years. It's still rough around the edges, but it promises to enable new programming languages to run on a high-performance JVM, compiled to native code. Write-once, run anywhere, at native speed. And now they're donating it. It's very decent of them.

bluejekyll 4y ago
It may not only be benevolence though. The JVM and Graal are not the only game in town anymore. Webassembly is growing in various areas, clienside, edge, backend. WASM fills much of the same needs as Graal, and then some since it’s embedded in every major browser. This move is good for Graal, as it will help it compete, but there’s still a big question in my mind at least about if Graal is going to be able to compete long-term. Yes, I know Graal can also execute WASM generated binaries, so it may have a space in this environment, but will it outperform native WASM VMs? And will WASM become the de facto binary format for shipping things where JVM bytecode has been used in the past? What’s Graal’s place in the future?
- dopidopHN 4y ago
  Yeah. I see that as a way to position the JVM for cloud-function and other highly available and disposable compute.
- lostmsu 4y ago
  WASM is not really a replacement for Graal. Graal is more of a language implementation framework, while WASM is a compilation target.
  - lostmsu 4y ago
    I think down in the comments people mentioned, that the language part of Graal is not actually included in the contribution.
- vips7L 4y ago

dig1 4y ago

Wonderful news! I was always scared that Oracle could slap some $$$ licensing scheme for GraalVM, but this proves me wrong. I'm not following other parts of GraalVM development, except Native Image capability, but I must say that, IMHO, GraalVM/native-image is one of the best things after sliced bread and JVM out there. Native Image shows true power when it has to compile higher-level languages than Java, like Scala, Clojure, or Kotlin, and it compiles them pretty darn well.

rafaelturk 4y ago

Unexpected move from such an evil company like Oracle

sroussey 4y ago

TL;DR Oracle plans to contribute the most applicable portions of the GraalVM just-in-time (JIT) compiler and Native Image. Oracle does not currently intend to contribute the polyglot technologies supporting other languages such as Python, Ruby, R, and JavaScript.

cutler 4y ago
Hmmmm, aren't the latter one of the big reasons for adopting GraalVM?
- niwinz 4y ago
  The later one is just a library and you can already use it in the standard JVM ( with the disadvantage of not having the same performance as if you run it with graalvm), but if the JIT and other internal stuff is already on standard JVM, that will run the same way

w10-1 4y ago

GraalVM is truly great stuff. GraalVM native compilation helps Java in the data center to avoid being a cost sink and to reduce start-up latency. Oracle needs Java to sell enterprise software. Oracle contributing to OpenJDK may be required for Amazon cooperation (since Amazon is pushing its own JDK build) and probably helps the library ecosystem work towards native compatibility. Native support for reflection (used in many libraries) requires "reachability metadata", maps of reflective API usage, at build time. Anyone can do it, but enterprise requires authoritative sources. Until authoritative reachability metadata covers the transitive graph of library+version dependencies in enterprise software, GraalVM native AOT builds are a PITA. - https://github.com/oracle/graalvm-reachability-metadata https://github.com/oracle/graalvm-reachability-metadata - latest release: https://medium.com/graalvm/graalvm-22-3-is-here-jdk-19-builds-jlink-support-new-monitoring-features-and-more-f6e2b2eeff95 https://medium.com/graalvm/graalvm-22-3-is-here-jdk-19-build... - graalvm "community" roadmap: https://github.com/orgs/oracle/projects/6 https://github.com/orgs/oracle/projects/6 (As a side note: Mark Reinhold has run the JDK team since 1997: is there any comparable example of such stellar leadership for broadly-adopted software across multiple technical and organizational eras?)

whartung 4y ago
Java has been on a freight train run for the past 5 years. It is exhausting to keep up with. From the demonic release pace, to the dramatic changes to the platform, it's been a rough ride for some. But at the same time, it's also smooth sailing, and it's getting better all the time. It's still Java, for a bazillion applications it still "Just Works". It's still (IMHO) far more manageable and stable than many other platforms. I think the combination of Oracle and the entire community around it have been marshaling it really well with little drama. Change, sure. But not Drama. The Enterprise Edition departure was a big deal, but even that transitioned pretty well. That was no small task, and I think the vendors and framework folks have been handling that pretty well. GraalVM is just another step forward for the entire community, and it is kind of Oracle (however motivated) to release it. In truth, I think, overall, Java has been mostly (mostly) Oracle free, despite their monster investments into the technology and community. They could have been a much less benevolent dictator.
mapme 4y ago

dopidopHN 4y ago

I’m surprising myself writing that but I’m looking with excitement at upcoming version of java. With Loom and GraavVM, I can have cheap treads on fast booting JVM.

axelfontaine 4y ago

Makes total sense to avoid wasteful duplication of effort between Native Image and Leyden!

alberth 4y ago

Does this have any impact on Truffle to speed up Ruby on Rails?

mike_hearn 4y ago
Nothing technical is changing. It's just a change in the development process used by Oracle. A lot of this announcement will be opaque if you don't know the history of Sun, but suffice it to say that the core Java development process has a lot of oddness in it that exists to make Java more open and less controlled by Sun-then-Oracle, for example if you go look at their mailing lists you'll see they "vote" on whether their own new colleagues should be allowed to commit to the source tree. This is basically legacy stuff these days but if I understand correctly was written into various legal agreements. Anyway, OpenJDK is its own project with its own processes and culture, GraalVM was historically from a totally separate part of Oracle and adopted its own processes and development culture. This announcement doesn't change what tech is available, it's more about re-organizing how development is done. It doesn't really affect Java developers much, except that maybe now more stuff will come out of the box with a 'regular' JDK. Currently to get Graal technology you need to use their own custom spin of the JDK.
- sitkack 4y ago
  The part I like is that it basically _forces_ GraalVM on everyone who is currently using a JVM with Oracle lineage. It would be not unlike PyPy and CPython agreeing to ship together, not really but kinda. GraalVM is going to see adoption go up > 100x.

MichaelCollins 4y ago

Always look a gift horse from Larry Ellison in the mouth. Very carefully.

firstSpeaker 4y ago

Very likely with direct connection with project Leyden. https://openjdk.org/projects/leyden/ https://openjdk.org/projects/leyden/

PedroBatista 4y ago

I refuse to praise Oracle for anything. But I could make an exception if they put Isolates in the CE version of Graal and not only the Enterprise one. :) Also, obviously Oracle didn't do this out of the kindness of their hearts, if they didn't contribute Graal into the OpenJDK the would risk to Graal never become anything other than a niche VM because most people, specially big clients don't want to change VMs and the CE version will be their new gateway drug to their Enterprise version of Graal.

pron 4y ago
Linux, Chromium and V8, Java, .NET, and Go, and most other large open source projects these days are developed by for-profit corporations, none of them do it out of kindness. Frankly, if corporations were to bestow gifts worth hundreds of millions of dollars on society, I'd rather those gifts not be free software that is largely enjoyed by other for-profit corporations.
- PedroBatista 4y ago
  I agree, I was just pointing that this is not a "donation" because Larry is Santa Claus but just a business move. Which I have no problem with.
grashalm 4y ago
Which isolates do you mean? Support for Native image isolates is included in CE. There are some features like polyglot isolates that are currently EE, but they are just a use of native image isolates.

deleted 4y ago

[deleted]