Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TruffleC: A C implementation on top of JVM (2014)

dl.acm.org

Post reply on HN
Print view View original

41–50 of 93 posts

Re: TruffleC: A C implementation on top of JVM (2014)

#41

Post by edg5000 »

yakorevivan wrote: post #15
languageserver wrote: post #11

Earlier quoted context omitted.

The JVM is an absolutely beautiful constructed software and protocol. I hope it stands for millennia, just like the colosseum, even if not in active use.

Absolutely correct. And frankly I don't understand the hate people have against Java. Especially the new generation developers. Maybe the language part only. But have seen much hate towards JVM too. With projects like loom, valhalla, graalVM, JVM/Java is everything a modern language/runtime needs, plus a lot lot more. I frankly believe the only other commercially viable language that has similar philosophy to JVM dev…

The JVM is a beautiful place for code to run, and the language is great as well. The only and main weakness is interfacing with the OS and libraries. TCP and file access is builtin and is no problem, but to access a serial device you'd need JNI. To interact with OpenGL, you need JNI. To interact with the Linux kernel, JNI. C/C++ library: JNI. JNI is fine if you have no other choice (e.g. to invoke Android's Java-only SDK's, e.g. for Bluetooth), but voluntarily, much less so. It is much less of a pain to invoke Linux or Windows C libraries (or Apple's Obj-C APIs) from, say, C++ than it is from Java.

Re: TruffleC: A C implementation on top of JVM (2014)

#42

Post by batmanturkey »

yakorevivan wrote: post #15
languageserver wrote: post #11

Earlier quoted context omitted.

The JVM is an absolutely beautiful constructed software and protocol. I hope it stands for millennia, just like the colosseum, even if not in active use.

Absolutely correct. And frankly I don't understand the hate people have against Java. Especially the new generation developers. Maybe the language part only. But have seen much hate towards JVM too. With projects like loom, valhalla, graalVM, JVM/Java is everything a modern language/runtime needs, plus a lot lot more. I frankly believe the only other commercially viable language that has similar philosophy to JVM dev…

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

Re: TruffleC: A C implementation on top of JVM (2014)

#43

Post by chaosite »

chrisseaton wrote: post #33
suprjami wrote: post #25

Earlier quoted context omitted.

I don't think this is how it works. The JVM is a specification which describes a pretend computer and its instruction set. This TruffleC doesn't translate C to Java and run a Java program. This compiles C to bytecode which operates on the JVM. Whatever Java does or doesn't support is irrelevant to this compiler. TruffleC has nothing to do with the Java programming language at all. Just like you can compile C and get…

> This compiles C to bytecode which operates on the JVM. No, it compiles C to an AST, which it then interprets. The AST, which is also the interpreter in the Truffle design, are then partially evaluated to produce machine code. No bytecode is generated at any point, and in fact you can run it on a JVM that doesn't use byteocde, and then there is no bytecode anywhere.

I learned most of what I know about Truffle and Graal from your blog posts, so you obviously know more about this than me. However, I was under the impression that Truffle is quite closely integrated into GraalVM, that is, you can't use Truffle on a different JVM. Is that not true?

Re: TruffleC: A C implementation on top of JVM (2014)

#44

Post by chaosite »

dzaima wrote: post #34
rschatz wrote: post #30

Earlier quoted context omitted.

You can still use pointers. It's a bit hidden, but there are things like `Unsafe.allocateMemory`, `Unsafe.getByte` and so on ;)

right; at which point the subset of jvm you're using is a subset of any other IR/VM, the 'j' in 'jvm' being only useful as an implementation/runtime.

Sure, but don't discount all of the JIT optimizations that were implemented in the JVM and the huge number of engineer years invested in that particular implementation/runtime...

Re: TruffleC: A C implementation on top of JVM (2014)

#45

Post by origin_path »

batmanturkey wrote: post #42
yakorevivan wrote: post #15

Earlier quoted context omitted.

Absolutely correct. And frankly I don't understand the hate people have against Java. Especially the new generation developers. Maybe the language part only. But have seen much hate towards JVM too. With projects like loom, valhalla, graalVM, JVM/Java is everything a modern language/runtime needs, plus a lot lot more. I frankly believe the only other commercially viable language that has similar philosophy to JVM dev…

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

