Hacker News Reader

Comment by jonahbenton | Hacker News Reader

Because there is no sensible mapping from, like, C source to the JVM. C expresses semantics that are not available on the JVM, like most casts, and the JVM is built around concepts that don't exist in C or Fortran, like objects and method dispatch. They do exist to some extent in C++ but the semantics, memory model, etc, are completely different.

Someone could make up a mapping but it would be a numerological exercise, a flight of fancy forever lacking utility.

And anyway there is a practical integration between C and Fortran world and JVM world. The JVM can link to compiled C and Fortran object code, and for those who like suffering, JVM structures can be reached from C source.

View on HN

That’s absolutely not true. C only needs a huge array, and you can do anything you want with that in any language. That’s pretty much what WASM does as well.

I’m sure there are some other ways as well, but a supported one is through the Graal project, which can run LLVM bitcode (and thus any of C, C++, Rust, etc) natively. Hell, it can interop with regular Java code, or that of other Truffle languages, and even optimize across language barriers!

Yes, but at that point you've implemented abstractions on the JVM's abstractions, or used platform/implementation dependent code.

What's the point, just to say you did it?

It's not impossible, it's just not worth the ROI time wise for most people with the desire to make a C/C++ standard compliant compiler to do so-- and even if they do, the amount of traction it'll gain will be minimal because developers can make an educated choice not to use it when native C/C++ compilers are available, or alternative JVM languages like Kotlin.

Which is why you have a bunch of attempts at this that stopped development in 2009/2015.

while technically true in the sense that any turing machine can simulate another turing machine, it probably wouldn't be efficient enough to be worth it.

What would be the point of doing that?

>Because there is no sensible mapping from, like, C source to the JVM

Really?

C is available on so many hardware sets ... it's practically universal (Arduino, x86, MIPS, 68k, PowerPC, ARM, SPARC, RISCV...)

I find it incredibly hard to believe that you couldn't target the JVM (which also runs on SPARC, ARM, RISCV, x86, POWER...) with C as the source language!

There has been multiple C compilers targetting the JVM, however they've all also had bad performance penalties since the JVM has no notion of references and pointers so it becomes "emulated", best case you write one that works on ByteBuffer objects (Like early Asm.JS before WASM used a WebGL TypedArray objects before they became part of JavaScript proper) but once you go that route it becomes frustrating to interface with the rest of the Java ecosystem (and you kinda loose the entire point of a JVM targeting C compiler).

Even Sun/Oracle recognized the mismatch and that's why GraalVM is a thing (and why Graal isn't entirely meshable with classic Java runtimes even if I hope they have a merge-strategy for the long-term).

Java understands "references" and "pointers" (or, at least did in the 1.6 (and before) era...does it not any more?)

C++ and Java reference semantics are very different. Java, like Python, has a model of "references passed by value".

  void caller() {
    T a = new T(0);
    T b = new T(1);
    callee(a, b);
  }

  void callee(T a, T b) {
    a = b;
  }

In Java, a and b are references, but from caller's perspective, callee is a no-op. On the other hand, using C++'s reference semantics, (and replacing T with T&) callee would modify the a object, not just locally change the reference.

I don’t see its relevance, that’s up to the compiler to “solve”, adhering to reference’s semantics. It is just pointers/transformations either way in machine code, which can be trivially emulated in any language/platform that has an array of bytes available.

Yes, the language runtime version of the "Turing tarpit". Any Turing-complete system can emulate any other. However, in this case, you're bounds-checking absolutely every memory operation, whereas with native Java field access, the class verifier proves the field access is legal just once at class load time.

The JIT compiler can elide most of those just as well at runtime

The JVM can elide most of the Java bounds checks because it has much more static information from Java class files than is available from C code. Once you're emulating a memory-unsafe language, you lose most of those static semantic guarantees you get from valid Java code. In the general case, in a memory unsafe language, statically removing bounds checks is equivalent to solving the halting problem.

One could definitely add some extra load-time static analysis to the JVM, similar to what the NaCL / PNaCL did at binary load time to greatly increase the opportunities for JVM bounds check removal. However, this would need some extensions to the class file format and/or some new class file annotations to expose some more static information than the JVM has for vanilla Java class files.

In addition, there are also plenty of ways one could optimize away some bounds checks based on undefined behavior, which would result in a standards-conforming C implementation, yet break tons of C code in the wild. (There at least used to be a C to Go transpiler that implemented C unions this way.) For instance, it's UB to write to one field of a union and then read another field, so it'd be legal for a compiler to implement a union as a struct. However, there's plenty of code in the wild (such as many nanboxing/nunboxing implementations) that rely on union fields occupying the same physical addresses.

