Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-04-20

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:06 lizmat joined #moarvm
00:23 dalek MoarVM/more_debug_names_in_exceptions: 2e059d9 | timotimo++ | src/6model/reprs/P6opaque.c:
00:23 dalek MoarVM/more_debug_names_in_exceptions: "this type" will now actually mention the type
00:23 dalek MoarVM/more_debug_names_in_exceptions: review: https://github.com/MoarVM/MoarVM/commit/2e059d922e
00:23 dalek MoarVM/more_debug_names_in_exceptions: 350a1ba | timotimo++ | src/6model/reprs/P6opaque.c:
00:23 dalek MoarVM/more_debug_names_in_exceptions: "missing serialize" and "rebless" also mention type now
00:23 dalek MoarVM/more_debug_names_in_exceptions: review: https://github.com/MoarVM/MoarVM/commit/350a1ba691
00:23 dalek MoarVM/more_debug_names_in_exceptions: 6d630aa | timotimo++ | src/6model/reprs.c:
00:23 dalek MoarVM/more_debug_names_in_exceptions: default repr functions will now mention debug_name.
00:23 dalek MoarVM/more_debug_names_in_exceptions: review: https://github.com/MoarVM/MoarVM/commit/6d630aa48e
00:23 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 #moarvm
01:26 diakopter timotimo: :D'
02:15 geekosaur joined #moarvm
03:29 vendethiel joined #moarvm
06:10 leont joined #moarvm
06:35 Ven joined #moarvm
06:49 domidumont joined #moarvm
06:54 domidumont joined #moarvm
07:00 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:29 zakharyas joined #moarvm
07:47 domidumont joined #moarvm
07:51 lizmat joined #moarvm
08:45 brrt joined #moarvm
08:57 jnthn moarning o/
08:58 jnthn timotimo: Nice idea, see the review comment somebody left, though :)
08:58 Ven joined #moarvm
09:04 brrt good moarning too
09:35 synopsebot6 joined #moarvm
09:38 zakharyas joined #moarvm
10:05 cognominal joined #moarvm
10:08 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 timotimo but it's very good someone wrote a review <3
10:09 timotimo nine_: sorry about that :S
10:09 arnsholt gcc -Wall-the-things? =)
10:09 timotimo -Waste-all-my-time-please
10:09 arnsholt =D
10:09 * psch .oO( llvm --Wall-the-garden # apple specific extension )
10:21 dalek MoarVM/reframe: 1d92223 | jnthn++ | src/6model/6model.h:
10:21 dalek MoarVM/reframe: Add collectable flag for frames.
10:21 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/1d922231c9
10:21 dalek MoarVM/reframe: 2ec94b7 | jnthn++ | src/core/frame.h:
10:21 dalek MoarVM/reframe: Give MVMFrame an MVMCollectable header.
10:21 jnthn (just a rebase)
10:22 dalek joined #moarvm
10:24 Ven joined #moarvm
10:28 nwc10 OMG he killed dalek
10:29 dalek MoarVM/more_debug_names_in_exceptions: 75d91f6 | timotimo++ | src/6model/reprs/P6opaque.c:
10:29 dalek MoarVM/more_debug_names_in_exceptions: @patzim noticed a missing format string placeholder
10:29 dalek MoarVM/more_debug_names_in_exceptions: review: https://github.com/MoarVM/MoarVM/commit/75d91f6543
10:29 nine_ OMG he killed Ven
10:31 Ven joined #moarvm
10:39 brrt joined #moarvm
10:45 dalek MoarVM/reframe: f6f1085 | jnthn++ | src/core/ (3 files):
10:45 dalek MoarVM/reframe: Add write barriers to late-bound lexical binds.
10:45 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/f6f1085037
10:45 dalek MoarVM/reframe: 91530a3 | jnthn++ | src/gc/gen2.h:
10:45 dalek MoarVM/reframe: Bump number of gen2 bins.
10:46 dalek MoarVM/reframe:
10:46 dalek MoarVM/reframe: So that an MVMFrame fits inside the binned area, rather than landing
10:46 dalek MoarVM/reframe: up in an overflow. Might be able to undo this after an MVMFrame diet.
10:46 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/91530a358d
10:46 jnthn If you disable JIT, the reframe branch now gets to building CORE.setting in the Rakudo build
10:46 jnthn (It may yet complete that too, just takes a while in a debug/no-optimize build)
10:47 jnthn Especially one where we allocate all frames using the GC, 'cus I didn't put the new common case fast-path in yet :)
10:48 jnthn hah, it does as well
10:48 jnthn Guess that probably means it can build an NQP too
10:50 timotimo reassuring!
10:50 jnthn Yeah, it does
10:50 jnthn Even though I know I've a couple of missing write barriers still to add :)
10:50 jnthn And yeah, the JIT is teh bust :(
10:51 nwc10 ASAN build (JIT disabled) has just passed all the NQP tests
10:51 jnthn Nice
10:52 nwc10 Rakudo build failed with
10:52 nwc10 failed to load library 'dynext/libperl6_ops_moar.so'
10:52 nwc10 retrying with a non-parallel make
10:53 nwc10 might be a Makefile race condition
10:53 nwc10 no, not so. does explode
10:54 nwc10 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 nwc10 not seen that one before
10:54 timotimo that's not an error?
10:55 nwc10 no. it's a warning.
10:55 timotimo right
10:55 nwc10 it's an error in C++, IIRC
10:55 timotimo the function doesn't exist, i bet
10:55 timotimo i mean, not any more
10:55 nwc10 I suspect no prototype
10:55 jnthn nwc10: Oh...
10:55 nwc10 however, as "my" machine has 64 bit pointers and 32 bit ints
10:55 timotimo no, i bet the function was *deleted*
10:55 nwc10 it might cause fun
10:55 timotimo removed from the API
10:56 jnthn nwc10: Rakudo's moar/reframe branch
10:56 nwc10 aha
10:56 jnthn It's...hard to see how to do this and not break API there...
10:57 jnthn Thankfully, we can still get away with it *for now*
10:57 jnthn I suspect there'll come a time we can't so easily...
11:01 jnthn 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:04 * brrt is back from lunch
11:04 brrt ok, whats busted, and why
11:05 jnthn brrt: FRAME
11:05 Ven joined #moarvm
11:05 jnthn brrt: I'm killing of frame reference counting
11:05 jnthn *off
11:05 brrt oh, yes, i recall
11:05 brrt cool
11:05 jnthn brrt: In favor of a call stack for the simple "linear" case, and then using the normal GC if they "escape"
11:06 jnthn This breaks the "an MVMFrame never moves over its lifetime" invariant
11:06 brrt ok.........
11:06 nwc10 I forget what it gains us (and I think that you've explained previously)
11:06 brrt not having refcounts, yay
11:06 jnthn And thus the JIT's FRAME register gets out of date
11:07 brrt yes
11:07 brrt oh, that's... oh well
11:07 brrt not necessarily even that bad
11:07 dalek MoarVM/more_debug_names_in_exceptions: 98c462b | timotimo++ | src/6model/reprs/P6opaque.c:
11:07 dalek MoarVM/more_debug_names_in_exceptions: make no_such_attribute more helpful with action and debug_name
11:07 dalek MoarVM/more_debug_names_in_exceptions: review: https://github.com/MoarVM/MoarVM/commit/98c462b839
11:07 dalek MoarVM/more_debug_names_in_exceptions: b33db60 | timotimo++ | src/6model/reprs/P6opaque.c:
11:07 dalek MoarVM/more_debug_names_in_exceptions: invalid access (get/bind) now contain type and kind
11:07 dalek MoarVM/more_debug_names_in_exceptions: review: https://github.com/MoarVM/MoarVM/commit/b33db6092a
11:07 dalek MoarVM/more_debug_names_in_exceptions: a7f438b | timotimo++ | src/6model/reprs/P6opaque.c:
11:07 dalek MoarVM/more_debug_names_in_exceptions: add tons of detail to p6opaque's compose
11:07 dalek MoarVM/more_debug_names_in_exceptions:
11:07 dalek MoarVM/more_debug_names_in_exceptions: who knows, maybe someone will have need for this ...
11:07 dalek MoarVM/more_debug_names_in_exceptions: some time in the far future ...
11:07 dalek MoarVM/more_debug_names_in_exceptions: review: https://github.com/MoarVM/MoarVM/commit/a7f438b96c
11:07 jnthn brrt: Yeah, I'm curious how you'd handle it :)
11:07 brrt hmmm
11:08 brrt ok, let me check out how it's used, before i say anything else
11:09 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
11:10 brrt 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
11:10 jnthn brrt: The one that concerned me was some invokish check
11:10 brrt letmeseeaboutthat
11:11 brrt that is a good one
11:11 brrt i think the invokish check is always post-c-call
11:11 brrt so it's save to put the current frame in a callee-saved register, or on the stack
11:12 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
11:12 brrt hmm
11:12 brrt storing jit entry labels uses the frame pointer
11:12 jnthn brrt: But what if the thing did a GC?
11:12 brrt ehm
11:12 jnthn brrt: And moved the frame?
11:12 brrt good point...
11:12 jnthn If it's on the C stack though
11:13 jnthn Then we can actually use the temp roots thing we use for things normally on the C stack
11:13 jnthn I guess we can call that from the JIT
11:13 brrt we can, but, it's evil
11:13 jnthn :-)
11:15 brrt i'm not entirely sure
11:16 timotimo i wonder if it's more expensive to grab tc->current_frame after every invokish ...
11:16 timotimo invokish or allocish
11:16 jnthn timotimo: That's not the problem here
11:17 jnthn timotimo: The problem is that we use "FRAME != tc->cur_frame" as our "did we invoke" test
11:17 timotimo oh
11:17 timotimo OH!
11:17 brrt which is not a perfect test to start with, though
11:17 jnthn Which is now not going to be reliable
11:18 dalek MoarVM/reframe: 6bd4b0d | jnthn++ | src/core/frame. (2 files):
11:18 dalek MoarVM/reframe: Add write barriers on binding dynamic lexicals.
11:18 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/6bd4b0d506
11:24 brrt i can't imagine that we can't come up with something cleverer
11:24 brrt than what we have with invokish
11:24 dalek MoarVM/reframe: a30c2ea | jnthn++ | src/6model/reprs/NativeRef.c:
11:24 dalek MoarVM/reframe: Write barrier in string lexical ref assignment.
11:24 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/a30c2ea795
11:25 jnthn Lunch, bbl :)
11:30 nwc10 ilmari: ^^ :-)
11:30 brrt eat well
11:31 brrt jnthn: i feel like adding a temp root on every potentially invokish function call is more trouble than it is worth
11:31 brrt it means pre-and post-wrapping
11:31 brrt (for when you're back)
11:31 timotimo so then just add it when we enter and remove it when we leave?
11:32 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?
11:32 brrt hmmm
11:32 timotimo sorry, i mean when we enter a jitted frame and when we leave it
11:32 brrt that is true
11:32 timotimo that *should* still leave all push/pop pairs properly paired up, right?
11:32 brrt yes
11:33 brrt it still feels like a hack :-)
11:33 brrt and i'm not sure why we couldn't figure out something... more clever
11:33 brrt less hacky
11:34 timotimo well, a jitted frame can put the root in there properly when it's marked
11:35 timotimo in its gc_mark, i mean
11:35 timotimo does that sound good?
11:35 konobi joined #moarvm
11:35 brrt not yet
11:36 konobi just been reading about luajit... pretty dang impressive work
11:36 timotimo yeah, luajit is really quite something
11:36 * brrt concurs
11:37 timotimo i don't understand why using gc_mark isn't good :)
11:41 brrt we need a cheap and effective way to see that we are no longer in the same place on the stack
11:41 brrt the frame pointer is the main thing
11:42 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
11:42 brrt we take a pointer to the frame in the jit enter code
11:42 brrt we push that as a temp root
11:42 brrt we pop it on leaving
11:43 brrt then, we *pass a pointer to that* on jit entry
11:43 brrt e.g. jit entry gets MVMFrame**
11:43 timotimo a pointer to the pointer you mean?
11:43 brrt because the first pointer is on the stack, it ought to be in cache
11:43 brrt yes
11:44 timotimo sorry, why do we need the MVMFrame** on jit entry?
11:44 timotimo i thought we'd just pushed that as a temporary root?
11:45 timotimo the work pointer won't move, right? i mean, the blob of memory that we're working on
11:45 brrt ehm
11:45 timotimo i must be misunderstanding something important :)
11:46 brrt i must be misexplaining something important
11:46 brrt :-)
11:46 timotimo don't misunderestisplain me!
11:47 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:48 brrt 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 brrt so we want that to be a cheap check that is usually false
11:48 timotimo .o( wheeeee! )
11:49 ilmari *boing*
11:50 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 brrt so we can make that comparsison, 'are we still in the same frame'
11:51 brrt actually, any way to answer that question is good to me
11:52 brrt easy to forget what we're doing it for :-)
12:12 cognominal joined #moarvm
12:16 domidumont joined #moarvm
12:18 domidumont joined #moarvm
12:28 * jnthn back
12:29 brrt \o jnthn
12:32 jnthn So, something still wants a fix, given my build on HEAD just exploded Rakudo CORE.setting
12:32 jnthn (Something other than the JIT :))
12:34 brrt :-)
12:41 dalek MoarVM/reframe: 40a3087 | jnthn++ | src/6model/serialization.c:
12:41 dalek MoarVM/reframe: Another write barrier.
12:41 dalek MoarVM/reframe:
12:41 dalek MoarVM/reframe: Maybe not needed, but better safe than sorry.
12:41 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/40a3087ff1
12:43 Ven joined #moarvm
12:47 dalek MoarVM/reframe: 6d15151 | jnthn++ | src/core/frame.c:
12:47 dalek MoarVM/reframe: Fix continuation clone for GC-able frames.
12:47 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/6d151518cf
12:51 * 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
13:00 jnthn Yeah, that shows up plenty wrong.
13:24 dalek MoarVM/reframe: b625398 | jnthn++ | src/6model/reprs/MVMIter.c:
13:24 dalek MoarVM/reframe: Add missing MVMROOTs in context iteration.
13:24 dalek MoarVM/reframe:
13:24 dalek MoarVM/reframe: One of these cases was an existing bug. The other was needed for the
13:24 dalek MoarVM/reframe: frame changes.
13:24 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/b625398c80
13:35 dalek MoarVM/reframe: 5ac981d | jnthn++ | src/gc/debug.h:
13:35 dalek MoarVM/reframe: Update debugging macro for lazy fromspace alloc.
13:35 dalek MoarVM/reframe:
13:35 dalek MoarVM/reframe: Also make it dump out the pointer in question.
13:35 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/5ac981d978
13:46 dalek MoarVM/reframe: e1114b6 | jnthn++ | src/core/frame.c:
13:46 dalek MoarVM/reframe: Missing MVMROOT of outer.
13:46 dalek MoarVM/reframe:
13:46 dalek MoarVM/reframe: Meant we could end up assigning outdated pointers to a frame->outer.
13:46 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/e1114b6671
13:46 dalek MoarVM/reframe: 4509fd0 | jnthn++ | src/core/frame.c:
13:46 dalek MoarVM/reframe: Remove a bit of now-unrequied flow control.
13:46 dalek MoarVM/reframe:
13:46 dalek MoarVM/reframe: We don't need the NULL check when we're not going to try and fiddle
13:46 dalek MoarVM/reframe: with a reference count.
13:46 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/4509fd0cb1
13:47 jnthn Onto the next SEGV...
13:53 [Coke] RT: 26 SEGVs.
13:55 domidumont joined #moarvm
13:56 jnthn [Coke]: hah, I meant "arising from the stuff I'm refactoring"
13:56 jnthn But yeah, I'm trying to pick those off too :)
13:59 Ven joined #moarvm
14:10 zakharyas joined #moarvm
14:13 brrt joined #moarvm
14:14 brrt jnthn: I think i've solved it
14:14 brrt we add a current_frame_nr and next_frame_number to the threadcontext
14:14 brrt initialized to zero
14:15 brrt whenever we create a frame, we increment the next frame number and assign it to the frame
14:16 brrt e.g. frame->sequence_nr = ++tc->next_frame_number;
14:16 brrt whenever we enter the frame (MVM_frame_invoke iirc), we assign the current frame number to the tc
14:17 brrt tc->current_frame_nr = frame->sequence_nr
14:18 brrt 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 brrt sequence numbers may wrap arounnd all we like (just not too often)
14:18 brrt we no longer need FRAME in a register, or even on the stack as a gc temp root
14:19 * brrt will make a patch
14:21 jnthn brrt: ooh :)
14:21 jnthn brrt++
14:32 brrt oh, and during unwinding, of course
14:32 brrt that's centrally handled somewhere too, iirc
14:37 * 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:58 lizmat joined #moarvm
15:08 zakharyas joined #moarvm
15:13 dalek MoarVM/reframe: 5da3e1e | jnthn++ | src/6model/reprs/MVMCompUnit.c:
15:13 dalek MoarVM/reframe: Fix a SC resolution / GC race.
15:13 dalek MoarVM/reframe:
15:13 dalek MoarVM/reframe: Not a race in the threading sense, just an ordering one. If the SC is
15:13 dalek MoarVM/reframe: not resolved by the compunit's code before the next GC run happens,
15:13 dalek MoarVM/reframe: then the ->sc pointer can be out of date.
15:13 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/5da3e1ec14
15:24 geekosaur joined #moarvm
15:24 jnthn That as a darn pain to find
15:24 jnthn And nothing at all to do with the refactor I've been doing
15:26 jnthn NQP builds and passes tests on a 32KB nursery
15:26 jnthn Rakudo will take forever to build with a 32KB nursery
15:28 timotimo i bet
15:28 jnthn Curently it's building Actions.nqp
15:32 jnthn Now it's made it so far as building CORE.setting
15:32 jnthn Heap corruption detected: pointer 000000000068E9D0 to past fromspace
15:32 jnthn wow
15:33 jnthn Guess there is something more :)
15:42 * TimToady wonders if a frame can move out from under our current env var cache...
15:43 jnthn TimToady: That's stored in the frame, and so far as I can tell it's safe
15:43 jnthn (I had to fix up that bit of code)
15:43 jnthn I'm suspecting the thing I just ran into now is another "not related to this refactor"
15:43 TimToady s/env/dyn/
15:44 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
15:44 dalek MoarVM/reframe: bb42773 | jnthn++ | src/gc/worklist.h:
15:44 dalek MoarVM/reframe: Detect another problem in GC worklist add debug.
15:44 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/bb42773efc
15:44 jnthn timotimo: Apparently, yes
15:45 jnthn Which probably means we should set up automated runs with a small nursery
15:46 [Coke] We really should have a lot more automated testing, aye. :)
15:46 jnthn Yeah. Daily automated valgrind too was on my todo list
15:46 jnthn Well, still is, I just...have a long todo list :P
15:46 jnthn And plenty of things wanting to be near the top
15:50 timotimo .o( and i'm not too helpful at making it any shorter these days )
15:52 jnthn Oh wait, that previous commit may be bogus...
15:53 jnthn yeah, it is as well
15:54 jnthn Darn
15:54 jnthn 'cus we've flipped from/to at the point we're running that
15:56 timotimo at least that'd mean the very first GC run would explode when marking the very first object from the nursery, no?
15:58 jnthn yeah, exactly
15:58 jnthn Didn't stop me looking into why that pointer was bad :P
15:58 zakharyas joined #moarvm
15:58 timotimo i can imagine
16:02 vendethiel joined #moarvm
16:07 jnthn Gah, it SEGVs at my fix for the previous issue :/
16:10 jnthn And it's enitrely possible that is the reason for the next fail
16:11 timotimo AFK for a bit
16:11 dalek MoarVM/reframe: 0081193 | jnthn++ | src/gc/worklist.h:
16:11 dalek MoarVM/reframe: Correct worklist add sanity check.
16:11 dalek MoarVM/reframe:
16:11 dalek MoarVM/reframe: We've flipped to/from by the point we hit this check, so it can't be
16:11 dalek MoarVM/reframe: just like the check in gc/debug.h.
16:11 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/0081193935
16:19 awwaiid joined #moarvm
16:21 dalek MoarVM/jnthn/debug: fc8c871 | jnthn++ | src/ (3 files):
16:21 dalek MoarVM/jnthn/debug: Branch to shove debug tweaks to my VM.
16:21 dalek MoarVM/jnthn/debug: review: https://github.com/MoarVM/MoarVM/commit/fc8c871973
16:29 timotimo oh, interesting
16:31 jnthn Oh wow, we actually free the SC
16:31 timotimo neat, so things get cleaned up when things are not needed
16:31 timotimo (except, maybe we free it accidentally? :) )
16:32 jnthn Between its creation and trying to take reference to it
16:32 jnthn Yeah, prematurely
16:32 timotimo oooh, whoops :)
16:32 timotimo so it's not rooted somewhere before the first allocaty thing gets called?
16:33 jnthn It's only held by the sc_weakhash, which doesn't mark it to be weak
16:33 jnthn :)
16:34 timotimo oooh
16:34 timotimo i didn't know we have weak hashes yet! :P
16:37 jnthn We...don't officially have weak refs
16:37 jnthn But we fake them up
16:37 jnthn Badly
16:37 jnthn Which means I should probably implement them properly.
16:42 dalek MoarVM/jnthn/debug: 6e30284 | jnthn++ | src/6model/reprs/MVMCompUnit.c:
16:42 dalek MoarVM/jnthn/debug: Revert "Fix a SC resolution / GC race."
16:42 dalek MoarVM/jnthn/debug:
16:42 dalek MoarVM/jnthn/debug: This reverts commit 5da3e1ec149d8fcc8127242a289b965d0c8db4a9.
16:42 dalek MoarVM/jnthn/debug: review: https://github.com/MoarVM/MoarVM/commit/6e302841f7
16:42 dalek MoarVM/jnthn/debug: 31f3d4d | jnthn++ | src/ (3 files):
16:42 dalek MoarVM/jnthn/debug: A (hopefully) more correct fix for the SC race.
16:42 dalek MoarVM/jnthn/debug:
16:42 dalek MoarVM/jnthn/debug: The previous fix more hid the issue than resolved it. This fixes it
16:42 dalek MoarVM/jnthn/debug: by making sure we mark its one reference in the weak hash (so it does
16:42 dalek MoarVM/jnthn/debug: not go and get collected) until a compunit actually claims it.
16:42 dalek MoarVM/jnthn/debug: review: https://github.com/MoarVM/MoarVM/commit/31f3d4d18e
16:45 jnthn OK, that seems a bit better
16:48 dalek MoarVM/reframe: d1485f7 | jnthn++ | src/6model/reprs/MVMCompUnit.c:
16:48 dalek MoarVM/reframe: Revert "Fix a SC resolution / GC race."
16:48 dalek MoarVM/reframe:
16:48 dalek MoarVM/reframe: This reverts commit 5da3e1ec149d8fcc8127242a289b965d0c8db4a9.
16:48 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/d1485f7b20
16:48 dalek MoarVM/reframe: abe4cdd | jnthn++ | src/ (3 files):
16:48 dalek MoarVM/reframe: A (hopefully) more correct fix for the SC race.
16:48 dalek MoarVM/reframe:
16:48 dalek MoarVM/reframe: The previous fix more hid the issue than resolved it. This fixes it
16:48 dalek MoarVM/reframe: by making sure we mark its one reference in the weak hash (so it does
16:48 dalek MoarVM/reframe: not go and get collected) until a compunit actually claims it.
16:48 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/abe4cddaef
16:57 jnthn That builds NQP and passes its tests OK again...and doing a Rakudo build from scratch
16:57 jnthn Locally got some debugging turned on and 32KB nursery
16:59 jnthn It's made it some way into CORE.setting this time. Guess this'll not be fast :)
17:07 jnthn I'll leave it running, but calling it a day...tired :)
17:08 * nwc10 hopes that the beer fridge is stocked
17:09 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:10 timotimo 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
17:11 jnthn nwc10: It is :)
17:11 timotimo oh, is there a simple call that i can use for that? probably!
17:11 timotimo i won't have to invent it myself!
17:11 jnthn No
17:11 jnthn It's not exposed
17:11 timotimo but i can probably tear it out of some place?
17:11 jnthn spesh/graph.c is where it lives though
17:14 * jnthn ponders what to have for dinner :)
17:15 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:17 domidumont joined #moarvm
17:18 jnthn yeah, think you'd have to get rid of the existing children
17:18 jnthn maybe do that beforehand
17:19 jnthn 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
17:19 timotimo yay
17:19 timotimo see you later jnthn :)
17:51 konobi left #moarvm
17:57 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 timotimo so i need to clear out some stuff it seems
17:57 timotimo and for that i'll have to actually read that code :S
18:15 timotimo 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:16 timotimo 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:20 timotimo 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:21 timotimo time to build a function name just like in PHP
18:22 jnthn Some very tasty Indian scrambled eggs later, and CORE.setting build is still alive
18:22 timotimo wow, that's rather slow running
18:22 jnthn Well, it's GCing every 32KB
18:22 timotimo MVM_spesh_manipulate_remove_successor_real? _clean? _properly? _EX?
18:23 timotimo 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? :)
18:24 timotimo the dfs currently errors out when that number isn't "right"
18:25 timotimo 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?
18:25 jnthn I'd been thinking about making a second pass post-inline
18:25 timotimo but i'd be using pretty much the exact dfs algorithm to calculate that number
18:25 jnthn (Of all inlines)
18:26 jnthn And just getting our house in order ahead of that
18:28 timotimo ah, so after we're through completely once, we eliminate dead BBs and recalculate the dominance and such then
18:28 timotimo and then do a whole optimization pass with the new information?
18:28 jnthn Yeah
18:28 jnthn So the first pass is doing enough to inline things
18:28 jnthn The second is where I planned to put box/unbox removal, native ref elimination, etc.
18:28 timotimo how would it sound to give the "recalculate dfs" function a "verify or recalculate bb num" flag?
18:28 timotimo yeah
18:29 timotimo 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 timotimo potentially not immediately for the caller -> callee direction
18:30 timotimo 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:33 timotimo but moving the recompilation to after the last inline has happened will of course only recalculate once
18:45 timotimo "could not find processed initial dominator" *sigh*
18:53 timotimo bb number 1 has 0 preds
18:53 timotimo Spesh: could not find processed initial dominator
18:53 timotimo that's the problem; i wonder how it happens.
19:00 timotimo the bb with index 1 ends up being the entry bb which we were supposed to skip
19:06 awwaiid joined #moarvm
19:20 timotimo which is most likely because our postorder is based on the non-fixed number of bbs, still
19:21 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:23 diakopter meh, I guess that'd be an entirely different GC, since it would only scan the nurseries. never mind
19:24 diakopter 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:25 brrt joined #moarvm
19:31 diakopter brrt: o/
19:42 timotimo couldn't get it to work yet, but i've been distracted washing up and helping cook and such
19:42 timotimo and now eating
20:13 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 jnthn diakopter: And yeah, it's hard to know it'd catch all the useful stuff
20:14 jnthn While I was eating/doing errands, it finished building CORE.setting here :)
20:16 jnthn Alas, make install explodes in install-core-dist.pl
20:16 jnthn So I've some debugging ahead of me this week
20:17 nine_ jnthn: is this already with JIT or still without?
20:18 jnthn nine_: Without
20:18 jnthn nine_: brrt++ seemed interested in taking on the JIT changes
20:19 jnthn So I'll focus on hammering out the regressions
20:19 nine_ brrt++ seems interested in JITs ;)
20:19 jnthn Indeed ;)
20:19 jnthn They're a fun area :)
20:19 jnthn A bit more than hunting GC fails :P
20:20 jnthn (Though with their own painful debugging too, no doubt)
20:21 patrickz joined #moarvm
20:22 brrt ohai.. yes JITs are fun :-)
20:22 brrt patch won't be done this evening
20:24 jnthn brrt: np
20:25 jnthn 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:26 jnthn 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?
20:26 timotimo i can't estimate how hard that'd be
20:26 jnthn Unlikely
20:27 timotimo okiedokie
20:27 jnthn If you're asking about the stack opt thing
20:27 timotimo that's what i'm asking about, aye
20:27 jnthn I don't have all the pieces settled in my head on how to most cleanly do it
20:27 jnthn Also, I'm really tired this week :S
20:28 * jnthn blames over-long meeting on Monday
20:29 jnthn Though going to be an hour earlier the last couple of nights woulda helped too
20:29 jnthn *to bed
20:31 jnthn I'll be happy if I can flush out all the bugs from the "make frames collectables" changes this week :)
20:32 * diakopter wonders whether to remind jnthn I pushed for collectable frames, like, years ago
20:32 * diakopter fails at wondering non-aloud
20:33 jnthn diakopter: Yeah, but I don't recall you having a how-to-cheat strategy. :-)
20:33 diakopter probably I didn't, yes
20:33 jnthn And the performance of "just have all the frames collectable" is...non-awesome
20:34 jnthn But yeah, it was on the right path.
20:34 * diakopter wonders how many times VMNull is pushed to the GC mark list
20:35 jnthn In nursery collections, probably never
20:35 jnthn Well, it never makes it onto the list
20:35 jnthn Things may ask to push it :)
20:35 diakopter oh, I didn't know you added that optimization
20:35 jnthn Pretty sure I did
20:36 jnthn yeah
20:36 jnthn if (*item_to_add && (worklist->include_gen2 || !((*item_to_add)->flags & MVM_CF_SECOND_GEN))) { \
20:37 diakopter hunh
20:38 jnthn (In MVM_gc_worklist_add
20:38 jnthn )
20:39 timotimo well, my num_bbs correction code is kind of wrong now :)
20:43 jnthn so, correct it :P
20:43 timotimo wow, silly me, just forgot to return the result of a recursively called reverse_postorder
21:13 timotimo the "runner" is now running in-place, at 0, while the finish line is at 3
21:13 timotimo and i've not done much to understand the algorithm itself yet
21:13 jnthn The paper it's from is refd at the top of graph.c
21:14 timotimo ah
21:15 jnthn rest time... 'night o/
21:16 timotimo gnite jnthn!
21:52 masak 'night, jnthn
21:57 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
22:01 geekosaur and same for "keep this repo synced with the one I forked from"

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary