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

51–60 of 93 posts

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

#51

Post by chrisseaton »

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…

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

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

#52

Post by samus »

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…

TCP and file system access use JNI under the hood as well. For most other use cases there are already libraries that provide wrappers. And after Panama is shipped, they will eventually be upgraded to use that faster FFI. Btw, aren't serial devices treated as files under Unix?

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

#53

Post by chaosite »

origin_path wrote: post #47
chaosite wrote: post #43

Earlier quoted context omitted.

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.

Well, OK, sure, but Truffle without partial evaluation is just an interpreter written in a very particular way...

I see what you mean though, thanks!

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

#54

Post by chrisseaton »

chaosite wrote: post #53
origin_path wrote: post #47

Earlier quoted context omitted.

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.

Well, OK, sure, but Truffle without partial evaluation is just an interpreter written in a very particular way... I see what you mean though, thanks!

> Well, OK, sure, but Truffle without partial evaluation is just an interpreter written in a very particular way..

That's what it was to start with. Partial evaluation came later.

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

#55

Post by samus »

JavaOnlyGuy wrote: post #12

How are pointers implemented in a language that doesn't support them?

Well-behaved usages of pointers according to the C standard can be implemented by whatever means fit best. Fat pointers with metadata about the destination and a huge block of memory for generic cases come to mind. The rest is undefined behavior where the runtime can just nuke the program, aka segfaulting.

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

#56

Post by rschatz »

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?

Truffle and partial evaluation also works on native-image. You could say this is a VM where there are no bytecodes anymore.

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

#57

Post by chaosite »

rschatz wrote: post #56
chaosite wrote: post #43

Earlier quoted context omitted.

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?

Truffle and partial evaluation also works on native-image. You could say this is a VM where there are no bytecodes anymore.

Oh, of course, but native-image is still a Graal feature, and I was asking about Truffle without Graal.

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

#59

Post by hawk_ »

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…

> And frankly I don't understand the hate people have against Java.

There are two kinds of programming languages : ones that people complain about and ones that no one uses.

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

#60

Post by kaba0 »

chrisseaton wrote: post #51
batmanturkey wrote: post #42

Earlier quoted context omitted.

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…

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

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.
Post reply on HN