VLAs (Re: C99 Features)
rmainz at redhat.com
Thu Jul 9 11:12:29 EDT 2015
----- Original Message -----
> From: "Nico Williams" <nico at cryptonector.com>
> To: "Benjamin Kaduk" <kaduk at mit.edu>
> Cc: "krbdev at mit.edu" <krbdev at mit.edu>
> Sent: Wednesday, June 24, 2015 2:20:39 AM
> Subject: VLAs (Re: C99 Features)
> On Sat, Jun 20, 2015 at 03:11:03PM -0400, Benjamin Kaduk wrote:
> > On Fri, 19 Jun 2015, Nico Williams wrote:
> > > > Well, take common inner-function heap allocations and turn them into
> > > > stack allocations. That is a significant performance gain.
> > >
> > > Probably. A decent heap allocator with per-thread magazines ought to be
> > > good enough in most cases.
> > I'm not sure I follow what point Nico is trying to make, here. [...]
> That we shouldn't be making this optimization except where it's really
> necessary. I.e., find a hotspot where VLAs or alloca() is the fix.
> The heap allocator ought to be good enough.
No... it is not. Sun long ago did a detailed analysis of the problem (related to libumem and the Solaris kernel memory allocator) and it was found while libumem (this applies to all normal allocator systems) is very fast&&efficient it does not distinguish between object types and object usage/lifetime.
The small/artificial testcases used to "prove" the "superiority" of a specific allocator typically do not measure effects of long-term heap thrashing/fragmentation caused by interleaving allocations and out-of-order-|free()| between threads or mixture between temporary allocations (with |malloc()|+|free()| in the same function) and long-term allocations.
One of the findings of this analysis was that if the temporary allocations come from a different memory pool (or stack via VLA/|alloca()|) then the long-term fragmentation of the global heap can be *GREATLY* reduced.
So using memory from stack to serve allocations of temporary memory still makes sense because it reduces the long-term fragmentation of the global heap a *lot*. This becomes even more important for threaded applications but still applies to single-threaded but long-running processes (like the krb5kdc), too.
__ . . __
(o.\ \/ /.o) rmainz at redhat.com
\__\/\/__/ IPA/Kerberos5 team
/O /==\ O\
(;O/ \/ \O;)
More information about the krbdev