dalek arVM: 7193cda | timotimo++ | src/moar.c:
oops. that was *not* the mutex ...
00:09
arVM: d912f3c | timotimo++ | src/6model/6model.c:
free debug names in STables
arVM: 616acc8 | timotimo++ | src/6model/reprs/MVMCompUnit.c:
free the string_heap_fast_table in CompUnit bodies
arVM: 30d7a32 | timotimo++ | src/moar.c:
free permroot descriptions.
00:11
arVM: 463fded | timotimo++ | src/core/threadcontext.c:
free each TC's finalization queue in tc destruction
00:16
timotimo in the current frame code, we're leaking frames that fell off the FSA size limit and got allocated with malloc instead. not sure what path should normally at some point reach those pointers and free them, but we're probably also missing cleanup for those that are "in" the FSA. though these would get destroyed whole with the FSA itself at teardown 00:18
here i see a bunch of things leaking that got created from serialization_demand_object and actually have corresponding MVM_free in 6model_stable_gc_free. not sure why they don't end up getting freed 00:21
maybe we're not going through the whole gen2 to gc_free stuff on shutdown, or something like that?
05:39 domidumont joined 05:44 domidumont joined 06:10 domidumont joined 07:21 cognominal joined 07:37 cognominal joined 08:24 brrt joined 08:48 zakharyas joined 09:24 zakharyas joined 11:48 brrt joined
brrt good * #perl6 11:48
eh, #moarvm
11:53 vendethiel- joined
jnthn o/ brrt :) 12:02
brrt \o jnthn 12:04
ehm, i was wondering how far along you are with the reframe branch 12:05
because, if you want to merge it, then, probably, you should just do it
jnthn brrt: It builds NQP/Rakudo fine. Fails some spectests.
Some, some debugging remains.
brrt right
jnthn Plus the JIT thing. ;)
brrt and disable the JIT for now, i was going to say
which, almost, works
something funny happening 12:06
jnthn Well, I'll have to go debugging still, so there's time for getting the JIT to actually work :)
brrt yeah, but there is my velocity, and there is yours
on the long list of to-do-things, i want better jit graph logging 12:07
rather than the adhoc logging we have now, better something like spesh logging
oh, i thought of a way to avoid mallocing the 'fake extop arguments' 12:08
we can put these in a 'data' section in the jit code
which is also where we can place (function) pointers, which would allow storage and linking 12:10
not only that, it's much more elegant that way... 12:12
do you think lifetime hole analysis is worth the complexity? 12:16
12:47 harrow joined
jnthn Sorry, was in a meeting... 13:07
+1 on the data section stuff
LHA - don't know it's worth the complexity in the short term. 13:08
brrt well, i don't really know either.... :-) 13:14
hmmm
14:14 colomon joined 15:15 colomon_ joined 15:21 colomon_ joined 16:30 domidumont joined 17:06 ggoebel114 joined 18:15 brrt joined 19:00 dalek joined 19:05 dalek joined 19:37 dalek joined 19:56 colomon joined 20:26 jnthn joined 20:33 dalek joined 20:38 colomon_ joined 20:40 dalek joined