Locality, modular analysis

General
21

Completely agree! My biggest interest with the actor model is using it as a way to wire together different “flavors” of computation. I think this is also how the Syndicate Actors Smalltalk implementation works. It views the Smalltalk VM as an actor with Syndicate Entities running inside, and these entities can receive or send Preserves messages with the “outside world”. The SmalltalkVM is connected to other Syndicate actors by running the Syndicate protocol over transports like TCP or Unix sockets. There’s a similar Syndicate project experimenting with term rewriting: ehmry/sirja: Nova language experiment - git.syndicate-lang.org and I’m currently working on a Syndicate actor that wraps the Steel VM.

This thread now has me wondering if looking at VM’s this way could lead to new and interesting ways we could externalize[0] the state of the VM? Especially for debugging purposes.

Cranelift, a Rust codegen project has a JIT compiler that allows you to return a raw pointer to a function you compiled using the JIT[1]. Taking this idea to the extreme, you could have an actor that you can send AST’s (serialized using Preserves or something similar) and get a message in response with a capability to the piece of machine code for that compiled function. Is serializing pointers like this even possible on Linux? Maybe with mmap() and friends? I’m not sure, but it might be neat?

[0]: Neat paper on externalizing state: Dialectics for new computer science - Salon des Refusés 2017 and 2018

[1]: good example of what this looks like here: cranelift-jit-demo/src/jit.rs at main · bytecodealliance/cranelift-jit-demo · GitHub

2 Likes
22

Yes, that’s the sort of thing I’d like to see. Both images, and “diffs” of images. Ie, a read-only base image plus a read-write overlay of changes - like how containers work, and also backups, and also software updates, and also transactions, and also undo/restore. These sets of images/diffs would need to be mountable and unmountable at runtime, with their mount points being a specified object, but only intercepting defined messages or object names sent to that object. And object pointers would need to be transparently handled by the VM in such a way that mounting or unmounting an image/diff didn’t break them, so you could safely roll back a transaction or restore from a backup.

I guess it would mean that any newly created objects would be actually an almost empty object, with an inheritance chain including all the mounted images referenced when it was created.

I feel like such a mechanism would be the minimal requirement for really applying the object/actor model to communicating systems of objects. If done right, this mechanism should be able to scale up to entire clouds or the entire internet.

(Because if a universal model of computation inspired by the Internet’s message-passing mechanism can’t be used to model the very thing it was inspired by… then something has gone badly wrong in the process of model-building.)

2 Likes