A JIT compiler doesn’t operate at that compile time, so it simply doesn’t have to solve it statically — it notices that this invocation at this place always uses 46 for n, so it can use it as a constant for its compilation, at which point it is more than possible to elide many checks.

Bounds checks are either runtime checks or removed by static analysis. JIT just pushes back the time at which that static analysis is done and increases the amount of context available (largely through inlining).

It's still fundamentally static analysis, just run at JIT time, not at class file generation time. My point is that the JIT-time static analysis in the JVM is heavily optimized for memory accesses typical of Java programs.

Typical C code is drastically different, especially since pointer arithmetic is common in C code. In order to properly statically check an access via pointer arithmetic from a pointer allocated via malloc(), the JIT would need to be operating over a code fragment that included both the malloc call (to know where the base address is relative to the bound) and the memory access site. Lots of C code has way too much code executing between malloc and your pointer arithmetic to reasonably expect that the JIT is going to have all of that code in the execution trace it's currently optimizing.

In the specific case suggested above, just using a giant byte array to represent all of memory, bounds-checking some memory access to an arithmetic-modified pointer gotten from malloc(), the bounds removal would be dependent on the exact address returned by malloc(). In some programs, maybe there's tons of access to a small number of buffers allocated at program start-up time. In that case, current JVMs might do a pretty good job at eliding bounds checks by noticing that the base address is usually one of a small number of values and having a dedicated code path for those common cases. However, if you're doing frequent malloc(), then you're getting tons of different base addresses. In other programs, the malloc() and the access will be close enough together that the JIT'd fragment will include both the malloc and the access, in which case the JVM will have enough context to elide the bounds access. However, it's way too hand-wavy to just say the JVM is good at eliding array bounds checks.

The JVM is very good at eliding array bounds checks typical of Java programs. This is very different from eliding array bounds checks typical in memory-unsafe languages.

I'm really interested in this space. I'm the original author of the Wikipedia page on SafeTSA. I really want compiling to native code to be as common as writing inline assembly currently is (and I see no fundamental reason why it won't eventually be). I used to be one of 5 developers for the most popular Java desktop program in the early 2000s. I have some ideas for hardware features to reduce the overhead of run-time code re-optimization based on real-time profiles. I guess when I eventually retire, I'll play around with an FPGA CPU implementation of my ideas.

I really believe JITs can do what you're describing, but I think it's important not to over-sell current JIT implementations. Over-selling the technology results in skepticism.

In my ideal world, we compile to either a high-level control-flow-graph/static-single-assignment representation (maybe similar to SafeTSA) as a distribution format. At installation time, we AoT-compile to native code (similar to the current Android runtime). At run-time, we take advantage of extremely low overhead hardware profiling/tracing features to re-optimize hot spots. Optimal ordering/inclusion of various optimizations is a bit of a black art, so I expect some degree of randomization here. In cases where profiling shows the re-optimized code out-performs the AoT version, we'd then cache the re-optimizations to disk. Optionally, a periodic process would periodically perform more expensive offline static-re-optimization of the AoT'd binary, similar to the current Android runtime.

Crucially, the garbage collector should be decoupled from the binary generation/re-optimization system. The CPU overhead of garbage collection can be brought pretty low, but there's a size/space trade off. Last I checked, the rule of thumb is that unless you're manually pooling objects, you can expect a GC'd program to use roughly twice as much memory as an equivalent C++ program. Now, the cognitive/development overhead of manual memory management usually isn't worth the memory savings. However, I've worked in several domains where the memory savings are worth the slower development time.

Not like C. They are not comparable. You get a reference to something you allocate on the heap, and you can have primitives on the stack. But you cannot take a reference to a primitive, or a reference to another reference, or a reference to the second element of an array. To run C on the JVM you are really swimming uphill.

You see &variable in a function body, you allocate a stackframe for that in the heap abstraction and return that’s address.

And now for a reference to a field in a struct living on the heap?

Of course you can get C to run on the JVM (any CPU emulator written in Java proves that) but due to JVM limitations you cannot do so efficiently. Which is why it the JVM is not an attractive target for the 'traditional' languages.

That struct on the heap is just consecutive bytes in an array, so you just return an integer.

warrenm was asking whether Java's (and implicitly: the JVMs) concept of references could be used. I'm glad that you agree with me that they cannot.

Representing the memory of a compiled C program with a giant byte array would of course work, but also defeat the purpose of running on the JVM in the first place. You lose all the advantages that running on the JVM might have given you, and are slower than a natively compiled program.

It has references, but from what I understand they don't entirely conceptually match in use, implementation, and semantics to C++ references.

It has pointers aliased as references. They are pointers for all practical purposes. NullPointerException is named as such for this very reason - pointers were considered scary back then, hence the marketing term.

Yes, implementation wise underneath in most cases they're likely some structs/pointers/whatever, but the point was that interaction with them from the perspective of an application running on the JVM is not the same as what the JVM sees itself, nor are the same exact operations available-- you'd have to create abstractions or use implementation specific jdk.internal.misc.* calls, and at that point why are you using the JVM.

Java doesn’t have pointers in the C sense. Code such as

   while(*dst++=*src++);

   char buf[100];
   char *p = buf+13;
   p[-3] = p[1];

doesn’t map well to the JVM. As others said, you’d have to (almost) emulate memory in a byte array or byte buffer to fully support C.

I think the point is that you are unable to address memory in the same way as C because the underlying technologies are different.

You're making the mistake of assuming transitivity in targets—because C targets all these architectures and the JVM runs on all these architectures, therefore C should target the JVM. The whole point of the JVM is to abstract away the underlying machine, so which architectures it runs on is irrelevant to whether its instruction set is a good semantic fit for C! I can write a Lisp to target any of those architectures as well, but I wouldn't suggest you should compile C to it.

The big problem is that C assumes a low-level target language, which all these architectures provide but the JVM does not. A C runtime on the JVM would have to re-implement things like direct memory access on top of JVM arrays, which, while possible, would introduce performance penalties that would completely negate the purpose of writing C.

The "mapping" is from concept to concept. For example if there is no concept of collective objects in a spoken language- no way to talk about books for example only a book. Then mapping "we (plural) like books on all subjects" gets to be very hard. The hardware (people) is the same but the conceptual frame works are just too different. Not sure if that was what you were talking about...

You could… but why would you want to? C can’t use any of the Java features so you’d just be adding pointless inefficiencies

The architectures that the code runs on has no bearing on whether it makes sense. What, for instance, do you turn a malloc() call for a number of bytes into? The JVM manages your memory for you and assumes you don't do it yourself. There are no instructions for telling the JVM how to manually fiddle with raw memory. And why would you want that? You already have code that expresses how to fiddle with the memory! The JVM provides functionality that C code already implements manually itself.

The JVM knows how to handle memory (to some greater or lesser degree ... hence Xmin/Xmax) - https://antipaucity.com/2011/08/08/why-technical-intricacies...

That's the point. The JVM deals with objects. Classes. It has a garage collector. You can't make that work (at least not without a huge amount of effort) with a language whose code doesn't have a concept of those things. The abstraction the JVM implements isn't useful to C code.

That’s nonsense. Ad absurdum every Turing-complete language can emulate every other. And in this particular case it is not even particularly complex.

The point is that emulating the JVM abstraction isn't useful to C programmers. Just because it can be done in theory doesn't mean it's practical.

I don't think they said otherwise. I believe the point was that JVM bytecode doesn't expose anything for manual memory deallocation at runtime.

would seem trivial to map free() to a garbage collector call ...

Or just make it a noop, and use a malloc implementation that returns ByteBuffers/arrays.

> There are no instructions for telling the JVM how to manually fiddle with raw memory.

Ahem, sun.misc.Unsafe.{get,put}{Byte,Short,Int,Long,Float,Double,Address}

> What, for instance, do you turn a malloc() call for a number of bytes into?

Perhaps sun.misc.Unsafe.allocateMemory?

From what I understand jdk.internal.misc.Unsafe.* methods do not contain direct JVM opcodes for memory management, but virtual methods with implementation defined behavior, that usually require reflection to access, and are not 100% portable behavior wise between JVM implementations-- am I wrong?

In order to execute C/C++ code in the JVM you would essentially have to write a whole emulator. Allocate a single huge byte array and treat that as the "memory" of the emulated computer. Then you can write malloc that operates on it.

In practice this is totally pointless.

Why would it be pointless? A region of the heap which malloc can return doesn’t sound too problematic at all, nor would it have significant performance penalty. Getting pointers to stack variables is a bit more cumbersome, but you can just escape analyze functions, and store in a heap-allocated ByteBuffer stack variables that might be dereferenced.

the JVM IS a "whole emulator" ... that's the whole point of the JVM :)

You make a ByteBuffer at program startup, indexes into it are your pointers. Malloc finds free space in it in exactly analogous mode to how it works in a C-implementation.

Arduino is not a chip. It's either AVR or ARM depending on which Arduino board you buy.

I don't know if it counts, but you could compile it down to llvm bitcode and run it on sulong as a part of graalvm. I imagine it comes with caveats but it's used for real stuff.

Reply on news.ycombinator.com