[Openmcl-devel] Slow Slime Startup with 1.9 dev OS X
alexander.repenning at Colorado.EDU
Thu Aug 23 22:49:33 CDT 2012
On Aug 23, 2012, at 7:44 PM, Gary Byers wrote:
> Matt opened a ticket for the problem that Wade reported a couple of weeks ago (and that he'd been seeing); see <http://trac.clozure.com/ccl/ticket/1005>.
> Matt was able to reproduce the problem and investigated; the short version is
> that a data structure that CCL allocates whenever a thread is first made known
> to lisp has to be in the low 32 bits of the address space and the way we'd
> historically tried to do that (calling #_malloc repeatedly until it returned
> a 32-bit pointer) could take an extremely long time. I don't think that we'd
> ever seen or heard of it doing so prior to 10.8, but I think that that was just
> due to luck (and good clean living ...). It's possible that 10.8 tries to do
> some sort of address space randomization (this is sometimes seen as a way of
> minimizing the damage after malicious could forces a buffer overflow) that previous
> OSX versions didn't, and that may explain why the problem seems to have just
> surfaced with 10.8. (It didn't: the "call #_malloc and cross your fingers"
> strategy has never been a viable one.)
> This was fixed in r15437 (but I was nervous about some thread-safety issues
> and tried to deal with them better in r15439.) Both of those changes were
> just made to the trunk; they haven't yet been propagated to the 1.8 tree but
> likely will fairly soon.
> This particular problem (trying to force a pointer to be allocated in
> the low 32 bits of the address space and doing so in bounded time)
> obviously only affects the 64-bit version of CCL.
Yikes, that does not explain our problem then. Did you see my other email with the test program? It appears to be able to crash CCL 64 and 32 bit versions on Mountain Lion.
Prof. Alexander Repenning
University of Colorado
Computer Science Department
Boulder, CO 80309-430
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel