41–50 of 141 posts
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.
Earlier quoted context omitted.
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.
You implement the runtime itself in Java, and you use that runtime to run your runtime.
Earlier quoted context omitted.
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.
No. See Scheme48 or Go. There are some ways around that bootstrap problem.
Earlier quoted context omitted.
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 sit…
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/44e68777b130c8ee781c72b... Note the @Uninterruptible annotation - that's saying that this code is safe to use withi…
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.
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?
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
- latest release: https://medium.com/graalvm/graalvm-22-3-is-here-jdk-19-build...
- graalvm "community" roadmap: 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?)
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.
Can someone play devil's advocate to explain how this news may actually favor this negative view of Oracle? The sentiment in this thread is praising Oracle's decision here, so I'm just curious if there's an alternative viewpoint that's skeptical or wary of this decision and Oracle's motivation to make it.
With that said, I'm not looking for reason to diminish the positives. I'm just curious. Good moves that benefit the community should absolutely be acknowledged and encouraged.
EDIT: It looks like another person commented how this may not be benevolent in the context of WebAssembly while I was slowly typing this comment up on mobile. I'd still be interested in this discussion though.
Maybe we will soon see the Java Virtual Machine implemented wholly in (a subset of) Java...
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)
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.
With Loom and GraavVM, I can have cheap treads on fast booting JVM.
Maybe we will soon see the Java Virtual Machine implemented wholly in (a subset of) Java...
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.
> 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?