freenode/#sbcl - IRC Chatlog
Search
18:00:58
fortitude
is alloc_overflow_ecx related to an out-of-memory condition, or is it part of the normal allocation flow?
18:03:53
nyef``
IIRC, it's normal flow for when the current allocation region is insufficient to handle the allocation, and so either a "large object" needs to be allocated or a new allocation region needs to be set up.
18:04:03
fortitude
I'm getting out of my depth here, but does the safepoint mechanism rely on threads being in an alertable wait state on windows?
18:04:46
stassats
fortitude: nobody knows what safepoints rely on windows, that's why they're broken
18:05:22
nyef``
ACTION has reasons for using 32-bit SBCL. They are HPPA, SPARC, PPC, MIPS, MIPS again, MIPS yet again...
18:05:57
fortitude
aside from more memory space and a larger register set, does 64-bit sbcl differ significantly from 32-bit?
18:09:22
fortitude
stassats: I know that's a non-trivial thing to have, but does it make a big difference architecturally (and not just perf-wise)?
18:12:50
nyef``
It's not alone in not having threads. And I have long had a theory about how to scare up that one extra register for the TLS block, but have never sat down to actually try it out.
18:14:58
nyef``
I actually don't have a working Linux ARM system anymore. Which is annoying, because my former Linux ARM system was set up as power control for my Linux PPC system.
18:51:02
fortitude
what is thread_in_lisp_raised used for? seems to be called by an exception handler, but I can't find where
18:55:34
nyef``
Two hits in interrupt.c, one in win32-os.c, one in thread.h, and a pile in safepoint.c, btw.
18:56:25
fortitude
nyef``: I've found the function, but the call stacks says the immediate parent is handle_exception, which doesn't look like any of those