An Extended Low Fat Allocator API and Applications

April 13, 2018 Β· Declared Dead Β· πŸ› arXiv.org

πŸ‘» CAUSE OF DEATH: Ghosted
No code link whatsoever

"No code URL or promise found in abstract"

Evidence collected by the PWNC Scanner

Authors Gregory J. Duck, Roland H. C. Yap arXiv ID 1804.04812 Category cs.PL: Programming Languages Citations 10 Venue arXiv.org Last Checked 3 months ago
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.
Community shame:
Not yet rated
Community Contributions

Found the code? Know the venue? Think something is wrong? Let us know!

πŸ“œ Similar Papers

In the same crypt β€” Programming Languages

Died the same way β€” πŸ‘» Ghosted