The vm has special knowledge of its data structures though, right? I’m not entirely sure why a process couldn’t refcount itself and know which other processes have borrowed a reference, and on process death do push a recopy of those about to be gc’d memory bits into the target (like, a “lazy copy”). A lot of use cases are going to be transient tasks which are effectively read only, with the parent (say genserver) being long lived, so not copying seems to me like it would be useful. I just wish I had time to look at the internals and contribute more than just my armchairing.
ityonemo
sribe
-
What happens when any process in this scenario needs to GC?
-
Then the target has to be paused when the source of the data dies.
1
ityonemo
Why? You could have a read only pointer table in the target that gets written to by the source after the copy has been performed. You might have to make the pointer operation atomic but that’s not terrible, it’s just one word.
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Atomic operations across cores require the cores to synchronize. This is a non trivial bottleneck when you have thousands of concurrent processes. What you’re proposing it the “refcount everything” option I mentioned earlier. The performance penalty to this on multicore systems is non trivial.
That one word may also be more expensive than you think. Consider something like a list. A list isn’t a single thing, it’s a chain of [head | tail]. Refcounting each link in the chain (cause remember, any arbitrary part of the list could have been sent to a different process) would double the memory overhead of the list cell which is only 1 word to begin with.
4
ityonemo
I’ll be honest I don’t know how cross core memory operations work on x86 with it’s potentially convoluted nonuniform memory access. The last system I wrote machine code for was the rex neo, which had hierarchical scratchpad memory instead of cache so a write across from one core to another was instantly guaranteed to be atomic without any synchronization primitive at all.
0
OvermindDL1
ityonemo
if anyone is curious:
The two 20-year olds taped out a chip in six months, which is incredible, and the chip worked and had a power profile a fraction (i think 10x lower) that of Nvidia GPU for FFT, and 5x faster at 200 MHz on 22nm process; the intended target audience was 5G modem manufacturers, but they couldn’t find a buyer, since they didn’t really know how to do technical sales (also they burned 6 months because the person they contracted to do the motherboard screwed them and they had to redo most of it themselves). They should have nabbed ericsson but ericsson has a cosy relationship with intel and got hosed when intel’s 7nm process failed.
I do think it’s interesting that the chip layout basically has you running concurrent cores for which the best model for processing is the actor model. It seems like my whole computer industry “career” has been about nudging me to the actor model over and over again.
1
rvirding
Creator of Erlang
I think you will end up copying most of the data anyway but it a much less controlled fashion. As someone has pointed out you are viewing the data sent in a message as one big coherent chunk created in the sender and sent to the receiver, but this is generally not the case. Usually the data in a message is put together from smaller bits which come from many different processes. This will mean that either you have a right mess of keeping track of what and from where, or you will be doing a lot of copying between processes which is what you are trying to avoid.
A simple example of what I mean. Assume A sends a chunk of data to B which sends it on to C, so A → B → C. From what I understand of your method is that the data is not copied and A knows it has sent to B and B knows it has sent it to C. What happens if/when B dies? A does not know about C so if A now dies it can’t copy the data to C. Or should B tell A about C? But that means a process has to keep track of where all its data has come from, which we don’t need to do now.
This is exactly the problem you get with atomics, counters and persistent_terms. Atomics and counters solve the problem by only allowing integers while persistent_terms allow complex data structures but require a global gc when you update the data.
9