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

31–40 of 93 posts

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

#31

Post by captaincaveman »

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.

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

#32

Post by rschatz »

drdebug wrote: post #20

Is there an implementation that can be used for experimenting or verifying performance claims? I could not find anything. edit: Found a reference there in case it helps others https://www.graalvm.org/22.0/community/publications/

I don't think the original TruffleC is available anymore. But TruffleC evolved into the GraalVM LLVM runtime. We're now running the C programming language on GraalVM indirectly, by compiling it to LLVM bitcode first. The core idea is still the same from back then, but it's a lot less work to implement.

The code is available at https://github.com/oracle/graal/tree/master/sulong

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

#33

Post by chrisseaton »

suprjami wrote: post #25
JavaOnlyGuy wrote: post #12

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

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.

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

#34

Post by dzaima »

rschatz wrote: post #30
dzaima wrote: post #28

Earlier quoted context omitted.

the JVM bytecode does not have any memory address type. Just various width integers & floats, and references to managed heap objects. Arbitrary pointers would have to be done with 'long's one way or another.

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.

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

#35

Post by EmilyHughes »

kgeist wrote: post #22
EmilyHughes wrote: post #8

Earlier quoted context omitted.

Mostly migration of legacy programs probably, so companies can say they ported their stuff to java. It's stupid but companies do it.

It's easier to gradually refactor a legacy program to a different language using the Strangler pattern when they run on the same runtime and there's easy and performant interoperation between old and new code. I wouldn't call it stupid.

yeah but in most cases it's better to just rewrite everything fresh. it's more of quick fix to me.

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

#36

Post by kaba0 »

realitysballs wrote: post #3

Way over my head here , but can someone perhaps explain the value and/or use-case of running c within a jvm?

I believe it’s more about truffle’s llvm interpreter (which is perhaps the successor of this project), but one motivation is that many scripting languages (python, ruby) use C (and fortran) libraries extensively through FFI.

Truffle can give these scripting languages a huge boost in performance (TrufflyRuby is 3x faster than the second fastest implementation), but the JVM “doesn’t like to” rely on FFI all that much - and also, truffle is polyglot with the ability to optimize between different languages. So by creating an LLVM interpreter, ruby or python calling into that can be also optimized by e.g. inlining, in certain cases bettering the performance compared to native FFI.

Other than becoming truly cross-platform, running on top of a singular runtime gives it the ability to observe these parts as well (which in itself a huge advantage because the JVM has some killer observability tools), so for example project loom might be applicable to a python script using C libs for IO, putting the whole on a virtual thread and making its blocking calls unblocking magically.

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

#37

Post by brabel »

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…

What do you mean by similar philosophy? The JVM and Rust are quite different in every aspect, practical and philosophically speaking... except for both having lots of corporate backing perhaps?

Perhaps you meant to say WASM, which is indeed very similar to the JVM in goals and philosophy.

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

#38

Post by pantulis »

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…

My opinion: people dislike the Java platform mainly for the language, perhaps too ceremonial and verbose for today's trends. Also older developers remember Java from the J2EE/Struts/applets days as something overarchitected, slow and with cumbersome tooling, but that would not apply to the younger cohorts. Maybe a new programmer just sees Java and thinks "legacy", and we love to feel we are on the edge of technology.

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

#39

Post by pron »

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'm not sure I understand the comparison to Rust. The JVM is a virtual machine, analogous to the LLVM virtual machine that Rust targets. But that aside, I don't agree with the sentiment. Rust and C++ are languages that emphasise full low-level control. As such they offer different constructs the programmer chooses from for different characteristics -- e.g. virtual vs static dispatch -- in cases that are abstracted into a single abstraction in the JVM which then relies on the JIT compiler to profile the execution and pick the best implementation (virtual or static dispatch). Java, therefore, aims for a balance between ease of use and performance -- with an emphasis on _amortised_ performance -- whereas C++/Rust aim for maximum control with an emphasis on the worst case.

As for the hatred to Java, some of it is due to experience with "old Java" which is then negatively compared to some "new X" (rather than comparing "new X" to "new Java"). Some just comes from popularity. In 20222 Java is the dominant server-side language, with no other language coming remotely close in that domain. In 2002 Java was also the most popular server-side language. Very few languages have ever achieved such success for such a long time (e.g. COBOL and PHP never did), and I believe the list includes just C, Java, JavaScript, and, to a lesser extent, Python. Of those four, only C, Java, and JavaScript are commonly/mostly used in large projects, and people often hate large codebases. Those three languages receive roughly equal amounts of hate. C++, which isn't as popular but is also mostly used in large projects, also receives a lot of hate.

I think people believe that some language X easily fixes some flaw they see in Java, but so far it's come at the cost of other shortcomings they don't see, which explains why X never becomes as popular -- which makes those people disappointed -- which, in turn, means that it rarely has big, old codebases, and so is never hated but just fades to remain fondly-remembered, or lingers as a niche language (although sometimes a not very small niche). This is somewhat like the Betamax vs. VHS debate. A relatively small group of ardent fans liked Betamax because it was superior in a metric they cared about, but was inferior in metrics other people -- a larger group than the first -- cared about.

In short, I think it's a combination of unfamiliarity with "new Java", the language's extended popularity, and its use in large codebases.

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

#40

Post by pantulis »

EmilyHughes wrote: post #35
kgeist wrote: post #22

Earlier quoted context omitted.

It's easier to gradually refactor a legacy program to a different language using the Strangler pattern when they run on the same runtime and there's easy and performant interoperation between old and new code. I wouldn't call it stupid.

yeah but in most cases it's better to just rewrite everything fresh. it's more of quick fix to me.

Rewriting everything fresh is not always an option in terms of cost and opportunity.
Post reply on HN