6 ms·

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

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

by simias 4y ago

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/