This is a game where you have to allocate and free contiguous memory blocks. You can hover or drag on free cells to preview the allocated memory. If it's not possible to allocate a contiguous memory block, you lose and have to start from the first level. If you succeed to allocate all the blocks, you win and can play the next level. Each new level becomes more and more challenging.
A memory allocator manages a region of memory and decides where each new allocation should go. When memory is allocated and freed over time, the free space can become split into many small gaps. This is called external fragmentation: there may be enough total free memory, but not enough contiguous free memory for a request.
There is no universally best allocation strategy. Real allocators usually balance speed, memory usage, fragmentation, and implementation complexity.
| Strategy | Idea | Pros | Cons |
|---|---|---|---|
| First fit | Place the request in the first free block large enough to hold it. | Simple and usually fast, because the search can stop early. | Can leave many small holes near the beginning of memory. |
| Best fit | Choose the smallest free block that is large enough. | Tries to avoid wasting large blocks. | Usually slower, and may create tiny leftover fragments. |
| Worst fit | Choose the largest available free block. | Tries to leave a remaining block that is still useful. | Often breaks up large blocks unnecessarily and can perform poorly. |
| Next fit | Like first fit, but continue searching from the previous allocation position. | Avoids repeatedly scanning from the start. | Can still fragment memory and may miss better earlier holes. |
| Buddy allocator | Split memory into power-of-two blocks and merge neighboring buddies when freed. | Fast splitting and merging. | Can waste space because requests are rounded up. |
| Pool / slab allocator | Keep fixed-size blocks for objects of the same size. | Very fast for repeated same-size allocations. | Less flexible for varied allocation sizes. |