6 ms·

Nice read! I am not very familiar with this field of research but, could runtimes of other languages (say, Node.js or Python) benefit from such optimizations? W

by pythux 7y ago

Nice read! I am not very familiar with this field of research but, could runtimes of other languages (say, Node.js or Python) benefit from such optimizations? What about libraries like libuv, I guess they must be fairly fine-tuned already? Or is this something that is specific to Go and would be hard in other contexts?

kevingadd 7y ago
Go is one of the only languages that does syscalls itself (mostly because it's extremely high-risk and low-payoff), so some of its syscall-related techniques are not easily adapted to other runtimes.
- derefr 7y ago
  Do JITing runtimes like the JVM or LuaJIT, just generate libc-syscall-wrapper calls in the emitted object code, then?
  - blattimwind 7y ago
    Something like LuaJIT doesn't have the concept of a syscall, only calling into external C code. The same is probably(?¹) true for the JVM, since Java uses native methods to talk to the OS as well. So the JIT'ed code would call into the language runtime library, which in turn would call a syscall wrapper provided by the libc. ¹ It's possible the JVM, being the highly optimized workhorse VM it is, has specialized optimizations for I/O and does indeed skip over JNI and libc in these cases.
    - justincormack 7y ago
      ljsyscall for example calls into the libc syscall() wrapper. Most ffi type APIs can’t generate assembly for calling directly.
      - fsfod 7y ago
        In theory you could do it directly with the intrinsic system I built for LuaJIT[1]. It would dynamically generated the assembly for a user declared intrinsic\arbitrary machine opcode when there first called in the interpreter and the opcode is directly emitted when the code is JIT'ed. I think defining an intrinsic for a system call would just be a matter of setting the correct input and output registers. [1] https://github.com/LuaJIT/LuaJIT/pull/116 https://github.com/LuaJIT/LuaJIT/pull/116
  - cesarb 7y ago
    For the JVM: AFAIK, the JIT-generated code (and the interpreter) never does system calls, either directly or indirectly through the C library. Instead, they call "native" code written in C or C++, and it's that native code which does all the system calls or equivalent.
  - deleted 7y ago
    [deleted]
- lonelappde 7y ago
  This is presumably because the authors of Go are also Unix implementers or close to it. It's interesting to see the philosophy extended to non-Unix deployments.
- pcwalton 7y ago
  Note that even Go only does syscalls itself on Linux. On macOS and Windows it calls into libSystem and kernel32.dll respectively, as the syscall interface is not stable on those platforms.
  - earenndil 7y ago
    ntdll is pretty close to stable. Technically not stable, but high-profile projects like chrome depend on it, so it's not likely to change at this point.
  - masklinn 7y ago
    > Note that even Go only does syscalls itself on Linux. AFAIK Go does syscalls itself on any platform but Windows and macOS, this includes all BSDs. And even for macOS despite that having never been officially supported it took multiple breakages a few years back. The first thread here mentions the issues that causes for openbsd.
  - loeg 7y ago
    Go does (or did) bare syscalls on the BSDs as well, despite the syscall interface not being stable there.
Mathnerd314 7y ago
Haskell has had an I/O manager for doing asynchronous I/O for a while: https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.649.3381 https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.649... There's been some discussion about using libuv but no consensus: https://gitlab.haskell.org/ghc/ghc/issues/8400 https://gitlab.haskell.org/ghc/ghc/issues/8400. It's available as a library: https://haskell-stdio.github.io/stdio/ https://haskell-stdio.github.io/stdio/ I didn't re-read the papers but IIRC GHC just spawns an extra OS thread any time a possibly-blocking function is called, as it doesn't follow a strict M:N model. There's a thread pool to reduce overhead but it's probably not as efficient as Go's method.

by pythux 7y ago

kevingadd 7y ago

Go is one of the only languages that does syscalls itself (mostly because it's extremely high-risk and low-payoff), so some of its syscall-related techniques are not easily adapted to other runtimes.

derefr 7y ago
Do JITing runtimes like the JVM or LuaJIT, just generate libc-syscall-wrapper calls in the emitted object code, then?
- blattimwind 7y ago
  Something like LuaJIT doesn't have the concept of a syscall, only calling into external C code. The same is probably(?¹) true for the JVM, since Java uses native methods to talk to the OS as well. So the JIT'ed code would call into the language runtime library, which in turn would call a syscall wrapper provided by the libc. ¹ It's possible the JVM, being the highly optimized workhorse VM it is, has specialized optimizations for I/O and does indeed skip over JNI and libc in these cases.
  - justincormack 7y ago
    ljsyscall for example calls into the libc syscall() wrapper. Most ffi type APIs can’t generate assembly for calling directly.
    - fsfod 7y ago
      In theory you could do it directly with the intrinsic system I built for LuaJIT[1]. It would dynamically generated the assembly for a user declared intrinsic\arbitrary machine opcode when there first called in the interpreter and the opcode is directly emitted when the code is JIT'ed. I think defining an intrinsic for a system call would just be a matter of setting the correct input and output registers. [1] https://github.com/LuaJIT/LuaJIT/pull/116 https://github.com/LuaJIT/LuaJIT/pull/116
- cesarb 7y ago
  For the JVM: AFAIK, the JIT-generated code (and the interpreter) never does system calls, either directly or indirectly through the C library. Instead, they call "native" code written in C or C++, and it's that native code which does all the system calls or equivalent.
- deleted 7y ago
  [deleted]
lonelappde 7y ago
This is presumably because the authors of Go are also Unix implementers or close to it. It's interesting to see the philosophy extended to non-Unix deployments.
pcwalton 7y ago
Note that even Go only does syscalls itself on Linux. On macOS and Windows it calls into libSystem and kernel32.dll respectively, as the syscall interface is not stable on those platforms.
- earenndil 7y ago
  ntdll is pretty close to stable. Technically not stable, but high-profile projects like chrome depend on it, so it's not likely to change at this point.
- masklinn 7y ago
  > Note that even Go only does syscalls itself on Linux. AFAIK Go does syscalls itself on any platform but Windows and macOS, this includes all BSDs. And even for macOS despite that having never been officially supported it took multiple breakages a few years back. The first thread here mentions the issues that causes for openbsd.
- loeg 7y ago
  Go does (or did) bare syscalls on the BSDs as well, despite the syscall interface not being stable there.

Mathnerd314 7y ago

Haskell has had an I/O manager for doing asynchronous I/O for a while: https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.649.3381 https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.649... There's been some discussion about using libuv but no consensus: https://gitlab.haskell.org/ghc/ghc/issues/8400 https://gitlab.haskell.org/ghc/ghc/issues/8400. It's available as a library: https://haskell-stdio.github.io/stdio/ https://haskell-stdio.github.io/stdio/ I didn't re-read the papers but IIRC GHC just spawns an extra OS thread any time a possibly-blocking function is called, as it doesn't follow a strict M:N model. There's a thread pool to reduce overhead but it's probably not as efficient as Go's method.