[prev in list] [next in list] [prev in thread] [next in thread]
List: bugtraq
Subject: More about multi-stack allocator.
From: Serge Orlov <sorlov () CON ! MCST ! RU>
Date: 1998-10-28 13:12:30
[Download RAW message or body]
Hi,
I received some questions about multi-stack allocator, here is
the answers:
> how about performance compare with "canary" and "stack guard"?
Author of StackGuard wrote to me about multi-stack:
> Way cool...
> ...
> Your performance figures are very impressive.
StackGuard puts "canaries" into every function (at least in the
current version). In contrast multi-stack allocator is used only
for local arrays and does not affect functions without local arrays.
So if a program spends most of time in functions without arrays,
it is even hard to measure slowdown. If a program uses arrays, then
the slowdown is about 1%. That is lower than with StackGuard.
The main difference is memory. StackGuard almost does not increase
memory consumption, while multi-stacked program can use a lot of
additional memory. Reread my first post for figures. Fortunately,
memory is cheap nowadays.
> So how compatible is it? Can it inter-operate with standard shared
> libraries? Do you just have to re-compile the shared libraries?
You can mix multi-stacked programs and shared libraries in all possible
ways. Well, at least on elf-i386-linux, other platforms may need some
porting and checking.
Shared libraries are also easy to recompile. Just add -fmulti-stack
option.
Crispin Cowan also noted that the C standard states that automatic
variables are to be laid out in sequential memory, although some padding
is allowed. OK, I'll add this to "Limitations" paragraph, but I have not
seen any programs that depend on layout of automatic variables.
Serge Orlov <sorlov@con.mcst.ru>.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic