4 ms·

I dislike everything the JVM stands for and is. There’s no real gentle way to put that. I don’t support the notion of a fat runtime platform. The LLVM IR code i

I dislike everything the JVM stands for and is. There’s no real gentle way to put that. I don’t support the notion of a fat runtime platform. The LLVM IR code is a much better conceptualization of where and WHEN code executes. My feelings about Oracle and the entities around Java are also less than optimal. I only feel free to be so blunt as you asked for opinions. I gather that you disagree. Rust is rather unrelated. It’s a compiled static language with no runtime, in which you manage memory. The JVM is a thick VM and you basically only get to script it, which is fine and all considering it’s Turing complete, etc, but you really aren’t anywhere near the metal where rust can go bare metal with no OS or stdlib

origin_path 4y ago
It's highly ineffective to be close to the metal for most software. Progress comes through abstraction. Even video games is like that these days. Not many companies writing their own game engines anymore: they all ship with giant "runtimes" like Unreal.
chrisseaton 4y ago
> The LLVM IR code is a much better conceptualization of where and WHEN code executes. Funny - because LLVM IR makes the 'when' (the required partial ordering of instructions) implicit and so both too loose and too constrained at the same time, because it's a linear IR, while the JVM's Graal and C2 IRs makes the 'when' completely explicit and a first-class part of the representation, because they're graphical IRs.
- kaba0 4y ago
  Could you please expand on this/link me somewhere? I am not familiar with LLVM, and I am only familiar with the JVM spec (currently in the process of writing a templated interpreter), but not yet familiar with OpenJDK’s existing code base, nor a complete JIT compiler.
  - chrisseaton 4y ago
    Given this C code: int foo(int a, int b, int c, int d) { return a * b + c * d; } LLVM gives you a single total-ordering of all operations in this code, which makes it appear like computing %5 has to happen before %6, but in reality it doesn't - they could be swapped. define dso_local i32 @foo(i32 noundef %0, i32 noundef %1, i32 noundef %2, i32 noundef %3) local_unnamed_addr #0 !dbg !7 { %5 = mul nsw i32 %1, %0, !dbg !18 %6 = mul nsw i32 %3, %2, !dbg !19 %7 = add nsw i32 %6, %5, !dbg !20 ret i32 %7, !dbg !21 } Java's IRs instead tell you that %5 and %6 need to be computed before %7, but don't apply an ordering between them otherwise. They can do this because they use a graph of instructions, not a linear list of instructions. https://chrisseaton.com/truffleruby/basic-graal-graphs/ https://chrisseaton.com/truffleruby/basic-graal-graphs/
    - kaba0 4y ago
      Thank you very much!

origin_path 4y ago

It's highly ineffective to be close to the metal for most software. Progress comes through abstraction. Even video games is like that these days. Not many companies writing their own game engines anymore: they all ship with giant "runtimes" like Unreal.

chrisseaton 4y ago

> The LLVM IR code is a much better conceptualization of where and WHEN code executes. Funny - because LLVM IR makes the 'when' (the required partial ordering of instructions) implicit and so both too loose and too constrained at the same time, because it's a linear IR, while the JVM's Graal and C2 IRs makes the 'when' completely explicit and a first-class part of the representation, because they're graphical IRs.

kaba0 4y ago
Could you please expand on this/link me somewhere? I am not familiar with LLVM, and I am only familiar with the JVM spec (currently in the process of writing a templated interpreter), but not yet familiar with OpenJDK’s existing code base, nor a complete JIT compiler.
- chrisseaton 4y ago
  Given this C code: int foo(int a, int b, int c, int d) { return a * b + c * d; } LLVM gives you a single total-ordering of all operations in this code, which makes it appear like computing %5 has to happen before %6, but in reality it doesn't - they could be swapped. define dso_local i32 @foo(i32 noundef %0, i32 noundef %1, i32 noundef %2, i32 noundef %3) local_unnamed_addr #0 !dbg !7 { %5 = mul nsw i32 %1, %0, !dbg !18 %6 = mul nsw i32 %3, %2, !dbg !19 %7 = add nsw i32 %6, %5, !dbg !20 ret i32 %7, !dbg !21 } Java's IRs instead tell you that %5 and %6 need to be computed before %7, but don't apply an ordering between them otherwise. They can do this because they use a graph of instructions, not a linear list of instructions. https://chrisseaton.com/truffleruby/basic-graal-graphs/ https://chrisseaton.com/truffleruby/basic-graal-graphs/
  - kaba0 4y ago
    Thank you very much!