[LLVMdev] [PATCH] Protection against stack-based memory corruption errors using SafeStack

[Volodymyr Kuznetsov]

Yes, indeed, the increase in the memory footprint is minimal and constant
for each stack frame that uses the unsafe stack - it's just a single unsafe
stack frame pointer per unsafe stack frame. The space for each stack object
is still allocated only once: either on normal or on the unsafe stack, but
not both. In practice, we indeed didn't observe any measurable increase in
the memory footprint due to the safe stack in our experiments.

As for the cache locality, we actually observed that the safe stack
sometimes improves the cache hit rate. This is especially the case for
programs that allocate large arrays or long-lived objects on the stack that
should be normally evicted from the cache, but are kept there only because
they share the same cache lines with e.g., spilled registers. With the safe
stack, such objects are moved elsewhere, which results in the frequently
accessed objects on the normal stack being closer to each other and occupy
less cache lines in total. Of course there might be pathological negative
cases as well, but as we show in our paper, both the average and the
maximum overhead looks quite good in practice (see Figures 3 and 4 in
http://dslab.epfl.ch/pubs/cpi.pdf).

- Vova

On Tue Nov 04 2014 at 11:50:01 AM David Chisnall <
David.Chisnall at cl.cam.ac.uk> wrote:

> On 4 Nov 2014, at 00:36, Kostya Serebryany <kcc at google.com> wrote:
>
> > You at least increase the memory footprint by doubling the stack sizes.
>
> Not quite.  The space overhead is constant for each stack frame - you just
> need to keep track of the top of two stacks, rather than one.  The
> important overhead is that you reduce locality of reference.  You will need
> a minimum of two cache lines for each stack frame instead of one.  In
> practice, this is not a huge problem, because you need several cache lines
> live for good performance of the stack and the total number of lines is not
> much different.
>
> There are likely to be some pathological cases though, when both the safe
> and unsafe stacks have the same alignment for the top and you are dealing
> with some other heap data with the same alignment.  This will increase the
> contention in set-associative cache lines and may cause more misses.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141104/b96ba34e/attachment.html>