Live data from Hacker News

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

dl.acm.org

71–80 of 93 posts

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

#71
post #48

Earlier quoted context omitted.

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.

Nice!

Is it still interpreter only, or will we have C1 and C2 JIT support as well?

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

#72
post #69
post #39

Earlier quoted context omitted.

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 in…

Forgetting about .NET?

No, but it's hard to define what .NET is, because while there has been something called .NET for 20 years, it hasn't quite been the same thing. Is .NET now (.NET Core) the same platform as .NET of 2005?

Also .NET is not as popular, and its adoption is also a little weird. It's quite popular overall, but doesn't dominate any domain. It's used on the server but not nearly as much as Java; it's used on the client, but not nearly as much as JavaScript. I think it's still largely confined to Microsoft shops.

So both in longevity and popularity it's not quite in the same class as those others.

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

#73
post #72
post #69

Earlier quoted context omitted.

Forgetting about .NET?

No, but it's hard to define what .NET is, because while there has been something called .NET for 20 years, it hasn't quite been the same thing. Is .NET now (.NET Core) the same platform as .NET of 2005? Also .NET is not as popular, and its adoption is also a little weird. It's quite popular overall, but doesn't dominate any domain. It's used on the server but not nearly as much as Java; it's used on the client, but n…

Java surely hasn't taken any bite out of .NET desktop development, or the game industry, with exception of Minecraft.

Regarding defining what Java is, what about Android Java, real time Java, Java on mainframes, forks like microEJ, Graal, OpenJ9, Azul....

Just as hard to define.

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

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

We are actively in the process of rewriting a legacy system using the Strangler pattern, 50 devs and 2 years later it's still less than 50% because business wants new features as well, they can't afford waiting 1-2 years with no business value added in the meantime.

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

#75
NestedVM was another early attempt (2004) to run C, C++, Fortran, etc. on the JVM, but at substantial performance degradation. This was a clever hack that ran a Java coded MIPS emulator and loaded a compiled binary into a large array. Performance was 20-40% of native speed, but still fast enough for some applications, such as SQLite as a JDBC driver.

Website, source repo, and paper seem to still be available, try archive.org for dead links:

http://nestedvm.ibex.org/

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

#76

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 think you're (perhaps intentionally) overestimating the hate the JVM gets to paint Java critics as unreasonable, but the fact of the matter is that the JVM and Java the language are light years apart in quality and (subsequently) the attitude they get from their users. One is a decent VM with man-centuries of work and inspiration from academia (Self, whose VM heavily influenced hotspot), the other is an ugly mess o…

I think having both int as a value type and Integer as an object, etc. is defensible given what the original Java had to run on. The thing I never understand, however, is why, at the same time, they went with a language that allows one to use synchronized on any object.

Because object allocation and the use of an allocated object in a synchronized part can be far away from each other both in time and in source code (quite possibly even in different jars), I would think that creates object overhead that’s hard to optimize away.

What would Java have lost if it required a synchronizable keyword on class definitions to allow callers to synchronize on instances of a class?

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

#77

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

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

Why is just running say your Ruby existing program on Truffle with a big performance gain stupid? A lot of the languages use C extensions and running them on the JVM is faster then using the FFI to call them from the JVM.

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

#78
post #19

Earlier quoted context omitted.

Ha! Your paper is a "highly influential citation" https://www.semanticscholar.org/paper/TruffleC%3A-dynamic-ex...

The side-bar says 'highly influential' but the badge lower down says 'highly influenced' which sounds like a bad thing doesn't it?

Probably meant as "[this paper has] highly influenced [citing paper]".

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

#79
post #56

Earlier quoted context omitted.

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.

native-image was created as part of the Graal project but I think it's a separate JVM implementation from GraalVM

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

#80
post #41

Earlier quoted context omitted.

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.

What I miss from Panama, is that it is still early steps, even with jextract it is a bit more involved than using P/Invoke.
Post reply on HN