[Paper Review] An Extended Low Fat Allocator API and Applications

Gregory J. Duck, Roland H. C. Yap|arXiv (Cornell University)|Apr 13, 2018

Security and Verification in Computing8 references3 citations

TL;DR

This paper proposes an extended LowFat allocator API that leverages low-fat pointers—encoding object size and base address within native pointers—to enable efficient, low-latency operations like size, base, and offset retrieval. The key contribution is supporting these extended operations uniformly across heap, stack, and global objects, enabling novel applications such as memory error detection, compact data structures, and typed pointers with minimal performance overhead.

ABSTRACT

The primary function of memory allocators is to allocate and deallocate chunks of memory primarily through the malloc API. Many memory allocators also implement other API extensions, such as deriving the size of an allocated object from the object's pointer, or calculating the base address of an allocation from an interior pointer. In this paper, we propose a general purpose extended allocator API built around these common extensions. We argue that such extended APIs have many applications and demonstrate several use cases, such as (manual) memory error detection, meta data storage, typed pointers and compact data-structures. Because most existing allocators were not designed for the extended API, traditional implementations are expensive or not possible. Recently, the LowFat allocator for heap and stack objects has been developed. The LowFat allocator is an implementation of the idea of low-fat pointers, where object bounds information (size and base) are encoded into the native machine pointer representation itself. The "killer app" for low-fat pointers is automated bounds check instrumentation for program hardening and bug detection. However, the LowFat allocator can also be used to implement highly optimized version of the extended allocator API, which makes the new applications (listed above) possible. In this paper, we implement and evaluate several applications based efficient memory allocator API extensions using low-fat pointers. We also extend the LowFat allocator to cover global objects for the first time.

Motivation & Objective

• Address the lack of standardized, efficient extensions to the traditional malloc API for retrieving allocation metadata such as size, base, and offset.
• Enable uniform treatment of memory objects (heap, stack, and global) through a consistent extended API.
• Demonstrate that low-fat pointer encoding allows for highly optimized, inlined operations critical for performance-sensitive applications.
• Enable new programming patterns and data structures that were previously infeasible due to high overhead in traditional allocators.
• Extend the LowFat allocator to support global objects, completing full coverage of all major object types in C/C++ programs.

Proposed method

• Encode object size and base address directly into the pointer representation using bit fields, leveraging 64-bit pointer alignment and unused bits.
• Implement the extended API using low-fat pointer operations that are compiled to a few inlined assembly instructions, minimizing runtime cost.
• Extend the LowFat allocator to support global variables by storing metadata in a lookup table, enabling consistent behavior across all object types.
• Use the extended API to implement applications such as bounds checking, hidden metadata storage, typed pointers, and compact vectors.
• Evaluate performance using microbenchmarks on operations like vector construction, access, and size calculation, comparing LowFat to traditional and Boehm GC-based approaches.
• Leverage the efficiency of LowFat operations to support applications requiring frequent metadata access, such as bounds checking in hardening tools.

Experimental results

Research questions

• RQ1 Can low-fat pointer encoding be extended to global variables to provide uniform metadata access across all object types?
• RQ2 How efficiently can extended allocator operations (size, base, offset) be implemented using low-fat pointers compared to traditional allocators?
• RQ3 What performance overhead do applications built on the extended LowFat API incur, and under what conditions are they beneficial?
• RQ4 Can the extended API enable new programming patterns such as typed pointers or compact data structures that are infeasible with standard allocators?
• RQ5 How does the performance of LowFat-based implementations compare to existing alternatives like the Boehm garbage collector for similar use cases?

Key findings

• The extended LowFat API enables size, base, and offset operations in just a few inlined instructions, achieving sub-10-cycle latency on average.
• Low-fat vectors reduce memory overhead by eliminating explicit len and pos fields, saving 3 words per vector when all fields are 1-word in size.
• Constructing low-fat vectors incurs a 1.33× to 2× performance overhead depending on size alignment, with access overhead around 1.2×.
• Low-fat tagged pointers outperform traditional tagged pointers by ~20% in size-typed pointer benchmarks, while extended tagged pointers are ~27% slower but support more tag bits.
• Boehm GC-based implementations of similar functionality are over twice as slow as LowFat due to library call overhead, highlighting the benefit of inlined operations.
• The extension of low-fat pointers to global objects enables full coverage of heap, stack, and global memory, making the extended API universally applicable across C/C++ programs.