Hacker News Reader

Comment by simias | Hacker News Reader

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.

View on HN

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

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.

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.

Some people at IBM did it in the '90s and wrote a paper about it:

https://dl.acm.org/doi/10.1145/320385.320418

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.

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.

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

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.

You implement the runtime itself in Java, and you use that runtime to run your runtime.

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.

The missing detail is that you have to AOT compile the outermost runtime.

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.

Just imagine a Python interpreter written in Python. Then the interpreter could interpret its own code while interpreting its own code.

https://www.pypy.org/

No.

See Scheme48 or Go. There are some ways around that bootstrap problem.

Not sure about Scheme48, but Go's solution is AOT compiling the runtime, which is essentially what the parent is asking about.

Reply on news.ycombinator.com