00:14:21 -!- daimrod [daimrod@91.121.93.86] has quit [*.net *.split] 00:14:38 The plain fact of the existence of CMUCL's cgc.[ch] is interesting, in and of itself, and suggestive when it comes to SBCL's gencgc. 00:19:24 |3b| [foobar@cpe-72-177-66-41.austin.res.rr.com] has joined #sbcl 00:25:37 Okay, cmucl cgc seems to be an odd variant on a cheney twospace collector, only with "regions" that can be flipped from one region to the other without having to relocate the objects within. 00:26:17 And DTC apparently wrote the original gencgc. 00:26:38 Over '96-'99. 00:28:15 And I'm beginning to understand why WHN might have wanted to get away from CMUCL. Ye gods does CMUCL have a different idea about maintaining source code. 00:41:45 And a moment of "this seems awful sophisticated and coherent for a comment in CMUCL source" passes as I realize that it's a copy of a comment that I wrote for SBCL about three years ago. (-: 00:47:57 :)) 00:58:47 ... dont_move pages not getting WPd seems to be an SBCLism. 01:02:12 daimrod [daimrod@91.121.93.86] has joined #sbcl 01:04:27 -!- wbooze [~wbooze@xdsl-78-35-142-240.netcologne.de] has quit [Ping timeout: 245 seconds] 01:04:35 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Ping timeout: 245 seconds] 01:05:30 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 01:15:57 -!- Bike [~Glossina@75-164-174-146.ptld.qwest.net] has quit [Ping timeout: 256 seconds] 01:50:27 Wow, seven years and four months between the initial landing of thread support (dan barlow at around 2003-04) and the first non-x86oid threaded target (me, at around 2010-08). And the runtime wasn't properly thread-safe until the latter date. 01:57:58 pkhuong_: Is commit b7eed59f1877263e1af5ad80299e641e8276f77d doing what I think it's doing WRT write-protection and pinned pages? 02:00:15 so, "danb` what were you thinking?" eh? 02:01:21 the good news is I think I understand what's going on in the garbage_collect_generation hunk 02:01:33 we don't preserve pointers that aren't in from_space. 02:02:02 Right, so we don't need to clear the flag unless the page is in from_space. 02:02:41 The only question is, why skip write protection if an object is pinned for alien access? 02:03:11 right. 02:03:33 Like I said DTC had a comment re SCL to the effect that doing so is FFI friendly, but I don't buy that. 02:04:48 I'm wondering if I might ALMOST buy that, given that some system calls will error out rather than trip a write barrier. 02:06:22 yes, but we already have that issue 02:06:35 pin an object that's already WPed -> lose. 02:07:23 But yeah, we're looking at something nearly a decade old, by a programmer who has long since retired from the field, and who is more respected for his accomplishments than his ability to write understandable, maintainable code. 02:07:26 I could see leaving unWPed pages as is, but not the whole object. 02:11:36 Okay, there's no documentation in that commit that so much as implies that the pages won't be WP'd at the runtime's whim. 02:16:19 I think that I'm going to kill the WP restriction, as a separate commit, and include reference to where it was originally added and speculation as to the "benefits". 02:16:34 completely? 02:17:20 My position is going to be that it makes no sense for pinned objects to override the normal WP behavior for a page. 02:17:56 pretty sure that's going to break some code 02:17:59 A boxed page should be WP'd. An unboxed page shouldn't be WP'd. And pinning an object on a boxed page shouldn't change this. 02:18:19 Such as? 02:18:30 1) what happens on core load, for unboxed pages? 02:18:42 2) what do you do if you need to pass small unboxed vectors to C? 02:18:55 (that'll then syscall on the vectors) 02:19:38 For case 1, are we talking about loading a cold-core, or a saved core? 02:19:42 savec core 02:19:47 Bike [~Glossina@75-164-174-146.ptld.qwest.net] has joined #sbcl 02:19:47 *saved 02:19:52 Unboxed pages don't get WP'd there anyway. 02:19:59 is that new? 02:20:15 No, they've never been WP'd there, AIUI. 02:20:27 I'm positive there was a time when we WPed everything on core load 02:20:47 Unboxed pages, because they don't contain boxed pointers, don't need a write barrier. 02:21:03 but they're interleaved with boxed pages, and we just run a huge contiguous mprotect 02:21:29 ISTR a hungarian bug report on that kind of issue, and the only fix that came up was to pin the vector and write in < 4k increments to it before executing a syscall. 02:21:46 Hrm, you're right. All pages loaded from a saved core are considered to be boxed. 02:22:16 not oncisdered boxed, but they're WPed and silently unprotected for unboxed pages 02:22:40 Oh, wait, that's for !partial_pickup. 02:22:54 (and I'm amazed at how badly I mangled "considered.") 02:23:11 Which means that the boxed / unboxed page distinction survives a core save. 02:23:37 Case 1 seems to me to be a non-issue. 02:23:43 Besides, we don't pin over a core save. 02:24:17 no, the issue is: allocate a huge unboxed vector, pin it. Usually works fine. After a core load, if the vector is WPed, pinning doesn't suffice. 02:25:10 so we tell users to pin, write from lisp, and then FFI, but your patch would leave a race condition with GC between (some) writes from lisp and FFI 02:26:56 gc_alloc_large() and maybe_adjust_large_object() both honor boxed/unboxed page distinctions. 02:27:13 again, that was only after a load 02:27:30 Maybe the core saving code is broken? 02:28:30 perhaps. 02:28:40 Or the core loading code, for that matter. 02:29:02 but only protecting boxed pages is a ton of syscalls. 02:29:18 regardless, that still leaves small unboxed vectors. 02:29:28 Supposedly, we only protect unpinned boxed pages anyway. 02:29:35 And, yes, small unboxed vectors remain. 02:31:23 nyef_: I mean, at core-load time. 02:33:54 If we split allocation into boxed and unboxed allocation in the compiler, telling it about both a boxed and unboxed allocation region, would that issue Go Away Entirely? 02:34:34 I think so 02:34:56 I don't, but I think it'll get the worst of it. 02:35:18 To get the last of it, we'd need to fix genesis to split up boxed and unboxed allocation, and to emit a page table on gencgc ports. 02:35:33 not entirely, but enough so that we can tell ourselves (who else does that? ;) to stop playing dirty tricks. 02:36:25 Another possibility would be to get real stack-maps and register-maps for precise GC on x86oids, leaving us with JUST the pinned objects for conservative roots. 02:37:07 And we can completely evacuate boxed objects from pages with conservative roots. 02:37:36 But that's clearly a long-shot project at this point. 02:37:44 right. I'm not holding my breath. 02:38:39 Yeah, neither am I. 02:39:17 -!- christoph2 [~christoph@ppp-188-174-30-114.dynamic.mnet-online.de] has quit [Ping timeout: 252 seconds] 02:40:54 well, back to parsing object files to build a poor man's runtime compiler. 02:41:41 Oof. Good luck. 02:42:09 well, it's fun and cross-platform ;) 02:42:41 Oh, for the love of... 02:42:59 The page table parsing code is OBVIOUSLY broken. 02:43:21 good. I thought I didn't understand it (: 02:43:44 It seems to be one word per page. 02:44:46 But the low two bits of each word is treated as the allocation flags for the page, which is desperately wrong because there are three allocation bits and the low bit is the open-region flag. 02:46:05 does it adjust for the two possible sizes of page_bytes_t? 02:46:08 Just going to double-check against the core saving code. 02:46:55 It's... not setting bytes_used? 02:47:48 Ye gods this is horrific. 02:48:29 "Thanks to alignment requirements, the low two bits are always zero", but it's bloody region_start_offset, which is in multiples of -GENCGC_CARD_BYTES. 02:48:30 is that code ever invoked? At this point I'm surprised anything works (: 02:48:52 Yes, it's invoked. I had to fix a bug in it earlier this month. 02:49:24 I'm not fixing this tonight. I'm making a note about it and leaving it until tomorrow. 02:51:05 ... nikodemus. I thought nikodemus was beyond making mistakes like this? 02:52:14 christoph2 [~christoph@ppp-46-244-143-38.dynamic.mnet-online.de] has joined #sbcl 02:53:12 I doubt gencgc + coreparse fits in anyone's head currently 02:53:33 I doubt gencgc fits in any active maintainers head right now. 02:53:38 Let alone coreparse. 02:54:46 Actually, it might be that the save/load logic was correct at the time, and that the number of allocation bits was subsequently increased. 02:56:31 Hrm. So all loaded regions are either "free" or "unboxed data". 02:57:33 How the heck did this ever work? 02:59:43 leuler changed the pagetable format a couple years ago to make it more calloc friendly. Documentation might have lagged. 02:59:53 -!- Watcher7 is now known as Watcher7|off 02:59:54 Ah! The comments are out of date. 03:00:24 The comments say that the open region flag is the low bit, and it's actually the high bit. 03:01:28 It's non-optimal, as we lose the bytes_used value over save/coreparse, but the logic is correct. 03:04:04 -!- Watcher7|off is now known as Watcher7 03:07:35 pranavrc [~pranavrc@122.174.43.18] has joined #sbcl 03:10:44 ... region_start_offset is always a multiple of -GENCGC_CARD_BYTES, bytes_used is always <= GENCGC_CARD_BYTES and =0 for free pages and >0 for allocated pages, and bytes_used always has the low (1+ WORD-SHIFT) low bits clear due to alignment. 03:12:40 WORD_SHIFT is always at least two, which means that we have three bits available. I can pack everything except the generation index into a single word for saving into the core file. 03:23:29 -!- drmeister [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [*.net *.split] 03:29:23 Ah, and as a data point on that "large unboxed objects in core files" thing, adding allocation information to the saved page tables was 1.0.32.25, on 2009-11-11. 03:30:07 Prior to that, we'd've WP'd everything on core load. 03:37:35 And I think that it's time I got some sleep. 03:37:39 -!- nyef_ [~nyef@pool-64-222-174-41.man.east.myfairpoint.net] has quit [Quit: G'night all.] 03:37:46 -!- LiamH [~none@96.231.225.69] has quit [Quit: Leaving.] 03:41:02 drmeister1 [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 03:49:17 -!- drmeister1 [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 03:49:56 LiamH [~none@96.231.225.69] has joined #sbcl 03:50:08 ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has joined #sbcl 03:50:26 drmeister1 [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 03:54:55 -!- drmeister1 [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has quit [Ping timeout: 246 seconds] 04:04:07 -!- LiamH [~none@96.231.225.69] has quit [Quit: Leaving.] 04:06:41 -!- Bike [~Glossina@75-164-174-146.ptld.qwest.net] has quit [Ping timeout: 245 seconds] 04:19:08 Bike_ [~Glossina@75-164-174-146.ptld.qwest.net] has joined #sbcl 04:32:17 -!- pranavrc [~pranavrc@122.174.43.18] has quit [Remote host closed the connection] 05:01:31 -!- Bike_ is now known as Bike 05:38:48 scymtym [~user@89.31.118.161] has joined #sbcl 05:49:07 -!- robgssp [~user@2620:8d:8000:e50:21c:c0ff:fea3:7cc5] has quit [Ping timeout: 264 seconds] 05:53:56 Strigoides [~owen@114-134-0-102.lightwire.co.nz] has joined #sbcl 05:57:46 robgssp [~user@2620:8d:8000:e50:21c:c0ff:fea3:7cc5] has joined #sbcl 06:00:14 sdemarre [~serge@91.176.198.219] has joined #sbcl 06:11:32 -!- Watcher7 [~w@silly.tabby.cat] has left #sbcl 06:21:55 -!- Strigoides [~owen@114-134-0-102.lightwire.co.nz] has quit [Quit: leaving] 06:26:05 -!- ehaliewicz [~user@50-0-51-11.dsl.static.sonic.net] has quit [Read error: Operation timed out] 06:49:53 Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has joined #sbcl 07:07:17 -!- 6JTAAJHK0 is now known as ASau 07:23:55 Krystof [~user@81.174.155.115] has joined #sbcl 07:23:55 -!- ChanServ has set mode +o Krystof 07:24:11 angavrilov [~angavrilo@217.71.227.190] has joined #sbcl 07:26:51 lichtblau [~user@port-212-202-134-139.static.qsc.de] has joined #sbcl 07:32:12 -!- Quadrescence [~quad@unaffiliated/quadrescence] has quit [Quit: Leaving] 07:33:58 attila_lendvai [~attila_le@92.46.8.95] has joined #sbcl 07:33:58 -!- attila_lendvai [~attila_le@92.46.8.95] has quit [Changing host] 07:33:58 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 07:52:39 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 08:05:20 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Quit: leaving] 08:12:42 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 08:33:13 -!- sdemarre [~serge@91.176.198.219] has quit [Ping timeout: 256 seconds] 08:48:11 -!- antoszka_ is now known as antoszka 08:49:53 sdemarre [~serge@109.134.154.83] has joined #sbcl 08:57:05 stassats [~stassats@wikipedia/stassats] has joined #sbcl 08:57:38 wbooze [~wbooze@xdsl-78-35-142-240.netcologne.de] has joined #sbcl 08:59:05 samskulls [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 09:05:10 -!- specbot [~specbot@common-lisp.net] has quit [Remote host closed the connection] 09:06:24 minion [~minion@common-lisp.net] has joined #sbcl 09:06:24 specbot [~specbot@common-lisp.net] has joined #sbcl 09:16:49 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 09:50:47 davazp [~user@92.251.221.46.threembb.ie] has joined #sbcl 09:51:57 -!- pkhuong_ [~pkhuong@gravelga.xen.prgmr.com] has quit [Remote host closed the connection] 09:59:55 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 256 seconds] 10:19:37 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 10:30:41 teggi [~teggi@113.173.18.21] has joined #sbcl 10:32:11 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Quit: Leaving.] 10:32:30 -!- wbooze [~wbooze@xdsl-78-35-142-240.netcologne.de] has quit [Ping timeout: 256 seconds] 11:08:29 edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has joined #sbcl 11:31:43 -!- sdemarre [~serge@109.134.154.83] has quit [Ping timeout: 256 seconds] 11:43:14 wbooze [~wbooze@xdsl-78-35-188-153.netcologne.de] has joined #sbcl 11:54:49 -!- cmm- [~cmm@bzq-79-182-100-51.red.bezeqint.net] has quit [Read error: Operation timed out] 11:55:16 cmm [~cmm@109.65.105.2] has joined #sbcl 11:57:30 -!- samskulls [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Ping timeout: 256 seconds] 12:07:18 -!- wbooze [~wbooze@xdsl-78-35-188-153.netcologne.de] has quit [Quit: none] 12:08:42 -!- davazp [~user@92.251.221.46.threembb.ie] has quit [Remote host closed the connection] 12:08:55 -!- Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has quit [Remote host closed the connection] 12:12:43 sdemarre [~serge@109.134.154.83] has joined #sbcl 12:17:44 wbooze [~wbooze@xdsl-78-35-188-153.netcologne.de] has joined #sbcl 12:21:17 attila_lendvai [~attila_le@92.46.8.95] has joined #sbcl 12:21:17 -!- attila_lendvai [~attila_le@92.46.8.95] has quit [Changing host] 12:21:17 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 12:30:05 pkhuong [~pkhuong@modemcable086.239-37-24.mc.videotron.ca] has joined #sbcl 12:55:50 stassats` [~stassats@wikipedia/stassats] has joined #sbcl 13:04:20 -!- yacks [~py@180.151.36.168] has quit [Ping timeout: 240 seconds] 13:11:16 yacks [~py@180.151.36.168] has joined #sbcl 13:31:51 drmeister1 [~drmeister@pool-173-59-25-70.phlapa.fios.verizon.net] has joined #sbcl 13:51:55 prxq [~mommer@mnhm-5f75eeba.pool.mediaWays.net] has joined #sbcl 13:55:16 Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has joined #sbcl 14:18:01 -!- stassats [~stassats@wikipedia/stassats] has quit [Write error: Broken pipe] 14:29:05 nyef [~nyef@pool-64-222-174-41.man.east.myfairpoint.net] has joined #sbcl 14:29:15 G'morning all. 14:30:45 So, I've been thinking about unboxed data. My current theory is that unboxed data is any simple-vector with a specialization other than T, SAPs, and anything from the numeric tower other than ratios and unspecialized complexes. Does that seem about right? 14:31:31 structure slots? 14:32:18 I'm looking for purely unboxed objects, not hybrids. 14:32:21 and characters 14:32:38 Characters are immediate types, also not what I'm looking for. 14:33:37 I'm looking for things that would be heap-allocated, not immediate data, and that don't need to be scanned for references. 14:37:31 -!- scymtym [~user@89.31.118.161] has quit [Ping timeout: 245 seconds] 14:39:08 (and (not simple-vector) simple-array), I guess. 14:41:34 Doesn't that have an array header? 14:42:00 pkhuong: doesn't that leave simple-array-t? 14:44:23 -!- sdemarre [~serge@109.134.154.83] has quit [Ping timeout: 256 seconds] 14:45:44 and non-vector types 14:46:43 stassats`: ... simple vector? 14:47:21 For the non-vector types I think that I can get away with either a flag at objdef time or direct manipulation of the MOVE VOPs. 14:49:58 floats, complex floats 14:50:24 Falls under "anything from the numeric tower" without falling under the two given exceptions. 14:50:46 Ah I see I'd split the enumeration wrong ;) 14:50:48 And also fall under the "MOVE VOPs" clause for implementation. 14:50:52 pkhuong: simple-vector is (simple-array t (*)), that still leaves (simple-array t *) 14:51:19 stassats`: I was referring only to vector types. 14:52:22 I think anyone working in that area knows that non-vector arrays are implemented by indirecting into a vector 14:54:48 And, on a related topic, should I update the save/coreparse code to also store the bytes_used and large object flag for each page, given that it won't take any extra space in the core file? 14:55:21 Any downside or potential backward compatibility break for programs? 14:55:37 Well, the core file format would change... 14:55:46 I can't think of anything here, except perhaps slower load? 14:56:12 That too, but not by overmuch. Unpacking an extra two fields per GC page. 14:57:26 nyef: if you're going to work in that area, maybe you can commit something like https://github.com/pkhuong/sbcl/tree/cleverer-array-alloc, and help eliminate a stupid class of heap exhaustion bugs. 14:59:44 pkhuong: What does this branch do? 15:00:09 davazp [~user@178.167.168.15.threembb.ie] has joined #sbcl 15:00:33 triggers a GC instead of dropping to LDB when allocating large arrays with too little heap left 15:01:06 Ah. Hrm... 15:01:21 The limit is really on address space, rather than memory, isn't it? 15:01:35 whatever the user set as the maximu heap size 15:01:52 it tries to allocate; on failure, drop out of PA, force a GC, try again, force a major GC, try again, and then ldb. 15:03:20 we only do that for vectors because other objects are usually small enough, and the allocation sequence for vectors (and everything else, most likely) is correct when we turn PA off and back on before allocating 15:04:19 Yeah, sounds about right. The only other possibly-stupidly-large objects are code-objects. If someone has a class or struct with enough slots to trip this, they're doing something wrong. 15:06:38 class slots indirect via a vector anyway (: 15:06:58 Struct slots don't, though, surely? 15:07:06 That just makes it Even More Wrong. 15:07:21 not anymore (the old unboxed slot hack) 15:07:55 Old unboxed slot hack? 15:08:38 Is this one of those things where I'm going to say "please, bring that back, I know how to use it to make non-x86oid backends even more awesome"? 15:08:46 hmm 15:08:49 before storing unboxed slots at offsets from the end of the struct, we had a slot that referred to an unboxed vector 15:08:56 is the documentation borken on 1.1.7? http://paste.faui2k9.de/f/ba5a7caaa8b8ed55ad6f9d5850969f04c5c67bb7efd97fe07d190bca5d964af2 15:09:27 ... Yes. Yes, it is. If we can stack-allocate unboxed vectors on the number stack, we could stack-allocate structs with unboxed slots on said backends. 15:09:28 christoph2: I vaguely remember a texinfo version mismatch. 15:10:08 meaning what exactly? I need newer texinfo to build it? 15:13:21 christoph2: or an older. I think there was a post about that on -devel a couple months ago. 15:14:58 hm there's a mention of texinfo in Nov 2011 15:15:17 Heh. I love using rebase --interactive to re-order commits. 15:17:15 nothing obvious since 1.1.4 and even 1.1.6 worked fine 15:17:37 though I might have updated 4->5 in the meantime, let's see 15:18:01 Hydan` [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has joined #sbcl 15:19:12 angavrilov_ [~angavrilo@217.71.227.190] has joined #sbcl 15:22:53 robgssp` [~user@2620:8d:8000:e50:21c:c0ff:fea3:7cc5] has joined #sbcl 15:23:23 _8david [~user@port-212-202-134-139.static.qsc.de] has joined #sbcl 15:24:46 -!- Hydan [~hydan@ip-89-103-110-5.net.upcbroadband.cz] has quit [*.net *.split] 15:24:47 -!- angavrilov [~angavrilo@217.71.227.190] has quit [*.net *.split] 15:24:48 -!- robgssp [~user@2620:8d:8000:e50:21c:c0ff:fea3:7cc5] has quit [*.net *.split] 15:24:51 -!- Ralt [Ralt@2a01:7e00::f03c:91ff:feae:6c69] has quit [*.net *.split] 15:25:25 So, I'm not sure that I'm going to commit this immediately, but it doesn't break the build on x86-64, and makes a certain amount of sense to me: http://repo.or.cz/w/sbcl/nyef.git/commitdiff/5846ccaaf2779ded7b95522b509f2c548367c083 15:28:59 I don't get the second bullet point 15:29:47 -!- flip214 [~marek@unaffiliated/flip214] has quit [Write error: Broken pipe] 15:29:49 -!- pchrist [~spirit@gentoo/developer/pchrist] has quit [Write error: Broken pipe] 15:29:50 -!- angavrilov_ [~angavrilo@217.71.227.190] has quit [Write error: Broken pipe] 15:29:50 -!- lichtblau [~user@port-212-202-134-139.static.qsc.de] has quit [Write error: Broken pipe] 15:31:38 -!- asedeno [asedeno@nat/google/x-moxlyuctlwwlrgoi] has quit [Remote host closed the connection] 15:31:38 Ralt [Ralt@2a01:7e00::f03c:91ff:feae:6c69] has joined #sbcl 15:31:42 If a page is mostly live, why bother evacuating it? 15:31:43 angavrilov_ [~angavrilo@217.71.227.190] has joined #sbcl 15:31:46 flip214 [~marek@86.59.100.100] has joined #sbcl 15:31:46 -!- flip214 [~marek@86.59.100.100] has quit [Changing host] 15:31:46 flip214 [~marek@unaffiliated/flip214] has joined #sbcl 15:32:21 asedeno [asedeno@nat/google/x-ajzupwapmbjuyrba] has joined #sbcl 15:33:16 Flip it to newspace directly, we don't have to allocate enough space to hold all the live data AGAIN while we keep the old page around so that we can follow forwarding pointers. All of the references stay the same, so we just have to update outbound references not inbound references. 15:33:29 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 15:34:24 Basically, reduces peak memory load during GC if we don't have to have basically twice as much memory as we have unpinned pages with live data in the generation being collected. 15:34:44 I see that part. How is it enabled by the first change? 15:35:12 It's simplified, as we can just set the dont_move bit. 15:35:32 Instead of having to grovel through and relocate the pages immediately. 15:35:35 ok. 15:36:12 So, I should probably update the commit message to say "simplifies" rather than "enables"? 15:36:16 so now dont_move flag means don't move anything in that page, rather than "there's a conservative reference in that page" 15:37:53 Yeah. We don't actually care about the existence of conservative references beyond that the objects involved stay both live and in the same place. 15:38:43 Well, plus the whole WP thing. 15:38:53 now you're trying to copy less rather than more ;) 15:39:02 Yes! 15:40:14 If copying less means lower peak address space load, I'm all for it. 15:41:04 -!- teggi [~teggi@113.173.18.21] has quit [Remote host closed the connection] 15:42:28 And if we're only evacuating pages below a certain threshold of live allocation units, we could do the whole side-band forwarding pointer thing, and free the underlying memory. And I'm wondering if that also means that we could re-use the address space immediately, even before fixing up all of the old references, which would further reduce our peak address space load. 15:42:39 Or could, at least. 15:44:21 ok. Time to work on an address -> address dictionary. 15:44:49 Heh. 15:45:33 And here I thought that this was just going to take a weekend to rough in, but the rabbit hole just keeps getting deeper. 15:55:09 Either I've misunderstood the meaning of region_start_offset, or it's misleadingly commented. 15:56:16 given a page, it points back to the beginning of the allocation region. 15:56:38 (which is often in an lower-address page) 15:58:38 i guess the comment in gencgc-internal flipped the sign of the offset. 15:58:57 So, if you open an alloc region beginning in a partially-filled page, the start offset will be positive for the first page in the region and negative for the others? 16:00:40 I'm not sure how that's handled :\ 16:01:11 iirc, bytes_used also includes what was allocated before. 16:01:17 Yeah, I'm going to have to dig into this a bit myself. 16:01:29 Yes, bytes_used is basically the high-water-mark for the page. 16:02:02 And why do we even need to know the start offset? 16:02:36 And there's a lot of repetitive-seeming code in here. 16:02:39 to scan for objects 16:03:02 We can't tell what'sa header and what isn't except by scanning from the beginning of the allocation region. 16:03:56 We have to start scanning from a known object boundary, yes, but that doesn't necessarily mean that we need to start from an allocation region boundary... 16:04:18 well, that's what passes for common sense in gencgc-land ;) 16:07:52 search_dynamic_space() is broken if page_region_start points to within a page. 16:08:02 (as opposed to a page boundary) 16:09:07 There are a number of places where region_start_offset is asserted to be zero, but those could be special cases. 16:10:44 And if we open an alloc region in an already-partially-full page, we end up with a page_region_start that points to within a page. 16:12:05 Practical upshot: We can probably contrive a scenario that breaks conservatism this way. 16:21:52 Open an allocation region. Fill a chunk of a page. Close the region. Open a new allocation region starting on the same page. Try to pin an object from the first allocation region. The object won't pin, because it can't be found via search_dynamic_space(). 16:25:15 -!- ASau [~user@p4FF972AF.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds] 16:25:19 -!- davazp [~user@178.167.168.15.threembb.ie] has quit [Ping timeout: 246 seconds] 16:28:28 ASau [~user@p4FF972AF.dip0.t-ipconnect.de] has joined #sbcl 16:38:28 What are the costs associated with larger GC pages again? Is it just the expense of evacuating them and the granularity of tracking "young" pointers from them if the write barrier is tripped? 16:40:09 needing to scan more of the the heap for a minor gc is the biggie 16:41:04 last I tested it the optimal allocation region size seemed to be 8kB, so you certainly would not have wanted a larger page size 16:41:10 though that was a long, long time ago 16:41:34 I believe nikodemus bumped that up to 32 KB after working with ITA some time ago 16:49:33 So if we had finer-grained tracking for young pointers, we could bump the page size considerably? 16:52:03 are you suggesting a software write barrier? 16:52:51 ok texinfo 4 and sbcl documentation boulds, texinfo 5 not so much 16:53:34 No, I'm suggesting that we can track WP violations at the granularity of the hardware page size, even if our GC page size is larger. 17:02:56 -!- stassats` [~stassats@wikipedia/stassats] has quit [Ping timeout: 256 seconds] 17:11:03 and what's the goal? reducing the page table size? 17:12:39 I'm not sure where I'm going with that, actually. 17:13:37 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Quit: Leaving.] 17:14:36 fair enough :-) 17:15:00 so right now there are two related concepts: the page and the allocation region 17:15:30 I'm now fairly well convinced that the region_start_offset logic is broken, primarily due to its ability to hide valid objects from the conservative root logic and from MAKE-LISP-OBJ (and thus the debugger). 17:16:02 but the allocation regions don't really exist for old generations, they're effectively just reconstructed whenever needed 17:17:21 Mmm... Allocation regions don't exist for old generations, period. They only ever exist for newspace, surely? 17:18:39 so whenever we're scavenging an old generation, we scavenge the whole original allocation region 17:18:46 well, not "original" 17:18:52 samskulls [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 17:19:27 even if just one page inside the region had its write barrier hit 17:19:30 Are we talking "looking for references that need relocation" or "evacuating objects from pages"? 17:21:04 Okay, write barrier in play, that means the former... 17:22:27 So in practical terms, we need to start scanning from an object boundary that is before the end of the page, and not after the beginning of the page, right? 17:23:09 and potentially continue beyond the end of the page 17:23:23 And things would be a lot simpler if the only times an allocation region were permitted to cross a page boundary is if it were for a large object... 17:23:26 likewise preserve_pointer() will pin more pages than just one 17:23:54 Right, right, even though preserve_pointer() really only needs to pin a single object. 17:23:55 s/just one/just the one that pointed to from a conservative root/ 17:24:24 so what I'm mainly getting at is that we already have this "larger than page" concept 17:24:35 (certainly a suboptimal one) 17:25:05 and it seems like it'd be useful to actually reify that concept 17:25:16 if there's a need for a larger page-like entity 17:29:04 thinking a bit, I guess the reason things work the way they do is that in the current design there are no extra indirections, and since the address -> page lookup is fast 17:30:31 if those are actually important properties, I guess I could see the point of slightly a larger gc page, able to track the wp state of its constituent physical pages 17:32:21 Mmm. And I don't know what the really important properties are, here, but I do know that some of this logic is arguably wrong. 17:36:37 Why is the allocation region size a tunable parameter? 17:41:01 I don't think your plan for fooling pinning works. if you start a new region from the middle of a page, region_start_offset is not changed 17:42:36 Good catch, and that makes me a lot more comfortable about the whole logic, even if I can't do what I wanted to do with saved core files. 17:46:42 You know what would massively simplify a lot of this logic? If the only allocation regions permitted to cross a page boundary were for large (> page size) objects, and if opening a new alloc region always required a completely free page. 17:47:16 And when dealing with scavenging newspace, we can give an exemption to the rule about the new alloc region requiring a completely free page. 17:49:02 region_start_offset becomes zero except for large-object pages, a LOT of page_table scanning/manipulating logic just disappears, and so on. 17:50:17 And I'm liking the idea of this simplification too much to be able to come up with plausible-sounding downsides. 17:50:44 I don't see how that works 17:50:59 Which bit? 17:51:13 "region_start_offset becomes zero" 17:52:01 If regions are only allowed to be on a single page, and must be completely empty pages when opened, then region_start_offset is zero. 17:52:04 the point of region_start_offset (as I understand it) is to find a place where an object boundary is guaranteed 17:53:04 oh, didn't realize you meant only having one page / region 17:53:31 Yeah. An allocation region would not be allowed to cross a page boundary unless it was a large-object region. 17:54:15 and that'd be combined with a larger page size? 17:54:45 since the downsides to 4kB alloc regions would be obvious :-) 17:55:19 32kB alloc regions at this point, I believe. 17:56:58 But if we combine single-page regions with larger pages and tighter WP tracking (optionally with lazy set-up for finding the last object boundary before the WP boundary)... 17:59:54 At the very least, even without changing the way the GC behaves in the large, improving the documentation and reducing code duplication is in order. 18:04:08 Oh, and throw in allocating unboxed objects directly to unboxed regions, and widely separating boxed and unboxed regions in the heap (say, putting unboxed data towards the top end growing down, and boxed data towards the bottom end growing up), or something like that... 18:05:59 is there any benefit to allocating unboxed objects directly to unboxed regions? 18:06:15 the main benefit of unboxed regions is that you don't need to scan them for pointers 18:06:33 You know how pinned pages don't get WP'd? 18:06:35 but you won't do that for newspace anyway 18:07:21 ah, I see 18:07:22 The only cases that we were able to come up with where not WPing a pinned page makes sense involves unboxed objects and system calls. 18:07:42 And I tracked down the commit which STARTED the whole pinned pages not being WP'd in the first place. 18:08:33 I'd like to change it so that pinned pages can be WP'd if they are boxed pages, but that means separating out unboxed data from the start. 18:09:19 And, yes, I realize that this means some heavy lifting at genesis time, or starting out a cold core by doing a full GC before starting !COLD-INIT. 18:09:53 (Fortunately, I fixed things years ago so that we CAN do things like that without screwing up due to having SAPs pointing to random places in the heap.) 18:10:34 a full gc before cold-init would kind of suck for porting 18:10:47 True. 18:10:52 Since it'd kill the map file. 18:10:58 So, far better to push it back to genesis. 18:14:27 *nyef* sighs. 18:15:00 davazp [~user@178.167.150.166.threembb.ie] has joined #sbcl 18:15:33 I thought this was going to be a weekend hack. I really did. Instead, I have at least two more project descriptions to write, and the whole mess will take weeks just to get the basics in place. 18:34:06 -!- davazp [~user@178.167.150.166.threembb.ie] has quit [Ping timeout: 252 seconds] 18:34:19 While we're scavenging a region, we can "tighten up" the region_start_offset of any page after the first. 18:34:35 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 18:34:51 I fail to see why that wouldn't be a win. 18:38:38 hmm... so I don't see how it would be a loss, but it's not clear it'd be a win either 18:39:07 the problem is that it'll only help in the marginal case where you manage to adjust the offset to 0 18:39:22 Cuts down the lead space for scavenging when you're dealing with the tail end of a multi-page alloc region. 18:41:26 Leads to slightly faster conservative root checking, slightly faster MAKE-LISP-OBJ... And if you bring the offset to 0, less conservatism with pinned pages. 18:42:33 right now I believe that for scavenging / preserve_pointer there's no benefit to splitting an allocation region in two at anywhere except a page boundary 18:42:46 with sufficient other changes though it could be a big win 18:43:16 Less wading through objects during scavenge for a WP'd page means lower cache effects. 18:45:50 eheh 18:46:03 I definitely see the benefit of being able to tighten the scope of these kinds of operations :-) it's just that the quick hack of tweaking the region start doesn't accomplish that 18:46:25 except when you get lucky and tighten it to a page boundary 18:47:20 Some of the benefits require getting lucky in that way, but some of them work if you can tighten it up even so little as a cache line. 18:47:24 davazp [~user@92.251.208.99.threembb.ie] has joined #sbcl 18:59:50 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Quit: Leaving.] 19:22:46 -!- angavrilov_ [~angavrilo@217.71.227.190] has quit [Ping timeout: 246 seconds] 19:30:23 Large objects don't move, do they, they just get their pages flipped to newspace if they end up being live, right? 19:39:19 Quadrescence [~quad@unaffiliated/quadrescence] has joined #sbcl 20:03:10 davazp` [~user@92.251.208.99.threembb.ie] has joined #sbcl 20:11:46 -!- davazp [~user@92.251.208.99.threembb.ie] has quit [Read error: Connection reset by peer] 20:12:12 -!- Bike [~Glossina@75-164-174-146.ptld.qwest.net] has quit [Ping timeout: 256 seconds] 20:13:58 Okay, http://paste.lisp.org/display/137127 has most of my current thoughts on what we can do with gencgc. 20:15:49 I'd avoid the term simple-vector (especially with a hyphen), because simple-vector is (simple-array t 1). 20:16:49 Bike [~Glossina@75-164-174-146.ptld.qwest.net] has joined #sbcl 20:19:30 I think that every item on that list is reasonably well-motivated, and even if we stop short of computing markbits should be a good improvement over the status quo. 20:20:25 Well, the whole should be a good improvement. 20:20:45 I'm not sure about "arranging for GENESIS to output a page table": we increase the coupling between GC and the rest of the system, and I'm not sure I see how much of a win it is. 20:21:00 otoh, it can't hurt more than not having anything. 20:21:39 "Boxed pinned pages should be write protected" <- do we *unprotect* pinned but WPed pages? 20:21:50 Yes. 20:22:01 We unprotect every page in the generation we're scavenging. 20:22:10 We only pin pages in the generation we're scavenging. 20:22:16 ok, that really sucks. 20:22:24 And once we're done, we only re-protect boxed, unpinned pages. 20:22:30 I thought it only happened when the object was partially unWPed. 20:23:17 still, we have to keep in mind that we don't have explicit remembered sets, so we can't always re-protect unWPed pages. 20:23:33 Right. 20:23:37 ... adding that to the list. 20:24:29 "Track WP violations at a per-machine-page level, not per-gc-page" We've already split GC pages and allocation granularity. I'm still not sure I see the point in tracking writes at < GC page granularity. Just make GC pages smaller. 20:25:05 No, it goes with the limitation to single-GC-page allocation regions. 20:25:27 yeah, I see. 20:26:14 I'm coming at this from the opposite end it seems... "Only large-object regions should span multiple GC pages" seems wasteful. Lots of fragmentation for medium objects. Also, we'd have to bump the GC page size up to avoid slowing consing down too much 20:26:21 (especially with multiple threads) 20:27:27 I'm surprised you didn't mention keeping track of object boundaries somewhere, instead of constantly re-scanning chunks of the heap. 20:27:55 So, bump the GC page size up, and remember that we tend to evacuate pages when we GC, or if we have markbits we can create an allocation region within a range of formerly dead objects. 20:28:20 ISTM the more complex memory management could all be replaced by doing something like plugging a known malloc (say dlmalloc) on top of our heap. 20:28:57 I actually forgot about object boundary tracking on a sub-page granularity beyond our need to keep track of the "region_start_offset". 20:29:47 I work to bring the GC page down as low as possible without affecting allocation performance. 20:30:29 (because I work with GC page = card) You wish to embiggen GC pages, and have tiny cards. 20:30:35 Clearly I was right to put these items in the "more controversial options" section. 20:31:41 re remembered sets, it would be good to look for old-to-new pointers before leaving unprotected. 20:31:52 I believe that we do that already. 20:32:07 certainly not if it's pinned 20:32:25 We only pin pages in the youngest generation. 20:32:41 erh, what? 20:32:43 Hang on, there's something wrong there... 20:33:19 foreignFunction [~niksaak@ip-4761.sunline.net.ua] has joined #sbcl 20:33:24 Okay, if a page is pinned then we don't re-protect it anyway. 20:34:53 I'm putting "remembered sets" as "more controversial" at this point. 20:39:00 -!- slyrus [~chatzilla@adsl-76-254-42-198.dsl.pltn13.sbcglobal.net] has quit [Remote host closed the connection] 20:40:39 There's also the possibility that I'm not correctly understanding how remembered sets work at the moment... 20:42:30 reverse mapping from young objects to old references 20:43:27 Right, that makes sense, and is not at all what I had remembered. 20:43:49 Stripping the bit about remembered sets out from my notes. 20:44:08 Going to have to think about that one for a little bit before I come to any conclusion about it. 20:45:37 I don't think anyone else just keeps track of all potential old-to-new refs. In a non-moving GC, you can also only keep a conservative set of artificial roots. 20:48:24 On the whole, do these options seem like reasonable things to do? Is there a point at which they become less reasonable? 20:49:34 I'm not convinced on the GC pages size stuff 20:50:20 same for the free list etc. where ISTM we end up reimplementing a malloc. 20:50:21 Fair enough. But the things leading up to that? 20:50:51 on the fence re emitting a page table during genesis, but only because of extra coupling which could be an issue in ports 20:50:57 *new ports 20:51:59 Shouldn't be much of an issue with new ports, it'd be conditionalized for gencgc only, and tied to the gencgc implementation, not to anything precisely machine-specific. 20:52:41 sure, and new GC can either use the page table or ignore it as though it weren't there. 20:53:04 what's the benefit of having separate boxed/unboxed/etc pages during genesis? 20:53:08 Well, a new GC will probably have its own idea of what a reasonable page table is. 20:54:00 jsnell_: Similar to having it done during allocation in normal operation, I would think. 20:54:29 Although I'll admit that genesis is unlikely to be outputting very many unboxed objects that need to be written to by system calls. 20:54:34 nyef: but the last thing we do is save a core, so any benefit would be during bootstrap. 20:54:48 I only see consistency which can't hurt debugging 20:55:21 Consistency is a very strong argument, yes. 20:56:02 I think I might have forgotten to put something in these notes about trying to bunch boxed and unboxed pages in separate regions of the address space. 20:56:56 yes please. 20:57:14 not moving code pages as much would really help 20:58:24 Hrm... An awful lot of code objects are too small to trip the large_object's don't move thing, but markbits might help there. 20:59:09 Alternately, we could effectively "pin" any page that has a live code-object in it. 21:00:11 myeah... that's potentially a lot of zombie code objects that are kept alive by a single reference. 21:00:53 this is one of those cases where you'd want multiple allocation zones with different GC rules, no? 21:01:08 jsnell_: yes. We already have multiple zones, at least. 21:01:30 also we have a couple users who report insane core saving times with hundred-GC heaps. I think it's the heap compaction logic that doesn't scale well for tiny objects. 21:01:38 *hundred-GB heaps 21:02:07 copying for newspace data, mark-sweep-compact for oldspace data, mark-sweep for code, etc 21:03:15 it's surprising that the bear dances at all. asking it to dance well seems unreasonable ;-) 21:03:44 ... wrong lisp implementation, this is SBCL, not ABCL. d-: 21:04:43 it's looking at that wishlist that makes me think MPS might be a reasonable enginering choice 21:05:53 Some of this is complicated, sure, but quite a bit of it is actually low-hanging fruit. 21:09:13 Code pages are going to be relatively sparsely populated with respect to actual objects, aren't they? 21:10:06 That is, while they may have a lot of allocated bytes, they're going to tend to have larger (and thus fewer) objects occupying them than most pages. 21:14:03 seems likely (also easy enough to check from an existing core) 21:14:57 Yeah, I should be able to hack up a customization on ROOM to do a suitable breakdown. 21:17:13 If we don't have many objects per code page, doing a mark/sweep by maintaining a list of live objects should be quite doable. 21:24:02 Okay, the code-object for #'identity on my x86-64 build is 128 bytes. 21:24:38 And that has to be fairly minimal as far as code objects go. 21:32:10 -!- foreignFunction [~niksaak@ip-4761.sunline.net.ua] has quit [Quit: Leaving.] 21:42:19 -!- wbooze [~wbooze@xdsl-78-35-188-153.netcologne.de] has quit [Quit: none] 21:43:58 wbooze [~wbooze@xdsl-78-35-188-153.netcologne.de] has joined #sbcl 21:44:41 LiamH [~none@96.231.225.69] has joined #sbcl 22:11:44 -!- prxq [~mommer@mnhm-5f75eeba.pool.mediaWays.net] has quit [Quit: Leaving] 22:17:39 So, still picking at this project list, everything except for the "more controversial options" and the mark-bits stuff, plus separating boxed and unboxed pages and making code objects not moved is reasonable to work on? 22:17:43 -!- davazp` is now known as davazp 22:39:07 -!- edgar-rft [~GOD@HSI-KBW-149-172-63-75.hsi13.kabel-badenwuerttemberg.de] has quit [Quit: hallucinations] 22:57:24 -!- wbooze [~wbooze@xdsl-78-35-188-153.netcologne.de] has quit [Read error: Connection reset by peer] 23:30:54 nicdev [user@2600:3c03::f03c:91ff:fedf:4986] has joined #sbcl 23:34:31 Strigoides [~owen@114-134-0-47.lightwire.co.nz] has joined #sbcl 23:49:57 ASau` [~user@p5797F7E8.dip0.t-ipconnect.de] has joined #sbcl 23:53:46 -!- ASau [~user@p4FF972AF.dip0.t-ipconnect.de] has quit [Ping timeout: 256 seconds]