[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] "Enterprise" GCL
From: |
Camm Maguire |
Subject: |
[Gcl-devel] "Enterprise" GCL |
Date: |
19 May 2005 23:25:59 -0400 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 |
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