An Architecture for Millions of Things

Re:An Architecture for Millions of Things by josephg on Thursday July 14, 2016 @01:44AM (#12091883)

The author describes performance problems with existing heap (malloc) implementations, then describes their own memory allocation algorithm system like this:

- things of roughly similar total chunk sizes (constant + dynamic part) are stored in one "bucket", laid out contiguously in fixed-size slots, with a little leeway for growth inside

- there are buckets for each existing size of a thing

- if a thing outgrows the slot size of its bucket, it simply migrates to the bucket with the next bigger slot size

Isn't this exactly how many (most?) modern malloc implementations work? ... A series of buckets for different sizes of objects, combined with bitfields or free lists to keep track of which slots in each bucket are free?

[ Parent | on HN ]

Re:An Architecture for Millions of Things by anselm_eickhoff on Thursday July 14, 2016 @08:15AM (#12093085)

(author) I made the mistake of writing a blog post targeted towards non-programmers, leaving away a lot of essential detail. For example that buckets only contain one kind of actor or message and because of indirect references can be deallocated by a simple swap-with-last, so no free-lists are needed

[ Parent | on HN ]