Re: GC and stack marking

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Daniel Colascione <dancol@dancol.org>,  fabrice.popineau@gmail.com,  emacs-devel@gnu.org
> Date: Tue, 20 May 2014 18:03:51 -0400
> 
> > 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).

Because fixed-address heaps on Windows are limited to allocations
whose size is at most 0x7f000, and one of the vectors allocated for a
70K hash-table is larger than that.

> 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?

Yes.  And not just large vectors, any large object (e.g., string).
And that's what scared me, because I can always find a solution for
the case I know of, but how to make this reliable in the face of
future changes in Emacs?

Anyway, it looks like Fabrice found a way to work around the above
limitation, so I guess this issue is no longer such a big problem.