ISMM Wild&Crazy

1. ISMM Wild&Crazy Dave Detlefs, Microsoft

2. Here's a phrase: • “…efficient bump-pointer allocation…”

3. Here's a phrase: • “…efficient bump-pointer allocation…” • All of us have read it. • Many of us have written it!

4. Here's a phrase: • “…efficient bump-pointer allocation…” • All of us have read it. • Many of us have written it! • What does it mean? • Efficient compared to what? Free-list allocation?

5. Allocation sequences Bump-pointer Free list • res = CurAP;newAP = res + N;if (newAp < Lim) {CurAP = newAP;return res;

6. Allocation sequences Bump-pointer Free list • res = CurAP;newAP = res + N;if (newAP < Lim) {CurAP = newAP;return res; • res = FL[N];if (res != null) {newHd = res->next;FL[N] = newHd;return res;

7. Allocation sequences Bump-pointer Free list • res = CurAP;newAP = res + N;if (newAP < Lim) {CurAP = newAP;return res; • res = FL[N];if (res != null) {newHd = res->next;FL[N] = newHd;return res;

8. Allocation sequences Bump-pointer Free list • res = CurAP;newAP = res + N;if (newAP < Lim) {CurAP = newAP;return res; • res = FL[N];if (res != null) {newHd = res->next;FL[N] = newHd;return res;

9. Allocation sequences Bump-pointer Free list • res = CurAP;newAP = res + N;if (newAP < Lim) {CurAP = newAP;return res; • res = FL[N];if (res != null) {newHd = res->next;FL[N] = newHd;prefetchnewHd;return res;

10. Allocation sequences Bump-pointer Free list • res = CurAP;newAP = res + N;if (newAP < Lim) {CurAP = newAP;prefetchres+K;return res; • res = FL[N];if (res != null) {newHd = res->next;FL[N] = newHd;prefetchnewHd;return res;

11. Here’s a Heap:

12. Here’s a Heap: How Fragmented is it?

13. Here’s a Heap: How Fragmented is it? Is it more or less fragmented than it used to be?

14. Desired Properties of the Answer • It should not be relevant to some requested allocation size. • If we knew the future allocation requests, we wouldn’t have a problem! • But the answer should be some measure of how likely it is that future requests may be satisfied… • It should not mention the heap size, or sizes of allocated blocks. • If the heap I showed was the whole heap, or 1/10 of the heap, with the rest full… • And whether the allocated portion was 10 objects or 10,000… • …has no bearing on likelihood of satisfying future requests.

15. What we used at Sun for Conc MS • Somewhat like the formula for variance of a series:compactness(heap) = ∑ bi2/ (∑ bi)2fragmentation(heap) = 1 – compactness(heap) • Properties: • Has the desired properties – depends only on the distribution of the free blocks. • A maximally compacted heap = 0 • A highly-fragmented heap  1 • But what meaning can we associate with intermediate values?

16. Ramki*'s Observation • Translate the fragmentation metric back to a characteristic block size: • If we imagine we could coalesce the available free space (∑ bi), and then split it (again), but into equal-sized blocks, what block size would yield the same fragmentation? • This is probably more useful than a real number in [0..1]. • * (Y. S. “Ramki” Ramakrishnan)

17. Conclusion • Caveat – there’s no underlying theory here: no statement relating the fragmentation of two heaps to their likelihood of satisfying a stream of future allocation requests… • Theory research direction? • But it’s still as useful a measure as any I’ve seen in the literature…