GitLab

Created by: wks

This is an outline of issues related to the native interface, that is, interacting with the native world. This topic includes but is not limited to object layout, pointer types, object pinning and foreign function calls. We should open other issues to discuss concrete problems.

• Make a platform-specific Mu specification
  • Address some of the following issues, including object layout, calling convention, ...
  • Draft for AMD64: https://github.com/microvm/microvm-spec/wiki/native-interface-x64-unix
• Type system: (https://github.com/microvm/microvm-meta/issues/34)
  • Raw pointer types
  • Structure types with native/explicit object layout
  • Union types (unlikely to have in Mu)
  • Mapping Mu types to C types and native object layout: (in the Native Interface chapter in the spec)
• Memory space beyond heap/stack/global
  • Memory spaces with various constraints
    • Is it movable, pinnable, has reference, can be referenced to, GC-traced, GC-collected, ...?
  • Object pinning: https://github.com/microvm/microvm-meta/issues/28
    • If object pinning is allowed, what does "pin" mean?
• Foreign function interfaces
  • Calling foreign functions from Mu: (The CCALL instruction. See the spec)
    • Calling C functions
    • System calls
  • Calling back to Mu from foreign functions: https://github.com/microvm/microvm-meta/issues/39
    • From C functions
    • Signal handling

The following should be addressed by a higher-level abstraction:

• Loading native libraries
  • The client loads libc and finds the address of dlopen, dlsym, dlclose and dlerror. Then the CCALL instruction takes care of the rest by calling them.
• Loading "heavier-weight" Mu bundles (currently called MuLF): https://github.com/microvm/microvm-meta/issues/30

The following are not related to the native interface, but are related to raw memory:

• How to expose the address of objects so that the user can analyse the memory behaviour? (This involves profiling, too. We may open a dedicated issue for profiling.)