[ replies to questions asked elsewhere ]
4 jan. 2024 kl. 18.32 skrev Dmitry Gutov <dmitry@gutov.dev>:
+hash_table_alloc_bytes (ptrdiff_t nbytes)
+{
+ if (nbytes == 0)
+ return NULL;
+ tally_consing (nbytes);
+ return xmalloc (nbytes);
+}
Sorry if it's a stupid question, but if the operation doesn't add any Lisp
"garbage", why increase the consing counter? That is likely triggers more GCs
earlier which otherwise might not run, and if there are no slots to GC, it seems like
they would run in vain.
That's a good question and it all comes down to how we interpret
`consing_until_gc`. Here we take the view that it should encompass all parts of
an allocation and this seems to be consistent with existing code.
These ancillary allocations are parts of the hash-table object: they are
allocated and freed at the same time as the mother object, and subject to the
same `consing_until_gc` accounting.
The new code is radically more efficient when growing tables, because we can
free the old vectors immediately (and adjust consing_until_gc accordingly)
instead of leaving it as garbage waiting to be collected. This provides several
benefits in itself (GCs are made less often, we can re-use hot memory). Not
having to traverse them in either the mark or sweep phases is another big gain
(the key_and_value parts still have to be marked, of course).