unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).