Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

graalvm.org

Post reply on HN
Print view View original

31–40 of 141 posts

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#31

Post by chrisseaton »

Macha wrote: post #29
chrisseaton wrote: post #25

Earlier quoted context omitted.

> 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.

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.

> 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.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#32

Post by agilob »

pulse7 wrote: post #2

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.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#35

Post by sroussey »

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.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#36

Post by Taywee »

chrisseaton wrote: post #23
Taywee wrote: post #22

Earlier quoted context omitted.

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.

> It's possible only if the interpreter's Python source can be compiled ahead of time, like PyPy. That's what it does.

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.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#37

Post by Macha »

chrisseaton wrote: post #31
Macha wrote: post #29

Earlier quoted context omitted.

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.

> 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.

Isn't arbitrary reflection how Spring, Hibernate, AspectJ, every JSON library and other common libraries that you may be using directly or indirectly work?

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#38

Post by chrisseaton »

Macha wrote: post #37
chrisseaton wrote: post #31

Earlier quoted context omitted.

> 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.

Isn't arbitrary reflection how Spring, Hibernate, AspectJ, every JSON library and other common libraries that you may be using directly or indirectly work?

No they use predictable reflection, not arbitrary reflection. The subset just needs to be told ahead of time which classes you want to be able to interact with reflectively. As I say, it's not an issue for my quite-large application.

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#39

Post by quelltext »

chrisseaton wrote: post #11
maxloh wrote: post #8

Earlier quoted context omitted.

Java isn't as performant as C++. BTW, how do you implement a garbage collector with a garbage-collected language?

> 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/... .

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?

Re: Oracle Contributing GraalVM Community Edition Java Code to OpenJDK

#40

Post by chrisseaton »

quelltext wrote: post #39
chrisseaton wrote: post #11

Earlier quoted context omitted.

> 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/... .

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 within the GC itself. Notice how the file doesn't contain even a single 'new! (Outside of PosixVirtualMemoryProviderFeature, which is something else.)

Post reply on HN