5 ms·

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

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

by Thaxll 4y ago

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.