|
From: | Raymond Toy |
Subject: | [Gcl-devel] Re: Building gcl from cvs? |
Date: | Fri, 11 Jan 2008 21:10:32 -0500 |
User-agent: | Thunderbird 2.0.0.9 (Macintosh/20071031) |
Camm Maguire wrote:
This is no longer necessary given the absense of addresses output. we could put in a little code to check the /proc filesystem, which is what I assume pmap does, but there is another fly in the ointment.
I think the /proc filesystem is binary. Might be easier to parse the output of pmap.
Ironically, this memory layout is the "best" in many respects, but our current logic was adapted to the traditional *very* difficult shared mem location on x86 Linux at 0x40000000, right in the middle. Here, this address is not fixed, and indeed will change as the stack is enlarged, via ulimit or even GCL itself via setrlimit. Plus, given that cvs can load new shared libs on the fly, the floor of this space can decrease at runtime (presumably). So what is the best way to ensure that the shared libs remain above a certain address (for the imm fix table)? It is possible that the logic in GCL would allow overlap of the immfix table with the shared lib space, but definitely not the C stack space -- the latter can of course be adjusted -- but I have not verified this yet.
I think the easiest way would be to just mmap the entire fixnum space. Then the OS won't put stuff there. I guess if the stack is so large that it overlaps the fixnum space, you lose. But no shared libs will ever bother you.
Perhaps this won't work. I don't know how gcl allocates space.
We could of course just abandon automatic configuration here and provide configure switches for the expert user to control things.
That probably would work, if you gave some reasonable defaults. After all, that's what cmucl does. The spaces are at fixed addresses.
Ray
[Prev in Thread] | Current Thread | [Next in Thread] |