gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: Building gcl from cvs?


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





reply via email to

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