I've got a customer who's interested in making the switch from 6.3.0 to 6.4 when it's available.  Two very key metrics 
for them are boot time (time to get their application up & running) and memory consumption (they're very close to the 
limit for this product line).  Related to this is the smallest amount of free RAM that the kernel expects before it will
 stop running properly.

They made a similar switch for their 6.2.1B product to 6.3.0.  What they discovered was that in optimizing the 6.3.0 
memory allocator for speed in normal use, the changes negatively impacted total system ram used as well as time required
 to start applications.  The reasoning had to do with default heap blocks and/or some extra work done by the allocator 
during initialization.  Thankfully they were able to substitute the 6.2.1B allocator for the stardard one provided by 6.
3.0 to get their old behavior.  Which ensured that they still met their startup requirements *and* could still fit into 
16MB RAM.

So two questions.
1) Are we going to benchmark things like startup time and overall memory use of 6.4 against 6.3.0?  Clearly we can't do 
it for specific customer applications.  But will we have any idea what we've done and how it impacts various classes of 
user applications?  Like small, big but flat, big but using lots of .so's (like C++)?  Exampnles of things customers 
will need to know would be size of increase or decrease per malloc/per thread/per process.

2) Will we be able to use the old allocator from 6.3.0 or even 6.2.1B if necessary if the 6.4 allocator introduces some 
undesired side-effect?