Live data from Hacker News

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

dl.acm.org

21–30 of 93 posts

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

#21

Earlier quoted context omitted.

A class wrapping a long value with the pointer address in it.

How is the C memory modelled? One big Java array, or are there multiple data-structures? For instance, what happens when you call a function-pointer?

It can be done in a few different ways. Native memory can be managed as plain native memory (under the hood you can use Unsafe to access that memory) but the real advantage is that pointers to many objects can be kept as managed pointers and not converted to a native value most of the time. For example Ruby C extensions often use VALUEs to refer to Ruby objects which are normally tagged pointers. In TruffleRuby we use ValueWrapper objects to represent these, and maintain a fast map between native values and these objects when necessary.

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

#22

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.

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.

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

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

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

#25

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 a memory address of a stack or heap location on any physical computer supported by a C compiler, likewise you can compile C with TruffleC and get a memory address within the stack or heap of the pretend computer called the JVM.

This must be how it works, unless the JVM itself has no concept of memory addresses, which seems very unlikely to me. Let me know if I am wrong?

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

#26

Earlier quoted context omitted.

A class wrapping a long value with the pointer address in it.

How is the C memory modelled? One big Java array, or are there multiple data-structures? For instance, what happens when you call a function-pointer?

> How is the C memory modelled?

Using a combination of native memory and JVM managed memory, depending on what the memory is needed for.

> For instance, what happens when you call a function-pointer?

This is a good example - because TruffleC can inline-cache a function-pointer, inlining the called function!

All this is in the linked paper, of course.

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

#27
post #19

Earlier quoted context omitted.

A class wrapping a long value with the pointer address in it.

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?

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

#28

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…

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.

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

#29
post #2

Only 7% slower seems amazing. To me at least.

If the JVM is AOT compiling the bytecode back to native code there is a good chance that it ends up executing as object code that is more or less what a C compiler would have generated in the first place.

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

#30
post #28

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…

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