This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

The direction of malloc?

For a long time we have refused patches to malloc because they would
change the formatting of the code and make it difficult to ... I can
only assume... synchronize with the rapid upstream development of

It is my opinion that glibc should forge ahead on a new direction for
malloc.  We should accept any such patches that would:

* Make it easier for us to maintain the malloc implementation.
  - Removing dead code.
  - Simplifying macros.
  - Removing features we don't use.

* Add new and required features.
  - Add support for "have but don't need" kernel pages via vrange.

* Fix bugs.

We should accept these patches without the restrictions we previously
placed on the malloc implementation. We should use GNU formatting to
make the code match all of our other styles. In effect we should
own the copy of ptmalloc2 we started with and change it into the
implementation that we think our users need.

I even encourage the discussion of providing alternate allocators
like jemalloc.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]