Re: Larger GC thresholds for non-interactive Emacs

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Obviously this process ends up with a very large one-step allocation
> which is arguably interesting in itself (I suspect there's some
> GC-inhibition going on there), but the more interesting point
> is that with p=0.1 we get an amount of free space after GC
> (i.e. blocks we can't release, because of fragmentation) that's about as
> large as the next threshold, i.e. about 10%, whereas with p=1.0 this
> amount of unreleasable free space is significantly higher.

As far as I know, we never actually release back cons space to the OS
anyway -- even if we could.  (Because glibc's malloc implementation
doesn't do that unless we call that trim function, which we don't.)  So
I'm not sure that makes much difference -- especially in a batch process.

> I think p=1.0 (and the corresponding implication that we use up about
> twice as much memory as the minimum we need) might be an acceptable
> tradeoff (for batch use), but I don't think I'd be comfortable going
> beyond that.

Right.  We can still have the Emacs makefiles increase the threshold for
build purposes even if we settle on a lower general level for --batch.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no