3 ms·
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? Th
by 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 agoThe 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 agoThat'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 agoThat’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 agoThe 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 agoI don't think they said otherwise. I believe the point was that JVM bytecode doesn't expose anything for manual memory deallocation at runtime.
- 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 agoFrom 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 agoIn 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 agothe JVM IS a "whole emulator" ... that's the whole point of the JVM :)
- kaba0 4y agoWhy 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 agoYou 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.