Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-07-06

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

All times shown according to UTC.

Time Nick Message
00:30 Zoffix joined #moarvm
01:49 ilbot3 joined #moarvm
01:49 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:11 coverable6 joined #moarvm
05:11 mst_ joined #moarvm
05:19 eviltwin_b joined #moarvm
05:28 brrt joined #moarvm
06:38 brrt joined #moarvm
07:01 domidumont joined #moarvm
07:08 domidumont joined #moarvm
07:25 brrt fingers crossed
07:25 brrt (i've just compiled my great spesh annotation handling refactor and am running nqp build)
07:45 brrt joined #moarvm
07:57 brrt rakudo build is fine so far
07:58 AlexDaniel joined #moarvm
07:58 brrt rakudo make test is fine
08:00 lizmat whee! :-)
08:34 jnthn morning o/
08:36 nwc10 correct!
08:47 Geth ¦ MoarVM/even-moar-jit: 31c4c54eca | (Bart Wiegmans)++ | 6 files
08:47 Geth ¦ MoarVM/even-moar-jit: Handle spesh annotations in the expr JIT
08:47 Geth ¦ MoarVM/even-moar-jit:
08:47 Geth ¦ MoarVM/even-moar-jit: Previously we tried to let the legaacy JIT handle these, but that
08:47 Geth ¦ MoarVM/even-moar-jit: doesn't work very well, as we might handle the same annotations twice,
08:47 Geth ¦ MoarVM/even-moar-jit: and we didn't handle the after-instruction annotations at all. Also,
08:47 Geth ¦ MoarVM/even-moar-jit: it lead to the 'breakup' of the expression tree.
08:47 Geth ¦ MoarVM/even-moar-jit:
08:47 Geth ¦ MoarVM/even-moar-jit: With this patch the expr jit handles virtually all annotations, with
08:47 Geth ¦ MoarVM/even-moar-jit: the exception of DEOPT_INLINE and DEOPT_ONE, because these are
08:47 Geth ¦ MoarVM/even-moar-jit: attached to guards anyway, and we don't handle those yet.
08:47 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/31c4c54eca
08:47 brrt the cute bit
08:48 brrt i overwrite a DYNAMIC_LABEL control handle (which should be called POSITION_MARKER, but whatever) with a THROWISH_PRE, which has virtually the same effect
08:49 brrt this saves me from having to nest two guards
08:54 jnthn :)
09:24 Geth ¦ MoarVM/spesh-worker: 69cc08a25f | (Jonathan Worthington)++ | src/spesh/arg_guard.c
09:24 Geth ¦ MoarVM/spesh-worker: Insert rw container check nodes.
09:24 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/69cc08a25f
09:24 Geth ¦ MoarVM/spesh-worker: af8a998968 | (Jonathan Worthington)++ | src/spesh/dump.c
09:24 Geth ¦ MoarVM/spesh-worker: Update dump output of deref nodes.
09:24 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/af8a998968
09:26 zakharyas joined #moarvm
09:34 zakharyas joined #moarvm
09:45 brrt ugh, clang doesn't understand ; as a comment marker in assembly
10:02 Geth ¦ MoarVM/spesh-worker: ef6f631db8 | (Jonathan Worthington)++ | src/spesh/arg_guard.c
10:02 Geth ¦ MoarVM/spesh-worker: Add decont type tests into arg guard tree.
10:02 Geth ¦ MoarVM/spesh-worker:
10:02 Geth ¦ MoarVM/spesh-worker: With this, all the cases the current specializer spits out are - at
10:02 Geth ¦ MoarVM/spesh-worker: least in theory - built into the tree.
10:02 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/ef6f631db8
10:03 jnthn Example dump output: https://gist.github.com/jnthn/0e9542c94bbba1b6374c0af3cd53e35b
10:04 jnthn Notice how unlike today it lifts the callsite match and reading out of the args buffer
10:05 nwc10 "next week in MoarVM"
10:05 jnthn So we only need to do those comparisons once, not once for each candidate
10:05 nwc10 because "this week in $foo" is so last week.
10:05 nwc10 and no, I did not "notice" because I'm totally unfamiliar with how it used to look :-/
10:11 ggoebel joined #moarvm
10:11 jnthn Other thing is that we have a current active "test register", which if we JIT these guards could just be a CPU register
10:12 jnthn And since there's only one of them, no allocation fun
10:12 timotimo in the previous implementation we had an array of all candidates and each candidate has its own array of tests. if two candidates share tests, they'll be re-run until a full match is found
10:13 nine (architectural improvements)++
10:13 jnthn Next step is to implement the thingy that will interpret this
10:13 jnthn Well, also going to do a test run to make sure I don't hit any panics by surprise
10:14 jnthn Then I'll run it *and* the current guard checking implementation
10:14 jnthn And see that they always come out with the same result
10:15 nwc10 and only then will you stop for lunch? :-)
10:16 jnthn oh dear, an exploding test file
10:17 jnthn Which runs OK on its own out of the harness. Aww.
10:17 nwc10 pipe it to cat?
10:18 jnthn No difference, alas
10:19 jnthn But seems the spectest run will show up some more cases
10:19 jnthn It's an explosion in GC
10:21 jnthn Darn, every one I try is fine outside of the harness
10:22 timotimo do you at least get it if you run a single file with prove or some other tap parser?
10:25 jnthn Grr, can't even get the one in make test to fail again
10:25 timotimo time for a stresstest?
10:25 timotimo gc torture i mean
10:26 jnthn Hm, get a valgrind whine that seems unrelated
10:27 Geth ¦ MoarVM/spesh-worker: 50005f3142 | (Jonathan Worthington)++ | src/spesh/log.c
10:27 Geth ¦ MoarVM/spesh-worker: Use correct union branch to log static values.
10:27 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/50005f3142
10:28 * jnthn does a spectest again
10:28 jnthn I'm sure that one can't be it
10:28 jnthn hah, no
10:29 jnthn t/spec/S17-procasync/no-runaway-file-limit.t seems a reliable-ish exploder
10:30 jnthn Ah yes, invalid reads
10:30 timotimo i got a segv on every start because i forgot to recompile rakudo's extops to use the new headers %)
10:31 jnthn oh, duh...
10:31 jnthn Nothing to do with guard stuff at all, I think
10:37 timotimo aha double free or corruption
10:38 timotimo ugh, in precomp tests
10:38 timotimo those aren't small to be good debugging targets
10:39 Geth ¦ MoarVM/spesh-worker: 2502b0cdcb | (Jonathan Worthington)++ | src/spesh/log.c
10:39 Geth ¦ MoarVM/spesh-worker: Correct missing check in parameter logging.
10:39 Geth ¦ MoarVM/spesh-worker:
10:39 Geth ¦ MoarVM/spesh-worker: Parameter logging may log two entries. Must freshly get the logging
10:39 Geth ¦ MoarVM/spesh-worker: buffer each time, in case it became full and was sent.
10:39 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/2502b0cdcb
10:51 timotimo spectest looks kinda happy
10:51 timotimo not completely
10:51 jnthn Yeah, I still think somethings kinda up but it's not easy to repro
10:52 timotimo huh, the more i scroll the less happy it looks %)
10:52 timotimo i started out on a screen that had only "ok" on it and more "ok" scrolling past
10:54 jnthn Some of my failures are down to not having a latest Rakudo
10:54 timotimo oh wow, i'm further behind than i thought, too
10:55 nine jnthn: re 2502b0cdcb the if (IS_CONCRETE(param)) block now runs even if tc->spesh_log is NULL. That's different than before.
10:56 jnthn nine: True, but it's also harmless
10:58 jnthn Very occasionally, it'll cause a bit of throwaway work.
11:02 brrt joined #moarvm
11:06 Geth ¦ MoarVM/spesh-worker: 6aac97bf40 | (Jonathan Worthington)++ | 2 files
11:06 Geth ¦ MoarVM/spesh-worker: Initial implementation of arg guard interpreter.
11:06 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/6aac97bf40
11:06 Geth ¦ MoarVM/spesh-worker: 80a4d43309 | (Jonathan Worthington)++ | src/core/frame.c
11:06 Geth ¦ MoarVM/spesh-worker: Run new arg guards; compare the output.
11:06 Geth ¦ MoarVM/spesh-worker:
11:06 Geth ¦ MoarVM/spesh-worker: This shows up discrepancies in what is found today and what the new
11:06 Geth ¦ MoarVM/spesh-worker: mechanism discovers. There are some, which will next need to be
11:06 Geth ¦ MoarVM/spesh-worker: investigated.
11:06 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/80a4d43309
11:07 jnthn And that gives me my things to explore after lunch. bbl :)
11:08 zakharyas joined #moarvm
11:22 * timotimo also looks
11:25 timotimo oh i didn't know MVM_oops gives a stacktrace, too
11:29 timotimo hm, the spesh dumper for arg guards isn't call-from-gdb-friendly
11:45 timotimo i have been poking at one of the nativecall test files; routine-sig-sanity.t
11:46 timotimo the new guards tool finds no matching candidate, whereas the old one does. it's the first candidate and it's guarded with conc + dc_type scalar
11:47 Geth ¦ MoarVM/even-moar-jit: 7c58fc80fa | (Bart Wiegmans)++ | docs/jit/todo.org
11:47 Geth ¦ MoarVM/even-moar-jit: Describe stack walker for getting current position
11:47 Geth ¦ MoarVM/even-moar-jit:
11:47 Geth ¦ MoarVM/even-moar-jit: The code snippet actually works.
11:47 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/7c58fc80fa
11:48 timotimo i need to rr this so i can step back into the ag matcher
11:50 timotimo can't make install because the ag rejects one of the install scripts ...
11:51 timotimo okay installed it by bypassing the oops
11:52 timotimo something's very wrong with my installation here
12:00 timotimo arghle barghle, now the test file doesn't fail any more
12:06 timotimo okay i found something
12:09 * jnthn back
12:12 Geth ¦ MoarVM/spesh-worker: c42ecb6074 | (Jonathan Worthington)++ | src/core/frame.c
12:12 Geth ¦ MoarVM/spesh-worker: Include frame name/cuuid in mismatch error.
12:12 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/c42ecb6074
12:12 brrt joined #moarvm
12:15 timotimo jnthn: we have an anonymous union in the arg guard node; i thought we had to have all unions be nymous?
12:15 jnthn Um...what for?
12:15 jnthn Some compiler?
12:15 * jnthn checked the MSVC docs and they seemed allowed there
12:16 jnthn Ah, if you disable OSR then the NQP build completes
12:16 jnthn So the missing candidate is apparently OSR-y
12:19 timotimo okay so i'm invoking Stringy and it's going through the tree matching cs, container type, rwness, and then it doesn't find a match on the type inside the container
12:19 timotimo it's only checking for IO::Path, though
12:19 jnthn I'm looking at the NQP case(s) first, fwiw :)
12:19 timotimo let's look at the spesh candidate that gets the match outside the agn runner
12:20 jnthn Since they don't have any of the DEREF things in them :)
12:20 timotimo that's probably wise %)
12:20 jnthn I've no idea why OSR would make a difference
12:21 timotimo the num_spesh on the frame and the number of result calls in the agn tree match up at least
12:23 jnthn In the case in NQP, we're actually missing Wrong result from new arg guard for EXPR (100): got 2, wanted 0
12:24 jnthn Which is a bit nuts
12:25 jnthn Because the last guard tree it dumps out only contains result 0 and result 1 o.O
12:32 brrt joined #moarvm
12:35 timotimo hm, okay, so
12:35 timotimo we have a discrepancy between rwness handling in one vs the other
12:36 timotimo this is how i think it goes:
12:37 timotimo the old one is happy when an rw container is passed for a non-rw check
12:37 timotimo the new one will not consider anything that doesn't want an rw container if the container ends up rw
12:38 timotimo we don't use rw containers inside nqp (except maybe in the test suite for lexicalrefs?) so it wouldn't asplode there
12:40 jnthn Meanwhile, it seems that the NQP issue is that we are adding two things that have the same guards
12:40 Geth ¦ MoarVM/spesh-worker: 4120f7f35b | (Jonathan Worthington)++ | src/spesh/arg_guard.c
12:40 Geth ¦ MoarVM/spesh-worker: Detect and panic over duplicate guard addition.
12:40 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/4120f7f35b
12:40 jnthn That check makes it panic earlier
12:41 jnthn ho, it's OSR that is adding the dupe
12:41 jnthn But that OSR'd guard would never be reachable
12:41 jnthn or, OSR'd version I mean
12:41 timotimo that'd be why it's sensitive to osr, then. does it have a different code path to changing the tree?
12:42 jnthn no, but it may have a different one for "do we already have this"
12:44 jnthn ah
12:44 jnthn /* Beaten! */
12:44 jnthn result = osr ? NULL : &static_frame->body.spesh_candidates[i];
12:45 jnthn It then interprets that NULL to mean "we should install a new candidate"
12:45 jnthn But we perhaps should not :)
12:48 timotimo aha :)
12:49 Geth ¦ MoarVM/spesh-worker: 2a99ecdf62 | (Jonathan Worthington)++ | src/spesh/candidate.c
12:49 Geth ¦ MoarVM/spesh-worker: Don't install "hidden" OSRs in new arg guards.
12:49 Geth ¦ MoarVM/spesh-worker:
12:49 Geth ¦ MoarVM/spesh-worker: These are technically dupes today. This issue will be revisited when
12:49 Geth ¦ MoarVM/spesh-worker: OSR gets a larger overhauling during the move to doing it on the spesh
12:50 Geth ¦ MoarVM/spesh-worker: worker thread.
12:50 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/2a99ecdf62
12:51 jnthn With that we get through the NQP build and tests fine
12:51 jnthn Building Rakudo now
12:51 jnthn Reached CORE.setting
12:55 jnthn And works but make test failures, probably the thing timotimo found
12:55 brrt joined #moarvm
12:56 timotimo we could make the last no-branch of the yes-rw-branch point at the no-rw-branch and that should make things equivalent to the old guard system again
12:58 timotimo it'd give everything that wants rw priority if there is rw, but if there's nothing that needs the rw we'll go through the ro candidates
12:58 timotimo perhaps we'll want to note "this needs another specialization" anyway, though?
12:59 jnthn Hmm, interesting
12:59 timotimo not exactly sure how the different levels above spesh will do all of this with regards to read-writability, i.e. if there would be different staticframes anyway for some reason
13:01 jnthn Yeah, today "not rw" counts as "don't care"
13:01 timotimo right. in the new one it counts as "oh no!"
13:02 jnthn Indeed.
13:02 timotimo it will blow up the "do both agree?" but not cause actual trouble
13:02 jnthn It's a bit curious in that
13:03 jnthn my $a = [1,2,3]; sub x() { $a };
13:03 jnthn Then
13:03 timotimo fwiw, the "point end-of-yes-branch to no-branch" thing is potentially incompatible with multiple args
13:03 jnthn sub y($v) { }; y($a) for ^100; y(x()) for ^100
13:04 jnthn Will produce one specialization today
13:04 jnthn While
13:04 jnthn sub y($v) { }; y(x()) for ^100; y($a) for ^100
13:04 jnthn Will produce two
13:04 timotimo yup
13:06 jnthn Which feels...a bit off
13:06 jnthn This brings up another spesh weakness at the moment though
13:06 jnthn Which is that it doesn't actually matter if the rw-ness is used for now
13:06 timotimo right
13:06 jnthn uh
13:06 jnthn *used or not
13:06 jnthn Which is something we'll fix
13:06 timotimo we have a system for telling "this guard was used" but only for guard instructions inside spesh itself
13:06 jnthn I wonder if there's a possible bug here
13:06 timotimo i mean in the target bytecode itself
13:08 timotimo it's really rather warm here today :|
13:09 jnthn m: my $a = [1,2,3]; sub x() { $a }; multi m($v is rw) { say 1 }; multi m($v) { say 2 }; sub y(\v) { m(v) }; y(x()) for ^50; y($a) for ^50
13:09 camelia rakudo-moar c65652: OUTPUT: «2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤2␤1␤1␤1␤1␤1␤1␤1␤1␤1␤1␤1␤1␤1␤1…»
13:10 jnthn m: my $a = [1,2,3]; sub x() { $a }; multi m($v is rw) { print 1 }; multi m($v) { print 2 }; sub y(\v) { m(v) }; y(x()) for ^50; y($a) for ^50
13:10 camelia rakudo-moar c65652: OUTPUT: «2222222222222222222222222222222222222222222222222211111111111111111111111111111111111111111111111111»
13:10 jnthn m: my $a = [1,2,3]; sub x() { $a }; multi m($v is rw) { print 1 }; multi m($v) { print 2 }; sub y(\v) { m(v) }; y(x()) for ^50; say('') y($a) for ^50
13:10 camelia rakudo-moar c65652: OUTPUT: «===SORRY!=== Error while compiling <tmp>␤Two terms in a row␤at <tmp>:1␤------>  y(\v) { m(v) }; y(x()) for ^50; say('')⏏ y($a) for ^50␤    expecting any of:␤        infix␤        infix stopper␤        statement end␤        …»
13:10 jnthn m: my $a = [1,2,3]; sub x() { $a }; multi m($v is rw) { print 1 }; multi m($v) { print 2 }; sub y(\v) { m(v) }; y(x()) for ^50; say(''); y($a) for ^50
13:10 camelia rakudo-moar c65652: OUTPUT: «22222222222222222222222222222222222222222222222222␤11111111111111111111111111111111111111111111111111»
13:10 jnthn m: my $a = [1,2,3]; sub x() { $a }; multi m($v is rw) { print 1 }; multi m($v) { print 2 }; sub y(\v) { m(v) }; y($a) for ^50; say(''); y(x()) for ^50
13:10 camelia rakudo-moar c65652: OUTPUT: «11111111111111111111111111111111111111111111111111␤22222222222222222222222222222222222222222222222222»
13:10 jnthn Hm, seems OK
13:12 jnthn Maybe in the interim we could treat the no rw case as really meaning "not rw"
13:12 jnthn So then we'd produce the same specializations either way
13:13 jnthn (whichever order you do the calls in, I mean)
13:16 timotimo ah, right
13:16 timotimo definitely could
13:17 jnthn Seems like it'll help
13:17 timotimo so we'll also use the free-at-safepoint mechanism with the jitted machine code that comes from the agn tree, right?
13:17 jnthn Yeah
13:17 timotimo i *think* that forces us to trampoline off of the code that calls into the decision tree
13:18 timotimo otherwise a return address might still point at decision tree code that has been tossed already
13:18 jnthn I think we want to get the offset thingy in place before working on the machine code gen from it though
13:18 jnthn (for rw and deref)
13:19 timotimo not sure what the offset thingy is
13:19 jnthn So we don't have to call container_spec vtable functions
13:19 jnthn But instead can just read directly from the object
13:19 timotimo oooh
13:19 timotimo devirtualizing the repr ops, yeah?
13:19 jnthn yeah
13:20 jnthn Well, they ain't repr ops per se
13:20 jnthn Well, I guess they sorta are but :)
13:20 timotimo right, it lives in a different struct
13:20 timotimo it's functionally similar. if we know the stable we know the container spec
13:20 jnthn OK, make test is happy with the changes I proposed
13:20 timotimo nice!
13:21 jnthn Let's see how spectest goes
13:21 timotimo i think the amount of re-use from the regular jit and the agn jit will be so small that i might as well start from scratch
13:21 timotimo only copying some dynasm setup and teardown stuff
13:23 timotimo hm. actually. the nodes needed for the agn graph could live alongside nodes for the regular jit, and then we could use the same MVM_jit_compile_graph function
13:23 jnthn urgh, more fail
13:23 jnthn But not terribly more
13:23 jnthn I shoulda probably pulled a more recent Rakudo though
13:24 * jnthn does that
13:24 jnthn JIT entry label out of range for code!
13:24 jnthn ..that was not the error I was expecting!
13:25 timotimo wtf :)
13:25 brrt don't do that then
13:25 jnthn oh, I did make install in NQP while running it. maybe... :)
13:26 timotimo oh whoops
13:26 timotimo not sure if that can cause a jit error?
13:26 jnthn It'd be odd but :)
13:26 jnthn Let's see
13:27 jnthn hah, segv this time
13:27 brrt well, i like the jit label out of range one perhaps better
13:28 AlexDaniel joined #moarvm
13:28 brrt but i'm happy as long as it is replicable
13:28 jnthn Seeing if valgrind has anything to say
13:29 jnthn Darn, looks like it's going to pass under valgrind
13:29 brrt uh-oh
13:29 jnthn That always make finding stuff more annoying
13:31 brrt what about ASAN
13:31 brrt and, what about jit sensitivity
13:32 jnthn hmm
13:32 jnthn *** Error in `/home/jnthn/dev/MoarVM/install/bin/moar': corrupted size vs. prev_size: 0x00007fffc0018e40 ***
13:32 jnthn JIT entry label out of range for code!
13:32 jnthn (label 0x7ffff40096e8, func_ptr 0x7ffff4008000, code size 3716i, offset 5864, frame_nr 3273, seq nr 555)
13:32 jnthn and...uh...a wedged gdb...wat
13:33 timotimo wedged?
13:34 timotimo wedgdb
13:34 jnthn It woudln't response to anything after process exit
13:34 jnthn hm, this itme it said Spesh: get_osr_deopt_finalize_index failed
13:34 jnthn OK, this whiffs of memory corruption
13:34 jnthn Cannot find user-level thread for LWP 21440: generic error
13:35 jnthn And it hung up gdb again :P
13:35 AlexDaniel joined #moarvm
13:35 jnthn ah no, this time it recovered
13:35 jnthn heh, hung again
13:35 jnthn What on earth.
13:36 * jnthn tries --asan to Configure.pl
13:36 AlexDaniel joined #moarvm
13:37 jnthn wowser
13:37 jnthn ==22674==ERROR: AddressSanitizer: heap-use-after-free on address 0x619000cf3200 at pc 0x7f6891c53484 bp 0x7f6886ba4dc0 sp 0x7f6886ba4db0
13:37 jnthn READ of size 8 at 0x619000cf3200 thread T5
13:37 jnthn ==22674==AddressSanitizer: while reporting a bug found another one. Ignoring.
13:37 jnthn ASAN:SIGSEGV
13:37 jnthn ==22674==AddressSanitizer: while reporting a bug found another one. Ignoring.
13:38 jnthn ASAN:SIGSEGV
13:39 brrt and… is that JIT sensitive, or not?
13:39 jnthn brrt: Didn't check yet, but I suspect not
13:40 jnthn (My feeling is it's not significant)
13:40 jnthn (It's just a consequence of corruption)
13:47 jnthn huh, got some stack traces out of ASAN, but it's use after free in optimize_decont of all places o.O
13:48 timotimo o_O
13:48 timotimo are threads involved at all?
13:50 timotimo man, i gotta take another shower
13:50 jnthn Yes
13:50 brrt :-o
13:50 jnthn It's as if two threads both end up trying to specialize the same candidate o.O
13:50 brrt but. that. should not happen?
13:51 timotimo using the same spesh memory region?!
13:51 jnthn Yes, since that's allocated pre-logging
13:51 jnthn And this is post-logging
13:51 jnthn brrt: No, and I can't figure out how anything I've changed would make it happen
13:52 nwc10 check this by building MoarVM  master and NQP master with ASAN and running the same thing from them?
13:52 nwc10 or just take a break?
13:57 timotimo aha, yeah, they share that
13:57 timotimo that makes sense
14:01 jnthn OK, going back to c42ecb6074348 but with the throw on wrong guard result disabled works fine
14:03 jnthn huh, looks like it's 2a99ecdf621
14:03 jnthn ohhh!
14:03 jnthn bah
14:06 Geth ¦ MoarVM/spesh-worker: 6f6d2c0278 | (Jonathan Worthington)++ | src/core/frame.c
14:06 Geth ¦ MoarVM/spesh-worker: Tighten up rw/non-rw specializations.
14:06 Geth ¦ MoarVM/spesh-worker:
14:06 Geth ¦ MoarVM/spesh-worker: Most immediately, to match up the semantics of the new guard tree.
14:06 Geth ¦ MoarVM/spesh-worker: However, the existing behavior would cause different specializations
14:06 Geth ¦ MoarVM/spesh-worker: to be produced depending on call order (rw then non-rw would make 2,
14:06 Geth ¦ MoarVM/spesh-worker: non-rw then rw would make 1).
14:06 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/6f6d2c0278
14:06 Geth ¦ MoarVM/spesh-worker: d4d59b4ce8 | (Jonathan Worthington)++ | src/spesh/candidate.c
14:06 Geth ¦ MoarVM/spesh-worker: Unconditionally increment candidate count.
14:06 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/d4d59b4ce8
14:06 jnthn Second one was to thank :P
14:10 * jnthn spectests again
14:13 jnthn Much better, though not totally happy
14:13 jnthn But in the same way as before the guards check was added
14:28 jnthn Seems that the new guard mechanism is giving the right results now, anyways
14:30 timotimo cool
14:36 AlexDaniel joined #moarvm
14:37 jnthn So the next step is to switch to using the new guards entirely :)
14:39 * jnthn spectests switching over in invoke of frame.c
14:42 Geth ¦ MoarVM/spesh-worker: c3bc6012fb | (Jonathan Worthington)++ | src/spesh/arg_guard.c
14:42 Geth ¦ MoarVM/spesh-worker: Don't walk NULL guard tree.
14:42 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/c3bc6012fb
14:43 Geth ¦ MoarVM/spesh-worker: d4bd25d9b4 | (Jonathan Worthington)++ | src/core/frame.c
14:43 Geth ¦ MoarVM/spesh-worker: Switch to using new arg guard tree on invoke.
14:43 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/d4bd25d9b4
14:51 jnthn Righty, that's it done on invoke. Next to sort out the use of it in optimize.c to find an existing spesh candidate for fast invoke or inlining
15:01 Geth joined #moarvm
15:01 colomon_ joined #moarvm
15:06 brrt joined #moarvm
15:11 colomon joined #moarvm
15:19 Geth ¦ MoarVM/spesh-worker: c4582644f7 | (Jonathan Worthington)++ | 3 files
15:19 Geth ¦ MoarVM/spesh-worker: First pass at using new guards in optimizer.
15:19 Geth ¦ MoarVM/spesh-worker:
15:19 Geth ¦ MoarVM/spesh-worker: This is used to resolve speshed callees so we can emit faster calls
15:19 Geth ¦ MoarVM/spesh-worker: or perform inlinings. Again, implement with comparison to result we
15:19 Geth ¦ MoarVM/spesh-worker: got from analyzing previous guards to help identify shortcomings.
15:19 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/c4582644f7
15:22 jnthn Close, but a couple of discrepancies from spectests
15:25 jnthn oh, it's probably the rw thing again
15:27 timotimo that does sound likely
15:27 jnthn Fixed the case I was looking at, at least
15:27 timotimo i wonder if there's something tough & tricky about the "make the agn interpreter read memory offsets directly"
15:27 timotimo or if i can just go ahead and try my luck
15:27 jnthn heh, if you make install moar while gdb is open and then try to set a breakpoint you get a bus error :)
15:28 jnthn Well, we probably need to figure out how ot make the container API cooperative in telling us them
15:28 timotimo right. until now that was the job of the spesh function
15:29 jnthn Yeah, that was all of the discrepancies
15:29 jnthn So, will cut over to using the new function instead
15:31 jnthn There's still some heisenbug to hunt down
15:31 jnthn Though not on such a warm day
15:31 jnthn Nor at this time of it :)
15:39 brrt jnthn, the agn tree is a branch tree
15:39 Geth ¦ MoarVM/spesh-worker: 9b2d7b7674 | (Jonathan Worthington)++ | src/spesh/optimize.c
15:39 Geth ¦ MoarVM/spesh-worker: Switch over to using new guards in optimize.
15:39 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/9b2d7b7674
15:39 brrt … okay, i have an idea of how to compile this
15:39 jnthn brrt: Just a binary tree really
15:40 jnthn That is organized aiming to minimize the number of loads/checks
15:40 brrt that's pretty cute
15:40 brrt if we find a NULL node, we break out, right?
15:41 timotimo yeah
15:41 jnthn Well, 0, but yes
15:41 jnthn 0 means "no result"
15:41 timotimo right, the "pointers" are indexes into the flattened tree array
15:41 timotimo that's why they are 16bit big only
15:41 jnthn Yeah, integers are compacter than pointers
15:41 brrt i'm familiar with the trick :-)
15:42 brrt it is an awesome trick and i'm so happy to see it reappear
15:42 brrt 'trick'
15:42 brrt anyway.
15:42 brrt okay
15:42 brrt i see how that works out
15:42 brrt i think...
15:42 brrt doesn't have to be a tree, though, does it
15:44 timotimo if we went with the idea i had about rw tree shape, no. but i don't think it's necessary
15:44 brrt and you use this one 'facts' value to hold the current facts
15:44 timotimo no, you're looking at the wrong instance of the interpreter
15:44 timotimo this one is the abstract interpreter
15:44 brrt i am?
15:44 brrt which one is the right one
15:44 timotimo the right one looks at an array named args
15:45 timotimo it's in MVM_frame_invoke
15:46 brrt aha, okay
15:51 timotimo it's interesting to note that we're only working with a single register that everything is checked against
15:57 Geth ¦ MoarVM/spesh-worker: 3c982ba8ae | (Jonathan Worthington)++ | src/spesh/candidate.c
15:57 Geth ¦ MoarVM/spesh-worker: Tease apart guard addtion from temp type tuple.
15:57 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/3c982ba8ae
16:10 domidumont joined #moarvm
16:23 Geth ¦ MoarVM/spesh-worker: 576fe32d97 | (Jonathan Worthington)++ | 3 files
16:23 Geth ¦ MoarVM/spesh-worker: Use new guards to check if specialization exists.
16:23 Geth ¦ MoarVM/spesh-worker:
16:23 Geth ¦ MoarVM/spesh-worker: For now, doing the original computation also to ensure we're getting
16:23 Geth ¦ MoarVM/spesh-worker: a match.
16:23 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/576fe32d97
16:25 jnthn Hm, spectest is happy with that right away
16:25 domidumont joined #moarvm
16:26 timotimo suspicious! ;)
16:28 jnthn ah, the d'oh is that we actually needed to know which matched
16:32 Geth ¦ MoarVM/spesh-worker: 59b8d945b5 | (Jonathan Worthington)++ | 3 files
16:32 Geth ¦ MoarVM/spesh-worker: Existing candidate check needs which matched.
16:32 Geth ¦ MoarVM/spesh-worker:
16:32 Geth ¦ MoarVM/spesh-worker: Rather than just "exists or not".
16:32 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/59b8d945b5
16:41 Geth ¦ MoarVM/spesh-worker: 99a3c6014f | (Jonathan Worthington)++ | src/spesh/candidate.c
16:41 Geth ¦ MoarVM/spesh-worker: Use new guards for existing candidate lookup.
16:41 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/99a3c6014f
16:45 Geth ¦ MoarVM/spesh-worker: 4366baa192 | (Jonathan Worthington)++ | 3 files
16:45 Geth ¦ MoarVM/spesh-worker: Remove old-style guards from spesh candidate.
16:45 Geth ¦ MoarVM/spesh-worker:
16:45 Geth ¦ MoarVM/spesh-worker: We no longer need to keep them around after initial specialization
16:45 Geth ¦ MoarVM/spesh-worker: production.
16:45 Geth ¦ MoarVM/spesh-worker: review: https://github.com/MoarVM/MoarVM/commit/4366baa192
16:45 jnthn There we go, nearly cleaned up :)
16:46 jnthn Last step I think is for args.c to make a type tuple directly, which I guess is a good code cleanup to do
16:46 jnthn But once we switch to the worker thread that's all rather inverted
16:46 jnthn The type tuple comes before the specialization there
16:47 jnthn Actually maybe that's the more forward-thinking way: make the type tuple from the args buffer and feed it into args spesh
16:47 jnthn Then less to refactor later
16:47 jnthn Either way, enough for today :)
16:50 jnthn &
16:50 timotimo have a good one!
16:57 TimToady .oO( what a bunch of slackers... :)
17:05 mst TimToady: we're *IRCers*, c'mon
17:08 timotimo oh, the op_deref_rw offset needs to be different from the deref_value offset
17:21 stmuk_ joined #moarvm
17:21 stmuk_ timotimo: https://github.com/MoarVM/MoarVM/issues/610#issuecomment-313462214
17:29 timotimo huh, can you give us a diff of the moarvm makefile generated in each case?
17:35 stmuk_ yes shortly
17:43 stmuk_ https://gist.github.com/stmuk/94143d97f0bb3262ed5a32e0323e350e
17:44 stmuk_ I'll experiment with the CONFIG line
17:45 stmuk_ grrr why does "make clean" not remove the Makefile
17:45 timotimo we do have make realclean
17:46 timotimo which also throws out 3rdparty build results
17:46 timotimo iirc
17:46 stmuk_ ah
17:48 timotimo i don't think it's normal for make clean to remove the makefile
17:48 timotimo "make distclean" perhaps
17:53 stmuk_ oh yeah
18:02 stmuk_ it's the  --optimize flag to moar configure
18:08 timotimo actually, the rakudo scalar seems to have two dereferences in its can_store function
18:09 timotimo i'd have to go to the descriptor pointer and behind that is the rw flag
18:40 AlexDaniel joined #moarvm
18:42 timotimo huh
18:42 timotimo debug fprintf isn't agreeing with callgrind output
18:44 timotimo the fprintf i have in the "we don't have an offset so we have to do a call" branch doesn't get called, but it does count instructions and calls from that
18:45 timotimo even worse: i see Ir for the call to fetch, but none for the fprintf in front of that
19:32 timotimo 5,167,657,570 Ir if the offset thing is there, 5,135,101,054 if it's missing
19:32 timotimo so that's kind of bad?
19:33 timotimo or just noisy
19:35 jnthn Sounds odd, yes
19:35 timotimo another run without is 5,135,005,870  -  5,135,107,574 another
19:35 jnthn Would have to take a look at the patch to see why
19:35 jnthn but gotta be away for a bit now
19:36 timotimo maybe i did it wrong and caused it to never match any guards and then keep re-speshing something over and over?
19:38 stmuk_ is there anyway of passing NOISY apart from editing the Makefile?
19:38 timotimo i think you can make foo NOISY=1
19:39 stmuk_ ah
19:40 timotimo yeah, it's giving wrong results
19:41 stmuk_ although I'm trying to debug --make-install
19:43 timotimo ah, of course. i calculated the offset from the beginning of the object's data, but i applied it to the beginning of the object's header
19:46 * stmuk_ wonders if qemu arm would be faster than a real PI
19:47 timotimo oh, also it'd have to know about REAL_DATA
19:54 TimToady joined #moarvm
20:02 timotimo now i have valgrind processes that won't die
20:03 timotimo everytime i ctrl-c i get a new block of "process terminating with default action of signal 2 (SIGINT)
20:03 timotimo same with ctrl-\, but then it's 3 (SIGQUIT) of course
20:03 timotimo okay, htop wouldn't do it, but kill will
20:05 timotimo curiously this test file quits with an exception if run under callgrind?
20:06 timotimo i can't measure stuff like this
20:07 timotimo ok 9 - making an "is rw" parameter optional dies with adequate error message and mentions the parameter name
20:07 timotimo Must specify something as a path: did you mean '.' for the current directory?
20:07 timotimo in block <unit> at t/05-messages/01-errors.t line 67
20:07 timotimo seems a bit fishy
20:10 timotimo comes from initializing a dynamic var, most likely $*EXECUTABLE
20:10 timotimo ah, heh.
20:11 timotimo that probably has valgrind somewhere in it
20:14 timotimo i think we want nqp::execname() || stuff instead of nqp::execname() // stuff
20:16 timotimo that's better
20:41 timotimo 73,002,727,218 with offset optimization, 59,651,101,659 without it ... :(
20:44 timotimo though maybe if i force Rakudo_Scalar to also use MVM_p6opaque_real_data, maybe that'll catch up? :\
21:01 timotimo what the ... a screenful of ^@ in my spesh log
21:02 timotimo null bytes, thousands of 'em
21:16 timotimo oh, perhaps because i had this set as an env var and subprocesses took it, too
21:16 timotimo and then they wrote over each other or something?
22:47 Ven joined #moarvm
23:39 AlexDaniel joined #moarvm
23:59 Geth ¦ MoarVM: f621f21191 | (Samantha McVey)++ | src/strings/nfg.c
23:59 Geth ¦ MoarVM: Throw an exception instead of panic'ing in MVM_nfg_get_synthetic_info
23:59 Geth ¦ MoarVM:
23:59 Geth ¦ MoarVM: In addition improve the error messages to be less confusing and more
23:59 Geth ¦ MoarVM: clear about what has occured when the errors occur.
23:59 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f621f21191

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