Closed ylluminate closed 6 years ago
Our webassembly runtime uses the same memory management code as all other native targets. It is written in C/C++ and is compiled to wasm together with the Kotlin code. So until you are all inside wasm32 you should notice no difference.
We are working on providing a richer Kotlin/WASM32 to JavaScript interoperability. That will bring some complications on the boundary between the languages.
Hmm, perhaps I'm missing something here in your explanation. As per a discussion I had here, gc still needs to be considered and implemented on a per language need / basis where gc is required by that language. In the case noted there, you'll see that they are saying that we have to get bdwgc running prior to Crystal working. Do you not do something similar? Or is there a way "around" this garbage collection issue that we're missing in that discussion?
FYI, it might be easier for you to look into using Emscripten to get the JS interop.
Yes, we have our garbage collection code (which is a reference counter with a cycle collector) ready and running on wasm32.
Interesting, I see you've got a binaryen.diff, is this where you implement the gc? I would be interested in exploring how you implemented your gc functionality.
@Alefas so if you could explain a little more... Your compiler and WASM is treating memory as linear array of bytes? And then you build your structures on top of that just as if you were dealing in assembly? How do you search the stack frame and global variable space for pointers?
@ylluminate Hopefully this might help - https://github.com/JetBrains/kotlin-native/blob/master/runtime/src/main/cpp/Memory.cpp#L34-L35
Not sure what is the issue here. Closing for now.
@olonho I think @catmando was hoping for some more verbose English based explanation of what is going with regards to memory management / gc from @alexander-gorshenev.
The question is an implementation question: how do you implement GC roots on the stack for the wasm target, which is a stack machine not a register machine.
Go's very WIP port recreates the stack in linear memory, at a speed cost, and the suggested solution from the emscripten guys was to write all pointers to the C stack. We were wondering about your approach to supporting gc on this platform.
@alexander-gorshenev how does the "automatic reference counting with a cycle collector on top" work in wasm without being able to walk the stack to look for roots? or does it not need to? (ref: https://blog.jetbrains.com/kotlin/2017/04/kotlinnative-tech-preview-kotlin-without-a-vm/ )
Could you provide an overview of how Kotlin generates WASM output given that garbage collection is a requirement for Kotlin and the garbage collection specification has not even been implemented yet for WebAssembly?
I'm curious to get a "10 mile view" of what you're doing that has overcome this deficiency for the time being and also working with providing standard libraries for the language.