00:09:38 -!- rpg [~rpg@216.243.156.16.real-time.com] has quit [Quit: rpg] 00:10:48 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [Quit: Leaving.] 00:15:38 An awful lot of the darwin games are to do with broken backtrace heuristics, aren't they? 01:01:17 LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has joined #sbcl 01:02:25 -!- leuler [~user@p54902E49.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 01:07:46 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [Quit: Leaving.] 01:09:23 borkman [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 01:55:47 -!- nyef [~nyef@pool-70-109-144-138.cncdnh.east.myfairpoint.net] has quit [Quit: G'night all.] 02:23:15 LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has joined #sbcl 03:18:16 attila_lendvai [~attila_le@87.247.48.155] has joined #sbcl 03:18:16 -!- attila_lendvai [~attila_le@87.247.48.155] has quit [Changing host] 03:18:16 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 03:49:05 ASau` [~user@89-178-12-27.broadband.corbina.ru] has joined #sbcl 03:52:03 -!- jingtao [~jingtaozf@118.186.129.179] has quit [Remote host closed the connection] 03:53:20 -!- ASau [~user@89-178-201-27.broadband.corbina.ru] has quit [Ping timeout: 260 seconds] 04:01:19 -!- antgreen [~user@bas3-toronto06-1177698358.dsl.bell.ca] has quit [Ping timeout: 248 seconds] 04:07:10 borkman` [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 04:09:15 -!- borkman [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Ping timeout: 276 seconds] 04:18:32 borkman`` [~user@S0106001111de1fc8.cg.shawcable.net] has joined #sbcl 04:19:25 -!- borkman` [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Ping timeout: 240 seconds] 04:54:04 drl [~lat@110.139.229.172] has joined #sbcl 05:04:05 -!- LiamH [~healy@pool-108-18-166-81.washdc.east.verizon.net] has quit [Quit: Leaving.] 05:05:50 -!- drl [~lat@110.139.229.172] has quit [Remote host closed the connection] 05:38:30 -!- borkman`` [~user@S0106001111de1fc8.cg.shawcable.net] has quit [Ping timeout: 240 seconds] 06:04:12 |3b| [foobar@cpe-72-179-19-4.austin.res.rr.com] has joined #sbcl 06:06:56 angavrilov [~angavrilo@217.71.227.181] has joined #sbcl 06:28:29 drl [~lat@110.139.229.172] has joined #sbcl 06:46:01 Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has joined #sbcl 07:05:58 sdemarre [~serge@91.176.28.91] has joined #sbcl 07:29:42 -!- sdemarre [~serge@91.176.28.91] has quit [Ping timeout: 240 seconds] 07:48:09 drl_ [~lat@110.139.229.172] has joined #sbcl 07:54:06 -!- drl_ [~lat@110.139.229.172] has quit [Quit: Leaving] 07:54:26 drl_ [~lat@110.139.229.172] has joined #sbcl 07:56:08 -!- drl_ [~lat@110.139.229.172] has quit [Client Quit] 08:02:53 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 08:02:53 -!- ChanServ has set mode +o nikodemus 08:09:06 nikodemus: maybe you'll have any ideas on the following backtrace: http://www.sw4me.com/private/sbcl-backtrace-linux-amd64-kernel-3.1.txt 08:10:41 homie` [~levgue@xdsl-84-44-179-190.netcologne.de] has joined #sbcl 08:10:43 32 bit host 08:10:46 ? 08:10:57 64-bit 08:11:16 target as well, i assume 08:11:36 yep. It might be a new linux kernel thing.. 08:12:14 -!- homie [~levgue@xdsl-78-35-179-221.netcologne.de] has quit [Ping timeout: 244 seconds] 08:12:29 ..as it starts to happen after some uptime, and affects every SBCL on the machine (since 1.0.50 at least) 08:12:54 what's that number in hex? 08:13:18 system-internal-run-time has an (unsigned-byte 31) declaration for usecs 08:13:34 also, 18446744 is how 2^64 starts 08:13:42 18446744073 => 44B82FA09 08:14:39 that is 18446744073 = 2^64/10^n 08:14:51 fun 08:15:35 it occured to me that maybe it doesn't depend on uptime, but of actual time-of-day :) 08:15:49 what does getrusage actually use? 08:16:20 sorry, (unsigned-byte 31) for utime-secs and stime-secs 08:16:32 so it would have to be quite some large uptime 08:17:04 unless someone put -1 there to indicate error 08:17:17 I one saw a test which would fail when the test run was started before UTC midnight, and the actual test was run after it :) 08:17:51 yes, 18446744 is also how 2^63 - 1 starts 08:17:55 no, 2^64 -1 08:18:12 whatever. (Actually that's how I know the number... the answer to the chess-inventor's reward) 08:18:33 time-t & susecond-t, and timeval isn't grovelled.. 08:19:10 to the grovelmobile! 08:19:38 ugh 08:20:09 we should really add support for groveling structs for our own internals 08:20:16 I should have nade that groveled back when I discovered that openbsd needed some #+ and #- for timeval and timespec 08:20:53 I have a patch somewhere for cffi-grovel which makes it smart enough to discover the size and signedness of struct members 08:21:19 joshe, akovalenko: do either of you have time to attend to this this week? 08:23:12 to groveling struct timespec and/or timeval? 08:23:53 I can take a look 08:24:02 groveling the struct would be supergood, but i expect groveling the component types would be enough for now 08:24:24 no, components /are/ grovelled (except that susecond-t ifdef..) 08:24:39 oh 08:24:54 well, SBCL gives 64 bit for both time-t and suseconds-t.. 08:25:00 let's ask C now :) 08:25:52 *nikodemus* goes for more coffee 08:29:04 also, is anyone up for looking at lutz's latest, or should i put that on my queue? 08:31:26 --eval '(loop repeat 1000 do (setf * (get-internal-run-time)))' ;;; reproduced without any GC... 08:32:05 this time, it's 18446744072, not 18446744073 08:35:10 -!- slyrus [~chatzilla@adsl-99-49-14-228.dsl.pltn13.sbcglobal.net] has quit [Remote host closed the connection] 08:36:27 Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has joined #sbcl 08:41:34 *nikodemus* leaves for the office, bbl 08:43:20 ..time_t is signed. Is timeval guaranteed to be normalized?.. 08:46:07 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 248 seconds] 08:54:50 good morning everyone 08:57:26 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 08:57:26 -!- ChanServ has set mode +o nikodemus 08:58:02 -!- drl [~lat@110.139.229.172] has quit [Remote host closed the connection] 08:58:28 hej Blkt 09:03:18 -!- akovalenko [~akovalenk@77.51.6.233] has quit [Ping timeout: 240 seconds] 09:11:58 akovalenko [~akovalenk@95.73.216.28] has joined #sbcl 09:20:30 did something change recently that "make.sh some/path/run-sbcl.sh" loads my ~/.sbclrc ? or has it always been like that? 09:21:32 iirc, it always been like that. run-sbcl.sh will pass -no-userinit to SBCL. 09:25:25 *attila_lendvai* has found the new way: ./make.sh --xc-host='/path/sbcl-1.0.47-x86-64-linux/run-sbcl.sh --no-userinit' 09:26:41 drl [~lat@110.139.229.172] has joined #sbcl 09:29:02 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Disconnected by services] 09:29:03 nikodemus_ [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 09:29:03 -!- ChanServ has set mode +o nikodemus_ 09:29:26 nikodemus [~nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 09:29:26 -!- ChanServ has set mode +o nikodemus 09:31:56 -!- drl [~lat@110.139.229.172] has quit [Remote host closed the connection] 09:37:56 akovalenko: do you have a moment to talk about long/unsigned long cleanups? 09:46:15 nikodemus: yep 09:48:49 are your changes limited to a non-huge number of commits, or are they spread out? 09:49:22 i'm going to start a long-cleanup, and i'd like to reuse as much of your work as is feasible 09:50:03 you'd better roll your own, 'cause mine is wrong. Adding uword_t and sword_t was not a great idea, as I understand now. 09:50:08 ok 09:51:36 iirc, there's approximately one /major/ commit for uword_t/sword_t thing, but also several scattered commits for overlooked things.. 09:55:04 It all could be useful for enumerating places where long has to be replaced, but (1) it's pretty much every usage of long, if done rightly, (2) I didn't touch code that has no chance to run on Windows at all. Checking out my mswinmt/HEAD and grepping for word_t can still be useful, however. 09:59:21 ok 10:02:14 joshe: aroundp 10:03:17 re "If you have X Gb of physical memory..." sentence in *-devel: I frequently run huge images with a small working set (so unused regions of the image is just "a better swap" for all practical purposes). That's why I'm unsure that people are against running into swap generally. Maybe it's just me.. 10:05:10 i've had computers run into ground because SBCL started eating into swap, taking ages -- and sometimes losing other work -- before i managed to kill of the offending process 10:08:10 me too 10:08:34 it's easy to do something wrong that ends up in a loop of doom 10:08:50 well, "easy". Most people don't go around replacing %coerce-to-function 10:09:10 re. long/unsigned long cleanup. is there any platform we run on where os_vm_size_t actually meaningfully differs from size_t? 10:09:49 nikodemus pasted "here are the typedefs we have for it" at http://paste.lisp.org/display/126072 10:10:43 -!- easyE [mBcRsGbFde@panix2.panix.com] has quit [Ping timeout: 258 seconds] 10:11:48 on netbsd it is vsize_t, on (and bsd (not (or openbsd netbsd))) it's vm_size_t 10:13:09 well, I can say that for Windows size_t == os_vm_size_t (both 32 and 64-bit) 10:13:33 I would regard alpha as the most suspicious platform here.. 10:14:31 we only run linux on alpha, afaik, and it's size_t there 10:16:24 ..on lisp side, I use (alien unsigned) most of the time where word-sized integer is needed. More convenient than something involving #.sb!vm:n-word-bits. 10:16:35 the darwin typedefs for vm_size_t seem to be uintptr_t and natural_t 10:17:14 -!- peddie [~peddie@repl.esden.net] has quit [Quit: peace!] 10:17:37 well, uintptr_t is something that I would expect (and I also would expect sizeof(uintptr_t)==sizeof(size_t) for realistic SBCL targets) 10:19:46 ah dammit. i'll use os_vm_size_t everywhere at least /that/ will be an easy thing to search and replace with size_t if we can discover that it's what we want everywhere 10:20:14 (everywhere not meaning for every unsigned long, just everywhere where it makes semantic sense) 10:21:15 yep. After a long quest for unsigned wrongs, I have one high-priority recommendation: whatever type you'll choose, make it mechanically replaceable 10:22:16 aha! i just figured out why we call it os_vm_size_t 10:22:48 vm_size_t is a /mach/ type, and cmucl was originally part of the mach project at cmu... 10:23:06 so os_vm_size_t == whatever corresponds to vm_size_t on this os 10:23:26 Intensity [UgkqQK1boU@unaffiliated/intensity] has joined #sbcl 10:25:59 peddie [~peddie@repl.esden.net] has joined #sbcl 10:28:50 do we still have no places supporting both CAS and fetch-and-add?.. 10:33:31 no, but we could add atomic-incf support for slots and arrays of fixnums, and add cas support for arrays of fixnums as well 10:34:19 cas support on word-size is probably feasible as well, but needs careful language in the specification 10:35:27 well, I've already forgotten what wonderful stuff I was going to implement when there is a single place available for both. mutex refactoring, perhaps?.. 10:40:12 iirc futex-mutexes would benefit if we could do cas, atomic-add, and atomic-swap all on the same slot 10:40:35 re. ulrich depper's futexes are tricky -paper 10:41:59 yep (iirc, that paper exactly caused me to look for cas-able/faa-able place..) 10:45:37 nikodemu_ [~Nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 10:45:41 -!- nikodemu_ [~Nikodemus@cs181056239.pp.htv.fi] has quit [Remote host closed the connection] 10:46:57 I just roll my own ;) 10:47:36 are there any tricky things to consider when one wants to preserve sldb-show-frame-source functionality in the expansion of a macro? I know that the cons cell identities of the source code are used for that, but I can't seem to make it work inside hu.dwim.reiterate expansions, even when I preserve the identities in the expansion (although, the continuity of them is of course broken) 10:50:25 attila_lendvai: i don't remember offhand how that stuff works. it's something i always have to puzzle out anew 11:01:06 -!- homie` [~levgue@xdsl-84-44-179-190.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 11:03:25 homie [~levgue@xdsl-84-44-179-190.netcologne.de] has joined #sbcl 11:13:11 first slice https://github.com/nikodemus/SBCL/commit/e52d796778ab4ba8e5d567b393f5299e6a3d850d 11:17:35 ..who did division-by-multiplication and when? 11:18:56 ah, Lutz Euler on Jul 25 2011. Too late for causing my getrusage problems. 11:31:42 -!- drdo`` [~drdo@85.207.54.77.rev.vodafone.pt] has quit [Ping timeout: 240 seconds] 11:33:23 hmm. an attempt to strace SBCL causes pagefaults and CORRUPTION WARNING. 11:34:24 strace stuffs its own signal handlers into the process 11:34:37 and not in a nicely well-behaved chained-sigaction() way either 11:34:48 ah 11:35:12 akovalenko: pkhuong improved division-by-multiplication more recently than July, I'm sure 11:36:44 that's /too late/ (I see problems with earlier SBCLs, e.g. 1.0.50) 11:37:02 ..but, apparently, no problem with 32-bit one. 11:38:09 ba 11:38:20 h. There goes the easy victim 11:39:00 and if it's linux, it is not something obvious (like getrusage returning denormalized timevals): a C example doing getrusage in a loop detects no anomalies. 11:39:30 could it be something silly like sign-extending something? 11:39:34 *pkhuong* breathes more lightly 11:39:51 we'll get you yet 11:40:18 after Dec 2nd, if possible. I have a predoctoral defence to go through ;) 11:41:01 have you had to submit written work? 11:41:08 well, something like sign-extension obviously happens here: I wouldn't get values close to (2^64/10^9) from random garbage.. 11:41:18 I'm preparing that right now. 11:42:36 maybe it only happens after 4295 seconds of actual cpu runtime? 11:42:51 or maybe 2147? 11:43:47 more like 2147 11:44:00 hmm 11:45:30 yeah it's linux: ru_stime={18446744072, 714702} 11:46:00 ..no. 11:46:37 it's odd. I see that weird ru_stime when ptracing a simple C program (with no signal handlers and the like...) 11:47:33 ptrace doesn't necessarily know about the signedness or otherwise of structures 11:47:36 I mean, it might 11:47:48 I know that ltrace is not always helpful in that respect, for example 11:48:15 well, it knows the size, and 64-bit 18446744072 can't really be negative 11:49:28 what happens here is that: C example doing rusage and checking for anomalies in a loop -- runs forever without anomalies when not straced. When straced, it constantly receives bogus ru_stime. 11:49:47 EINTR? 11:50:03 well, don't we check return code of getrusage? 11:50:57 and I know enough to reject the idea that getrusage fills the structure partially: I memset it all to 0xFFs before each call, so it wouldn't look this way 11:52:26 we do check the return code of getrusage, I think 11:52:35 unix-fast-getrusage uses syscall* 11:53:03 I guess that's a linux kernel bug: getrusage returns bogus ru_stime when signals and signal handlers are involved (?). That would explain why it happens in SBCL after several seconds of GC-heavy code, and why it happens constantly in ptraced C program. 11:53:45 what's your kernel version? 11:54:49 3.1.0 with some patches (not really a good environment for bug reports) 11:56:25 pchrist [~spirit@gentoo/developer/pchrist] has joined #sbcl 11:58:40 hmm. Same thing reported by someone for 1.0.48, 5 months ago: 11:59:05 pkhuong: yours! 12:00:52 IIRC, that one might have been electric-cloud-related 12:01:16 ? 12:01:42 erh, elastic cloud (: 12:01:51 lol 12:03:48 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 258 seconds] 12:07:46 pkhuong: well, Linux kernel obviously wants us to think that we spent /negative/ time in kernel. 12:08:22 ..my (dotimes (i #C(0 1))..) joke in #lisp was kinda prophetic :) 12:12:08 if we go back to raw nanoseconds from what's reported, we get something like -0.7sec for such ru_stime. 12:12:33 maybe we should just check the timeval for sanity, and retry if its bogus 12:12:59 could that be migration between cpus with unsynchronized clocks? 12:13:01 it's, even 12:13:15 akovalenko: I have a close-to-vanilla 3.0.0 -- send me your C test program and I'll run it 12:13:41 Kryztof: there hasn't been that kind of x86 for a couple years 12:14:16 hardware or kernel? 12:14:29 http://www.sw4me.com/private/rusage.c 12:14:45 fasl is bytecode ? 12:14:51 hardware. And libc/linux kind of depend on that working right for its gettimeofday fast path. 12:15:08 I can easily imagine running on hardware a couple of years old 12:15:33 AMD Phenom(tm) II X4 945 Processor, stepping 2 12:15:59 hmm. what if I set an affinity mask..? 12:19:58 after I pinned it to a single core, the problem went away! 12:20:28 go me 12:22:18 iirc, there is some clocksource= kernel parameter. Isn't there a good setting for avoiding such stuff? 12:23:27 dmesg has "switching to clocksourte HPET [...] switching to clocksource tsc." 12:24:01 what is tsc what is hpet ? 12:24:40 akovalenko: I don't know. (I only Think Very Hard; I don't actually *know* anything) 12:26:34 akovalenko: what are the flags in cpuinfo? 12:26:39 .. notsc parameter. 12:27:38 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt npt lbrv svm_lock nrip_save 12:28:12 pkhuong: and I use frequency scaling 12:29:08 right... I'll bet the problem disappears if you switch to the performance governor remove pinning. 12:30:07 yep, I'm pretty sure myself (will test it, though). Now the question: should we defend against it in SBCL, or should we fail early? 12:31:50 pkhuong: no, -g performance doesn't prevent it 12:33:16 meh. if they got out of sync, performance would only prevent further drift. 12:33:29 oh well. I'd rather fail hard. 12:34:23 how impractical. Well, I don't insint on anything here (there's no such problem on Windows and Wine, he-he) 12:35:02 fix thy kernel ;) 12:37:28 ..well, I would insint on /one/ thing: more friendly error message would be better here (so the next user with out-of-sync cores won't have to google 18446744073 (that's how I found pkhuong's paste)) 12:50:42 the next user will know about the rice-grain reward from the Persian Shah 12:53:20 Tip of the day: did you know some algorithms have exponential growth? 12:53:31 heh. 13:18:05 -!- akovalenko [~akovalenk@95.73.216.28] has quit [Quit: rcirc on GNU Emacs 24.0.91.1] 13:20:05 nikodemu_ [~Nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 13:21:59 -!- nikodemu_ [~Nikodemus@cs181056239.pp.htv.fi] has quit [Remote host closed the connection] 13:40:16 do we want os_vm_word_t, or are we willing to use os_vm_size_t for "random unsigned word" as well? 13:41:08 akovalenko [~akovalenk@95.73.216.28] has joined #sbcl 13:41:12 ask again! 13:41:33 do we want os_vm_word_t, or are we willing to use os_vm_size_t for "random unsigned word" as well? 13:42:38 i'm looking at "unsigned long data[4096]; unsigned long word;" in coreparse.c, specifically 13:43:54 they're about as close to "random word" as it gets, since it's packed data containing both region_start_offset (which will be os_vm_size_t) and two low bits for allocation type 13:46:05 leuler [~user@p549043F4.dip.t-dialin.net] has joined #sbcl 13:51:27 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 13:51:35 LiamH [~none@pdp8.nrl.navy.mil] has joined #sbcl 14:15:41 attila_lendvai1 [~attila_le@87.247.63.233] has joined #sbcl 14:15:41 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Disconnected by services] 14:15:43 -!- attila_lendvai1 is now known as attila_lendvai 14:15:44 -!- attila_lendvai [~attila_le@87.247.63.233] has quit [Changing host] 14:15:44 attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has joined #sbcl 14:26:43 pkhuong: now trying to live with clocksource=hpet. Anyway, that getrusage thing is ugly. Just think of it: 1ns drift which wouldn't even get noticed during profiling may cause SBCL crash... 14:37:19 antgreen [~user@bas3-toronto06-1177890648.dsl.bell.ca] has joined #sbcl 15:05:00 -!- Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has quit [Read error: Connection reset by peer] 15:05:18 Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has joined #sbcl 15:10:41 nikodemu_ [~Nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 15:11:05 -!- nikodemu_ [~Nikodemus@cs181056239.pp.htv.fi] has quit [Read error: Connection reset by peer] 15:38:07 -!- hlavaty [~user@91.65.217.112] has quit [Remote host closed the connection] 15:47:11 -!- leuler [~user@p549043F4.dip.t-dialin.net] has quit [Quit: ERC Version 5.1.2 $Revision: 1.796.2.6 $ (IRC client for Emacs)] 15:55:27 https://github.com/nikodemus/SBCL/commits/wip-runtime-cleanups/ # one pass done 15:55:38 grep -e "[( ]long[ )]" *.[hc] | wc -l 15:56:09 before: 531, after 487 ...this is going to take a while 16:02:21 nikodemus: hooray! (WORD_FMTX... well, it will work everywhere, at least) 16:03:44 nyef [~nyef@pool-70-109-144-138.cncdnh.east.myfairpoint.net] has joined #sbcl 16:03:52 G'morning all. 16:04:33 morn. 16:04:34 good-universal-time nyef. 16:08:09 Hrm... We're still not in code-freeze? 16:11:41 from my wild hacker's hurried, disorganized perspective, you're always in code-freeze :-/ 16:12:19 Heh. 16:21:08 nikodemus: we'll have to updat sa2c's, froydnk's and tcr's email addresses. 16:35:34 *lichtblau* writes another lengthy mail regarding flexible heaps 16:36:59 It may look like I'm arguing against my own features, let me assure you it's not meant that way. :-) Also, "popular sentiment" basically means "jsnell casually mentioned". 16:42:47 I think my main worry with arbitrarily fragmented heap was the implementation complexity around saving / restoring cores 16:43:36 and my main worry is that dealing with the saving/restoring complexity will prevent sharing in mmapped image.. 16:46:30 but really my main practical consideration these days is that I want to make sure sbcl processes can't run amok on our production servers when something goes wrong. so as long as the simple pre-allocated heap of a fixed size remains an option, I'm happy 16:49:52 my plan is explicitly production friendly and amok-prevention oriented! 16:54:12 lichtblau: i didn't realize this until i read your last email, but one of the reasons why I think potential for incremental mapping is good is our inability to ship with globally sensible defaults without it 16:54:29 ie. some platforms have low ulimits, and we should fit under them 16:54:59 tweaking the default size per platform makes talking to users hard. 16:55:57 i'm not sure how important that really is 16:56:13 *nikodemus* will think on this more 16:57:34 akovalenko: by the way, i would recommend against trying to merge that tree just yet. i'm still going to be rebasing it in all likelihood, and rewriting some of the commits 17:00:08 jsnell: core saving seems like a rare enough operation that we could require the final core to fit in a contiguous range. 17:01:51 how do javas do it? 17:02:35 Nevermind, they don't actually need contiguous heaps, just to be able to control the order of mapped pages somewhat. 17:03:48 akovalenko: the dynamic space in the core is contiguous (because core file saving compacts), so sharing will still work (unless of course for processes in which the initial reservation fails and relocation to a different memory area happens) 17:03:49 sure, producing a compacted core from a fragmented address space is what I meant by the complex part. the alternative of saving multiple dynamic space fragments seems easy enough to do, but also incredibly ugly 17:04:30 -!- akovalenko [~akovalenk@95.73.216.28] has quit [Ping timeout: 240 seconds] 17:05:39 jsnell: well, that "complex part" seems to work in practise. But: 17:06:53 I suppose if you want to make certain that you are not exercising this complex code path, and if nikodemus doesn't want #ifdef, then the compromise is to have --initial-dynamic-space-reservation, where you can just specify insanely many GB, knowing that a contiguous heap is effectively guaranteed then because your SBCL will never need more than that. 17:16:13 akovalenko [~akovalenk@95.73.216.28] has joined #sbcl 17:20:56 nikodemu_ [~Nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 17:21:11 -!- nikodemu_ [~Nikodemus@cs181056239.pp.htv.fi] has quit [Remote host closed the connection] 17:24:15 lichtblau: in my plan whole --dynamic-space-size is mapped at startup 17:35:53 -!- Blkt [~user@89-96-199-46.ip13.fastwebnet.it] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 17:45:38 OK, I see. 17:48:35 It seems to me then that --dynamic-space-size would matter to almost nobody anymore (except jsnell). Users would mostly use --dynamic-space-limit to say how much space they want without running into issues. I.e., I like the features; I'm not that certain about the naming. 17:57:21 -!- redline6561 is now known as redline6561_nop 18:03:45 I'm kind of partial to --dynamic-space-size meaning the soft limit. --dynamic-space-max-size could be the hard limit, --dynamic-space-min-size the initial size. 18:03:48 i'm equally unsure of the naming 18:03:51 *lichtblau* doesn't actually care that much 18:04:30 -!- attila_lendvai [~attila_le@unaffiliated/attila-lendvai/x-3126965] has quit [Ping timeout: 276 seconds] 18:04:42 i'm wondering if we could just call them --heap-*. 18:07:30 ... short is good ... 18:09:32 sdemarre [~serge@91.176.28.91] has joined #sbcl 18:17:32 --heap-{soft,hard}-limit ? 18:21:58 --heap-size = initial size, default limit. --heap-limit = soft limit. --heap-hard-limit = hard limit. --reserve-heap-size = total initial mapping is size + reserve size? 18:23:54 or --initial-heap-size, --soft-heap-limit, --hard-heap-limit, --reserve-heap-size? 18:25:42 or we could go all Java. -Xms, -Xmx, -Xmxx, Xmr 18:29:09 ... -Xmms ? 18:30:42 leuler [~user@p549047A1.dip.t-dialin.net] has joined #sbcl 18:31:03 Oh, right! Is there some way to get synchronous signals for a thread delivered to a separate thread, similar to the whole mach message-handling noise or ptrace(), but within the same process space? 18:31:35 nyef: with linux you could use signalfd, I believe 18:32:06 Hrm... Would that still give access to the interrupt context and whatnot? 18:33:20 Ah, no, signalfd() doesn't look like it'd work. 18:33:30 Only gets signals directed to the thread that reads the fd. 18:33:49 Synchronous signals are directed to the thread that causes them. 18:40:17 nikodemu_ [~Nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 18:44:37 -!- nikodemu_ [~Nikodemus@cs181056239.pp.htv.fi] has quit [Ping timeout: 240 seconds] 18:54:01 nikodemus: regarding sbrk, I wouldn't propose to use it everywhere, but rather to use it on platforms where it 1. works and 2. works better than alternatives. I'd imagine that sbrk works fine on a Real UNIX like SunOS. 19:09:22 -!- Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has quit [Read error: Connection reset by peer] 19:09:44 Phoodus [~foo@ip72-223-116-248.ph.ph.cox.net] has joined #sbcl 19:11:55 slyrus [~chatzilla@adsl-99-49-14-228.dsl.pltn13.sbcglobal.net] has joined #sbcl 19:12:52 cpc26 [~cpc26@fsf/member/cpc26] has joined #sbcl 19:13:11 grr, doesn't build at all on x86, and I don't have the sparc machines yet that hlavaty wanted to organize 19:16:31 lichtblau: surely sbrk doesn't provide any more protection for earlier mappings than MAP_FIXED? 19:24:11 nikodem__ [~Nikodemus@cs181056239.pp.htv.fi] has joined #sbcl 19:24:20 -!- nikodem__ [~Nikodemus@cs181056239.pp.htv.fi] has quit [Remote host closed the connection] 19:24:51 -!- nikodemus [~nikodemus@cs181056239.pp.htv.fi] has quit [Quit: This computer has gone to sleep] 19:33:41 nikodemus [~Nikodemus@GGZYYYMMCCXV.gprs.sl-laajakaista.fi] has joined #sbcl 19:33:41 -!- ChanServ has set mode +o nikodemus 19:38:53 Hrm... Signal handlers aren't supposed to call pthread_*() functions, but are allowed to read and write on FIFOs... 19:45:01 -!- nikodemus [~Nikodemus@GGZYYYMMCCXV.gprs.sl-laajakaista.fi] has quit [Ping timeout: 252 seconds] 19:47:33 nikodemus [~Nikodemus@GGZYYYMMCCXV.gprs.sl-laajakaista.fi] has joined #sbcl 19:47:33 -!- ChanServ has set mode +o nikodemus 20:01:27 nikodemus: sbrk fails cleanly when hitting mmap()ed pages 20:02:00 (more?) importantly, malloc() is implemented using sbrk, so if that isn't incentive enough for kernel hackers to keep their hands off this part of the address space, I don't know what would be. 20:03:36 Umm... Doesn't that imply trouble when using both sbrk() and malloc() in the same program? 20:06:21 I think that a whole reason for a libc-provided sbrk(), distinct from brk(), is to allow a peaceful coexistence of malloc and a custom allocator. 20:07:18 But please don't take it as the encouragement to use sbrk(). 20:07:54 *lichtblau* goes off to print t-shirts saying "I sbrk" 20:08:03 awww. 20:08:04 ok, not really. But on Solaris it might be a good option. 20:13:51 -!- LiamH [~none@pdp8.nrl.navy.mil] has quit [Quit: Leaving.] 20:20:08 nikodemus: erm, actually, my test program says that mmap address hints work just fine. Solaris 11 on x86. 20:20:34 does anyone here have Solaris on SPARC and would run a toy program for me? 20:23:05 aha: 20:23:09 | Before Solaris 11, the mmap ADDR parameter is mostly ignored without MAP_FIXED set. Before we give up, search the desired address space with mincore to see if the space is really free. 20:23:37 Key phrases being "before solaris 11" and "mincore(2)". 20:35:13 -!- homie [~levgue@xdsl-84-44-179-190.netcologne.de] has quit [Read error: Operation timed out] 20:35:27 homie` [~levgue@xdsl-84-44-177-79.netcologne.de] has joined #sbcl 20:36:29 pkhuong: got getrusage problem again, this time with clocksource=hpet 20:37:42 -!- nikodemus [~Nikodemus@GGZYYYMMCCXV.gprs.sl-laajakaista.fi] has quit [Ping timeout: 240 seconds] 20:40:21 -!- homie` [~levgue@xdsl-84-44-177-79.netcologne.de] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)] 20:44:02 nikodemus_: I am now 20:47:34 homie [~levgue@xdsl-84-44-177-79.netcologne.de] has joined #sbcl 20:50:30 -!- angavrilov [~angavrilo@217.71.227.181] has quit [Ping timeout: 258 seconds] 20:54:36 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 20:54:36 -!- ChanServ has set mode +o nikodemus 21:05:48 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Remote host closed the connection] 21:07:34 rpg [~rpg@216.243.156.16.real-time.com] has joined #sbcl 21:15:20 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 21:15:20 -!- ChanServ has set mode +o nikodemus 21:30:06 -!- cpc26 [~cpc26@fsf/member/cpc26] has quit [Ping timeout: 240 seconds] 21:58:37 -!- nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has quit [Ping timeout: 240 seconds] 21:59:35 akovalenko: blast. glibc and their strange fast paths. 22:01:55 nikodemus [~Nikodemus@cs181063174.pp.htv.fi] has joined #sbcl 22:01:55 -!- ChanServ has set mode +o nikodemus 22:18:42 -!- redline6561_nop is now known as redline6561 23:22:03 chp [~chp@dyn-carl-202-105.dyn.columbia.edu] has joined #sbcl 23:35:43 -!- sdemarre [~serge@91.176.28.91] has quit [Ping timeout: 248 seconds] 23:57:42 -!- joshe [~joshe@opal.elsasser.org] has quit [Ping timeout: 240 seconds]