VLAs (Re: C99 Features)

[Roland Mainz]

----- 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.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) rmainz at redhat.com
  \__\/\/__/  IPA/Kerberos5 team
  /O /==\ O\  
 (;O/ \/ \O;)