freenode/#sbcl - IRC Chatlog
Search
18:23:56
dougk_
trying to look at the PPC64 requirements, just discovered the most insanely horrible restriction: Load/Store of 8-byte values don't accept an immediate displacement that is other than a multiple of 4. Basically kills subtracting lowtag "for free".
18:31:57
dougk_
it's always going to cost us an instruction to load index to register. load/store of size 1,2,4 byte allow any displacement. 8 byte explicitly robs the low 2 bits of your displacement, and moreover, assumes they're 0.
18:56:21
jmercouris
it seems to be stuck at: SB-CONCURRENCY-TEST::MAILBOX.SINGLE-PRODUCER-MULTIPLE-CONSUMERS
19:01:55
jmercouris
I find that really surprising, because I had done C-c earlier, and it was not a good time
19:19:03
jmercouris
stassats: I'm sorry to distract you, but this question has been bothering me for over a year, what exactly is your github profile image?
19:21:18
stassats
i like chemistry, it's colorful and easily identifiable, scales to small sizes well
19:43:00
stassats
ok, single core, MAILBOX.SINGLE-PRODUCER-MULTIPLE-CONSUMERS has no trouble on freebsd 10
19:48:26
jmercouris
if you like, I can spin up another instance and leave it running for a day or so
19:52:24
joshe
I just do the occasional low-level portability fix now and then, but don't have regular access to the other BSDs
19:57:18
stassats
and i'm running openbsd 5.6, but i don't feel like sb-concurrency tests should be lowered
19:57:48
joshe
iirc the right thing to do is find a working interface to query for scheduler granularity and adapt the tests to that, rather than assume the kernel is build with HZ=1000
22:03:41
stylewarning
I haven't reduced to a test case, but I'm getting a case where adding (sb-ext:gc :full t) saves me from a heap exhaustion. Without it, I get thrown into ldb. Any thoughts on this kind of error situation?
22:35:41
stylewarning
If I set (generation-number-of-gcs-before-promotion 0) to 5, the bug isn't triggered.
1:44:51
slyrus_
stylewarning, have you tried with the actual latest SBCL? There have been a number of gc fixes since 1.4.7 was released.
1:45:08
stassats`
stylewarning: it's the usual gc stuff, you don't have enough memory for the amount of garbage you're discarding at once
1:46:19
stylewarning
stassats: is there some scaling law associated with amount of garbage and memory required?
1:46:31
stassats`
slyrus_: it could always do "emergency best effort mark and sweep" but then stylewarning will ask "why is the gc slow each 7 iterations"
1:49:54
stylewarning
I think so yeah. As it stands, it’s entirely unpredictable when this kind of thing will happen.
1:53:55
stylewarning
What is that supposed to mean? These functions are provably within limits with a huge margin.
1:55:19
stassats`
a single call to F produces 1GB of garbage, just two of the hash-tables alive at the same time are not enough for 4GB
1:56:33
stylewarning
I sent mail to the list and did away with these complicated hash tables and did bulk allocation of a vector instead