On Mon, 5 Mar 2012, Evgeny Voevodin wrote:
> > As I understand, your approach removes linking back to the previous allocated > chunk to avoid usage of already allocated and used memory again. Also you > added g_free() to tcg_pool_reset(). Wouldn't it slow down emulation? No, it would not. I added g_free() for large memory chunks only. Emulation runs which use only small allocations are unaffected. If an emulation run uses a large memory allocation - well, it was broken before. So there is nothing to compare speed to in this case. > Maybe such linkage to previous chunk was made with assumption that big > allocations will not happen twice one after another? For example, while > loading kernel on realview and exynos, the code never reaches this string in > tcg_malloc_internal(): > > p->next = s->pool_current; > The corresponding code had not changed since 2008. And, probably, never worked. It would be hard to know now what the author wanted from this code back then. > If this assumption is correct, maybe it's better to just insert a verification > that allocated chunk has enough space to hold requested block? > > + if (s->pool_cur - p->data + size > p->size) { > + goto new_pool; > + } > > s->pool_current = p; > s->pool_cur = p->data + size; > s->pool_end = p->data + p->size; > return p->data; > First, this verification does not solve problem of circular links in the list. Second, it does not solve problem of unbound increase of memory consumption. I probably should clarify that I found this issue when I was writing an unrelated modification to the register allocator which required large memory allocations. Current code in TCG probably never does such allocations and does not trigger memory corruption. -- Kirill Batuzov