> On Wed, 20 Nov 2019, Jan Hubicka wrote: > > > Hi, > > I have noticed that for Firefox around 1GB of peak memory use goes into > > the fact that we never free memory_block_pool::freelist. > > > > This patch adds memory_block_pool::trim which reduces freelist to a given > > size. It is called from ggc_collect which is a convenient place to return > > heap allocations too and fully freeed prior forking in ggc_collect. > > > > I originaly was freeing block directly in memory_block_pool::release > > but that makes it non-leaf function which prevents optimization. > > So I decided to go this way we get tiny bit better code > > given that we already have ggc_collect that is conveninet place > > to do such a bookeeping. > > > > Bootstrapped/regtested x86_64-linux, tested on Firefox build, OK? > > Huh, I think given that trimming happens explicitely the whole > overhead of counting the number of freelist entries plus adding > a prev member to the block list is useless overhead. In trim > just do > > block_list **tailp = &m_blocks; > for (unsigned cnt = freelist_size; cnt != 0 && *tailp; --cnt) > tailp = &(*tailp)->next; > while (*tailp) > free blocks starting from here > > the list walk is O(constant) and the above would just mean adding > a single method rather than cahnges all over the place.
Hmm, you are right - I changed the code bit way too many times and lost track :)) Will implement your suggestion. Honza
