I wonder if this comes under “Code Style” or not…
Anyway, Monty and I finished getting Drizzle ready for adding “-Wframe-larger-than=32768” as a standard compiler flag. This means that no function within the Drizzle source tree can use greater than 32kb stack – it’s a compiler warning – and with -Werror, it means that it’s a build error.
GCC is not perfect at detecting stack usage, but it’s pretty good.
Why have we done this?
Well, there is a little bit of recursion in the server… and we can craft queries to blow a small stack (not so good). On MacOS X, the default thread stack size is only 512kb. This gives not many frames if 32kb stack is a even remotely common.
I found some interesting places to throw a lot of things on the stack too – that would be rather far down on a callchain – leading to the possibility of blowing up in really strange ways.
We’d love to make it 16kb…. but that’s a fair bit more work, so something for the future.
We’ve used the Boost scoped_ptr to address a bunch of these situations as it provides pretty much minimal code change for the same effect (except that memory is dynamically allocated instead of as part of the stack frame).
I’ve tried that in MariaDB 5.3 few days ago.
Surprisingly, we were pretty cool about it – no warnings with 16kb limit in the server *at all*. Few warnings in archive and aria engines – which I’ll fix before pushing, and few in standalone tools like gen_lex_hash, which don’t really matter (but I’ll have to do something about them too, I suppose).
You’re probably better off than we are, we got a bunch of places with things on the stack due to gradually going from char* to std::string in some places.
Probably got one or two in innodb though?
I have fixes for the archive ones in Drizzle, using boost::scoped_ptr – same for MyISAM (no doubt Aria is the same).
Next thing is to run:
valgrind –tool=drd –show-stack-usage=yes /bin/ls
to check what we get to.
Dynamic allocation cost much more than automatic allocation. Don’t you have abreak in performance due to this choice?
Although have had some trouble with drd… so going to try massif. Will blog about how it goes.
Not from our benchmarks. We probably trade off extra cycles for keeping the stack more cache-friendly.