[joosters]

The performance is impressive, considering that maintaining a second stack presumably requires another register exclusively dedicated to it. I'm surprised it makes such little difference. Or are there some cunning optimisations going on?

[evanpw]

I was wondering the same thing. The linked article (http://dslab.epfl.ch/pubs/cpi.pdf) says that they don't use a dedicated register. The unsafe stack pointer is saved in the thread control block, accessible through a segment register. From there, they let LLVM choose a register (not necessarily the same one for each function). They also say that only 25% of functions need any unsafe stack access at all, which I guess is why this is faster than using a dedicated register.

[tomp]

Essentially, what they are doing is allocating all unsafe objects (i.e. arrays and objects whose pointer is passed to another function) on a dedicated region of the heap (that they call the unsafe stack) that only keeps these objects, so all (de-)allocation happens in the LIFO order and can be implemented as a stack. As pointed out by evanpw, they keep a pointer to this region in the thread-local store.

[sanxiyn]

Safe stack gets a dedicated register, unsafe stack does not. Then the problem is to keep as much as possible on safe stack.

[moyix]

From the paper:

> This is because objects that end up being moved to the regular (unsafe) stack are usually large arrays or variables that are used through multiple stack frames. Moving such objects away from the safe stack increases the locality of frequently accessed values on the stack, such as CPU register values temporarily stored on the stack, return ad- dresses, and small local variables.

I wonder if this speedup effectively hides the performance overhead of SafeStack.