gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] GCL, >2Gb memory, and si::*code-block-reserve*


From: Camm Maguire
Subject: [Gcl-devel] GCL, >2Gb memory, and si::*code-block-reserve*
Date: Fri, 20 Nov 2015 11:07:07 -0500

Greetings!  This is just a note to memorialize the current situation of
handling more than 2Gb on x86_64  in GCL.

gcc by default generates code which assumes all symbols lie within the
same 2Gb area, with certain explicit big data arrays excepted.  clang
does as well.  gcc, unlike clang, provides the -mcmodel option, which
can be set to small, medium, or large, defaulting to medium.  Small
removes the support for big data array symbols, while large drops the
2Gb assumption entirely.  Small is about 10% faster than large on
typical jobs.

Essentially no one needs more than 2Gb of actual code, but gcl loads
code dynamically along with other data objects, and unless controlled,
the code layout can be sparse.  

The GCL linker does attempt to put in a veneer to rewrite short to long
jumps on some machines, but the x86_64 situation cannot be handled this
way, as data addresses (as apart from function calls) are involved as
well.  

2.6.13 will default to mcmodel small when using gcc.  This means code
loaded over the 2Gb threshold will fail (gracefully).  I might try to
put in an automatic detection of this situation, modifying
compiler::*cc* to mcmodel large when the heap gets too big, but this
will not work with clang (mac), and until recently, mcmodel large was
buggy in gcc (though it seems OK now.)

Therefore 2.6.13 provides si::*code-block-reserve*, which is an optional
big string allocated *statically* for preferential use in code loading
until full.  This is sub-optimal, as it represents an exception to the
grow-as-needed memory management model, but I don't see a way around
this at present.  The ACL2 regression suite runs well with a 40 or 50M
code-block-reserve buffer, for example, but the ultimate size alas
depends on the intended use.  If desired, users can allocate this buffer
at any time the heap + buffer size is less than 2Gb.  When saved into a
new executable, the unused buffer will be available silently as needed.

In 2.6.13pre, a more aggressive attempt to make use of all available
memory is implemented, so the 2Gb threshold can be reached in practical
situations.  The GCL allocation algorithm is controllable with certain
environment variables at runtime.  Currently these are:

GCL_MEM_MULTIPLE (default 1.0) -- use this fraction of available memory
GCL_GC_ALLOC_MIN (default 0.05)
GCL_GCL_PAGE_MIN (default 0.5)
GCL_GCL_PAGE_MAX (default 0.75)

memory=mem_multiple*physical_memory
do_gc? == heap>page_min*memory && 
recent_allocation>1.0+alloc_min-min(heap,page_max*memory)/(page_max*memory)

Thoughts most appreciated.

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



reply via email to

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