* Spare memory
@ 2012-06-13 19:14 BT Templeton
2012-06-13 23:12 ` Stefan Monnier
0 siblings, 1 reply; 3+ messages in thread
From: BT Templeton @ 2012-06-13 19:14 UTC (permalink / raw
To: emacs-devel
The `refill_memory_reserve' function (in alloc.c) is a no-op if
SYSTEM_MALLOC is defined, so the spare memory is never actually
allocated. Is this intentional?
Also, why doesn't `memory_full' collect garbage immediately when memory
is exhausted? (Currently it sets `memory_full_cons_threshold', which is
checked in `Feval' and `Ffuncall'.)
--
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Spare memory
2012-06-13 19:14 Spare memory BT Templeton
@ 2012-06-13 23:12 ` Stefan Monnier
2012-06-14 6:46 ` Andreas Schwab
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Monnier @ 2012-06-13 23:12 UTC (permalink / raw
To: BT Templeton; +Cc: emacs-devel
> The `refill_memory_reserve' function (in alloc.c) is a no-op if
> SYSTEM_MALLOC is defined, so the spare memory is never actually
> allocated. Is this intentional?
I do not really understand enough about the way we try to handle
out-of-memory situations to be able to answer.
> Also, why doesn't `memory_full' collect garbage immediately when memory
> is exhausted? (Currently it sets `memory_full_cons_threshold', which is
> checked in `Feval' and `Ffuncall'.)
But I can answer this one: the GC can only be called at a few safe
points, so calling it from memory_full might be unsafe. With the
conservative stack scanning, we can probably safely run the GC in many
more cases, but when using the GCPROs, the only safe spots are when
`eval' can be called.
Stefan
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Spare memory
2012-06-13 23:12 ` Stefan Monnier
@ 2012-06-14 6:46 ` Andreas Schwab
0 siblings, 0 replies; 3+ messages in thread
From: Andreas Schwab @ 2012-06-14 6:46 UTC (permalink / raw
To: Stefan Monnier; +Cc: BT Templeton, emacs-devel
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> But I can answer this one: the GC can only be called at a few safe
> points, so calling it from memory_full might be unsafe. With the
> conservative stack scanning, we can probably safely run the GC in many
> more cases, but when using the GCPROs, the only safe spots are when
> `eval' can be called.
Even without GCPRO it may be unsafe, since GC can compact strings.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-06-14 6:46 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-06-13 19:14 Spare memory BT Templeton
2012-06-13 23:12 ` Stefan Monnier
2012-06-14 6:46 ` Andreas Schwab
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.