Hacker News Reader

Comment by derefr | Hacker News Reader

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.

Reply on news.ycombinator.com