6 ms·
After this merge we will have JVM implemented mostly in Java (aka "self hosted"). Currently about 1% of the JVM runtime is implemented in C and this will be rep
by pulse7 4y ago
After this merge we will have JVM implemented mostly in Java (aka "self hosted"). Currently about 1% of the JVM runtime is implemented in C and this will be replaced with instrumented Java code (including garbage collectors). This means that only one runtime will be maintained in the future and Java developers will do it (and not C/C++ developers which are harder to get). It will be much easier to implement and test new memory management mechanisms than it is today.
If they also decide to merge support for other languages (including WASM and LLVM) we will be able to run everything that compiles to WASM and to LLVM on the same runtime - in the same JVM. So we will get another "Docker Without Containers"...
EDIT: It seems that I am wrong with the above 1% statement. I meant that about 1% of the Java standard library is written in C/C++. Regarding JVM: I guess that the whole HotSpot VM will be replaced with GraalVM in the future and when this happens, majority of the JVM code will be in Java.
- Alifatisk 4y agoIs C devs really hard to get?
- Alupis 4y agoC devs? No. Competent systems-level C devs - yes. The embedded and systems space are hard and require special talent and knowledge. You can't just take some front-end React developer and get them writing quality systems C code in a weekend... people spend entire careers in that space, and the number of people interested in that work shrinks by the year (look at all developer surveys).
- pyuser583 4y agoHow does embedded programming pay?
- delusional 4y agoBut can you take some JavaEE backend developer, shove them into the compiler, and expect them to do well? I think the language difference is a red herring.
- yakak 4y agoIt's certainly very interesting since Java was among the few high level languages that had unlimited access to C OS devs in theory, but it doesn't show this in practice. I always felt they were hostile to understanding OSes and problems/solutions they provide and thereby limiting themselves to mostly junior C devs who didn't rock the boat by making real OS features for the JVM.
- Yoric 4y agoIncidentally, that's one of the reasons for which Rust is so successful in this space. Rust won't magically make you productive in a week-end, but the Rust compiler (with its error messages) is pedagogic enough that it is going to help you learn from your mistakes. That's the extreme opposite of raw C (or raw JavaScript, etc.) in which it's very easy to believe that you have solved an issue, only to realize much later that you've been entirely misunderstanding some constructions of the language and (if your code somehow managed to land) you have made the entire product unstable or insecure without realizing it. Of course, there are tradeoffs to each approach. But I believe that investing in Rust was a great initiative from Mozilla.
- PartiallyTyped 4y agoI have said this multiple times, but I am grateful for learning Rust as it helped shape the way I view memory ownership, and in the process made me a better developer.
- Koshkin 4y ago> C devs? No. Competent systems-level C devs - yes. I don't think C is special in this regard.
- samus 4y agoIt actually is. Managed languages don't suffer from many kinds of bugs that C/C++ and other unsafe languages do. Memory corruption and concurrency bugs can be devilishly hard to find in the latter.
- danielscrubs 4y agoThe percentage of developers that do C might be shrinking but the number of C developers surely has to be increasing. You can barely throw a rock in a major city without it landing on a developer nowadays.
- Alupis 4y agoJust because someone took a class in school, or did some online tutorial doesn't make them a C developer. Most developers you see/hear/interact with are not C developers - rather they use higher level languages mostly to build web apps and mobile apps.
- jalcazar 4y agonot really hard just harder than Java
- mike_hearn 4y agoWhere did you get the 1% figure from? HotSpot has millions of lines of C++, that seems far too low. Graal doesn't affect memory management. It's a JIT compiler, not a GC. Although there's a relatively simple GC written in SystemJava for native images, G1, ZGC and Parallel will continue to be the standard GCs in the regular JVM for the foreseeable future and they are all written in C++.
- taeric 4y agoTo add to your question, assuming the tooling at github is ok, it has ~20% as c/c++ for https://github.com/openjdk/jdk https://github.com/openjdk/jdk. I would think most of that would be concentrated in the hotspot code, but I don't know. Would be delighted to know what the original post was referring to.
- fathyb 4y agoI think the entirety of Hotspot is written in C++ [0]? The standard library in the JDK is mostly written in Java, but the VM itself with the GC and JIT code is in C++, which makes sense. If you do not count the standard library as part of the JVM (but part of the JDK), then the JVM is written mostly in C++. [0]: https://github.com/openjdk/jdk/tree/master/src/hotspot https://github.com/openjdk/jdk/tree/master/src/hotspot
- taeric 4y agoThat definitely matches my read of the source. Would still be delighted to know there is something else going on, though. :D
- samus 4y agoBecause of its inherent memory safety, Java is attractive for anything in the JVM which is not strictly necessary to be coded in C/C++ for some reason (raw performance, low-level, or OS-specific). With Projects Valhalla ann Panama around the corner, there will be even less hard reasons going forward. Also, C/C++ compilers can be tricky dependencies at times.
- kasperni 4y ago> Currently about 1% of the JVM runtime is implemented in C The JIT is probably half of the VM and is written in C++. Github [1] says (for the whole JDK, not just the VM): Java 75.1% C++ 13.4% C 7.4% Assembly 2.3% Objective-C 0.4% [1] https://github.com/openjdk/jdk https://github.com/openjdk/jdk
- morelisp 4y agoIt's surprising to me that effective knowledge of C and/or C++ is the stumbling block for contributing to the core of the JVM. I work at a company with one large C++ codebase, and also many Go projects where C and C++ knowledge are helpful. We have trouble hiring good C++ developers, because our candidate pool starts as "people who want to write web applications". But if you're already restricted to people who want to work on an extremely mature compiler, VM, and JIT - is lack of C knowledge really what's making it hard to hire people? These are people who are likely to end up reading kernel code and C-defined ABI documentation and etc. etc. even if the codebase is 100% Java...
- lmm 4y agoThe people who believe in and care about Java tend to be Java people; C-oriented people tend to be rather anti-Java.
- kaba0 4y agoWriting state-of-the art runtimes is probably one of the hardest CS fields. They are way above this “your language sucks” category.
- lmm 4y agoPeople are human; we get petty and tribal at every level. And ever putting all that aside, if you genuinely believe that one kind of programming or another is the way forward then of course you're going to be more interested in working on technologies that support that.
- still_grokking 4y agoEven you're maybe right about "the C people" (most of I'm meet were indeed the kind of "there's nothing besides C") this doesn't seem to be relevant here. The JVM is written in C++, not C. Also there is a large chunk of people (like me) who don't care about Java (the language) but very much about the JVM (and to some degree also about the Java ecosystem). I'm a Scala developer. But I'm also interested lately in Rust (and to some degree C++, as both languages are related), 'cause, you know, max performance and full control, and such. So at least when it comes to interests there is some pool of people for sure who would like to look into the low-level JVM internals.
- vips7L 4y ago> Regarding JVM: I guess that the whole HotSpot VM will be replaced with GraalVM in the future and when this happens, majority of the JVM code will be in Java. I believe this is still incorrect. GraalVM is HotSpot with the Graal JIT compiler and the truffle languages.