4 ms·
That's exactly how Truffle's cross-language-interface works though. Instead of paying the high cost of conversion, data stays in its existing representation and
by trishume 10y ago
That's exactly how Truffle's cross-language-interface works though. Instead of paying the high cost of conversion, data stays in its existing representation and it is the interface code that is recompiled to fit.
An example is JRuby+Truffle where in its C extensions, pointers to Ruby objects act to the C code as if they are pointers to MRI data structures, but behind the scenes Graal compiles code that accesses them like the JRuby objects that they are.
The C-memory to Java GC transition doesn't work as well, but you can get around that by implementing C-memory using the Java GC like the Managed-C paper does, alternative implementations only have to keep the same behaviour, not the same underlying data representation.
- nostrademons 10y agoInteresting. What happens if the native memory layout doesn't support a feature that the extension code requires? For example, what if a JRuby+Truffle script calls into a C library, which allocates a struct and invokes a Ruby callback with it, which then wants to access the fields via reflection? C doesn't normally include type information with its structs, so how would the Ruby code know the memory layout of the object? What if it's not the C extension in your project that does the allocation, but a closed-source third-party library that your C code calls into? Do you need to recompile all source code to generate the appropriate typemaps?
- thomaswue 10y agoYes. Sulong assumes that at least the LLVM bitcode including debug information is available. It does not work with third party machine code binaries where no source information is available.