I currently don't plan to pursue this, so I'm closing the issue.

Let's do that :-)

I see. It still seems fragile though, and will behave weirdly if other parts of
the code start using the extra padding. For example, if some code requests
padding before the CEGAR heuristics are constructed and the CEGAR heuristic is
configured to use no padding, it will still release the padding requested by
someone else, which I don't think it should interfere with. I think the feature
should be redesigned.

I realize your suggestion was to take the feature out altogether, so you might
not be all that interested in working on making it more featureful. :-) Perhaps
we can discuss offline how to proceed.

No, because the abstractions are built one after the other (just checked this 
:-)).

I had a brief look. Would having two CEGAR heuristics with default settings
crash the planner (in debug mode) because it would attempt to allocate extra
memory twice, which is asserted against?

I made a pull request at
https://bitbucket.org/jendrikseipp/downward/pull-requests/93 .

OK. The feature is currently always used. I'll make it configurable.

Internal memory limits, just like internal time limits, are often important for
performance. Is there a fundamental difference between this feature and, for
example, the time limit within iPDB?

I think we should not be too much focused on the specific time and memory limits
we typically use in experiments. Other people might want to set a higher/lower
time/memory limit, and then limiting time/memory for specific computations might
become more relevant.

To make experiments more reproducible, it's sufficient not to use this
functionality. It doesn't have to be removed from the code.

We currently reserve some extra memory before building Cartesian abstractions. 
If we run out of memory, we release the extra memory and continue with the 
search. This makes planner runs non-deterministic since they depend on the 
memory layout. Also, this feature is becoming less relevant now that we're 
starting to use a 3.5 GiB instead of a 2 GiB memory limit. Therefore, I'd like 
to remove this functionality and abort when running out of memory.

The CEGAR code is currently the only user of this memory-padding functionality 
(in utils/memory.h). The question is whether we should remove the corresponding 
functions. I'd be in favor of doing so, because of YAGNI and to advocate for 
reproducible experiments. If you need the functionality in an unmerged branch, 
please speak up.