gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Memory management in 2.6.9


From: Bruce-Robert Fenn Pocock
Subject: Re: [Gcl-devel] Memory management in 2.6.9
Date: Fri, 12 Jul 2013 12:28:58 -0400

Not an expert by any means, but I believe the brk overcommitment behaviour is a (compile or runtime) option on Linux, as well …

On Jul 12, 2013 12:24 PM, "Camm Maguire" <address@hidden> wrote:
Greetings!  Largely to accommodate acl2's growing appetite, I've put in
some memory management enhancements in 2.6.9.  Among these is a dynamic
maxpage -- no longer a compile time constant, the executable will try to
manage memory according to the amount available at runtime.

This of course does not pertain to Windows or Mac, where sbrk is
emulated.  (Don't really think sbrk needs mac emulation, but that will
have to wait.)

I've run into a few issues with this across the available unix like
systems, no surprise.  There does not appear to be a generic reliable
way to determine the available memory in advance without waiting for a
failure in the middle of some calculation.  The first attempt is using
brk, which is nice as it does not actually add pages to the process
until the memory is written.  Some systems, notably kfreebsd and perhaps
hurd, return success for brk calls beyond the physical memory of the
system.  Next I tried supplementing with sysconf (_SC_PHYS_PAGES).  This
actually returns -1 an ia64, which appears permissible from the
manpage.  On the bsd's it appears to work OK.

Suggestions?

Take care,
--
Camm Maguire                                        address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah

_______________________________________________
Gcl-devel mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gcl-devel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]