|
|
|
|
|
|
by brabel
1116 days ago
|
|
|
JVM bytecode assumes the GC allocates and frees memory, so no, you don't have direct access to memory... though the Java standard library does let you allocate bytes and manage those yourself[1], not sure if you would consider that "more control over memory allocations". JVM bytecode is quite approachable: https://en.wikipedia.org/wiki/List_of_Java_bytecode_instruct... And does look superficially similar to WASM instructions. When WASM gets GC, I have trouble seeing what's fundamentally different between the two, to be honest... even something like (parts of) the Java stdlib will be available to WASM with the WASI API, making the difference too small to distinguish them into different categories IMO. [1] https://blogs.oracle.com/javamagazine/post/creating-a-java-o... |
|
|
That's interesting. So if you wanted to build a C compiler targeting the JVM, you would just request a big byteslice from the API and implement your own stack + heap on top of it (such that you never actually use the JVM GC)?
> And does look superficially similar to WASM instructions. When WASM gets GC, I have trouble seeing what's fundamentally different between the two, to be honest... even something like (parts of) the Java stdlib will be available to WASM with the WASI API, making the difference too small to distinguish them into different categories IMO.
It sounds like the fundamental distinction is that WASM will have both manual memory management APIs as well as GC APIs while Java will only have GC APIs.