00:02:32 ... let me guess. The bulk of the "Western hegemony" is sufficiently far east of me as to have gone to bed already? 00:04:17 ..some eastern takeover guys are not yet in bed, but they've seen an HPPA once or twice in their life :) 00:04:58 It's got to be, what, 3am there, give or take? 00:05:08 4am+ 00:05:48 Night owl, aren't you? 00:06:07 sometimes night and sometimes random. 00:07:01 *akovalenko* imagined a Random Owl, and that's impressive. 00:15:44 So, 1.0.23.33 is when MIPS got stack-allocatable-vectors, before the feature itself was named. 00:15:57 And it doesn't do ANYTHING to protect against the failure case. 00:16:21 what it is? too big vectors or "too liberal" stack scavenging for boxed ones? 00:16:47 The failure case is storing unboxed data in a boxed-data area (the control stack). 00:17:27 There are two failure modes, both to do with the way frame-allocation can leave uninitialized "holes" in the control stack. 00:19:19 In 1.0.38.4, I fixed a gencgc bug wherein PPC systems weren't scrubbing the control stack, leading to bogus data appearing in these "holes". 00:20:49 that's (not c-stack-is-control-stack), right? otherwise I can't imagine a system that could *guarantee* any positive result of stack scrubbing.. 00:21:08 Yeah, that's for a precise GC on the stack. 00:21:48 But cheneygc as well as non-x86oid gencgc both do the precise stack scavenge. 00:22:00 And unboxed arrays lead to possible badness here. 00:22:11 Actually, any stray header could, now that I think of it. 00:22:28 could we have one more stack for those? actually, reusing alien stack is a possibility here.. 00:22:55 well, the problem of "mixed" structures can't be solved this way.. 00:23:00 For unboxed arrays? We SHOULD be stashing them on the number stack, which is unboxed storage. 00:23:31 The only "mixed" case that we need to worry about is actually defstructs with raw slots, and I have a patch for that on my work machine. 00:23:45 (Essentially, if there are raw slots, a structure is unsuited for d-x.) 00:24:50 Yup! A stray boxed-object header on the control stack can cause a GC assertion failure in scavenge. 00:24:57 Ah, that's it. I was thinking along the lines of "let it look at object headers", disregarding the crucial possibility of just giving up :) 00:27:51 I may even be able to trigger one of these failure modes reliably on non-x86oids. 00:28:41 unscrub_control_stack could be useful here. 00:29:11 Heh. 00:29:56 I'm actually thinking of adding another "mode" to scavenge, where it knows it's working on a control stack, and just ignores object headers instead of looking them up in scavtab. 00:31:19 That would eliminate the failure mode wherein a dead object with a header in a "hole" slot can cause scavenge to run off the end of the stack or to ignore a number of stack slots. 00:31:35 But would make the case of an unboxed array causing untold damage far more likely. 00:32:06 From there, add the machinery to put unboxed d-x arrays on the number stack instead of the control stack. 00:32:37 After that, everything should be more-or-less good. 00:34:17 btw, are there bad sides in (not c-stack-is-control-stack) at all? on Windows, I frequently wish it were so: OS is too intimate with "real control stacks" there in many aspects.. 00:34:47 At the very least, you burn a register on a stack pointer, and possibly a frame pointer. 00:35:18 I'm giving semi-serious thought to setting up an x86-64 port with separate control stack and a partitioned register set. 00:36:43 I don't think we'll ever be able to properly disentwingle the two on x86, though. 00:37:09 And I'm about out of time for tonight. Do we need to discuss anything else before I disappear? 00:38:32 Good night :) I'm usually invent something weird in the "evening" and sort out worthy ideas the next day, so while I'm surely able to discuss something more, the usefulness of it all would be questionable at best. 00:38:40 s/I'm/I 00:39:14 Fair enough. Sleep well, whenever it is you do get to sleep. (-: 00:39:17 -!- nyef [~nyef@64.134.124.204] has quit [Quit: g'night all.] 01:51:05 -!- redline6561_nop is now known as redline6561 02:35:49 -!- akovalenko [~anton@95.73.122.127] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 02:41:59 akovalenko [~anton@95.73.122.127] has joined #sbcl 02:54:15 -!- redline6561 is now known as redline6561_nop 02:57:52 -!- akovalenko [~anton@95.73.122.127] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 03:32:57 akovalenko [~anton@95.73.122.127] has joined #sbcl 03:59:09 akovalenko: you want weird and probably useless? I'm drafting plans for a completely fresh middle-end that can punt the rest to LLVM. 03:59:42 *akovalenko* is enthusiastic, just as expected :) 04:00:27 I'm not... yet. Have to write things for my quals, and I don't get enthusiastic until there's demo code ;) 04:44:29 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 244 seconds] 04:49:34 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 05:10:36 -!- antgreen [~user@bas3-toronto06-2925098629.dsl.bell.ca] has quit [Ping timeout: 255 seconds] 06:31:54 sdemarre [~serge@91.176.28.90] has joined #sbcl 06:59:20 -!- daimrod [~daimrod@sbrk.org] has quit [Quit: leaving] 06:59:34 daimrod [~daimrod@sbrk.org] has joined #sbcl 07:23:02 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 07:29:32 good morning everyone 08:13:03 -!- loke [~elias@bb115-66-85-121.singnet.com.sg] has quit [Ping timeout: 256 seconds] 08:26:15 loke [~elias@bb115-66-85-121.singnet.com.sg] has joined #sbcl 10:01:10 attila_lendvai [~attila_le@95.56.172.20] has joined #sbcl 10:01:10 -!- attila_lendvai [~attila_le@95.56.172.20] has quit [Changing host] 10:01:10 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:02:48 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has left #sbcl 10:05:09 hlavaty [~user@91-65-217-112-dynip.superkabel.de] has joined #sbcl 10:22:09 akovalen` [~anton@95.72.96.201] has joined #sbcl 10:23:36 -!- akovalenko [~anton@95.73.122.127] has quit [Ping timeout: 240 seconds] 10:28:22 -!- akovalen` is now known as akovalenko 10:33:04 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Read error: Operation timed out] 10:39:56 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 10:54:00 nikodemus_pad [~nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 10:59:06 -!- sdemarre [~serge@91.176.28.90] has left #sbcl 11:05:41 -!- nikodemus_pad [~nikodemus@cs181063174.pp.htv.fi] has quit [Quit: Colloquy for iPad - http://colloquy.mobi] 13:06:37 nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has joined #sbcl 13:37:45 sdemarre [~serge@91.176.28.90] has joined #sbcl 13:40:45 -!- redline6561_nop is now known as redline6561 13:51:16 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 13:51:16 -!- ChanServ has set mode +o nikodemus 13:53:04 Hello nikodemus. 13:54:24 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Read error: Connection reset by peer] 13:54:58 Good-bye nikodemus. 13:59:57 lol 14:11:12 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 14:11:12 -!- ChanServ has set mode +o nikodemus 14:11:23 Hello nikodemus. 14:11:37 hi 14:12:13 *nikodemus* checks logs to see how much i was talking to no-one at all, really 14:12:30 quite a bit :) 14:12:41 recap follows 14:12:47 Yeah, you disappeared without saying anything. 14:13:16 i have a new locking scheme, now i just need to find pkhuong to tell me it's old news and known to suck or not :) 14:13:24 Ahh. 14:14:06 I spent some time over yesterday evening and this morning trying to figure out how to make stack-allocated objects not suck on non-conservative gc targets. 14:15:22 the idea is to have an unfair CAS lock (like our current spinlocks), with an additional waitcount/ticket/whatever used to keep track of the number of threads waiting for it. waiters in turn use that count/ticket to decide on their wait strategy: spin or sleep, how long to sleep, etc. possibly couple that with a /global/ idle counter to ramp up sleeps globally when there are oodles of idle threads to make sure the non-idle ones can get work done 14:16:02 so, not really fair, but it would /tend/ to be fair, as threads arriving sooner are going to have tighter wait-loops 14:16:21 /global/ idle counter sounds scary (FSB saturation and all that) 14:18:02 homie [~levgue@xdsl-78-35-155-218.netcologne.de] has joined #sbcl 14:18:44 akovalenko: I think the point is that it shouldn't get hit much when nothing is idling, and the value rises when there's lots of idling, so the delay due to longer sleeps somewhat counteracts the repeated access, so the access frequency doesn't get too far out of hand? 14:19:41 it could also be updated conservatively: eg. increment idle count only after you've slept at least 1 second waiting for an event 14:20:46 "everything is idle in _SBCL_" tells nothing about other processes. Well, one update per second won't be noticeable, of course-. 14:20:51 *per second per thread 14:28:39 *akovalenko* looked at comp.programming.threads, and it seems to be as good and useful as back then (too easy to take and reuse patented stuff from there, though; be careful) 16:00:08 what's the use case? 16:01:10 unfair spinlocks seem like a good default. If you really want fairness, queue locks work better with our need for cancellation, no? 16:12:17 -!- akovalenko [~anton@95.72.96.201] has quit [Remote host closed the connection] 16:15:40 pkhuong: i'm looking at backoff strategies right now 16:18:38 vaguely looking at a new front-end and a more runtime-compilation-oriented strategy. 16:18:40 akovalenko [~anton@95.72.96.201] has joined #sbcl 16:28:23 front-end? as in source-to-ir2 stage? 16:29:18 yup. 16:29:21 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 16:31:37 antgreen [~user@bas3-toronto06-2925099342.dsl.bell.ca] has joined #sbcl 16:32:18 *nyef* is looking at PPC storage allocation. 16:32:19 there's some recent (last ~5 years) work on composing abstract interpreters, and I think that's what we want. 16:33:24 our constraint prop + type stuff is a poor man's abstract interpretation, but the way it's structured puts a lot of pressure on the internal type system. 16:34:13 we *need* to be able to represent convoluted types because otherwise useful information won't be transferred via cprop. 16:37:02 we can go with abstract interpretation and have a lattice+transfer function for basic type stuff, one for ranges, and another for EQLity, and transfer information between each much simpler lattice. 17:07:29 -!- hlavaty [~user@91-65-217-112-dynip.superkabel.de] has quit [Ping timeout: 258 seconds] 17:22:18 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 255 seconds] 17:24:24 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 18:06:19 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Ping timeout: 258 seconds] 18:11:33 -!- whoops [u549@gateway/web/irccloud.com/x-xjeulhfkgthmaijq] has quit [Remote host closed the connection] 18:21:04 prxq [~mommer@mnhm-4d011906.pool.mediaWays.net] has joined #sbcl 19:05:26 Fare [~Fare@74.125.59.116] has joined #sbcl 19:05:46 Hello Fare. 19:16:14 hi nyef 19:16:25 I'd like to revive the BLM, after a year or so 19:16:36 maybe rename it to go beyond Lisp 19:16:43 care to give a talk? 19:16:45 still in NH? 19:17:15 I can see South Station across the street outside the window to my left. 19:17:36 Well, part of it, at least. 19:18:20 Not sure what I'd talk about, though. 19:19:08 Beyond lisp, huh? It's not going to become the "Boston Dynamic Systems Meeting", is it? 19:29:00 montreal should probably do that. 19:32:34 MDSM? 19:34:32 Boston Programming Language Meeting ? 19:36:30 but BDSM is not bad 19:36:56 hahaha 19:44:41 nyef: more accurate than scheme/lisp user group, probably. 19:45:37 pkhuong: "SLUG"? 19:46:21 MSLUG, yup. 19:46:36 Ah. 19:46:38 Metal SLUG ? 19:47:06 montreal. 20:00:06 pkhuong: is ir2-block-%trampoline-label set for locall targets when fall-through jumps are eliminated and _not set for other things_? Looks like I have a simple fix for emarsden's (mod (mod ...)) thing, but I'd like to ensure I'm not killing fall-through jump elimination entirely :) 20:00:50 akovalenko: yeah it's a one-line fix to not allow fall through trampolines. 20:01:06 I'm just too busy to write the test case and commit. 20:10:45 whoops [u549@gateway/web/irccloud.com/x-qzoykgbwcuuhsliu] has joined #sbcl 20:10:53 ... Why does the PPC version of ALIGN-CSP go to the trouble of storing a zero into the alignment padding on the stack? 20:10:58 Just... why? 20:11:48 nyef: irrational fear of conservatives :-E 20:12:19 And then, after that, the dx allocation sequences use clrrwi to zap the (already zeroed, thanks to alignment) lowtag bits. 20:22:09 Okay, build with a number of PPC d-x changes now running. 20:22:38 I hope I got them right, or that they fail quickly. 20:33:35 frito [~user@cpc12-sotn9-2-0-cust535.15-1.cable.virginmedia.com] has joined #sbcl 20:35:25 -!- frito [~user@cpc12-sotn9-2-0-cust535.15-1.cable.virginmedia.com] has quit [Remote host closed the connection] 20:37:36 -!- ljos [~mozzyb@login1.uib.no] has quit [Ping timeout: 255 seconds] 20:40:03 ljos [~mozzyb@login1.uib.no] has joined #sbcl 20:43:27 frito [~user@cpc12-sotn9-2-0-cust535.15-1.cable.virginmedia.com] has joined #sbcl 20:44:10 -!- frito [~user@cpc12-sotn9-2-0-cust535.15-1.cable.virginmedia.com] has quit [Read error: Connection reset by peer] 20:44:34 frito [~user@cpc12-sotn9-2-0-cust535.15-1.cable.virginmedia.com] has joined #sbcl 20:44:53 akovalenko: not quite, unfortunately. 20:45:18 pkhuong: well, I'm ready to through it away when it's fixed upstream :) 20:46:01 akovalenko: it's currently going to transitively fall through blocks with trampolines 21:03:55 -!- homie [~levgue@xdsl-78-35-155-218.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 21:05:08 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [Quit: +++ killed by SIGSEGV +++] 21:05:12 -!- sdemarre [~serge@91.176.28.90] has quit [Ping timeout: 240 seconds] 21:15:12 -!- Fare [~Fare@74.125.59.116] has quit [Ping timeout: 240 seconds] 21:18:21 -!- frito [~user@cpc12-sotn9-2-0-cust535.15-1.cable.virginmedia.com] has quit [Remote host closed the connection] 21:18:38 frito [~user@cpc12-sotn9-2-0-cust535.15-1.cable.virginmedia.com] has joined #sbcl 21:20:19 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl 21:22:14 -!- frito [~user@cpc12-sotn9-2-0-cust535.15-1.cable.virginmedia.com] has quit [Remote host closed the connection] 22:13:20 -!- prxq [~mommer@mnhm-4d011906.pool.mediaWays.net] has quit [Quit: Leaving] 22:51:57 -!- nyef [~nyef@c-174-63-105-188.hsd1.ma.comcast.net] has quit [Quit: G'night all.]