00:06:23 -!- segv- [~mb@95-91-241-10-dynip.superkabel.de] has quit [Ping timeout: 245 seconds] 00:30:43 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 00:34:35 -!- kwmiebach [~kwmiebach@xdsl-213-196-192-206.netcologne.de] has quit [Ping timeout: 245 seconds] 00:40:03 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 240 seconds] 00:44:33 -!- hlavaty [~user@friedrichstrasse.knowledgetools.de] has quit [Ping timeout: 252 seconds] 00:53:19 -!- Bike [~Glossina@wl-nat101.it.wsu.edu] has quit [Ping timeout: 272 seconds] 00:53:47 kwmiebach [~kwmiebach@xdsl-195-14-198-183.netcologne.de] has joined #sbcl 00:56:15 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Ping timeout: 245 seconds] 00:56:44 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 240 seconds] 01:04:31 Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has joined #sbcl 01:10:49 drmeist__ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 01:13:04 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 264 seconds] 01:20:50 -!- danlentz [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has quit [Ping timeout: 272 seconds] 01:43:33 eudoxia [~eudoxia@r186-54-250-225.dialup.adsl.anteldata.net.uy] has joined #sbcl 01:46:26 echo-area [~user@182.92.247.2] has joined #sbcl 02:10:27 -!- drmeist__ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 02:11:06 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 02:13:44 ASau` [~user@p54AFED13.dip0.t-ipconnect.de] has joined #sbcl 02:15:01 drmeist__ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 02:15:55 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 02:17:27 -!- ASau [~user@p54AFEF5F.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 02:19:35 -!- drmeist__ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 245 seconds] 02:20:41 -!- kwmiebach [~kwmiebach@xdsl-195-14-198-183.netcologne.de] has quit [Quit: Leaving] 02:23:05 ah, cl-bench... I'm pretty sure 1D-arrays reflects the performance of SEARCH of a list in a vector. 02:29:10 -!- eudoxia [~eudoxia@r186-54-250-225.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 02:30:33 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 02:52:35 ASau`` [~user@p5083D530.dip0.t-ipconnect.de] has joined #sbcl 02:56:05 -!- ASau` [~user@p54AFED13.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds] 03:33:03 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 03:33:29 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 03:38:31 -!- christoph_debian [~christoph@ppp-46-244-239-98.dynamic.mnet-online.de] has quit [Ping timeout: 246 seconds] 03:51:51 christoph_debian [~christoph@ppp-46-244-191-100.dynamic.mnet-online.de] has joined #sbcl 03:53:18 I pushed my new development branch at . I'll see about rebasing everything for a commit later this week. 03:54:39 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 03:54:46 There's been some changes to the greedy regalloc as well, mostly because I fixed logic bugs. 03:55:17 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 04:00:09 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 04:46:16 -!- oleo [~oleo@xdsl-78-35-156-132.netcologne.de] has quit [Read error: Operation timed out] 04:55:20 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 05:02:10 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 05:02:16 oleo [~oleo@xdsl-78-35-155-107.netcologne.de] has joined #sbcl 05:14:33 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 246 seconds] 05:14:43 -!- easiere [~user@213.33.70.157] has quit [Remote host closed the connection] 05:16:31 easiere [~user@213.33.70.157] has joined #sbcl 05:29:06 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving] 05:47:21 Notes on regalloc up at http://paste.lisp.org/display/140025#1 to #3. I'm still not sure if we want to commit that so late in the month. OTOH, if it were to break anything, it'd have done so already (famous last words). 05:54:54 -!- oleo [~oleo@xdsl-78-35-155-107.netcologne.de] has quit [Quit: Leaving] 05:55:15 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 05:56:32 drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 05:59:21 -!- scymtym [~user@2001:638:504:2093:baca:3aff:fe83:e736] has quit [Ping timeout: 245 seconds] 06:01:39 -!- drmeiste_ [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 06:08:44 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Read error: Connection reset by peer] 06:27:46 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 06:29:18 prxq [~mommer@x2f65790.dyn.telefonica.de] has joined #sbcl 06:35:05 sdemarre [~serge@157.106-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 06:57:17 drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 06:58:35 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Remote host closed the connection] 07:01:51 -!- drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 252 seconds] 07:11:24 -!- ASau`` is now known as ASau 07:22:28 -!- sdemarre [~serge@157.106-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 272 seconds] 07:58:04 drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 08:03:15 -!- drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 08:06:42 poglesbyg_ [~poglesbyg@uib-guest.uib.no] has joined #sbcl 08:10:40 -!- scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Ping timeout: 264 seconds] 08:43:17 scymtym [~user@2001:638:504:2093:baca:3aff:fe83:e736] has joined #sbcl 08:58:47 drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 09:03:01 -!- drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 248 seconds] 09:06:30 -!- poglesbyg_ [~poglesbyg@uib-guest.uib.no] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 09:16:51 poglesbyg_ [~poglesbyg@uib-guest.uib.no] has joined #sbcl 09:32:54 -!- poglesbyg_ [~poglesbyg@uib-guest.uib.no] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz] 09:46:05 pkhuong: I say commit it, and let's actually freeze, test, and find interesting benchmarks 09:46:16 aiming to freeze this evening or tomorrow morning 09:46:32 release Friday 29/Sunday 30 09:56:56 -!- echo-area [~user@182.92.247.2] has quit [Remote host closed the connection] 09:57:39 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 09:59:31 drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 10:04:19 -!- drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 10:08:02 yacks [~py@103.6.159.103] has joined #sbcl 10:32:11 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 272 seconds] 10:34:13 hlavaty [~user@friedrichstrasse.knowledgetools.de] has joined #sbcl 10:34:56 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 10:41:59 attila_lendvai [~attila_le@5.251.140.27] has joined #sbcl 10:41:59 -!- attila_lendvai [~attila_le@5.251.140.27] has quit [Changing host] 10:41:59 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 10:45:25 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 245 seconds] 10:54:21 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 272 seconds] 10:59:49 kludge` [~comet@unaffiliated/espiral] has joined #sbcl 11:00:15 poglesbyg_ [~poglesbyg@uib-guest.uib.no] has joined #sbcl 11:00:18 drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 11:03:00 easiere` [~user@213.33.70.157] has joined #sbcl 11:03:03 -!- poglesbyg_ [~poglesbyg@uib-guest.uib.no] has quit [Client Quit] 11:04:33 -!- easiere [~user@213.33.70.157] has quit [Ping timeout: 246 seconds] 11:04:37 -!- drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 248 seconds] 11:05:12 abarch [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 11:06:29 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 11:17:02 stassats [~stassats@wikipedia/stassats] has joined #sbcl 11:26:55 turns out, just moving start-the-world out of the lock causes a deadlock on linux 11:27:10 now trying to move *gc-inhibit* out of the lock, seems to work on windows 11:40:27 echo-area [~user@114.254.106.233] has joined #sbcl 11:40:42 that still locks on linux-x86 11:40:59 but which is build without safepoints 11:51:57 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:53:36 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Client Quit] 11:54:06 attila_lendvai [~attila_le@87.247.13.112] has joined #sbcl 11:54:06 -!- attila_lendvai [~attila_le@87.247.13.112] has quit [Changing host] 11:54:06 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 11:56:07 eudoxia [~eudoxia@r186-52-38-227.dialup.adsl.anteldata.net.uy] has joined #sbcl 12:01:01 drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 12:05:49 -!- drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 272 seconds] 12:37:48 drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 12:52:07 -!- drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 12:52:46 drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has joined #sbcl 12:57:05 -!- drmeister [~drmeister@pool-173-59-25-58.phlapa.fios.verizon.net] has quit [Ping timeout: 245 seconds] 12:59:39 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 13:20:25 teggi [~teggi@123.21.198.146] has joined #sbcl 13:44:29 drmeister [~drmeister@166.137.104.11] has joined #sbcl 13:48:45 -!- Posterdati [~kvirc@host5-216-dynamic.16-87-r.retail.telecomitalia.it] has quit [Ping timeout: 246 seconds] 13:50:44 attila_lendvai [~attila_le@5.251.151.176] has joined #sbcl 13:50:44 -!- attila_lendvai [~attila_le@5.251.151.176] has quit [Changing host] 13:50:44 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:52:04 segv- [~mb@95-91-241-66-dynip.superkabel.de] has joined #sbcl 13:55:31 -!- drmeister [~drmeister@166.137.104.11] has quit [Read error: Connection reset by peer] 13:57:47 drmeister [~drmeister@166.137.104.11] has joined #sbcl 13:58:00 danlentz [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has joined #sbcl 14:03:02 Posterdati [~kvirc@host5-216-dynamic.16-87-r.retail.telecomitalia.it] has joined #sbcl 14:06:50 -!- drmeister [~drmeister@166.137.104.11] has quit [Read error: Connection reset by peer] 14:13:46 drmeister [~drmeister@166.137.104.11] has joined #sbcl 14:19:59 -!- drmeister [~drmeister@166.137.104.11] has quit [Read error: Connection reset by peer] 14:20:18 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Remote host closed the connection] 14:21:06 attila_lendvai [~attila_le@5.251.151.176] has joined #sbcl 14:21:06 -!- attila_lendvai [~attila_le@5.251.151.176] has quit [Changing host] 14:21:06 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:31:49 oleo [~oleo@xdsl-78-35-155-107.netcologne.de] has joined #sbcl 14:35:47 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 252 seconds] 14:36:10 attila_lendvai [~attila_le@84-236-117-182.pool.digikabel.hu] has joined #sbcl 14:36:10 -!- attila_lendvai [~attila_le@84-236-117-182.pool.digikabel.hu] has quit [Changing host] 14:36:10 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:49:25 -!- eudoxia [~eudoxia@r186-52-38-227.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 15:01:23 -!- teggi [~teggi@123.21.198.146] has quit [Remote host closed the connection] 15:04:41 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 15:19:54 k. 15:19:55 cmack [~charlie@adsl-74-179-28-220.bna.bellsouth.net] has joined #sbcl 15:31:19 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 15:37:19 what was again the way to set all floating point exception masks? Google isn't my friend today 15:38:03 sb-int:get/set-floating-point-modes sb-vm:floating-point-modes sb-int:with-float-traps-masked 15:39:31 thanks 15:46:35 i now don't know how to fix sub-gc anymore 15:46:54 maybe ensuring that release-mutex doesn't have any safepoints might work 15:47:07 but that's prone to failure 15:53:50 -!- yacks [~py@103.6.159.103] has quit [Ping timeout: 272 seconds] 15:56:16 shouldn't a thread that ignore interrupts resume on safepoints? 16:00:06 Krystof: tomorrow evening would be better for me. I was hoping to get some defence prep done ;) 16:00:50 pkhuong: up to which point? will it be tripping on every safepoint until it reaches the end of without-interrupts? 16:02:03 stassats: what I thought should happen. 16:02:24 but a lexical declaration to not emit safe points makes sense to me, FWIW. 16:02:59 the only problem is it doesn't have a non-safepoint equivalent, so "in theory" it should never be necessary. 16:04:02 attila_lendvai [~attila_le@5.251.151.176] has joined #sbcl 16:04:02 -!- attila_lendvai [~attila_le@5.251.151.176] has quit [Changing host] 16:04:02 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 16:04:21 would inihibiting safepoints make sense for other uses of with-mutex, though? 16:12:49 pkhuong: boah, if you're allowed to defend you've already passed 16:13:01 (ok, tomorrow or thereabouts it is) 16:20:50 fisxoj [~fisxoj@2620:101:f000:9c00:224:7eff:feda:1209] has joined #sbcl 16:22:37 stassats: for something like release-mutex that never loops? It won't hurt. 16:33:06 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 16:33:44 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 16:36:19 as i'm out of ideas, i'll try that 16:38:16 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 264 seconds] 16:46:35 now, why is (incf *n-bytes-freed-or-purified* freed) positioned after (gc-start-the-world)? it can turn into a bignum, cause another GC / trip on a safepoint 16:48:31 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 240 seconds] 16:48:42 because you want to minimise consing while the world is stopped. 16:49:05 Frankly, I think I'd go for a CAS loop outside the lock, though. 16:50:52 is *n-bytes-freed-or-purified* that important? 16:51:15 most likely little to no contention, so why not be correct? 16:51:32 stassats: re locking, I'm pretty sure the simplest potential fix is to keep everything as is, but only lock around the unsafe root clearing (and even then... it should be safe to do that outside the lock) and top the world. 16:51:36 *stop the world. 16:52:18 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 16:52:51 well, i tried almost that, it's fine on windows, but locks up on linux 16:53:31 stassats: it's very different if the bindings are kept inside with-mutex. 16:54:16 i brought (*gc-inhibit* t) outside of with-mutex 16:54:33 this solves linux-x86-64-safepoint, but locks linux-x86-no-safepoints 16:57:35 that would deadlock. You want to inhibit once the mutex is acquired. Otherwise, you'll have a deadlock between the thread that's inhibiting GC and the one that can actually start it. 16:58:34 well, i'm deadlocking left and right 16:58:50 The sequence would (let [bindings (*gc-inhibit* *gc-inhibit*)] (with-mutex (...) (setf *gc-inhibit* t) [clear roots, but that should either not be locked or after stop the world?] (gc-stop-the-world)) ...) 17:00:04 haven't tried that way 17:00:15 but i'll try inhibit-safepoints first 17:00:29 inhibit safepoints make little sense though. 17:00:54 i'm ready to try anything 17:00:58 If it works, there is no reason to believe it's not accidental. 17:03:04 If it keeps deadlocking, looking for deadlock cycles between *already-in-gc* and *gc-inhibit* may be useful: having *gc-inhibit* true locks stop-the-world out, but that won't be detected automatically. 17:05:51 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 17:06:17 the gc lock might almost be a reader/writer lock. 17:06:27 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 17:06:38 Shared ownership to inhibit gc, exclusive to actually gc. 17:06:42 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:11:16 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 264 seconds] 17:11:30 sbcl seems to be creating fasls in a way that they are not immediately available on the FS 17:11:52 i keep getting "not found" errors when it tries to LOAD them 17:12:06 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 272 seconds] 17:12:38 -!- oleo [~oleo@xdsl-78-35-155-107.netcologne.de] has quit [Ping timeout: 246 seconds] 17:14:55 just to be clear, does this scenario make sense for what you've tried: the thread that holds the gc mutex unbinds gc-inhibit, then something happens, and it tries to GC again in that tiny window when gc-inhibit is nil but the gc mutex held. 17:15:38 i believe that's what happens, because when i moved *gc-inhibit* binding around the mutex, windows stopped having the deadlocks 17:15:49 attila_lendvai [~attila_le@5.251.151.176] has joined #sbcl 17:15:49 -!- attila_lendvai [~attila_le@5.251.151.176] has quit [Changing host] 17:15:49 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 17:16:42 ugly one-line fix: turn that into a recursive mutex (no, I don't think that's a good idea). 17:17:37 I much prefer locking only around stop the world (+ setf *gc-inhibit*). 17:18:18 ok, safepoints do help on windows 17:18:22 inhibit-safepoints, that is 17:18:56 that would prevent the safepoint on function entry, and eliminate the race condition. 17:21:45 but then there's the same window at the beginning of the with-mutex block 17:23:07 poglesbyg_ [~poglesbyg@uib-guest.uib.no] has joined #sbcl 17:23:46 -!- poglesbyg_ [~poglesbyg@uib-guest.uib.no] has quit [Client Quit] 17:25:37 oleo [~oleo@xdsl-84-44-208-74.netcologne.de] has joined #sbcl 17:26:38 so, without-interrupts is supposed to prevent recursive GCs. Why doesn't it? 17:32:24 stassats: http://paste.lisp.org/display/140038. It makes sense (or, rather, what the comment says it's doing), at least. 17:43:47 your previous suggestion (with square brackets) works on windows 17:44:44 if it also works on non-safepoint buids, I think the paste also takes care of the same race condition on entry. 17:45:08 pkhuong: and on that paste, when should it call collect-garbage? 17:46:34 the loop replaces the short (with-mutex ...) block in the square-brackets suggestion. 17:47:52 i'm more confused about (maybe-handle-pending-gc) 17:48:20 that's so that the thread obeys stop-the-world if it can't acquire the gc lock. 17:48:53 right, but when the world starts again, that would mean the two gcs will run in quick succession, one with nothing to do 17:49:03 yacks [~py@103.6.159.103] has joined #sbcl 17:49:18 that's already what's happening right now (that, or a deadlock) 17:49:49 it could abort out of the function if gc-pending becomes false. 17:50:25 solving the deadlock is the priority indeed 17:52:25 also, avoiding back-to-back GC is what my initial :wait-p nil suggestion did. and that just resulted in heap exhaustion. 17:53:00 i think it resulted because i didn't reset from (setf *gc-pending* :in-progress) 17:53:11 perhaps. 17:55:59 also, I'm not sure that it's a good idea to cancel a (gc :full t) because an automatic nursery GC was triggered. 17:59:30 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 18:00:29 stassats: something like , perhaps. 18:02:04 the first variant works on windows, now to test it on linux 18:07:24 You might need to unset *gc-pending* before (maybe-handle-pending-gc). 18:07:30 -!- Bike [~Glossina@gannon-wless-gw.resnet.wsu.edu] has quit [Ping timeout: 245 seconds] 18:11:00 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 18:11:36 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 18:12:14 yes, you will; http://paste.lisp.org/display/140038#2. 18:14:47 Bike [~Glossina@wl-nat109.it.wsu.edu] has joined #sbcl 18:16:09 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 252 seconds] 18:17:53 -!- Bike [~Glossina@wl-nat109.it.wsu.edu] has quit [Client Quit] 18:18:06 Bike [~Glossina@wl-nat109.it.wsu.edu] has joined #sbcl 18:22:39 what should happen to (setf *gc-pending* :in-progress) at the beginning then? 18:23:25 sdemarre [~serge@157.106-64-87.adsl-dyn.isp.belgacom.be] has joined #sbcl 18:24:58 It's not necessary, but I don't think it hurts either. 18:25:16 It helps avoid consecutive minor gcs. 18:26:09 eudoxia [~eudoxia@r190-135-15-146.dialup.adsl.anteldata.net.uy] has joined #sbcl 18:28:08 i'm not sure why sub-gc is even written in lisp 18:28:16 all it does is calling c functions 18:29:47 I don't disagree (: 18:41:05 apparent success on linux, safepoints/no safepoints 18:41:29 Maybe our GC scheduling woes are caused by the flurry of minor GCs when multiple threads hit the GC condition. 18:42:11 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 18:43:47 Later, it might be a good idea for gc_start_the_world to clear *gc-pending* and/or *stop-for-gc-pending*. 18:44:32 -sb-safepoint/+sb-safepoint dichotomy complicates things a bit 18:45:45 worst case: not clearing them doesn't hurt. 18:46:56 (can't clear :in-progress, though ;) 18:48:16 i had somewhere a test case for a failure on consing + sigchld on safepoints 18:48:22 i need to dig it up and see if it's fixed 18:57:13 iirc, gc_stop_the_world clears stop-for-gc-pending. it could do the same for gc-pending T. 18:57:56 it's only called from sub-gc, isn't it? 18:58:53 leuler [~user@p548F9903.dip0.t-ipconnect.de] has joined #sbcl 19:00:28 -!- Bike [~Glossina@wl-nat109.it.wsu.edu] has quit [Ping timeout: 264 seconds] 19:05:42 Bike [~Glossina@wl-nat109.it.wsu.edu] has joined #sbcl 19:06:17 -!- eudoxia [~eudoxia@r190-135-15-146.dialup.adsl.anteldata.net.uy] has quit [Quit: Leaving] 19:07:07 yes. 19:12:24 gc pending is also cleared on non safepoint uilds. 19:13:17 and safepoint as well. Good. 19:15:36 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 246 seconds] 19:15:46 eudoxia [~eudoxia@r190-135-15-146.dialup.adsl.anteldata.net.uy] has joined #sbcl 19:15:51 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 272 seconds] 19:20:43 interestingly, :BUG-936304 in gc.impure.lisp takes 115 seconds on ppc, while just 2 seconds on x86 19:20:56 and :BUG-981106 takes 15 seconds on ppc and 8 seconds on x86 19:21:18 not sure if that's due to the sub-gc changes 19:25:58 and suddenly, i have a ton of unexpected success on ppc 19:26:02 heh. 19:26:05 in dynamic-extent.impure.lisp 19:26:42 interrupt.c might have a race condition too: sig_stop_for_gc_handler unconditionally clears gc-pending. 19:26:56 But sub-gc depends on it being :in-progress when it does its thing. 19:27:16 So it should probably do like safepoints and only clear if it's T. 19:33:03 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 19:37:16 I also don't get SetTlSymbolValue(GC_PENDING,T,self); in safepoint.c:614. That code is only executed if GC_PENDING is T... 19:46:48 scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl 19:51:46 -!- eudoxia [~eudoxia@r190-135-15-146.dialup.adsl.anteldata.net.uy] has quit [Remote host closed the connection] 19:52:49 ok, it takes 118 seconds without any changes to sub-gc 19:58:06 phew, not a regression ( 19:58:28 so, gcing a (truncate (* 0.2 (dynamic-space-size)) sb-vm:n-word-bytes)-length vector takes 7 seconds 19:59:51 no easy way to profile that 20:01:02 perf might work: you can ignore all hits that aren't in the runtime. 20:01:17 i meant on that machine 20:01:24 ah. 20:01:31 i could use gprof 20:02:38 and the unexpected successes aren't caused by sub-gc changes either 20:03:01 are you pinned on a single core? 20:03:09 no 20:03:27 Unexpected success: dynamic-extent.impure.lisp / HANDLER-CASE-BOGUS-COMPILER-NOTE 20:03:37 so, maybe it was due to handler-case changes 20:03:46 things like Unexpected success: dynamic-extent.impure.lisp / (NO-CONSING HASH-TABLES) 20:04:18 HANDLER-CASE-EATING-STACK is also succeeding now 20:04:28 i can't think of any other changes that could have affected it 20:04:43 -!- Bike [~Glossina@wl-nat109.it.wsu.edu] has quit [Ping timeout: 245 seconds] 20:05:25 -!- echo-area [~user@114.254.106.233] has quit [Ping timeout: 248 seconds] 20:05:34 or was it restart-case 20:09:16 in any case, sub-gc changes look good everywhere i tested them so far 20:11:55 pkhuong: that's how it looks right now http://paste.lisp.org/display/140038#3 20:12:08 except for a good explanatory comment 20:13:50 should the case (when (eql gen 0) (return)) return T from sub-gc? 20:14:00 that's what used to determine whether to run post-gc or not 20:14:10 ltt_ [~ltt_@189-47-255-79.dsl.telesp.net.br] has joined #sbcl 20:15:14 it should probably return NIL. 20:16:38 I'd move the final maybe-handle-pending-gc outside after without-thread-waiting-for 20:16:59 (the final one in perform-gc) 20:22:22 poglesbyg_ [~poglesbyg@uib-guest.uib.no] has joined #sbcl 20:23:21 I'm adding comments. 20:23:50 -!- poglesbyg_ [~poglesbyg@uib-guest.uib.no] has quit [Client Quit] 20:24:17 i'm eager to commit it today, so that scymtym's tool can test it 20:25:31 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 20:26:09 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 20:30:41 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 272 seconds] 20:32:47 hm, *gc-epoch* could be set to NIL before collect-garbage 20:33:33 except that it's declaration is CONS 20:34:27 or it may be initialized to (cons nil nil) before collect-garbage 20:35:53 or will that make it move to a higher generation 20:36:47 and there may be not enough space, so, bad idea, only if setting it to NIL 20:39:55 Bike [~Glossina@wl-nat99.it.wsu.edu] has joined #sbcl 20:46:34 eudoxia [~eudoxia@r190-135-15-146.dialup.adsl.anteldata.net.uy] has joined #sbcl 20:51:25 bah. Really, trying to save a single cons? 20:51:36 see comments + patch for interrupt.c 20:52:05 will review tomorrow, not today 20:53:17 -!- samskulls [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Remote host closed the connection] 20:57:33 huh. the comment on INCF being racy is wrong. We're protected by without-gcing. 20:57:39 hm, can I change my mind about the regalloc merge? 20:58:12 if we're doing scary gc/race condition fixes, I'd like that to be in and then not also fundamentally change the compiler output within a short window of time 20:58:22 good. 20:59:56 good luck with your defence :) 21:00:13 pkhuong: racy wrt to other threads? 21:00:32 stassats: wrt other threads collecting garbage, but that won't happen. 21:01:05 other threads can still see stale values, but I'm pretty sure we still don't care. 21:01:35 ok, i see now 21:02:09 i should also test on solaris-x86 21:06:53 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 21:16:03 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl 21:19:03 I'm also pretty sure the magic *gc-pending* value is now redundundant. 21:26:16 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds] 21:26:46 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 21:29:05 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 21:36:50 -!- ltt_ [~ltt_@189-47-255-79.dsl.telesp.net.br] has quit [Quit: Textual IRC Client: www.textualapp.com] 21:46:02 -!- leuler [~user@p548F9903.dip0.t-ipconnect.de] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 21:48:05 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 21:48:32 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 22:03:06 -!- eudoxia [~eudoxia@r190-135-15-146.dialup.adsl.anteldata.net.uy] has quit [Remote host closed the connection] 22:04:38 ASau` [~user@p5083D79B.dip0.t-ipconnect.de] has joined #sbcl 22:05:57 -!- ASau [~user@p5083D530.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds] 22:25:07 -!- sdemarre [~serge@157.106-64-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 252 seconds] 22:27:11 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Read error: No route to host] 22:27:51 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 22:32:42 hydan [~user@ip-89-103-110-5.net.upcbroadband.cz] has joined #sbcl 22:35:50 -!- fisxoj [~fisxoj@2620:101:f000:9c00:224:7eff:feda:1209] has quit [Ping timeout: 240 seconds] 22:36:04 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Remote host closed the connection] 22:36:43 drmeiste_ [~drmeister@155.247.96.196] has joined #sbcl 22:40:37 drmeist__ [~drmeister@155.247.96.196] has joined #sbcl 22:40:47 -!- jsnell [~jsnell@ash.snellman.net] has quit [Ping timeout: 260 seconds] 22:41:32 jsnell [~jsnell@ash.snellman.net] has joined #sbcl 22:41:47 -!- drmeiste_ [~drmeister@155.247.96.196] has quit [Ping timeout: 272 seconds] 22:46:51 -!- Bike [~Glossina@wl-nat99.it.wsu.edu] has quit [Ping timeout: 272 seconds] 22:50:01 -!- abarch [~user@ip-5-147-115-29.unitymediagroup.de] has quit [Ping timeout: 272 seconds] 23:24:03 -!- prxq [~mommer@x2f65790.dyn.telefonica.de] has quit [Quit: Leaving] 23:28:25 eudoxia [~eudoxia@r190-135-0-204.dialup.adsl.anteldata.net.uy] has joined #sbcl 23:28:53 -!- eudoxia [~eudoxia@r190-135-0-204.dialup.adsl.anteldata.net.uy] has quit [Read error: Connection reset by peer] 23:31:04 ltt_ [~ltt_@189-47-255-79.dsl.telesp.net.br] has joined #sbcl 23:45:47 -!- drmeist__ [~drmeister@155.247.96.196] has quit [Ping timeout: 252 seconds] 23:49:02 -!- segv- [~mb@95-91-241-66-dynip.superkabel.de] has quit [Remote host closed the connection]