Daniel Micay on Twitter: "Slab size classes match the ones in jemalloc (https://t.co/UxQJ8FTAvi), so bin indexes even match up. Example with N_ARENA = 1 for a trivial test: https://t.co/0kQyX7eUvx Large allocations are treated as the closest thing in jemalloc, huge allocations, but in an special arena." / Twitter

Since I was already working on implementing stats (twitter.com/DanielMicay/st), I also implemented Android's internal extensions to jemalloc for providing stats to Bionic: github.com/GrapheneOS/har Bionic uses these four functions to implement Android's public malloc_info API.

Quote Tweet

Daniel Micay

@DanielMicay

Apr 7, 2019

Android Q uses mallinfo as part of the ART GC for better integration with native code: developer.android.com/preview/featur. Commits: android.googlesource.com/platform/art/+ android.googlesource.com/platform/art/+ I added an actual implementation to hardened_malloc in preparation for moving to Q: github.com/GrapheneOS/har

Show this thread

1

3

Daniel Micay

@DanielMicay

Apr 7, 2019

It provides structured output divided up at the top level based on arena, showing the total memory allocated for small, large and huge allocations along with each of the size class bins for the arena and a counter of total allocations / deallocations for each arena. It fits well.

1

Daniel Micay

@DanielMicay

Slab size classes match the ones in jemalloc (github.com/GrapheneOS/har), so bin indexes even match up. Example with N_ARENA = 1 for a trivial test: gist.github.com/thestinger/221 Large allocations are treated as the closest thing in jemalloc, huge allocations, but in an special arena.

6:09 AM · Apr 7, 2019Twitter Web Client

Replying to

The only Android API extension still missing is malloc_iterate, which is used with malloc_enable/malloc_disable to implement libunreachable, a zero overhead leak detector via on-demand imprecise mark-and-sweep pass querying the malloc implementation: android.googlesource.com/platform/syste

1

2

Daniel Micay

@DanielMicay

Apr 7, 2019

I can certainly implement the malloc_iterate API, but it would be very inefficient with the current open addressed hash table used for tracking large allocations. I already want to offer an alternative able to answer malloc_object_size queries within large allocations anyway.

Conversation