00:06 lizmat joined
dalek arVM/more_debug_names_in_exceptions: 2e059d9 | timotimo++ | src/6model/reprs/P6opaque.c:
"this type" will now actually mention the type
 00:23
arVM/more_debug_names_in_exceptions: 350a1ba | timotimo++ | src/6model/reprs/P6opaque.c:
"missing serialize" and "rebless" also mention type now
arVM/more_debug_names_in_exceptions: 6d630aa | timotimo++ | src/6model/reprs.c:
default repr functions will now mention debug_name.
timotimo i don't see a reason this could be problematic, but i decided to go for a branch anyway, because it's late
01:02 colomon joined
diakopter timotimo: :D' 01:26
02:15 geekosaur joined 03:29 vendethiel joined 06:10 leont joined 06:35 Ven joined 06:49 domidumont joined 06:54 domidumont joined
nine_ timotimo: oh those changes could have made my life much easier in the past couple of weeks. E.g. I only found out about debug_name by poking in gdb 07:00
07:29 zakharyas joined 07:47 domidumont joined 07:51 lizmat joined 08:45 brrt joined
jnthn moarning o/ 08:57
timotimo: Nice idea, see the review comment somebody left, though :) 08:58
08:58 Ven joined
brrt good moarning too 09:04
09:35 synopsebot6 joined 09:38 zakharyas joined 10:05 cognominal joined
timotimo i thought we had an option in our makefile that'd make gcc scream bloody murder when format strings don't match argument count 10:08
but it's very good someone wrote a review <3
nine_: sorry about that :S 10:09
arnsholt gcc -Wall-the-things? =)
timotimo -Waste-all-my-time-please
arnsholt =D
psch .oO( llvm --Wall-the-garden # apple specific extension )
dalek arVM/reframe: 1d92223 | jnthn++ | src/6model/6model.h:
Add collectable flag for frames.
 10:21
MoarVM/reframe: 2ec94b7 | jnthn++ | src/core/frame.h:
MoarVM/reframe: Give MVMFrame an MVMCollectable header.
jnthn (just a rebase)
10:22 dalek joined 10:24 Ven joined
nwc10 OMG he killed dalek 10:28
dalek arVM/more_debug_names_in_exceptions: 75d91f6 | timotimo++ | src/6model/reprs/P6opaque.c:
@patzim noticed a missing format string placeholder
 10:29
nine_ OMG he killed Ven
10:31 Ven joined 10:39 brrt joined
dalek arVM/reframe: f6f1085 | jnthn++ | src/core/ (3 files):
Add write barriers to late-bound lexical binds.
 10:45
arVM/reframe: 91530a3 | jnthn++ | src/gc/gen2.h:
Bump number of gen2 bins.

So that an MVMFrame fits inside the binned area, rather than landing up in an overflow. Might be able to undo this after an MVMFrame diet.
jnthn If you disable JIT, the reframe branch now gets to building CORE.setting in the Rakudo build
(It may yet complete that too, just takes a while in a debug/no-optimize build)
Especially one where we allocate all frames using the GC, 'cus I didn't put the new common case fast-path in yet :) 10:47
hah, it does as well 10:48
Guess that probably means it can build an NQP too
timotimo reassuring! 10:50
jnthn Yeah, it does
Even though I know I've a couple of missing write barriers still to add :)
And yeah, the JIT is teh bust :(
nwc10 ASAN build (JIT disabled) has just passed all the NQP tests 10:51
jnthn Nice
nwc10 Rakudo build failed with 10:52
failed to load library 'dynext/libperl6_ops_moar.so'
retrying with a non-parallel make
might be a Makefile race condition 10:53
no, not so. does explode
src/vm/moar/ops/perl6_ops.c:455:43: warning: assignment makes pointer from integer without a cast ((MVMContext *)ctx)->body.context = MVM_frame_inc_ref(tc, outer); 10:54
not seen that one before
timotimo that's not an error?
nwc10 no. it's a warning. 10:55
timotimo right
nwc10 it's an error in C++, IIRC
timotimo the function doesn't exist, i bet
i mean, not any more
nwc10 I suspect no prototype
jnthn nwc10: Oh...
nwc10 however, as "my" machine has 64 bit pointers and 32 bit ints
timotimo no, i bet the function was *deleted*
nwc10 it might cause fun
timotimo removed from the API
jnthn nwc10: Rakudo's moar/reframe branch 10:56
nwc10 aha
jnthn It's...hard to see how to do this and not break API there...
Thankfully, we can still get away with it *for now* 10:57
I suspect there'll come a time we can't so easily...
On the upside, it's probably a not-too-bad sign that it's still possible to refactor MoarVM, breaking a key invariant that's been in place since day 1, and still be back at being able to build (OK, without JIT) NQP and Rakudo within a day's effort. 11:01
brrt is back from lunch 11:04
ok, whats busted, and why
jnthn brrt: FRAME 11:05
11:05 Ven joined
jnthn brrt: I'm killing of frame reference counting 11:05
*off
brrt oh, yes, i recall
cool
jnthn brrt: In favor of a call stack for the simple "linear" case, and then using the normal GC if they "escape"
This breaks the "an MVMFrame never moves over its lifetime" invariant 11:06
brrt ok.........
nwc10 I forget what it gains us (and I think that you've explained previously)
brrt not having refcounts, yay
jnthn And thus the JIT's FRAME register gets out of date
brrt yes 11:07
oh, that's... oh well
not necessarily even that bad
dalek arVM/more_debug_names_in_exceptions: 98c462b | timotimo++ | src/6model/reprs/P6opaque.c:
make no_such_attribute more helpful with action and debug_name
arVM/more_debug_names_in_exceptions: b33db60 | timotimo++ | src/6model/reprs/P6opaque.c:
invalid access (get/bind) now contain type and kind
arVM/more_debug_names_in_exceptions: a7f438b | timotimo++ | src/6model/reprs/P6opaque.c:
add tons of detail to p6opaque's compose

who knows, maybe someone will have need for this ... some time in the far future ...
jnthn brrt: Yeah, I'm curious how you'd handle it :)
brrt hmmm
ok, let me check out how it's used, before i say anything else 11:08
jnthn nwc10: I've a lengthy analysis blog post in the works on that, but in summary: ref counts + generational GC don't play well, plus having to maintain the ref counts involved CPU atomic ops (costly) because threads, and it turns out that every situation where you can shorten the frame lifetime by ref-counting is one where you have a linear chain of frames. 11:09
brrt it's accessed in a bunch of places, but nothing that really relies on the static FRAME pointer being in its place
having FRAME in a callee-saved register is somewhat cheaper and easier to use, but not at all essential 11:10
jnthn nwc10: But if you've a linear chain of frames then you don't need the reference counts, because they'd all be 1
brrt: The one that concerned me was some invokish check
brrt letmeseeaboutthat
that is a good one 11:11
i think the invokish check is always post-c-call
so it's save to put the current frame in a callee-saved register, or on the stack
jnthn nwc10: So long as you uphold a "stack-allocated frames can point to GC-allocated frames, but never the other way around" invariant, you're good. 11:12
brrt oh.... waitaminute though
hmm
storing jit entry labels uses the frame pointer
jnthn brrt: But what if the thing did a GC?
brrt ehm
jnthn brrt: And moved the frame?
brrt good point...
jnthn If it's on the C stack though
Then we can actually use the temp roots thing we use for things normally on the C stack 11:13
I guess we can call that from the JIT
brrt we can, but, it's evil
jnthn :-)
brrt i'm not entirely sure 11:15
timotimo i wonder if it's more expensive to grab tc->current_frame after every invokish ... 11:16
invokish or allocish
jnthn timotimo: That's not the problem here
timotimo: The problem is that we use "FRAME != tc->cur_frame" as our "did we invoke" test 11:17
timotimo oh
OH!
brrt which is not a perfect test to start with, though
jnthn Which is now not going to be reliable
dalek arVM/reframe: 6bd4b0d | jnthn++ | src/core/frame. (2 files):
Add write barriers on binding dynamic lexicals.
 11:18
