Hacker News Reader

Comment by pythux | Hacker News Reader

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?

View on HN

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...

There's been some discussion about using libuv but no consensus: https://gitlab.haskell.org/ghc/ghc/issues/8400. It's available as a library: 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.

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.

Do JITing runtimes like the JVM or LuaJIT, just generate libc-syscall-wrapper calls in the emitted object code, then?

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.

ljsyscall for example calls into the libc syscall() wrapper. Most ffi type APIs can’t generate assembly for calling directly.

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

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.

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.

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.

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.

> 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.

Go does (or did) bare syscalls on the BSDs as well, despite the syscall interface not being stable there.

Reply on news.ycombinator.com