Re: GC and stack marking

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

> It's not a bug in GC.  The memory management scheme that Fabrice wrote
> does not dump the heap (because doing that is problematic on Windows,
> and requires addition of a separate section to the executable, which
> then precludes its stripping, and has also other complexities).
> Instead, temacs uses a private fixed-address heap that is located in a
> static array, and whose memory is allocated by a replacement malloc
> function.  So any address that points to memory allocated not in that
> array, but in the real heap provided by malloc from libc, cannot be
> safely dumped, because in the dumped Emacs it will point to some
> random location.

OK, so why is the hash table allocated elsewhere then the other objects
(I understand why one might want to do that, but the question is about
what is different in the code in the case of this purify-flag hash-table
compared to other vectors/hashtables allocated during the dump).

Is it just based on size?  I.e. would the same problem show up if some
large vector were to be allocated (and not freed) before dumping?


        Stefan