brrt i can't imagine that we can't come up with something cleverer 11:24
than what we have with invokish
dalek arVM/reframe: a30c2ea | jnthn++ | src/6model/reprs/NativeRef.c:
Write barrier in string lexical ref assignment.
jnthn Lunch, bbl :) 11:25
nwc10 ilmari: ^^ :-) 11:30
brrt eat well
jnthn: i feel like adding a temp root on every potentially invokish function call is more trouble than it is worth 11:31
it means pre-and post-wrapping
(for when you're back)
timotimo so then just add it when we enter and remove it when we leave?
brrt yeah, on a large proportion of all function calls 11:32
timotimo i mean, having a temp root more than necessary for an extended period of time shouldn't be bad or anything?
brrt hmmm
timotimo sorry, i mean when we enter a jitted frame and when we leave it
brrt that is true
timotimo that *should* still leave all push/pop pairs properly paired up, right?
brrt yes
it still feels like a hack :-) 11:33
and i'm not sure why we couldn't figure out something... more clever
less hacky
timotimo well, a jitted frame can put the root in there properly when it's marked 11:34
in its gc_mark, i mean 11:35
does that sound good?
11:35 konobi joined
brrt not yet 11:35
konobi just been reading about luajit... pretty dang impressive work 11:36
timotimo yeah, luajit is really quite something
brrt concurs
timotimo i don't understand why using gc_mark isn't good :) 11:37
brrt we need a cheap and effective way to see that we are no longer in the same place on the stack 11:41
the frame pointer is the main thing
timotimo oh, i thought we were trying for something to make moving frames update our local idea of what the current frame is 11:42
brrt ok, i have an idea that should be acceptable
we take a pointer to the frame in the jit enter code
we push that as a temp root
we pop it on leaving
then, we *pass a pointer to that* on jit entry 11:43
e.g. jit entry gets MVMFrame**
timotimo a pointer to the pointer you mean?
brrt because the first pointer is on the stack, it ought to be in cache
yes
timotimo sorry, why do we need the MVMFrame** on jit entry? 11:44
i thought we'd just pushed that as a temporary root?
the work pointer won't move, right? i mean, the blob of memory that we're working on 11:45
brrt ehm
timotimo i must be misunderstanding something important :)
brrt i must be misexplaining something important 11:46
:-)
timotimo don't misunderestisplain me!
brrt long story short, we *want* to have cheap access to 'the current place in the call stack of which this jit code is the code segment' 11:47
so that when we've secretly thrown ourselves out of it, or invoked into a deeper level, we will know to 'fall' on the interpreter 'trampoline' 11:48
so we want that to be a cheap check that is usually false
timotimo .o( wheeeee! )
ilmari *boing* 11:49
brrt so, we need to store 'our current frame' in a place where preferably the GC can update it, *or*, we need to have cheapish access to the same, which is already updated by the GC 11:50
so we can make that comparsison, 'are we still in the same frame'
actually, any way to answer that question is good to me 11:51
easy to forget what we're doing it for :-) 11:52
12:12 cognominal joined 12:16 domidumont joined 12:18 domidumont joined
jnthn back 12:28
brrt \o jnthn 12:29
jnthn So, something still wants a fix, given my build on HEAD just exploded Rakudo CORE.setting 12:32
(Something other than the JIT :))
brrt :-) 12:34
dalek arVM/reframe: 40a3087 | jnthn++ | src/6model/serialization.c:
Another write barrier.

