Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-04-21

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

All times shown according to UTC.

Time Nick Message
01:50 lizmat joined #moarvm
05:03 vendethiel joined #moarvm
06:28 domidumont joined #moarvm
06:34 domidumont joined #moarvm
06:51 domidumont joined #moarvm
06:56 domidumont joined #moarvm
07:08 zakharyas joined #moarvm
08:53 lizmat joined #moarvm
09:04 harrow joined #moarvm
09:12 zakharyas joined #moarvm
09:19 brrt joined #moarvm
09:20 brrt hi #moarvm
09:20 brrt can anybody help me recall how i could get an 'invokish' op?
09:20 jnthn As in, code that contains one?
09:23 brrt yeah :-)
09:23 moritz src/core/oplist:istrue              w(int64) r(obj) :invokish
09:23 moritz so, anything that uses an istrue?
09:23 jnthn Not quite
09:24 jnthn But something with a Bool method would do it
09:24 moritz oh, and assign, hllize, can, findmethod, ...
09:24 brrt oh, i'm seeing my error as i'm git add -p -ing it
09:24 moritz seems like basically any non-empty Perl 6 program would hit one
09:25 brrt :-)
09:25 brrt the hting is that non-empty perl6 programs are mindbogglingly complex behind the scenes
09:26 brrt and to debug something, i need something more lab-sized
09:26 moritz nqp-m: say(nqp::can(1, 'foo'))
09:26 camelia nqp-moarvm: OUTPUT«0␤»
09:26 moritz nqp-m: say(nqp::can_s(1, 'foo'))
09:26 camelia nqp-moarvm: OUTPUT«No registered operation handler for 'can_s'␤   at gen/moar/stage2/QAST.nqp:1584  (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_op)␤ from gen/moar/stage2/QAST.nqp:5798  (/home/camelia/rakudo-m-inst-1/share/nqp/lib/QAST.moarvm:compile_node)␤…»
09:26 moritz the nqp::can one should hit one too
09:30 brrt we're emitting a throwish control guard between every op :-o
09:31 brrt something is off
09:31 brrt ok, i can repeat it
09:31 brrt i'll debug further after lunch
09:34 brrt bbl
09:40 Kooda joined #moarvm
09:49 * timotimo is riding a train
09:49 timotimo a local thing rightnow, so no table or even space for my laptop
09:50 jnthn Grr
09:50 jnthn The crash in tools/build/install-core-dist.pl vanishes under the debugger :(
09:50 jnthn oh, duh
09:50 jnthn I ran it in a terminal where MVM_JIT_DISABLE wasn't defined
09:52 timotimo huh, does that mean with that enables it passed now?
09:52 timotimo that would be good news
09:52 jnthn No, that was the reason it crashed
09:52 jnthn But passed in the debugger
09:54 * jnthn tries it out with a 16KB nursery
09:54 jnthn Probably just NQP :)
09:54 jnthn 13KB in fact
09:54 jnthn Just to hit different places
09:55 jnthn ooh, a new failure :)
09:55 jnthn t/nqp/86-pipes.t
09:58 jnthn heh, another failure shaken out that's nothing to do with my frames changes
10:00 timotimo must be workloads that don't deal with collections in between start and finish that never got interrupted before?
10:00 arnsholt Mo' GC, mo' problems? =)
10:03 jnthn timotimo: Yeah
10:03 jnthn Though of course they can trigger occasionally in an unlucky user's program
10:03 jnthn And screw them up
10:04 jnthn But yeah, the last 2 issues my small nursery torture has turned up haven't been with my changes at all
10:09 timotimo oof. really shows we ought to run that kind of thing regularly
10:09 dalek MoarVM/reframe: c077b03 | jnthn++ | src/io/procops.c:
10:09 dalek MoarVM/reframe: Missing MVMROOT in shell/spawn.
10:09 dalek MoarVM/reframe: review: https://github.com/MoarVM/MoarVM/commit/c077b031e6
10:10 ilmari set up a travis job that does it?
10:10 jnthn Could do, it it won't time out
10:10 jnthn *if it
10:10 ilmari things that need to happen regularly should be automated
10:10 jnthn (It's slooow)
10:10 jnthn Agree fully on automated :)
10:11 timotimo i think Travis has a too short time out, but maybe it's only for when there is no output on stdout or stderr
10:11 * ilmari doesn't remember what the total job timeout is, but there's also a timeout if there's no output for a certain time, so you migth have to add some debug printing
10:11 timotimo hah
10:13 timotimo well, if it gets to the test suite, we will have tap output relatively regularly, i think. not sure if prove will directly output something on its own for every test that gets mentioned
10:13 jnthn It's maybe not *that* slow
10:13 jnthn It's more like compiling QAST -> MAST compiler
10:14 jnthn ooh, where'd dalek go...
10:14 ilmari if there's some particularly slow thing you could just spawn a background shell loop that does 'echo .' every N seconds
10:14 dalek joined #moarvm
10:14 jnthn ilmari: ooh, good point
10:15 ilmari I believe the DBIC travis scripts do this at some points
10:15 ilmari ribasushi has put a _lot_ of effort into making that as reliable as possible
10:16 timotimo what if the process itself crashes? :p
10:16 nwc10 oh, so travis has an idle timeout that is much stricter than a total wallclock timeout?
10:16 timotimo this asks for a completely over-engineered solution
10:17 ilmari nwc10: yes
10:18 ilmari timotimo: the loop can check for that and bail out in that case
10:18 * jnthn is find it increasingly hard to find bustage (aside from the JIT, which brrt++ is on with) after the frames refactor
10:19 ilmari jnthn: this is presumably a good thing?
10:19 jnthn ilmari: Well, yes if the appearance of non-brokenness implies non-brokenness. :)
10:23 jnthn Hm, TEST_JOBS=12 make spectest with a nursery size of 13KB is making this box a good bit noisier than usual :)
10:25 jnthn The NQP build on that is making progress :)
10:25 jnthn But given the last 2 bugs I fixed weren't frame related at all, and invocations is a crazily common path compared to the places I uncovered problems, I'm suspecting the branch is good, modulo JIT.
10:26 timotimo cool!
10:26 jnthn Which would mean the refactor was a good bit less traumatic than I was expecting.
10:26 timotimo can you quantify how big the performance hit is before the gack lands?
10:27 timotimo hack*
10:27 jnthn Not when my box is busy doing 13KB nursery spectest/build, no ;)
10:27 jnthn And this is a debug build
10:27 jnthn With extra checks switched on for nursery adds
10:28 jnthn But I'll do an optimized one afterwards and try things out
10:28 jnthn But we're without the JIT still so it's not a totally fair test
10:29 timotimo aye
10:36 brrt joined #moarvm
10:38 timotimo time for the talk i saved to my laptop and then the paper about frontiers and dominators and such
10:43 jnthn ooh, failures in le spectest!
10:55 jnthn ...which I'm having nearly no luck reproducing under the debugger
11:06 * jnthn figured out why
11:06 jnthn Turns out --execname="..." is really important to set :)
11:06 jnthn 'cus for some reason it wants to precomp things
11:07 jnthn It crashes in CUnion.c?!
11:07 nwc10 what does valgrind say?
11:08 jnthn No idea, but Moar's own GC debugging instrumentation says we're trying to put a corrupt collectible onto the worklist
11:08 jnthn In gc_mark_repr_data
11:15 jnthn Another crash is in arith.t, this time marking a hash which has a bad value
11:16 jnthn Long story short, this kind of testing is worth doing :)
11:19 jnthn lunch &
11:31 brrt oh god...
11:32 brrt i'm so... stupid
11:33 brrt question
11:33 brrt does it ever happen that we invoke a frame and invoke deeper than one?
11:37 geekosaur joined #moarvm
11:39 domidumont joined #moarvm
11:41 jnthn brrt: I...don't think so
11:42 brrt the reason i'm asking, is because i'm now assigning the jit reentry label to the frame under tc->cur_frame, whici is of course a callee
11:42 brrt there are two options possible
11:43 brrt one is the hacky one, which can be robustified, and there is also the not-so-hacky one
11:43 brrt the hacky one is: walk upwards until we find the correct frame, and assign the reentry label to that
11:43 brrt the robustification is: do this in a loop
11:43 brrt i.e. don't walk just one, walk a few
11:44 brrt the unhacky one assigns the jit reentry label prior to the invokish op, like MVM_JIT_THROWISH_PRE
11:45 brrt i kind of like that one better
11:45 jnthn Hm, but how much does that cost us?
11:45 jnthn I guess if we get good at optimizing out invokish though... :)
11:46 brrt not that much.... we're assigning the jit entry label way to much anyway
11:46 brrt i still want to figure out if we can do stack-walking instead
11:46 jnthn ok
11:47 jnthn Guess it's just a store, with no data dep, so ILP will make it not so bad
11:47 timotimo i have reached the land of a million tunnels
11:49 * brrt has become a great fan of org-mode, and notes that the MoarVM specific part is growing larger and larger...
11:52 timotimo it annoys me to no end that when we crash we sometimes don't output all of stdout or stderr >_>
11:52 timotimo but i don't like the solution i used in the --dump command either
11:55 brrt oh, timotimo, you can fix that
11:55 timotimo right now the calculation stumbles over a block that has a succ, but no pred
11:56 brrt run it under gdb, let it crash, call fflush(stdout) etc
11:56 brrt is how i get the jit bytecode map under a crash :-)
11:56 jnthn timotimo: That succs...
11:58 brrt hmmm ... it still no works :-(
11:59 timotimo fflush on both stderr and stdout gives no more output
11:59 brrt hmmm
12:00 timotimo .. and a print printf("%s", "hi!\n"); gives the output instantly o_O
12:03 timotimo must be because the print doesn't actually go through fully; it fills up the buffer and doesn't retry
12:04 timotimo same reason i wasn't able to do proper output in the dump command handler
12:04 timotimo maybe if we actually used libuv to output stuff like that, it'd happen properly :P
12:18 brrt :-)
12:19 brrt (why does nqp hang... hmm...)
12:19 timotimo at this point it would probably have been easier to actually do the recalculation of the dominator tree after the first run through the graph is done
12:19 timotimo because now i'm stumbling over blocks that have no predecessors (easily skipped) as well as the blocks that still have those as their predecessors ...
12:21 timotimo "i'll just do a hacky proof fo concept" my ass :)
12:23 brrt hacky proof of concept ftw :-)
12:24 brrt although, perl6 doesn't make that easy
12:24 timotimo pah, this is the very first file in the nqp build that blows up :)
12:24 timotimo touching inlining in spesh gives you that easily
12:26 timotimo a-ha! cannot invoke a null object! much better, clearly
12:26 timotimo need to get off my train soon, so talk to you later :)
12:26 brrt see you :-)
12:26 timotimo i shouldn't irc on the phone in the car, that usually make me feel sick for the rest of the day :P
12:27 timotimo good luck with jit + reframe, brrt :)
12:27 timotimo and good luck with reframe in general and all other bugs you find on the way, jnthn :)
12:42 timotimo turns out i get to sit in me mom's office for a bit
12:47 zakharyas joined #moarvm
12:49 timotimo guh. "cannot invoke null object" inside a frame that's about 100 BBs big (EXPR)
12:49 brrt joined #moarvm
12:49 timotimo i get a line number, but it's in the stage0, so i don't have the original files to go with it any more, really
13:33 brrt it's funny how we get into infinite loops and the outer seq nr is 10.000 or so and the inner is over 200.000
13:34 jnthn Hm
14:00 [Coke] (automated testing) I was just thinking about restarting the daily test runs. (they were super problematic for a while, so I disabled them, esp. since hardly anyone was looking at them.) I am thinking we need something like smolder to report on things. I will bump that up on my priority list so we can have a place with rakudo/nqp/moar test results.
14:00 geekosaur joined #moarvm
14:34 geekosaur joined #moarvm
14:53 brrt joined #moarvm
15:01 jnthn Fun fact: S05 is the first section that passes all its spectests with a 13KB nursery.
15:01 jnthn S02, S03, and S04 all had a couple of failures
15:08 zakharyas joined #moarvm
15:21 [Coke] did you fix things as you went, or just doing all the sections first to see what's what?
15:22 jnthn [Coke]: No, not fixed anything yet
15:22 jnthn [Coke]: Been doing $other-project stuff this afternoon, and left it running in the background :)
15:41 * jnthn analyzes a few more of the failures
15:58 jnthn Into S07 by now :) Such slow :)
16:16 leont joined #moarvm
16:57 domidumont joined #moarvm
17:04 awwaiid joined #moarvm
17:09 dalek joined #moarvm
17:12 retup__ joined #moarvm
17:13 leont_ joined #moarvm
17:13 jnthn * t\spec\S02-types\int-uint.rakudo.moar -> CUnion related crash
17:13 jnthn * t\spec\S02-types\lists.rakudo.moar -> could not reproduce outside of harness
17:13 jnthn * t\spec\S03-junctions\autothreading.t -> fails first test, unknown why
17:13 jnthn * t\spec\S03-operators\arith.t -> Crash in gc_mark of an MVMHash value
17:13 jnthn * t\spec\S04-declarations\constant.rakudo.moar -> Crash in gc_mark of an MVMHash value
17:13 jnthn * t\spec\S04-phasers\enter-leave.rakudo.moar -> Unwound entire stack and missed handler
17:13 jnthn * t\spec\S06-signature\shape.t -> could not reproduce outside of harness
17:13 jnthn * t\spec\S06-traits\native-is-rw.t -> Crash in gc_mark of P6str nested in P6opaque
17:13 jnthn * t\spec\S07-hyperrace\hyper.rakudo.moar -> Crash in MVM_gc_root_add_frame_roots_to_worklist, adding cur_frame->code_ref
17:13 jnthn damn!
17:14 jnthn I meant to link to the gist with those: https://gist.github.com/jnthn/2996cce212da18720a0e4660e71fe5a5
17:14 jnthn And mention those are the ones discovered/analyzed so far
17:14 geekosaur joined #moarvm
17:14 jnthn (This is from GC stressing, with a 13KB nursery)
17:14 harrow` joined #moarvm
17:16 jnthn I'll leave it running while I have dinner to see if it turns up more :)
17:17 * jnthn bbl
17:19 khagan joined #moarvm
17:44 lizmat joined #moarvm
18:09 timotimo good blerg perst, jernerthen
18:59 nine_ jnthn: "Would need to measure carefully, since it’d increase the cost of things like lexical lookups from outer frames (and, once we get better at optimizing, that will be “most of them”)."
18:59 nine_ Do I understand this correctly, that while it will be most of them, there won't be more of them? Just fewer lexical lookups in this frame?
19:00 timotimo most lexical accesses to the same frame will be turned into local accesses instead
19:00 timotimo and accesses to outer frames will have to stay lexical lookups
19:05 nine_ Isn't the return_type something static, i.e. shouldn't it be the same for every invocation of a block?
19:23 jnthn nine_: Correct, there won't be more of them
19:24 jnthn nine_: return_type in a frame is the type we want our callee to return to us, and (in general) we don't know what our callee is
19:25 nine_ Ah, makes sense of course :)
19:25 jnthn nine_: That's one of the kinds of dynamism that spesh eliminates
19:25 jnthn Um...I think it does, anyways
19:25 jnthn It certainly does it in the arg direction, and certainly does it for return values on inline
19:29 TimToady jnthn: s/forth/fourth/
19:34 TimToady I think with the dynvar cache scheme I have in my head we can reduce the three items to 1 pointer if it can GC, or max 2 things if we have to track reclaiming ourselves
19:35 TimToady lunch &
19:36 zakharyas joined #moarvm
19:40 jnthn TimToady++ # helping me pop mistakes off my stack of 'em :)
20:00 brrt joined #moarvm
20:05 dalek MoarVM/reframe-jit: a070519 | brrt++ | src/core/ (4 files):
20:05 dalek MoarVM/reframe-jit: Make frames identifiable using a sequence number
20:05 dalek MoarVM/reframe-jit:
20:05 dalek MoarVM/reframe-jit: Because frames can now be garbage-collected, they can be moved, and
20:05 dalek MoarVM/reframe-jit: the identity check used in the JIT will no longer work. Thus, we'd
20:05 dalek MoarVM/reframe-jit: like to have another cheap way to check if we are currently still
20:05 dalek MoarVM/reframe-jit: in the same frame.
20:05 dalek MoarVM/reframe-jit:
20:05 dalek MoarVM/reframe-jit: Sequence numbers are assigned to frames on allocation and assigned
20:05 dalek MoarVM/reframe-jit: to the thread context on the (re)entry of a frame. Thus, they
20:05 dalek MoarVM/reframe-jit: provide a per-thread identifier of the position in the call stack.
20:05 dalek MoarVM/reframe-jit: review: https://github.com/MoarVM/MoarVM/commit/a0705190d2
20:06 brrt killed dalke?
20:06 brrt dalek
20:07 brrt anyway.... something still going wrong with the istrue boolification
20:07 brrt will have to check that out
20:09 jnthn brrt++
20:29 jnthn fwiw, up to S15, only one more failure since S07
20:39 timotimo neat.
20:42 jnthn And one in S15
20:44 * jnthn wonders if this'll still be running this time tomorrow
20:44 jnthn We'll excise a good number of bugs from this, anyways.
20:44 jnthn Well, provided I can find 'em :)
20:44 timotimo \o/
20:45 jnthn I somewhat suspect they'll end up being more unrelated to my recent changes than not
20:45 jnthn But it doesn't really matter. Bug fixes are bug fixes.
20:49 timotimo that is true
21:11 dalek MoarVM: 8c7d8a9 | (A. Sinan Unur)++ | src/platform/ (2 files):
21:11 dalek MoarVM: VS 2013 and later provide stdint.h and inttypes.h
21:11 dalek MoarVM:
21:11 dalek MoarVM: Therefore, there is no need to use third party substitutes
21:11 dalek MoarVM: for those header files if build is on VS 2013 and later.
21:11 dalek MoarVM:
21:11 dalek MoarVM: See [What's New for Visual C++ in Visual Studio 2013][1] and
21:11 dalek MoarVM: [C99 library support in Visual Studio 2013][2].
21:11 dalek MoarVM:
21:11 dalek MoarVM: [1]: https://msdn.microsoft.com/library/hh409293%28v=vs.120%29.aspx
21:11 dalek MoarVM: [2]: http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx
21:11 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8c7d8a9f8f
21:46 jnthn 'night, #moarvm :)
21:46 timotimo gnite jnthn
22:06 leont_ joined #moarvm
22:14 vendethiel joined #moarvm
22:59 vendethiel joined #moarvm

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