[8330] in bugtraq
More about multi-stack allocator.
daemon@ATHENA.MIT.EDU (Serge Orlov)
Wed Oct 28 16:36:33 1998
Date: Wed, 28 Oct 1998 16:12:30 +0300
Reply-To: Serge Orlov <sorlov@CON.MCST.RU>
From: Serge Orlov <sorlov@CON.MCST.RU>
To: BUGTRAQ@NETSPACE.ORG
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>.
