6 ms·

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

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

MagicMoonlight 3y ago
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
bastawhiz 4y ago
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.
- warrenm 4y ago
  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-matter https://antipaucity.com/2011/08/08/why-technical-intricacies...
  - bastawhiz 4y ago
    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.
    - kaba0 4y ago
      That’s nonsense. Ad absurdum every Turing-complete language can emulate every other. And in this particular case it is not even particularly complex.
      - deleted 4y ago
        [deleted]
      - goatlover 4y ago
        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.
  - w7 4y ago
    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.
    - warrenm 4y ago
      would seem trivial to map free() to a garbage collector call ...
      - kaba0 4y ago
        Or just make it a noop, and use a malloc implementation that returns ByteBuffers/arrays.
- cesarb 4y ago
  > 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?
  - w7 4y ago
    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?
- nradov 4y ago
  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.
  - warrenm 4y ago
    the JVM IS a "whole emulator" ... that's the whole point of the JVM :)
  - kaba0 4y ago
    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.
- kaba0 4y ago
  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.
whizzter 4y ago
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).
- warrenm 4y ago
  Java understands "references" and "pointers" (or, at least did in the 1.6 (and before) era...does it not any more?)
  - Someone 3y ago
    Java doesn’t have pointers in the C sense. Code such as while(*dst++=*src++); or 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.
  - Thiez 4y ago
    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.
    - kaba0 4y ago
      You see &variable in a function body, you allocate a stackframe for that in the heap abstraction and return that’s address.
talkingtab 4y ago
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...
lloydatkinson 4y ago
Arduino is not a chip. It's either AVR or ARM depending on which Arduino board you buy.
lolinder 4y ago
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.

MagicMoonlight 3y ago

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

bastawhiz 4y ago

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.

warrenm 4y ago
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-matter https://antipaucity.com/2011/08/08/why-technical-intricacies...
- bastawhiz 4y ago
  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.
  - kaba0 4y ago
    That’s nonsense. Ad absurdum every Turing-complete language can emulate every other. And in this particular case it is not even particularly complex.
    - deleted 4y ago
      [deleted]
    - goatlover 4y ago
      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.
- w7 4y ago
  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.
  - warrenm 4y ago
    would seem trivial to map free() to a garbage collector call ...
    - kaba0 4y ago
      Or just make it a noop, and use a malloc implementation that returns ByteBuffers/arrays.
cesarb 4y ago
> 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?
- w7 4y ago
  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?
nradov 4y ago
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.
- warrenm 4y ago
  the JVM IS a "whole emulator" ... that's the whole point of the JVM :)
- kaba0 4y ago
  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.
kaba0 4y ago
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.

whizzter 4y ago

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

warrenm 4y ago
Java understands "references" and "pointers" (or, at least did in the 1.6 (and before) era...does it not any more?)
- Someone 3y ago
  Java doesn’t have pointers in the C sense. Code such as while(*dst++=*src++); or 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.
- Thiez 4y ago
  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.
  - kaba0 4y ago
    You see &variable in a function body, you allocate a stackframe for that in the heap abstraction and return that’s address.

talkingtab 4y ago

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

lloydatkinson 4y ago

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

lolinder 4y ago

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.