upvote
I’ve used the copy-stack trick before! It’s really great!

You can work around the pointer relocation issue by always coping the stack back onto the main stack. So you’re always running on the same range of stack in memory and saved stacks are always elsewhere

reply
Is this the technique you are describing?

https://langdev.stackexchange.com/a/4242

https://www.microsoft.com/en-us/research/wp-content/uploads/...

> How does he do it? By simply always restoring the continuation to exactly the place it was captured from, of course!

Pretty awesome. Gets around the problem by not relocating at all. I haven't read the full paper, to be honest. I just assumed it'd require defensive copying in case the stacks overlapped in memory.

Alexis King does outline the safety constraints that Fil-C would care about:

> references to stack-allocated data must not be shared across continuation chunk boundaries, as both capture and restore may relocate portions of the stack, making all references to stack-allocated memory in the relocated portions temporarily dangling

reply
> What ruins this for C is the existence of pointers. Stacks aren't freely relocatable since pointers into the stack could exist.

I sometimes wonder what computing would be like if the 80286 hadn't sucked, if segmentation had won over flat address spaces, and if we'd been able to do relocation pain-free by changing a segment base register in one spot instead of rewriting linear pointers everywhere. We could have done paging within segments.

Oh well.

reply
That'd only help for one object per address space. Main thing needing relocation - shared libraries - needs arbitrarily-many segment bases.

And when you're not a library, relocation is just a mild probabalistic security improvement (...that'd be massively-more bypassable than it already is if the program was littered full of gadgets of "read register as unrelocated offset and use it with its correct base" instructions).

reply
mmap with MAP_FIXED has allowed you to do this for some time.
reply
Not if you have an address space conflict, e.g. if you want to move a stack within a single process. Linear addresses are relative to a whole address space root.
reply
> What ruins this for C is the existence of pointers. Stacks aren't freely relocatable since pointers into the stack could exist. Other languages don't have this problem

What about languages with pass by reference?

reply
I suppose it would depend on the implementation. References could be implemented with absolute pointers, or with base pointers plus offsets.

Base pointers are trivially relocatable. Just set the base pointer and it's done. This is how my language supports stack expansion: just reallocate the memory, overwrite base pointers, elements always dereference base plus offset, done. The heap is also implemented this way. All objects are indexes into a massive object array, and the base pointer is implicit.

https://www.matheusmoreira.com/articles/lone-lisp-heap

Absolute pointer references are not easily relocatable. You'd need to rewrite every single pointer. I've never seen anyone actually do this in C since it'd hit the same problem conservative garbage collectors do: you might rewrite an integer variable that just happens to look like a pointer.

If you're audacious enough you can try to somehow remap the stacks in the exact same spot they used to be at in order to not invalidate the pointers to begin with:

https://langdev.stackexchange.com/a/4242

https://www.microsoft.com/en-us/research/wp-content/uploads/...

Some languages like Go manage to do it because they just know where all the pointers are in most circumstances. They tend to choke only on foreign code they can't introspect into.

reply