|Deletions are marked like this.||Additions are marked like this.|
|Line 9:||Line 9:|
|* Investigate vrange support http://sourceware.org/ml/libc-alpha/2013-04/msg00414.html|
- Accepted consensus on open source benchmarks to use for validating allocator changes.
- Stable API that allows interaction with allocator running in an application. This can be used by debuggers, audit libraries etc.
- Application hook to control arena creation.: Can use allocator API and application specific information to make decisions.
- Systemtap probes: Figure out additional probes and also characterize what we want to measure using the current probes
Investigate vrange support http://sourceware.org/ml/libc-alpha/2013-04/msg00414.html
- Take another look at the mallopt tunables and environment variables to ensure that they're honored in all valid cases.
- Hooks to allow arenas to be created using huge pages (either default size or particular sizes)
- Hook to allow application to do "something" to mmap'ed memory when it's fresh from the system - e.g. mbind(), or e.g. for the tile architecture we have some cachebinding magic we can optionally do for performance on newly-mmap'ed regions
- Controlled way to force allocation of memory up front like mmap(MAP_POPULATE) so that if requested, errors are always detected as NULL returns from malloc() rather than potentially as fatal signals delivered by the kernel on out-of-memory
- Hook to request MAP_SHARED for allocated anonymous memory so forked processes can share an arena (with inter-process mutex locking, like it currently does for pthreads)
Use pools for sizes < 64
- Use thread cache to avoid atomic operations when possible.
- see kam.mff.cuni.cz/~ondra/small_malloc.c for draft.
- Detect fork to avoid copy on write of free pages
- Throttle number of arenas based on process rlimit on process startup and/or everytime RLIMIT_AS is modified.