Maybe not needed, but better safe than sorry.		 12:41
12:43 Ven joined
dalek arVM/reframe: 6d15151 | jnthn++ | src/core/frame.c:
Fix continuation clone for GC-able frames.
 12:47
jnthn builds a MoarVM with a tiny nursery to try and flush out some more issues, now he's run out of those on his todo list 12:51
Yeah, that shows up plenty wrong. 13:00
dalek arVM/reframe: b625398 | jnthn++ | src/6model/reprs/MVMIter.c:
Add missing MVMROOTs in context iteration.

One of these cases was an existing bug. The other was needed for the frame changes.		 13:24
arVM/reframe: 5ac981d | jnthn++ | src/gc/debug.h:
Update debugging macro for lazy fromspace alloc.

Also make it dump out the pointer in question.		 13:35
arVM/reframe: e1114b6 | jnthn++ | src/core/frame.c:
Missing MVMROOT of outer.

Meant we could end up assigning outdated pointers to a frame->outer.		 13:46
arVM/reframe: 4509fd0 | jnthn++ | src/core/frame.c:
Remove a bit of now-unrequied flow control.

We don't need the NULL check when we're not going to try and fiddle with a reference count.
jnthn Onto the next SEGV... 13:47
[Coke] RT: 26 SEGVs. 13:53
13:55 domidumont joined
jnthn [Coke]: hah, I meant "arising from the stuff I'm refactoring" 13:56
But yeah, I'm trying to pick those off too :)
13:59 Ven joined 14:10 zakharyas joined 14:13 brrt joined
brrt jnthn: I think i've solved it 14:14
we add a current_frame_nr and next_frame_number to the threadcontext
initialized to zero
whenever we create a frame, we increment the next frame number and assign it to the frame 14:15
e.g. frame->sequence_nr = ++tc->next_frame_number; 14:16
whenever we enter the frame (MVM_frame_invoke iirc), we assign the current frame number to the tc
tc->current_frame_nr = frame->sequence_nr 14:17
whenever we enter the jit, we stash the frame sequence number somewhere safe. whenever we return from an invokish, we compare it to the stashed sequence number 14:18
sequence numbers may wrap arounnd all we like (just not too often)
we no longer need FRAME in a register, or even on the stack as a gc temp root
brrt will make a patch 14:19
jnthn brrt: ooh :) 14:21
brrt++
brrt oh, and during unwinding, of course 14:32
that's centrally handled somewhere too, iirc
jnthn got himself confused by running into a bug, assuming it was thanks to his refactor, and now is discovering it probably ain't 14:37
14:58 lizmat joined 15:08 zakharyas joined
dalek arVM/reframe: 5da3e1e | jnthn++ | src/6model/reprs/MVMCompUnit.c:
Fix a SC resolution / GC race.

Not a race in the threading sense, just an ordering one. If the SC is not resolved by the compunit's code before the next GC run happens, then the ->sc pointer can be out of date.		 15:13
15:24 geekosaur joined
jnthn That as a darn pain to find 15:24
And nothing at all to do with the refactor I've been doing
NQP builds and passes tests on a 32KB nursery 15:26
Rakudo will take forever to build with a 32KB nursery
timotimo i bet 15:28
jnthn Curently it's building Actions.nqp
Now it's made it so far as building CORE.setting 15:32
Heap corruption detected: pointer 000000000068E9D0 to past fromspace
wow
Guess there is something more :) 15:33
TimToady wonders if a frame can move out from under our current env var cache... 15:42
jnthn TimToady: That's stored in the frame, and so far as I can tell it's safe 15:43
(I had to fix up that bit of code)
I'm suspecting the thing I just ran into now is another "not related to this refactor"
TimToady s/env/dyn/
timotimo it's been a while since we last torture-tested the GC, eh? 15:44
TimToady do wanna poke a better cache in there at some point
dalek arVM/reframe: bb42773 | jnthn++ | src/gc/worklist.h:
Detect another problem in GC worklist add debug.
jnthn timotimo: Apparently, yes
Which probably means we should set up automated runs with a small nursery 15:45
[Coke] We really should have a lot more automated testing, aye. :) 15:46
jnthn Yeah. Daily automated valgrind too was on my todo list
Well, still is, I just...have a long todo list :P
And plenty of things wanting to be near the top
timotimo .o( and i'm not too helpful at making it any shorter these days ) 15:50
jnthn Oh wait, that previous commit may be bogus... 15:52
yeah, it is as well 15:53
Darn 15:54
'cus we've flipped from/to at the point we're running that
timotimo at least that'd mean the very first GC run would explode when marking the very first object from the nursery, no? 15:56
jnthn yeah, exactly 15:58
Didn't stop me looking into why that pointer was bad :P
15:58 zakharyas joined
timotimo i can imagine 15:58
16:02 vendethiel joined
jnthn Gah, it SEGVs at my fix for the previous issue :/ 16:07
And it's enitrely possible that is the reason for the next fail 16:10
timotimo AFK for a bit 16:11
dalek arVM/reframe: 0081193 | jnthn++ | src/gc/worklist.h:
Correct worklist add sanity check.

We've flipped to/from by the point we hit this check, so it can't be just like the check in gc/debug.h.
16:19 awwaiid joined
dalek arVM/jnthn/debug: fc8c871 | jnthn++ | src/ (3 files):
Branch to shove debug tweaks to my VM.
 16:21
timotimo oh, interesting 16:29
jnthn Oh wow, we actually free the SC 16:31
timotimo neat, so things get cleaned up when things are not needed
(except, maybe we free it accidentally? :) )
jnthn Between its creation and trying to take reference to it 16:32
Yeah, prematurely
timotimo oooh, whoops :)
so it's not rooted somewhere before the first allocaty thing gets called?
jnthn It's only held by the sc_weakhash, which doesn't mark it to be weak 16:33
:)
timotimo oooh 16:34
i didn't know we have weak hashes yet! :P
jnthn We...don't officially have weak refs 16:37
But we fake them up
Badly
Which means I should probably implement them properly.
dalek arVM/jnthn/debug: 6e30284 | jnthn++ | src/6model/reprs/MVMCompUnit.c:
Revert "Fix a SC resolution / GC race."

This reverts commit 5da3e1ec149d8fcc8127242a289b965d0c8db4a9.		 16:42
arVM/jnthn/debug: 31f3d4d | jnthn++ | src/ (3 files):
A (hopefully) more correct fix for the SC race.

