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 [email protected] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah _______________________________________________ Gcl-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gcl-devel
