Malloc timeline.

[OndÅej BÃlka <neleai at seznam dot cz>]

Hi,

As there were considerable discussion how improve malloc we should
decide what is feasible for 2.19 and what for 2.20. 

The most ugrent step for 2.19 is announce which features will not be
supported (malloc_set_state, malloc hooks...), for these we should
prepare a copy of current allocator as separate library.

We need to announce there will be changes in interface which happens
once per half of year so users will be prepared when actual changes
happen.

Could somebody review features and write which are needed and which are
not?

A second urgent item to resolve is make malloc signal safe. This is
prerequisite for improving performance, we could choose either that or
decide that memory corruption from signal invocation is user problem.

Then we could focus on important issues, we need to improve performance 
and per-thread cache for small allocations is easiest way to get these. 
This depends on resolving a malloc_set_state and signal safety. 

There are more improvements but these depend on refactoring of malloc
(better data structure for first fit).
As some refactoring would temporary decrease performance these probably
need to wait for 2.20

We should also focus on decreasing malloc memory footprint, each
allocation now has a 16 byte overhead which is not needed.

For these we need to do survey of what is known which will take time and
also will come in 2.20

Then there are features to make malloc more safe which will come in
2.20, I have more proposals which do not hurry so I ommited them now.

This is my view, feel free to add what do you desire. Try to keep these
in chronologic order to see what needs to be done.