00:03:39 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
01:20:08 -!- rpg [~rpg@198-74-7-110.fttp.usinternet.com] has quit [Quit: rpg]
01:21:44 ltt_ [~ltt_@201.75.216.14] has joined #sbcl
01:53:23 -!- jaimef [jaimef@166.84.6.60] has quit [Ping timeout: 252 seconds]
02:21:16 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
02:23:30 -!- ltt_ [~ltt_@201.75.216.14] has quit [Quit: Textual IRC Client: www.textualapp.com]
02:24:22 ... Just thinking about "simpler structure layout", from the GSoC '13 ideas list. Nevermind interleaving, what would happen if we declared that unboxed slots have negative slot indexes?
02:24:48 Or the other way around, that the BOXED slots have negative indexes?
02:27:57 that was lichtblau's preferred approach
02:28:04 we'd need support for interior pointers
02:28:09 (for structs)
02:28:16 ... more complexity!
02:28:51 How so?
02:29:00 How would we need interior pointers for this?
02:29:47 because if slots have negative indices, the boxed reference points in the middle of the struct?
02:29:50 You'd need for structs to have two "headers", one at the start for the GC and one at the end of the boxed slots for typechecking, that's all.
02:30:01 Same way we do with LRAs and SIMPLE-FUNs.
02:30:31 sure
02:45:50 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
02:49:50 prxq__ [~mommer@x2f64eec.dyn.telefonica.de] has joined #sbcl
02:53:02 -!- prxq_ [~mommer@x2f658c1.dyn.telefonica.de] has quit [Ping timeout: 264 seconds]
02:59:23 Scary, scary thought: Can we abuse the code-object layout to embed structures? There'd be a touch more overhead, probably, but...
03:01:33 Looks like the code object, as far as the GC is concerned, has a header, indicating how many boxed words are in the component prior to the first unboxed word, a fixnum indicating the number of unboxed words, and a pointer (which we'd have as NIL) pointing to the first embedded function.
03:01:59 what's the point? also, looks like a lot of space overhead.
03:02:16 I'd rather write 2 C functions ;)
03:02:24 Two words other than the header itself, and means possibly no GC changes.
03:02:49 Okay, that's not quite how it works, I know, but it's still an interesting idea even if we don't go with it.
03:03:08 (ok, I lied, I'd rather play with linear programming solvers ;)
03:04:58 Fair enough. I'm sortof avoiding dealing with some API changes for work and TAIL-CALL-VARIABLE on ARM.
03:05:10 ubii [~ubii@unaffiliated/ubii] has joined #sbcl
03:05:43 wbooze [~oleo@xdsl-78-35-163-221.netcologne.de] has joined #sbcl
03:05:59 -!- oleo [~oleo@xdsl-78-35-187-135.netcologne.de] has quit [Ping timeout: 252 seconds]
03:06:25 -!- wbooze is now known as oleo
03:13:29 If we go to mark/sweep, we'll end up with a marktab to parallel scavtab, sizetab, and transtab, won't we?
03:17:27 Hrm. Clearly, I'm going to have to think about this a bit more.
03:19:24 I was going to populate a bitmap via scavtab
03:19:51 (for pointers), and another to determine where objects begin/end via sizetab.
03:21:50 did anyone ever end up looking at trying MPS?
03:22:44 very quickly.
03:22:56 I'm worried about cores
03:33:40 -!- slyrus [~chatzilla@udp047553uds.hawaiiantel.net] has quit [Ping timeout: 246 seconds]
03:36:22 -!- christoph_debian [~christoph@ppp-88-217-54-53.dynamic.mnet-online.de] has quit [Read error: Operation timed out]
03:42:42 Okay, I've had a little time to think about mark/sweep GC and SBCL, and my preliminary conclusion is that I need to apply the Feynman method.
03:46:02 I'm assuming that we have a way to mark an object as live (transtab in our current system, setting a markbit in a mark/sweep system), a way to mark a live object as having been checked for further live references (a second bitmap in the case of a mark/sweep system, the fact that memory is allocated approximately linearly in our current system), and then I start to worry about the cases where we're evacuating a page of live object
03:46:02 s even in a mark/sweep regime.
03:52:11 christoph_debian [~christoph@ppp-46-244-229-3.dynamic.mnet-online.de] has joined #sbcl
03:57:25 -!- Subfusc [~Subfusc@tjenen.de] has quit [Ping timeout: 245 seconds]
03:58:59 There was another thought about deciding at the end of one collection that certain pages should be evacuated if possible, and instead of setting markbits during the mark phase arranging to transport the live objects instead.
03:59:01 slyrus [~chatzilla@udp047553uds.hawaiiantel.net] has joined #sbcl
03:59:08 Subfusc [~Subfusc@tjenen.de] has joined #sbcl
03:59:54 The mostly-dead pages stay live for the extra collection cycle, but there's no time-consuming after-the-fact "oh, we need to evacuate this page after all, and then re-scan all the other pages for references" phase.
04:07:35 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Ping timeout: 252 seconds]
04:08:42 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl
04:09:00 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl
04:55:37 -!- nyef [~nyef@pool-70-109-134-244.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.]
05:08:29 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:08:59 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:09:15 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:09:34 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:10:02 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:10:20 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:10:49 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:11:07 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:11:34 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:11:52 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:12:21 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:12:41 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:13:07 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:13:25 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:13:55 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:14:14 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:14:41 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:14:56 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:15:27 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:15:46 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:16:13 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:16:31 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:17:01 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:17:22 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:17:48 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:18:06 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:18:34 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:18:58 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:19:20 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:19:36 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:20:07 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:20:26 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:20:53 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:21:13 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:21:40 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:22:01 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:22:27 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:22:46 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:23:13 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:23:32 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:24:00 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:24:22 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:24:50 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:25:10 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:25:37 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:25:56 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:26:25 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:26:46 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:27:14 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:27:32 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:28:01 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:28:17 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:28:48 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:29:06 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:29:30 scymtym_ [~user@ip-5-147-115-29.unitymediagroup.de] has joined #sbcl
05:29:35 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:29:56 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:30:26 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:30:41 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:31:12 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:31:29 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:31:59 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:32:19 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:32:47 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:32:57 dto [~user@pool-96-252-62-251.bstnma.fios.verizon.net] has joined #sbcl
05:33:04 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:33:32 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:34:00 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:34:19 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:34:40 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:35:06 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:35:25 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:35:56 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:36:16 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:36:45 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:37:01 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:37:31 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:37:51 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:38:20 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:38:41 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:39:09 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:39:33 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:40:02 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:40:29 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:40:55 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:41:14 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
05:41:43 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
05:53:31 ltbarcly [~textual@li94-204.members.linode.com] has joined #sbcl
07:25:31 sdemarre [~serge@91.176.245.254] has joined #sbcl
07:33:30 yacks [~py@103.6.159.103] has joined #sbcl
07:33:41 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl
08:18:35 -!- Bike [~Glossina@c-24-21-88-250.hsd1.wa.comcast.net] has quit [Ping timeout: 272 seconds]
08:45:46 -!- ehaliewicz [~user@50-0-51-28.dsl.static.sonic.net] has quit [Remote host closed the connection]
08:56:07 stassats [~stassats@wikipedia/stassats] has joined #sbcl
09:17:52 -!- scymtym [~user@2001:638:504:2093:baca:3aff:fe83:e736] has quit [*.net *.split]
09:17:53 -!- Subfusc [~Subfusc@tjenen.de] has quit [*.net *.split]
09:17:54 -!- flip214 [~marek@unaffiliated/flip214] has quit [*.net *.split]
09:17:55 -!- angavrilov [~angavrilo@217.71.227.190] has quit [*.net *.split]
09:17:58 -!- echo-area [~user@123.112.228.105] has quit [*.net *.split]
09:18:02 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [*.net *.split]
09:18:02 -!- slyrus [~chatzilla@udp047553uds.hawaiiantel.net] has quit [*.net *.split]
09:18:02 -!- dto [~user@pool-96-252-62-251.bstnma.fios.verizon.net] has quit [*.net *.split]
09:18:02 -!- prxq__ [~mommer@x2f64eec.dyn.telefonica.de] has quit [*.net *.split]
09:18:02 -!- heddwch [~yoshi@76.8.3.189] has quit [*.net *.split]
09:18:05 -!- joshe [~joshe@2001:470:e862::1:1] has quit [*.net *.split]
09:18:06 -!- Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has quit [*.net *.split]
09:18:06 -!- fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has quit [*.net *.split]
09:18:08 -!- danlentz [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has quit [*.net *.split]
09:18:11 -!- ferada [~ferada@37.221.196.86] has quit [*.net *.split]
09:18:13 -!- hzp [~user@188-67-136-27.bb.dnainternet.fi] has quit [*.net *.split]
09:18:13 -!- DeadTrickster [~dead@62.122.188.214] has quit [*.net *.split]
09:18:14 -!- Posterdati [~kvirc@host208-231-dynamic.2-79-r.retail.telecomitalia.it] has quit [*.net *.split]
09:18:15 -!- minion [~minion@common-lisp.net] has quit [*.net *.split]
09:18:16 -!- Munksgaard [munksgaard@hub.pronoia.dk] has quit [*.net *.split]
09:18:17 -!- ivan`` [~ivan@unaffiliated/ivan/x-000001] has quit [*.net *.split]
09:18:18 -!- xymox [lechuck@unaffiliated/contempt] has quit [*.net *.split]
09:18:18 -!- nicdev [~user@kilimanjaro.rafpepa.com] has quit [*.net *.split]
09:18:24 -!- reb [user@nat/google/x-allzaxamjmqmdtkj] has quit [*.net *.split]
09:18:25 -!- foom [~jknight@2620:15c:6:14:be30:5bff:fedf:6db6] has quit [*.net *.split]
09:18:25 -!- loke_ [~loke@203.127.16.194] has quit [*.net *.split]
09:18:25 -!- |3b| [bbb@2600:3c00::f03c:91ff:fedf:5b65] has quit [*.net *.split]
09:18:26 -!- gko [gko@2400:8900::f03c:91ff:fe70:e605] has quit [*.net *.split]
09:18:28 -!- crixus [~Rob@135-23-80-105.cpe.pppoe.ca] has quit [*.net *.split]
09:18:29 -!- specbot [~specbot@common-lisp.net] has quit [*.net *.split]
09:18:33 -!- sdemarre [~serge@91.176.245.254] has quit [*.net *.split]
09:18:33 -!- christoph_debian [~christoph@ppp-46-244-229-3.dynamic.mnet-online.de] has quit [*.net *.split]
09:18:34 -!- segv- [~mb@cpeB-151.mvcable.net] has quit [*.net *.split]
09:18:36 -!- fikusz [~fikusz@catv-89-132-137-62.catv.broadband.hu] has quit [*.net *.split]
09:18:38 -!- brucem [~bmitchene@waywardmonkeys.com] has quit [*.net *.split]
09:18:39 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [*.net *.split]
09:18:40 -!- Krystof [~user@81.174.155.115] has quit [*.net *.split]
09:18:41 -!- Labrit [tribal@rcfreak0.com] has quit [*.net *.split]
09:18:42 -!- stassats [~stassats@wikipedia/stassats] has quit [*.net *.split]
09:18:42 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [*.net *.split]
09:18:44 -!- pkhuong [~pkhuong@modemcable086.239-37-24.mc.videotron.ca] has quit [*.net *.split]
09:18:46 -!- psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has quit [*.net *.split]
09:18:48 -!- jaimef [jaimef@dns.mauthesis.com] has quit [*.net *.split]
09:18:50 -!- antoszka [~antoszka@unaffiliated/antoszka] has quit [*.net *.split]
09:18:51 -!- redline6561 [~redline65@li69-162.members.linode.com] has quit [*.net *.split]
09:18:51 -!- mood [~mood@146.185.164.46] has quit [*.net *.split]
09:18:52 -!- ltbarcly [~textual@li94-204.members.linode.com] has quit [*.net *.split]
09:18:52 -!- oleo [~oleo@xdsl-78-35-163-221.netcologne.de] has quit [*.net *.split]
09:18:54 -!- luis [~luis@kerno.org] has quit [*.net *.split]
09:18:56 -!- pegu [~user@c7F7CBF51.dhcp.as2116.net] has quit [*.net *.split]
09:18:57 -!- kludge` [~comet@unaffiliated/espiral] has quit [*.net *.split]
09:19:06 -!- yacks [~py@103.6.159.103] has quit [*.net *.split]
09:19:06 -!- ubii [~ubii@unaffiliated/ubii] has quit [*.net *.split]
09:19:06 -!- milosn_ [~milosn@94.12.79.143] has quit [*.net *.split]
09:19:07 -!- daimrod [daimrod@sbrk.org] has quit [*.net *.split]
09:21:47 milosn [~milosn@94.12.79.143] has joined #sbcl
09:22:21 sdemarre [~serge@91.176.245.254] has joined #sbcl
09:22:21 christoph_debian [~christoph@ppp-46-244-229-3.dynamic.mnet-online.de] has joined #sbcl
09:22:21 crixus [~Rob@135-23-80-105.cpe.pppoe.ca] has joined #sbcl
09:22:21 segv- [~mb@cpeB-151.mvcable.net] has joined #sbcl
09:22:21 reb [user@nat/google/x-allzaxamjmqmdtkj] has joined #sbcl
09:22:21 foom [~jknight@2620:15c:6:14:be30:5bff:fedf:6db6] has joined #sbcl
09:22:21 loke_ [~loke@203.127.16.194] has joined #sbcl
09:22:21 ivan`` [~ivan@unaffiliated/ivan/x-000001] has joined #sbcl
09:22:21 nicdev [~user@kilimanjaro.rafpepa.com] has joined #sbcl
09:22:21 |3b| [bbb@2600:3c00::f03c:91ff:fedf:5b65] has joined #sbcl
09:22:21 specbot [~specbot@common-lisp.net] has joined #sbcl
09:22:21 gko [gko@2400:8900::f03c:91ff:fe70:e605] has joined #sbcl
09:22:21 fikusz [~fikusz@catv-89-132-137-62.catv.broadband.hu] has joined #sbcl
09:22:21 brucem [~bmitchene@waywardmonkeys.com] has joined #sbcl
09:25:33 ubii [~ubii@198.45.198.1] has joined #sbcl
09:26:36 xymox [lechuck@s0.barwen.ch] has joined #sbcl
09:28:51 daimrod [daimrod@sbrk.org] has joined #sbcl
09:28:51 yacks [~py@103.6.159.103] has joined #sbcl
09:28:51 danlentz [~danlentz@c-68-37-70-235.hsd1.nj.comcast.net] has joined #sbcl
09:29:12 dto [~user@pool-96-252-62-251.bstnma.fios.verizon.net] has joined #sbcl
09:29:12 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl
09:29:12 slyrus [~chatzilla@udp047553uds.hawaiiantel.net] has joined #sbcl
09:29:12 prxq__ [~mommer@x2f64eec.dyn.telefonica.de] has joined #sbcl
09:29:12 heddwch [~yoshi@76.8.3.189] has joined #sbcl
09:29:12 joshe [~joshe@2001:470:e862::1:1] has joined #sbcl
09:29:12 fe[nl]ix [~quassel@pdpc/supporter/professional/fenlix] has joined #sbcl
09:29:12 Blkt [~Blkt@2a01:4f8:150:80a1::aaaa] has joined #sbcl
09:29:57 Bike [~Glossina@c-24-21-88-250.hsd1.wa.comcast.net] has joined #sbcl
09:30:16 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl
09:30:16 stassats [~stassats@wikipedia/stassats] has joined #sbcl
09:30:16 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl
09:30:16 pkhuong [~pkhuong@modemcable086.239-37-24.mc.videotron.ca] has joined #sbcl
09:30:16 psilord [~psilord@c-69-180-173-249.hsd1.mn.comcast.net] has joined #sbcl
09:31:28 scymtym [~user@2001:638:504:2093:baca:3aff:fe83:e736] has joined #sbcl
09:31:43 hzp [~user@188-67-136-27.bb.dnainternet.fi] has joined #sbcl
09:31:43 DeadTrickster [~dead@62.122.188.214] has joined #sbcl
09:31:43 Posterdati [~kvirc@host208-231-dynamic.2-79-r.retail.telecomitalia.it] has joined #sbcl
09:31:43 minion [~minion@common-lisp.net] has joined #sbcl
09:31:43 Munksgaard [munksgaard@hub.pronoia.dk] has joined #sbcl
09:31:46 flip214 [~marek@unaffiliated/flip214] has joined #sbcl
09:31:55 kludge` [~comet@unaffiliated/espiral] has joined #sbcl
09:32:06 edgar-rft [~GOD@HSI-KBW-109-193-013-113.hsi7.kabel-badenwuerttemberg.de] has joined #sbcl
09:32:06 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl
09:32:06 antoszka [~antoszka@unaffiliated/antoszka] has joined #sbcl
09:32:06 mood [~mood@146.185.164.46] has joined #sbcl
09:32:06 redline6561 [~redline65@li69-162.members.linode.com] has joined #sbcl
09:32:17 -!- jaimef [jaimef@dns.mauthesis.com] has quit [Max SendQ exceeded]
09:32:40 jaimef [jaimef@dns.mauthesis.com] has joined #sbcl
09:35:22 echo-area [~user@123.112.228.105] has joined #sbcl
09:39:45 Subfusc [~Subfusc@tjenen.de] has joined #sbcl
09:44:24 Krystof [~user@81.174.155.115] has joined #sbcl
09:44:24 Labrit [tribal@rcfreak0.com] has joined #sbcl
09:44:24 -!- hubbard.freenode.net has set mode +o Krystof
09:53:58 ltbarcly [~textual@li94-204.members.linode.com] has joined #sbcl
09:53:58 oleo [~oleo@xdsl-78-35-163-221.netcologne.de] has joined #sbcl
09:53:58 luis [~luis@kerno.org] has joined #sbcl
09:53:58 pegu [~user@c7F7CBF51.dhcp.as2116.net] has joined #sbcl
10:05:39 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Ping timeout: 260 seconds]
10:25:21 hrrrm, something wrong with integer type derivation
10:26:16 (defun x (z y) (declare ((unsigned-byte 62) y) ((unsigned-byte 64) z) (optimize speed)) (cond ((< y sb-vm:n-fixnum-bits) (logand (1- (ash 1 y)) z)))) for some reason doesn't derive that the result is a fixnum
10:26:40 but it does if (declare ((unsigned-byte 63) y))
10:29:28 is it?
10:29:42 that's on x86-64, of course
10:30:35 ah, missed the comparison
10:30:53 *|3b|* is apparently not fully awake or something
10:31:09 the problem seems to be (ASH-DERIVE-TYPE-AUX # # NIL) => 0: ASH-DERIVE-TYPE-AUX returned #
10:32:55 with unsigned-byte 63 it's eventually called as (ASH-DERIVE-TYPE-AUX # # NIL)
10:33:27 -!- kludge` [~comet@unaffiliated/espiral] has quit [Ping timeout: 246 seconds]
10:33:52 with 63, ASH-DERIVE-TYPE-AUX is called three times, but only one time with 62
10:34:13 looks like another one of this too early optimizations
10:36:18 and if i remove logand, it's called with (mod 63) too, but not with logand
10:36:45 looks like logand steers away at some point from ash, not giving it a chance to optimize after (< y 63) is propagated
10:37:10 kludge` [~comet@unaffiliated/espiral] has joined #sbcl
10:37:48 i wouldn't care much, but even truly-the can't influence this
10:37:56 -!- milosn [~milosn@94.12.79.143] has quit [Read error: No route to host]
10:38:03 milosn [~milosn@94.12.79.143] has joined #sbcl
10:38:35 actually, it can, now knowing the culprit, i placed it at the right place, around y
10:49:59 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 260 seconds]
11:08:05 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
11:08:35 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
11:08:57 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
11:09:22 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
11:43:34 -!- milosn [~milosn@94.12.79.143] has quit [Read error: No route to host]
11:43:41 milosn_ [~milosn@94.12.79.143] has joined #sbcl
11:56:47 stassats [~stassats@wikipedia/stassats] has joined #sbcl
12:00:57 -!- milosn_ [~milosn@94.12.79.143] has quit [Ping timeout: 252 seconds]
12:01:24 ltt_ [~ltt_@201.75.216.14] has joined #sbcl
12:02:58 -!- dto [~user@pool-96-252-62-251.bstnma.fios.verizon.net] has quit [Remote host closed the connection]
12:09:37 milosn [~milosn@94.12.79.143] has joined #sbcl
12:13:25 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 246 seconds]
12:27:50 fiveop [~fiveop@p5DDC42AE.dip0.t-ipconnect.de] has joined #sbcl
12:41:47 pranavrc [~pranavrc@122.174.36.76] has joined #sbcl
12:41:47 -!- pranavrc [~pranavrc@122.174.36.76] has quit [Changing host]
12:41:47 pranavrc [~pranavrc@unaffiliated/pranavrc] has joined #sbcl
12:57:57 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
13:02:30 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Ping timeout: 245 seconds]
13:05:17 -!- pranavrc [~pranavrc@unaffiliated/pranavrc] has quit [Ping timeout: 245 seconds]
13:19:04 nyef [~nyef@pool-70-109-134-244.cncdnh.east.myfairpoint.net] has joined #sbcl
13:19:45 G'morning all.
13:35:41 -!- sdemarre [~serge@91.176.245.254] has quit [Quit: Leaving.]
13:47:08 LiamH [~none@96.231.226.143] has joined #sbcl
13:50:56 stassats [~stassats@wikipedia/stassats] has joined #sbcl
14:47:01 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
14:51:39 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Ping timeout: 260 seconds]
15:19:00 *stassats* closes on a non-consing LDB when the result is a fixnum, and less consing when the result is a bignum
15:19:20 Nice.
15:19:27 and an order of magnitude faster, too
15:20:06 I'm doing a brain-dump of GC ideas right now, some of which might get done "just because".
15:25:38 ... And I've just found a thinko in handling "conservative_stack" for ALL non-x86oid ports (both of them?)
15:25:47 gencgc ports, that is.
15:30:19 -!- oleo [~oleo@xdsl-78-35-163-221.netcologne.de] has quit [Ping timeout: 252 seconds]
15:30:40 oleo [~oleo@xdsl-78-35-153-18.netcologne.de] has joined #sbcl
15:47:34 nyef: write-barrier based refcount? (:
15:48:02 I'm... somehow horrified by the concept.
15:49:24 The "conservative_stack" flag is normally true. It is set to false during SLAD to allow a full "unconservative" GC.
15:49:57 But what this REALLY means is that we want to ignore all per-thread roots when it is false.
15:50:14 nyef: that's the essence of generetional gc
15:50:29 ok. First, coffee.
15:50:49 Hrm. Coffee. Good idea. I hope someone else is making coffee today.
15:52:17 *nyef* sees no coffee here.
15:54:03 nyef: oh, right... And we don't do that elsewhere? (re SLAD)
15:55:04 Not that I'm aware of.
15:55:27 And there's a lovely thread state that is only checked for in the x86oid code, STATE_DEAD.
15:56:56 I think it's only needed on one of our semi borked port (win32 or darwin/x86oid)
16:02:06 You may be right: all binding stacks get scavenged, regardless of thread state, on all platforms.
16:03:17 And that's per-process state, so it probably shouldn't when in SLAD.
16:12:06 -!- ltt_ [~ltt_@201.75.216.14] has quit [Quit: Textual IRC Client: www.textualapp.com]
16:34:21 pkhuong: I think that I might be able to make the x86-64 control stack be separate from the C stack, without having to partition the register set or anything to start with.
16:35:53 The upshot would be that the set of conservative roots becomes interrupt contexts and explicitly pinned pointers, and we lose the ability to stack-allocate some objects.
16:36:31 Oh, and I'd have to burn a couple of registers on it.
16:44:23 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 252 seconds]
16:58:33 I think I'll customise my irssi to turn your nick into "register-eater"
16:58:44 Heh.
16:59:00 It's not like x86-64 doesn't have the registers available.
17:00:53 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
17:00:56 Besides, two registers, or possibly thread struct slots on threaded builds, for the ability to relocate anything pointed to by the control stack?
17:01:29 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
17:01:30 Hrm. No, at least one of them needs to be a register. Damn.
17:01:50 And the other one really should be a register.,
17:01:50 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
17:01:51 ltt_ [~ltt_@201.75.216.14] has joined #sbcl
17:03:31 On x86-64, is there a set of high-order bits that are guaranteed to be clear at all times in user code?
17:03:37 Err... address bits, that is?
17:04:31 is there an assumption that the address space is 2^48 bytes? I seem to recall something like that in the olden days
17:05:22 Yeah, that's what I'm vaguely remembering.
17:06:59 If the top $n$ bits of addresses are known to be clear, for $n >= 5$, then I've definitely got an angle on splitting these stacks without having to deal with the same kind of boxed LRA nonsense that we do everywhere else.
17:14:17 -!- yacks [~py@103.6.159.103] has quit [Quit: Leaving]
17:21:16 -!- ltt_ [~ltt_@201.75.216.14] has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz]
17:22:59 nyef: the topmost bit must all be the same (sign extension)
17:23:55 The current page table design stops at 48 bits, but there are plans to push that to to 50-something soonish.
17:24:45 Wonderful, thank you.
17:25:00 what does 'NFP' in the context of VOPs stand for?
17:25:23 number frame pointer.
17:25:57 nyef: split stack? :p
17:26:22 I stubbed out a lot of the number stack stuff on ARM because it wasn't immediately necessary and there's a horrible shortage of registers.
17:27:07 fiveop: only boxed values and return addresses (and old frame pointer values, which happen to look like fixnums) go on the control stack. Unboxed values (e.g. machine words or floats) go on the number stack.
17:27:51 And return addresses on non-x86oid systems are considered to be boxed objects.
17:27:54 The number stack pointer's permanent residence is a global/thread-local slot, but is moved to a register in functions that access that stack.
17:29:36 what's the relationship of the number stack and control stack with the stack manipulated by the push and pop (ARM) instructions?
17:30:03 (when I start to sound like the 3 year old girls, that kept asking his grandmother 'Why?' in the subway today, just tell me :))
17:30:04 control stack is usually the native stack. Don't know how nyef set that up in the ARM port.
17:30:43 Control stack is rarely the native stack. I switch stack pointers during call-in/call-out.
17:31:15 nyef: sorry, native stack pointer.
17:31:23 ARM push and pop instructions work in terms of any register.
17:31:25 it gets switched to the alien stack for call-in/call-out
17:31:49 ah, the same RISC as 68k ;)
17:31:52 Only on x86oids and arm. Other platforms use the native (C) stack pointer for the number stack and call-out.
17:32:07 Makes backtrace easier. (-:
17:32:22 SPARC?
17:32:34 Okay, not sure about SPARC, but certainly PPC and MIPS.
17:32:52 but then again, PPC and MIPS don't really have hardware SP either.
17:34:29 For x86-64, I'm thinking to have RSP as the number stack pointer, leave return addresses there, and box RSP to push to the control stack as our LRAs so that the GC can find the pointers that it needs to update (or pin) to deal with code objects.
17:36:03 what is it with forth people and the abuse of ESP?
17:36:17 Abuse how?
17:36:45 What's LRA? (I came across it while browsing your changes, but didn't bother to ask then.)
17:36:51 In this case, my goal is to leave the machine return addresses the hell alone.
17:36:56 fiveop: Lisp Return Address.
17:38:04 fiveop: It's a tagged pointer value (other-pointer-lowtag) to a special header (return-pc-header-widetag) embedded within a code-object.
17:39:09 thanks you
17:39:41 We have a bit of a love-hate relationship with these things. They solve a definite technical problem, but they tend to rather badly conflict with modern CPU architectures.
17:39:41 nyef: (re)storing RSP from a control stack that's *not* where RSP points to.
17:39:55 I have a hate-hate relationship with them.
17:40:22 pkhuong: You don't like reg_CODE either, do you?
17:40:24 although I'm pretty sure the return address prediction doesn't care how we mess with the contents of the stack, as long as the return address eventually matches.
17:40:26 Is this all very sbcl specific or is there a good source to learn about what's done?
17:40:34 It's pretty sbcl-specific.
17:40:44 Is the sbcl-internals cliki still running?
17:40:49 yes
17:40:54 oh
17:40:57 I dont know
17:40:59 there is a text
17:41:03 fiveop: you can generalise it to CMUCL, and perhaps find 1-2 other systems from the era that are still alive.
17:41:08 Or there's the internals manual in doc/internals.
17:41:12 http://www.sbcl.org/sbcl-internals/
17:41:14 but
17:41:17 nyef: I think we lost that cliki during the great migration.
17:41:26 (They're still alive? Are they also doing science?)
17:42:42 re return address, I do like CCL's hack of encoding data in the low bits.
17:42:46 -!- slyrus [~chatzilla@udp047553uds.hawaiiantel.net] has quit [Ping timeout: 246 seconds]
17:44:05 ... By carefully aligning the CALL instruction?
17:44:11 yup.
17:44:47 Hrm... maybe if we had a return-pc-lowtag?
17:45:13 doesn't work on riscy archs though.
17:45:18 Yes, that's sufficiently evil as to be workable, and would only cost us a fixnum bit.
17:45:41 or 3 on 64 bit platforms.
17:46:42 I'm thinking about 64 bit platforms only, TBH, and I think I only need to scare up one bit (two lowtags).
17:49:45 ltt_ [~ltt_@201.75.216.14] has joined #sbcl
17:50:07 Oh, and now that preserve_pointer doesn't CARE if a page is CODE_PAGE_FLAG or not, I've figured out how to enforce it as an invariant.
17:50:46 how do define-vop's with no :generator make sense?
17:51:03 fiveop: you can inherit from another VOPs.
17:51:09 Like virtual base classes ;)
17:52:13 Mmm. You can have base VOPs with the :generator that behave differently based on options in the derived VOPs, or you can have base VOPs with no :generator that supply a lot of boilerplate parameters and such to the derived VOPs.
17:52:41 And, rarely, both at the same time.
17:53:27 so if they don't inherit and have no generator, they are probably meant as 'base' vops?
17:53:33 ah
17:53:46 thanks again
17:59:08 Another aspect is that VOPs are either referred to by name (typically in IR2TRAN), tied into the whole MOVE machinery, have a :TRANSLATE term, or are base VOPs intended to be inherited.
17:59:41 Umm... Or maybe tied into the type-checking machinery. Not sure there.
18:00:39 I encountered 'base vops' that have something to do with type checking.
18:01:20 Thanks again for all the pointers. I'll have to stop for today. More reading will follow on Monday :)
18:02:02 -!- fiveop [~fiveop@p5DDC42AE.dip0.t-ipconnect.de] has quit [Quit: humhum]
18:06:50 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
18:07:37 drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has joined #sbcl
18:10:11 nyef: I think only MOVE and call stuff is referred by name in IR2TRAN.
18:10:19 slyrus [~chatzilla@udp047553uds.hawaiiantel.net] has joined #sbcl
18:42:15 %NIP-VALUES, off the top of my head.
18:42:35 a lot of closure stuff.
18:42:53 %SET-SYMBOL-GLOBAL-VALUE.
18:43:30 INSERT-SAFEPOINT (that one's relatively new).
18:44:07 BIND and UNBIND. BRANCH. A couple of others.
18:46:29 stassats [~stassats@wikipedia/stassats] has joined #sbcl
19:20:17 -!- oleo [~oleo@xdsl-78-35-153-18.netcologne.de] has quit [Remote host closed the connection]
19:24:15 -!- prxq__ is now known as prxq
19:24:47 -!- prxq [~mommer@x2f64eec.dyn.telefonica.de] has quit [Quit: Leaving]
19:25:04 prxq [~mommer@x2f64eec.dyn.telefonica.de] has joined #sbcl
19:25:26 -!- stassats [~stassats@wikipedia/stassats] has quit [Ping timeout: 264 seconds]
19:31:22 stassats [~stassats@wikipedia/stassats] has joined #sbcl
19:32:30 -!- stassats [~stassats@wikipedia/stassats] has quit [Remote host closed the connection]
19:32:38 Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has joined #sbcl
19:46:01 oleo [~oleo@xdsl-78-35-153-18.netcologne.de] has joined #sbcl
20:03:38 Ah, right. I forgot about actual ir2 convert methods.
20:20:27 MOVE is extra special. We actually look for it in VOP names. Plenty more are inserted by name, but we don't do anything special later. (also, branch-if is special now)
20:21:02 Where do we look for MOVE in VOP names?
20:22:25 move-move straightening.
20:22:42 and when converting for type conversion.
20:23:11 i mean converting from vanilla MOVE to primitive-typed moves.
20:27:50 -!- Vivitron [~Vivitron@c-50-172-44-193.hsd1.il.comcast.net] has quit [Ping timeout: 264 seconds]
20:48:38 -!- slyrus [~chatzilla@udp047553uds.hawaiiantel.net] has quit [Ping timeout: 246 seconds]
21:26:50 -!- prxq [~mommer@x2f64eec.dyn.telefonica.de] has quit [Quit: Leaving]
21:28:07 -!- oleo [~oleo@xdsl-78-35-153-18.netcologne.de] has quit [Quit: Leaving]
21:41:38 oleo [~oleo@xdsl-78-35-153-18.netcologne.de] has joined #sbcl
22:13:33 should the type defined by DEFCLASS be visible to compilation of later forms in the same file?
22:16:27 ah, i guess i misread the clhs, and it should be more visible than it is
22:16:59 though still not sure CLHS explicitly says it should work in MAKE-array :element-type
22:17:11 since that isn't a "declaration" or defmethod
22:19:33 though since optimization is implementation dependent anyway, can't really say not optimizing for the declaration is a bug either, since it still works at runtime
22:58:51 -!- ltt_ [~ltt_@201.75.216.14] has quit [Quit: Textual IRC Client: www.textualapp.com]
22:59:48 ltt_ [~ltt_@201.75.216.14] has joined #sbcl
23:01:02 davazp [~user@70.Red-79-152-117.dynamicIP.rima-tde.net] has joined #sbcl
23:08:25 -!- drmeister [~drmeister@pool-71-175-2-214.phlapa.fios.verizon.net] has quit [Remote host closed the connection]
23:38:12 -!- Bike [~Glossina@c-24-21-88-250.hsd1.wa.comcast.net] has quit [Ping timeout: 245 seconds]
23:40:26 ppc addic.
23:40:26 Add Immediate Carrying and Record: http://www.nersc.gov/vendor_docs/ibm/asm/addic_dot.htm#idx270
23:40:53 Ah, a 404. Lovely.
23:40:59 ppc addic
23:40:59 Add Immediate Carrying: http://www.nersc.gov/vendor_docs/ibm/asm/addic.htm#idx266
23:42:30 Oh, right. The rule was "crib the code from the PPC, but look to the MIPS version to understand what it does and how".
23:53:24 Bike [~Glossina@71-222-62-106.ptld.qwest.net] has joined #sbcl