Search
Thursday, 14th of September 2017, 10:14:11 UTC
10:16:20
flip214
scymtym: not necessary anymore.... my error. sorry about the noise.
10:19:22
flip214
thank you very much, though!
12:47:05
stassats
when NOTE_GARBAGE is taken out both make-target-2 and (gc :gen 7) in slime succeed
14:18:23
dougk
how is note_garbage killing it?
14:18:40
stassats
-1 from find_page_index
14:21:24
dougk
that drops out of log_sweep isn't on though
14:21:32
dougk
i mean yes, it shouldn't access an array with a negative index
14:21:51
dougk
ah, so why it it scanning a page not in dynamic space ?
14:22:11
stassats
not updated page tables?
14:22:22
dougk
ah, because varyobj space is in there
14:22:31
dougk
ok, that'a a bug, i'll fix that
14:23:15
stassats
why do you go through zeroed and then update totals? can't you just increase totals directly?
14:24:31
dougk
yes, could. I think it used to do something differently for which that made sense
14:26:01
stassats
interestingly, to diagnose it i disabled -O2, that helped, but in the cases when it did not crash it did crash later during slad
14:26:09
stassats
does slad not work without -O2?
14:26:18
stassats
that'd be pretty strange
14:27:30
dougk
pretty. and another thing, sweep seems to clobber way too much on precise platforms. totally unusable
14:27:55
dougk
i wanted to diagnose it using 'traceroot' but that doesn't work on precise platforms either
14:28:06
stassats
what is the fullcgc doing exactly?
14:28:29
dougk
just bzeroing garbage. generation 6 is the problem. whether it bzeros younger is irrelevant
14:28:43
dougk
but it uses only static space and stacks as the root of the scan
14:29:57
stassats
isn't gencgc zeroing enough garbage?
14:30:50
dougk
it never zeros garbage in generation 6, ever.
14:31:44
stassats
so, fullcgc just zeroes without compacting?
14:31:45
dougk
generation 6 is demoted to 5 prior to slad
14:32:09
dougk
yes, it just zeros without compacting so that subsequent passes have fewer spurious roots
14:33:04
foom
Seems like a good start for a future more general non-moving GC, too. :)
14:34:00
stassats
another define-static-fun gone
14:34:21
stassats
i think i can do mips, then i'm out of testing machines
14:34:35
stassats
i'd really like to get rid of it universally
14:38:18
stassats
that leaves alpha and hppa...
14:40:17
stassats
./make.sh: time: not found
14:51:34
Shinmera
Why does make.sh invoke time anyway? Shouldn't that be a responsibility of the user if they want timing data?
14:53:04
stassats
anyway, i finally fixed it
14:57:37
stassats
ugh, the runtime doesn't build on sparc
14:57:47
stassats
error: 'os_context_t {aka struct sigcontext}' has no member named 'si_mask'; did you mean 'sigc_mask'?
15:00:51
stassats
nobody uses sparc anyway, so i'll forgo #ifdefs and just make it work on my machine (ha-ha)
15:04:34
stassats
/usr/bin/ld: sparc architecture of input file `sparc-assem.o' is incompatible with sparc:v9 output
15:09:03
foom
Time to just delete the sparc build?
15:18:16
stassats
and sparc-assem.S is not compatible with v9
15:21:52
stassats
no more v8plus support in the runtime (oh no)
15:22:32
foom
I mean, there's really no point in building sbcl for a 32-bit v8 sparc.
15:22:59
stassats
and there is for alpha?
15:30:28
stassats
i wonder if i just remove static functions from hppa and alpha altogether, will it work?
15:36:57
stassats
invalid magic number in core: 0x5342434c00000f14 should have been 0x5342434c.
15:37:02
stassats
did i build a 32-bit runtime?
15:53:46
Shinmera
foom: You'll probably have to fight nyef if you want to get rid of any architecture
16:08:43
stassats
getting a nice Segmentation fault
16:08:50
stassats
which means it's quite early
16:09:48
stassats
call_into_lisp () at sparc-assem.S:59 59 st reg_ZERO, [reg_NL0+%lo(foreign_function_call_active)]
16:12:03
stassats
the problem is from sethi %hi(foreign_function_call_active), reg_NL0
16:12:10
stassats
foreign_function_call_active is 0 for some reason
18:13:54
flip214
I've given my SBCL process ~6GB of RAM, but after an RSS of 2.4GB it drops into LDB, saying "No more immobile pages available"
18:14:27
stassats
those numbers you listed have no effect on immobile pages
18:15:09
flip214
SBCL 1.3.21.139-8408fe5a7
18:15:18
flip214
okay... so, what should I tune?
18:15:53
flip214
now I tried with 10GB of dynamic space -- but as you said, stopped again at the same size.
18:16:29
flip214
--control-stack-size wouldn't help too, I guess.
18:17:55
flip214
but what would allocate in there? closures?
18:18:11
flip214
I'm allocating quite some data, but what should I change?
18:19:20
flip214
ah, too many symbols? okay, that's an idea...
18:20:02
flip214
I'm currently using a package as a quick de-duplication storage, I can use a hash-table instead.
18:20:34
stassats
well, regardless of whether symbols are immobile, never use abuse packages like that
19:15:35
flip214
I get "There is no applicable method for the generic function XXX when called with arguments ( ... )"
19:15:43
flip214
but there IS such a method
19:16:27
flip214
well, if I try to inspect the functions symbol, I get
19:16:29
flip214
unhandled DEBUG-CONDITION:
19:16:48
flip214
#<SB-DI::BOGUS-DEBUG-FUN "foreign function: new_thread_trampoline"> has no debug variable information.
19:17:10
flip214
so I guess something is broken
19:17:50
flip214
I had that already a few hours ago... but it vanished after I removed all traces of a class (including its methods), and did a restart of my sbcl (to really clean up)
19:19:25
flip214
and (sb-mop:generic-function-methods #'...) tells me that there IS a method for that (single) argument's type
19:20:18
flip214
it did work with less data, ie. smaller inputs
19:20:38
flip214
how would I keep the source line information for the sbcl internal function when rebuilding?
19:21:31
flip214
I already do "make.sh --fancy", so :sb-xref-for-internals should be active
19:22:30
flip214
what would I need, then?
19:23:36
flip214
but I'd like to keep the information about source location of eg. SB-PCL::CALL-NO-APPLICABLE-METHOD
19:29:51
flip214
sb-pcl::flush-effective-method-cache doesn't help
19:35:00
flip214
freshly loaded it works...
19:35:55
flip214
but after some heavy load (11G of 14G RAM used) sbcl doesn't find the method any more
19:36:05
flip214
although the generic function still has it listed
19:42:31
flip214
hmmm, this time sbcl complains about /proc/sys/vm/max_map_count...
Thursday, 14th of September 2017, 22:14:11 UTC