Allocator Improvement: don't specify how much memory a program needs about mpl

[ramLlama]

I'll just note that with the current Chunk Pool setup, this is actually very tricky since I rely on the chunk pool being totally contiguous to make chunk/page metadata lookup easier. With a growable (and maybe shrinkable!) Chunk Pool, I'd need a way to figure out which metadata set to look into.

I have a concrete idea on how to do this, but let's focus on the other allocator effort first.

[shwestrick]

Just curious—do you actually rely on contiguity? Or do you only need chunks to be aligned at say, a large power-of-two?

[adrieng]

There's an easy solution: stop populating the chunk pool and set its default size to, say, 1 TB.

[ramLlama]

I do actually rely on contiguity in addition to power-of-two alignment. If you look at these lines in chunk-pool.c, you'll see that metadata for a particular address is basically metadatas[((address & mask) - start) / pagesize].

Also, Adrien's solution, while totally LOL-worthy, would actually work. The chunk pool would simply not support shrinking. This isn't okay for a general purpose compiler, but for the kind of programs we run (i.e. benchmarks, not useful things), this is fine.

[shwestrick]

My new chunk allocator (a part of 7383b55) fixes this issue, although there is still the separate issue of needing to specify the size of the global heap ahead of time.