[Gcl-devel] "Enterprise" GCL

[Camm Maguire]

Greetings!  We've been talking about extending GCL's sbrk past the
mmap base address at which shared libs begin to be loaded, 0x40000000
on 32bit Linux.   There appear to be about 3 solutions.  All
information relative to running big oracle/db2/... jobs on Linux is
relevant here (web search should turn up many.)

1) There is a "mapped_base" kernel patch (also found in the WOLK
   patches, see sourceforge) which provides a /proc/self/mapped_base
   pseudo file into which setuid programs can write the start address
   for shared libs, then exec itself as a child to see the new
   results.  We'd like to set somewhere around 0xb0000000, giving up
   to 2.7Gb contiguous brk memory area on 32bit Linux.  The .text
   address start can also be lowered from its default of 0x8000000 via
   a switch to ld at GCL compile time, but this savings appears meager
   by comparison.

2) Recent redhat kernels appear to have mmap allocations (e.g. malloc,
   shared libs, etc.) grown down from the stack by default, leaving
   the brk space growing up from .data end and the mmap space
   undivided.  I think they map executable mmaps below the .text
   section, but this should not be relevant for us unless they forbid
   making sbrk pages executable too.  I haven't isolated this patch
   yet.  Do a search in redhat's bugzilla under "mapped_base" for
   details. 

3) prelink can apparently set load addresses into the shared library
   files themselves.  Haven't played with it yet, but the way to
   proceed is to copy the GCL-used system shared libs into a local
   directory, set the LD_LIBRARY_PATH environment variable
   accordingly, and prelink the raw gcl image (e.g. unixport/raw_gcl,
   must be made explicitly with 'make raw_gcl' in unixport/), the
   effects of which should be preserved in the saved image (i.e. 'make
   saved_gcl', untested).  There is a known issue I haven't tracked
   down yet in prelinking GCL's unexeced saved images directly, but
   which should not be difficult to fix.  This option is likely the
   most desirable if it works, as it is portable across Linux
   distributions and does not require kernel modifications.

As these facilities all take place out of GCL proper, I'm wondering if
any of you might have time to see which might be feasible.  If any, we
could put the necessary steps into GCL's automated configure and
compile process, much like the redhat randomized sbrk workaround added
recently. 

Take care,


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