Re: [PATCH 2/2] Free multidicts from blockvector

Tom Tromey
2025-10-24T18:05:36Z

Simon> I guess that this restriction of "objects allocated on obstack must be
Simon> trivially destructible" is a bit artificial and arbitrary? It is
Simon> technically fine to allocate on obstack an object having a destructor,
Simon> as long as you ensure the destructor is called at some point. I guess
Simon> the restriction was put because it's easy to forget and error prone.

I think the specific difference from ordinary 'new' is that valgrind
will detect a new-based memory leak, but not an obstack-based leak. So,
in the heap case, the leak will also point out that the destructor isn't
being run; whereas in the obstack case it could go completely unnoticed.

Simon> - There is a ton of blocks created, so it's nice to be able to free
Simon> their memory in O(1). Unfortunately, having to free
Simon> block::m_multidict means that part is O(n), but the less we have to
Simon> do in O(n) the better I guess?

We could also track the ownership of the dictionaries separately,
e.g. with unordered_set<mdict_unique_ptr> or similar. This would reduce
the cost if it matters.

Tom