What does HackerNews think of liballocs?
Meta-level run-time services for Unix processes... a.k.a. dragging Unix into the 1980s
liballocs is an approach for providing high-level facilities such as changing structure layout to a a low-level Unix environment.
In general, I think there are two major interesting aspects in systems like the Ruby system browser and Smalltalk. On the one hand one can discover the system - you can dig into the implementation without using a disassembler or reverse engineering - and on the other hand it is possible to change the system behavior at runtime (though this is, of course, dangerous).
I would love to see at least the discoverability aspect to be more pervasive in standard operating systems. There are already partial approaches to this, such as DTrace/systemtap and the proc filesystem, but having discoverability as a first class concept - which might fit well to Plan 9's (and to some extent Unix's) "everything is a file" approach - would be nice.
The ability to change the system at runtime is also fascinating. I already mentioned the research of Stephen Kell in another comment [1] and there's a great video of one of his talks [2] in which he shows his approach to dynamically alter a program's behavior on Unix using shared library mechanisms (you can find the code on github [3]). I worked on related ideas in my PhD thesis 15 years ago, maybe it's time to dig these out again ;-).
However, these dynamic modifications should also be safe and accessible. I'm thinking of something related to AppleScript here, which allows to automate/scripts an amazingly large number of functions on OS X. Combining this with a browser that enables a user to discover the accessible OS functionality seems to be a good idea.
The persistent image ideas might also be useful again in the context of persistent main memory systems, which are becoming available now, e.g. with Intel Crosspoint [6]. There's so much prior work in persistent object systems also on the OS side that is almost forgotten nowadays, such as the Eumel/L3 system by Jochen Liedtke [4] (the inventor of the L4 microkernel) and the BirliX OS [5]. Sounds like a good time to re-evaluate these 1980's-era approaches.
I see some more recent work, such as Ksplice [7], as interesting related technology. What is really missing is an integration of many of these ideas into a consistent system.
[1] https://www.cs.kent.ac.uk/people/staff/srk21/
[2] https://www.youtube.com/watch?v=LwicN2u6Dro
[3] https://github.com/stephenrkell/liballocs
[4] Jochen Liedtke, A Persistent System in Real Use - Experiences of the First 13 Years, Third International Workshop on Object Orientation in Operating Systems 1993 - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.53.7112
[5] W. E. Kühnhauser, H. Härtig, O. C. Kowalski, W. Lux, Mechanisms for Persistence and Security in BirliX, International Workshop on Computer Architectures to Support Security and Persistence of Information 1990, https://link.springer.com/chapter/10.1007/978-1-4471-3178-6_22
[6] https://en.wikipedia.org/wiki/3D_XPoint
[7] Arnold, Jeff and Kaashoek, M. Frans, Ksplice: Automatic Rebootless Kernel Updates, EuroSys 2009 - https://ksplice.oracle.com/doc/ksplice.pdfI don't know enough to have an opinion on this. As an alterntative view, consider listening to Cliff Click describe the challenge the jvm faced when it had a more permissive ffi [1].
I read the paper imagining a kind of COM implementation (apartments/marshalling/...)? But the Github readme makes it seem more like a kind of tagged malloc wrapper.