[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GC and stack marking
From: |
Eli Zaretskii |
Subject: |
Re: GC and stack marking |
Date: |
Wed, 21 May 2014 05:51:45 +0300 |
> From: Stefan Monnier <address@hidden>
> Cc: Daniel Colascione <address@hidden>, address@hidden, address@hidden
> 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.
- Re: GC and stack marking, (continued)
- Re: GC and stack marking, Eli Zaretskii, 2014/05/21
- Re: GC and stack marking, Eli Zaretskii, 2014/05/21
- Re: GC and stack marking, Stefan Monnier, 2014/05/21
- Re: GC and stack marking, Eli Zaretskii, 2014/05/21
- Re: GC and stack marking, Eli Zaretskii, 2014/05/22
- Re: GC and stack marking, Stefan Monnier, 2014/05/22
- Re: GC and stack marking, Eli Zaretskii, 2014/05/24
- Re: GC and stack marking, Daniel Colascione, 2014/05/20
- Re: GC and stack marking, Eli Zaretskii, 2014/05/20
- Re: GC and stack marking, Stefan Monnier, 2014/05/20
- Re: GC and stack marking,
Eli Zaretskii <=
Re: GC and stack marking, Florian Weimer, 2014/05/31
Re: GC and stack marking, Barry OReilly, 2014/05/21
- Re: GC and stack marking, Eli Zaretskii, 2014/05/21
- Re: GC and stack marking, Barry OReilly, 2014/05/21
- Re: GC and stack marking, Eli Zaretskii, 2014/05/21
- Re: GC and stack marking, Daniel Colascione, 2014/05/21
- Re: GC and stack marking, David Kastrup, 2014/05/22
- Re: GC and stack marking, Stefan Monnier, 2014/05/22
- Re: GC and stack marking, Eli Zaretskii, 2014/05/22