Re: TruffleC: A C implementation on top of JVM (2014)

#46

Post by origin_path »

edg5000 wrote: post #41
yakorevivan wrote: post #15

Earlier quoted context omitted.

Absolutely correct. And frankly I don't understand the hate people have against Java. Especially the new generation developers. Maybe the language part only. But have seen much hate towards JVM too. With projects like loom, valhalla, graalVM, JVM/Java is everything a modern language/runtime needs, plus a lot lot more. I frankly believe the only other commercially viable language that has similar philosophy to JVM dev…

The JVM is a beautiful place for code to run, and the language is great as well. The only and main weakness is interfacing with the OS and libraries. TCP and file access is builtin and is no problem, but to access a serial device you'd need JNI. To interact with OpenGL, you need JNI. To interact with the Linux kernel, JNI. C/C++ library: JNI. JNI is fine if you have no other choice (e.g. to invoke Android's Java-only…

Panama is giving Java/JVM a much better FFI. You won't need JNI anymore after that. That said, it won't let you call C++ classes. But that's of course normal.

Re: TruffleC: A C implementation on top of JVM (2014)

#47

Post by origin_path »

chaosite wrote: post #43
chrisseaton wrote: post #33

Earlier quoted context omitted.

> This compiles C to bytecode which operates on the JVM. No, it compiles C to an AST, which it then interprets. The AST, which is also the interpreter in the Truffle design, are then partially evaluated to produce machine code. No bytecode is generated at any point, and in fact you can run it on a JVM that doesn't use byteocde, and then there is no bytecode anywhere.

I learned most of what I know about Truffle and Graal from your blog posts, so you obviously know more about this than me. However, I was under the impression that Truffle is quite closely integrated into GraalVM, that is, you can't use Truffle on a different JVM. Is that not true?

Not so. Truffle is just a Java library like any other. You can therefore run Truffle languages on any JVM. However, they will run slow as they are just interpreters, then. To get the speedups you need to use Graal, which recognizes Truffle as a library and treats it specially.

Re: TruffleC: A C implementation on top of JVM (2014)

#48

Post by samus »

MaxBarraclough wrote: post #14
languageserver wrote: post #11

Earlier quoted context omitted.

The JVM is an absolutely beautiful constructed software and protocol. I hope it stands for millennia, just like the colosseum, even if not in active use.

I think it will do better than just stand. In recent years there's been remarkable progress in low-pause garbage collectors, and ahead-of-time compilation. I'm not sure about the status of the RISC-V port, but that is (or will be) another nice addition.

The RISC-V post is gonna be shipped in Java 19.

Re: TruffleC: A C implementation on top of JVM (2014)

#49

Post by [deleted] »

captaincaveman wrote: post #31
captaincaveman wrote: post #24

JVM was originally designed for set top boxes (STB) I believe, the problem there being a variety of architectures, thus a Virtual Machine solved the problem of write code to the virtual machine and not the physical machine and applications could run on various STB's. OpenTV provided such a 'middleware' where the main language was C on such a VM, and was (possibly still is) widely used.

Downvoted, I suspect because people don't believe Java was originally invented for STB aka Interactive TV https://www.javatpoint.com/history-of-java there are other references to this on the web too. I am possibly conflating JVM with Java, however I was under the impression they was designed as one to begin with.

[deleted]

Re: TruffleC: A C implementation on top of JVM (2014)

#50

Post by TimTheTinker »

captaincaveman wrote: post #31
captaincaveman wrote: post #24

JVM was originally designed for set top boxes (STB) I believe, the problem there being a variety of architectures, thus a Virtual Machine solved the problem of write code to the virtual machine and not the physical machine and applications could run on various STB's. OpenTV provided such a 'middleware' where the main language was C on such a VM, and was (possibly still is) widely used.

Downvoted, I suspect because people don't believe Java was originally invented for STB aka Interactive TV https://www.javatpoint.com/history-of-java there are other references to this on the web too. I am possibly conflating JVM with Java, however I was under the impression they was designed as one to begin with.

The language, the compiler, and the JVM were developed at Sun starting in the early 90s at Sun under the leadership of James Gosling.
Post reply on HN