The previous fix more hid the issue than resolved it. This fixes it by making sure we mark its one reference in the weak hash (so it does not go and get collected) until a compunit actually claims it.
jnthn OK, that seems a bit better 16:45
dalek arVM/reframe: d1485f7 | jnthn++ | src/6model/reprs/MVMCompUnit.c:
Revert "Fix a SC resolution / GC race."

This reverts commit 5da3e1ec149d8fcc8127242a289b965d0c8db4a9.		 16:48
arVM/reframe: abe4cdd | jnthn++ | src/ (3 files):
A (hopefully) more correct fix for the SC race.

The previous fix more hid the issue than resolved it. This fixes it by making sure we mark its one reference in the weak hash (so it does not go and get collected) until a compunit actually claims it.
jnthn That builds NQP and passes its tests OK again...and doing a Rakudo build from scratch 16:57
Locally got some debugging turned on and 32KB nursery
It's made it some way into CORE.setting this time. Guess this'll not be fast :) 16:59
I'll leave it running, but calling it a day...tired :) 17:07
nwc10 hopes that the beer fridge is stocked 17:08
timotimo oh jnthn, do you have an intuition if it'd be problematic to weave inlined stuff (in spesh) into the dominator tree, as the optimizer goes through blocks by their children instead of their linear_next? 17:09
or should i instead try for something like a list of bbs that still need to be visited afterwards kind of deal? 17:10
jnthn timotimo: I'd just recalculate the dominance
nwc10: It is :) 17:11
timotimo oh, is there a simple call that i can use for that? probably!
i won't have to invent it myself!
jnthn No
It's not exposed
timotimo but i can probably tear it out of some place?
jnthn spesh/graph.c is where it lives though
jnthn ponders what to have for dinner :) 17:14
timotimo do you think reverse_postorder, compute_dominator, add_children, add_dominance_frontiers is the right set of instructions to steal? and perhaps adding code to add_children and such that deletes previous values so they don't get doubled? 17:15
17:17 domidumont joined
jnthn yeah, think you'd have to get rid of the existing children 17:18
maybe do that beforehand
CORE.setting failed to explode so far. :) I'll bbl 17:19
timotimo now that i think of it, add_children probably just allocates a blob of the right size using spesh_alloc, so "clearing it out" makes no sense
yay
see you later jnthn :)
17:51 konobi left
timotimo just calling those things after an inline was done throws moar into an explosion; a dump of the spesh graph and Spesh: reverse postorder calculation failed 17:57
so i need to clear out some stuff it seems
and for that i'll have to actually read that code :S
i wonder if it stumbles over a bb that has gone missing because it got eliminated? and the count of bbs got out of sync? 18:15
right, removing successors and predecessors will throw bbs out of the tree but not decrease the number of bbs if they were completely taken out. it probably should, then. 18:16
ugh, this involves giving spesh_manipulate_remove_successor and _predecessor a pointer to the graph, too. it didn't so far. and that's an API change >_> 18:20
time to build a function name just like in PHP 18:21
jnthn Some very tasty Indian scrambled eggs later, and CORE.setting build is still alive 18:22
timotimo wow, that's rather slow running
jnthn Well, it's GCing every 32KB
timotimo MVM_spesh_manipulate_remove_successor_real? _clean? _properly? _EX?
maybe #define MANIPULATE_SUCCESSORS_TAKES_G_ARGUMENT for our users to read >_> 18:23
jnthn You could just re-count the number of reachable ones? :)
timotimo the dfs currently errors out when that number isn't "right" 18:24
so using it to recalculate ... not sure if that's the right thing to do for this 18:25
jnthn Yeah, so make it right before doing that?
I'd been thinking about making a second pass post-inline
timotimo but i'd be using pretty much the exact dfs algorithm to calculate that number
jnthn (Of all inlines)
And just getting our house in order ahead of that 18:26
timotimo ah, so after we're through completely once, we eliminate dead BBs and recalculate the dominance and such then 18:28
and then do a whole optimization pass with the new information?
jnthn Yeah
So the first pass is doing enough to inline things
The second is where I planned to put box/unbox removal, native ref elimination, etc.
timotimo how would it sound to give the "recalculate dfs" function a "verify or recalculate bb num" flag?
yeah
that'd be a decent place to do it, but if the child order is already correct immediately after inline, we'll at least remove unboxing from returns 18:29
potentially not immediately for the caller -> callee direction
though that'd probably also just follow from dead instruction removal and grabbing the register that gets boxed rather than the box directly when descending into the inlined graph 18:30
but moving the recompilation to after the last inline has happened will of course only recalculate once 18:33
"could not find processed initial dominator" *sigh* 18:45
bb number 1 has 0 preds 18:53
Spesh: could not find processed initial dominator
that's the problem; i wonder how it happens.
the bb with index 1 ends up being the entry bb which we were supposed to skip 19:00
19:06 awwaiid joined
timotimo which is most likely because our postorder is based on the non-fixed number of bbs, still 19:20
diakopter jnthn: since when you're debugging a 32KB nursery, all you care about is moving/updating pointers, is there a way to skip the marking/reaping steps (yes you'd need a lot of spare memory)? 19:21
meh, I guess that'd be an entirely different GC, since it would only scan the nurseries. never mind 19:23
I mean, it'd probably be a useful test, but it certainly wouldn't catch all the potential errors caught by the usual thing. 19:24
19:25 brrt joined
diakopter brrt: o/ 19:31
timotimo couldn't get it to work yet, but i've been distracted washing up and helping cook and such 19:42
and now eating
jnthn diakopter: Well, maybe, but I have to eat/sleep sometimes, it's no sweat to leave the computer stressing itself while I do those things :) 20:13
diakopter: And yeah, it's hard to know it'd catch all the useful stuff
While I was eating/doing errands, it finished building CORE.setting here :) 20:14
Alas, make install explodes in install-core-dist.pl 20:16
So I've some debugging ahead of me this week
nine_ jnthn: is this already with JIT or still without? 20:17
jnthn nine_: Without 20:18
nine_: brrt++ seemed interested in taking on the JIT changes
So I'll focus on hammering out the regressions 20:19
nine_ brrt++ seems interested in JITs ;)
jnthn Indeed ;)
They're a fun area :)
A bit more than hunting GC fails :P
(Though with their own painful debugging too, no doubt) 20:20
20:21 patrickz joined
brrt ohai.. yes JITs are fun :-) 20:22
patch won't be done this evening
jnthn brrt: np 20:24
brrt: I suspect even non-debugging builds of my branch will be too big a performance regression to stand a chance of a merge. 20:25
So I'll be putting the stack optimization that replaces the good parts of the ref-counting in first. 20:26
timotimo will you have time to get that up and running this week, you think?
i can't estimate how hard that'd be
jnthn Unlikely
timotimo okiedokie 20:27
jnthn If you're asking about the stack opt thing
timotimo that's what i'm asking about, aye
jnthn I don't have all the pieces settled in my head on how to most cleanly do it
Also, I'm really tired this week :S
jnthn blames over-long meeting on Monday 20:28
Though going to be an hour earlier the last couple of nights woulda helped too 20:29
*to bed
I'll be happy if I can flush out all the bugs from the "make frames collectables" changes this week :) 20:31
diakopter wonders whether to remind jnthn I pushed for collectable frames, like, years ago 20:32
diakopter fails at wondering non-aloud
jnthn diakopter: Yeah, but I don't recall you having a how-to-cheat strategy. :-) 20:33
diakopter probably I didn't, yes
jnthn And the performance of "just have all the frames collectable" is...non-awesome
But yeah, it was on the right path. 20:34
diakopter wonders how many times VMNull is pushed to the GC mark list
jnthn In nursery collections, probably never 20:35
Well, it never makes it onto the list
Things may ask to push it :)
diakopter oh, I didn't know you added that optimization
jnthn Pretty sure I did
yeah 20:36
if (*item_to_add && (worklist->include_gen2 || !((*item_to_add)->flags & MVM_CF_SECOND_GEN))) { \
diakopter hunh 20:37
jnthn (In MVM_gc_worklist_add 20:38
)
timotimo well, my num_bbs correction code is kind of wrong now :) 20:39
jnthn so, correct it :P 20:43
timotimo wow, silly me, just forgot to return the result of a recursively called reverse_postorder
the "runner" is now running in-place, at 0, while the finish line is at 3 21:13
and i've not done much to understand the algorithm itself yet
jnthn The paper it's from is refd at the top of graph.c
timotimo ah 21:14
jnthn rest time... 'night o/ 21:15
timotimo gnite jnthn! 21:16
masak 'night, jnthn 21:52
diakopter I wish Github had a "automatically keep this branch sync'd with [master] branch, and email me (and don't merge) if the merge would fail" button 21:57
geekosaur and same for "keep this repo synced with the one I forked from" 22:01

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!