Re: Dumper problems and a possible solutions

[Stefan Monnier <monnier@iro.umontreal.ca>]

> Thanks for the feedback. Can you elaborate on how/why the hash
> changes, and where it's stored that would need to be updated?

When placing an object in a hash-table, the hashing function often just
uses the address as "the hash value".  So any hash-table that uses such
a hash-function will need to be rehashed after relocation.

> As far as the relocation, my impression is that it would just need to
> be able to identify pointers in lisp objects (this is already possible
> since the GC needs to do it, right?), and rewrite them to
> (essentially) "static_lisp_heap + offset_of_pointed_to_object" when
> writing the dump out as a C array.

Yes, the GC already knows how to find the references that are inside
Lisp objects, but there can also be references coming from global
variables (for sure) or non-Lisp data-structures or maybe from the stack
(not sure about those last two).

> This is the xemacs "portable dumper" approach, and I believe it's
> inferrior because it depends on being able to map back at the same
> location.

We could support relocation at mmap-time to solve this.
Neither solution is clearly superior to the other, it just depends on
you priority.  For me, either way would be an improvement over what we
have (tho, again, it might still depend on the constraints imposed by
the need to perform relocation).


        Stefan