01:50 lizmat joined 05:03 vendethiel joined 06:28 domidumont joined 06:34 domidumont joined 06:51 domidumont joined 06:56 domidumont joined 07:08 zakharyas joined 08:53 lizmat joined 09:04 harrow joined 09:12 zakharyas joined 09:19 brrt joined
brrt hi #moarvm 09:20
can anybody help me recall how i could get an 'invokish' op?
jnthn As in, code that contains one?
brrt yeah :-) 09:23
moritz src/core/oplist:istrue w(int64) r(obj) :invokish
so, anything that uses an istrue?
jnthn Not quite
But something with a Bool method would do it 09:24
moritz oh, and assign, hllize, can, findmethod, ...
brrt oh, i'm seeing my error as i'm git add -p -ing it
moritz seems like basically any non-empty Perl 6 program would hit one
brrt :-) 09:25
the hting is that non-empty perl6 programs are mindbogglingly complex behind the scenes
and to debug something, i need something more lab-sized 09:26
moritz nqp-m: say(nqp::can(1, 'foo'))
camelia nqp-moarvm: OUTPUTĀ«0ā¤Ā»
moritz nqp-m: say(nqp::can_s(1, 'foo'))
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)ā¤ā€¦Ā»
moritz the nqp::can one should hit one too
brrt we're emitting a throwish control guard between every op :-o 09:30
something is off 09:31
ok, i can repeat it
i'll debug further after lunch
bbl 09:34
09:40 Kooda joined
timotimo is riding a train 09:49
a local thing rightnow, so no table or even space for my laptop
jnthn Grr 09:50
The crash in tools/build/install-core-dist.pl vanishes under the debugger :(
oh, duh
I ran it in a terminal where MVM_JIT_DISABLE wasn't defined
timotimo huh, does that mean with that enables it passed now? 09:52
that would be good news
jnthn No, that was the reason it crashed
But passed in the debugger
jnthn tries it out with a 16KB nursery 09:54
Probably just NQP :)
13KB in fact
Just to hit different places
ooh, a new failure :) 09:55
t/nqp/86-pipes.t
heh, another failure shaken out that's nothing to do with my frames changes 09:58
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? =)
jnthn timotimo: Yeah 10:03
Though of course they can trigger occasionally in an unlucky user's program
And screw them up
But yeah, the last 2 issues my small nursery torture has turned up haven't been with my changes at all 10:04
timotimo oof. really shows we ought to run that kind of thing regularly 10:09
dalek arVM/reframe: c077b03 | jnthn++ | src/io/procops.c:
Missing MVMROOT in shell/spawn.
ilmari set up a travis job that does it? 10:10
jnthn Could do, it it won't time out
*if it
ilmari things that need to happen regularly should be automated
jnthn (It's slooow)
Agree fully on automated :)
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
timotimo hah
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
It's more like compiling QAST -> MAST compiler
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
jnthn ilmari: ooh, good point 10:14
ilmari I believe the DBIC travis scripts do this at some points 10:15
ribasushi has put a _lot_ of effort into making that as reliable as possible
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?
timotimo this asks for a completely over-engineered solution
ilmari nwc10: yes 10:17
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
ilmari jnthn: this is presumably a good thing? 10:19
jnthn ilmari: Well, yes if the appearance of non-brokenness implies non-brokenness. :)
Hm, TEST_JOBS=12 make spectest with a nursery size of 13KB is making this box a good bit noisier than usual :) 10:23
The NQP build on that is making progress :) 10:25
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.
timotimo cool! 10:26
jnthn Which would mean the refactor was a good bit less traumatic than I was expecting.
timotimo can you quantify how big the performance hit is before the gack lands?
hack* 10:27
jnthn Not when my box is busy doing 13KB nursery spectest/build, no ;)
And this is a debug build
With extra checks switched on for nursery adds
But I'll do an optimized one afterwards and try things out 10:28
But we're without the JIT still so it's not a totally fair test
timotimo aye 10:29
10:36 brrt joined
timotimo time for the talk i saved to my laptop and then the paper about frontiers and dominators and such 10:38
jnthn ooh, failures in le spectest! 10:43
...which I'm having nearly no luck reproducing under the debugger 10:55
jnthn figured out why 11:06
Turns out --execname="..." is really important to set :)
'cus for some reason it wants to precomp things
It crashes in CUnion.c?! 11:07
nwc10 what does valgrind say?
jnthn No idea, but Moar's own GC debugging instrumentation says we're trying to put a corrupt collectible onto the worklist 11:08
In gc_mark_repr_data
Another crash is in arith.t, this time marking a hash which has a bad value 11:15
Long story short, this kind of testing is worth doing :) 11:16
lunch & 11:19
brrt oh god... 11:31
i'm so... stupid 11:32
question 11:33
does it ever happen that we invoke a frame and invoke deeper than one?
11:37 geekosaur joined 11:39 domidumont joined
jnthn brrt: I...don't think so 11:41
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
there are two options possible
one is the hacky one, which can be robustified, and there is also the not-so-hacky one 11:43
the hacky one is: walk upwards until we find the correct frame, and assign the reentry label to that
the robustification is: do this in a loop
i.e. don't walk just one, walk a few
the unhacky one assigns the jit reentry label prior to the invokish op, like MVM_JIT_THROWISH_PRE 11:44
i kind of like that one better 11:45
jnthn Hm, but how much does that cost us?
I guess if we get good at optimizing out invokish though... :)
brrt not that much.... we're assigning the jit entry label way to much anyway 11:46
i still want to figure out if we can do stack-walking instead
jnthn ok
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
brrt has become a great fan of org-mode, and notes that the MoarVM specific part is growing larger and larger... 11:49
timotimo it annoys me to no end that when we crash we sometimes don't output all of stdout or stderr >_> 11:52
but i don't like the solution i used in the --dump command either
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
brrt run it under gdb, let it crash, call fflush(stdout) etc 11:56
is how i get the jit bytecode map under a crash :-)
jnthn timotimo: That succs...
brrt hmmm ... it still no works :-( 11:58
timotimo fflush on both stderr and stdout gives no more output 11:59
brrt hmmm
timotimo .. and a print printf("%s", "hi!\n"); gives the output instantly o_O 12:00
must be because the print doesn't actually go through fully; it fills up the buffer and doesn't retry 12:03
same reason i wasn't able to do proper output in the dump command handler 12:04
maybe if we actually used libuv to output stuff like that, it'd happen properly :P
brrt :-) 12:18
(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
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 ...
"i'll just do a hacky proof fo concept" my ass :) 12:21
brrt hacky proof of concept ftw :-) 12:23
although, perl6 doesn't make that easy 12:24
timotimo pah, this is the very first file in the nqp build that blows up :)
touching inlining in spesh gives you that easily
a-ha! cannot invoke a null object! much better, clearly 12:26
need to get off my train soon, so talk to you later :)
brrt see you :-)
timotimo i shouldn't irc on the phone in the car, that usually make me feel sick for the rest of the day :P
good luck with jit + reframe, brrt :) 12:27
and good luck with reframe in general and all other bugs you find on the way, jnthn :)
turns out i get to sit in me mom's office for a bit 12:42
12:47 zakharyas joined
timotimo guh. "cannot invoke null object" inside a frame that's about 100 BBs big (EXPR) 12:49
12:49 brrt joined
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 12:49
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:33
jnthn Hm 13:34
[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
14:00 geekosaur joined 14:34 geekosaur joined 14:53 brrt joined
jnthn Fun fact: S05 is the first section that passes all its spectests with a 13KB nursery. 15:01
S02, S03, and S04 all had a couple of failures
15:08 zakharyas joined
[Coke] did you fix things as you went, or just doing all the sections first to see what's what? 15:21
jnthn [Coke]: No, not fixed anything yet 15:22
[Coke]: Been doing $other-project stuff this afternoon, and left it running in the background :)
jnthn analyzes a few more of the failures 15:41
Into S07 by now :) Such slow :) 15:58
16:16 leont joined 16:57 domidumont joined 17:04 awwaiid joined 17:09 dalek joined 17:12 retup__ joined 17:13 leont_ joined
jnthn * t\spec\S02-types\int-uint.rakudo.moar -> CUnion related crash 17:13
* t\spec\S02-types\lists.rakudo.moar -> could not reproduce outside of harness
* t\spec\S03-junctions\autothreading.t -> fails first test, unknown why
* t\spec\S03-operators\arith.t -> Crash in gc_mark of an MVMHash value
* t\spec\S04-declarations\constant.rakudo.moar -> Crash in gc_mark of an MVMHash value
* t\spec\S04-phasers\enter-leave.rakudo.moar -> Unwound entire stack and missed handler
* t\spec\S06-signature\shape.t -> could not reproduce outside of harness
* t\spec\S06-traits\native-is-rw.t -> Crash in gc_mark of P6str nested in P6opaque
* t\spec\S07-hyperrace\hyper.rakudo.moar -> Crash in MVM_gc_root_add_frame_roots_to_worklist, adding cur_frame->code_ref
damn!
I meant to link to the gist with those: gist.github.com/jnthn/2996cce212da...60e71fe5a5 17:14
And mention those are the ones discovered/analyzed so far
17:14 geekosaur joined
jnthn (This is from GC stressing, with a 13KB nursery) 17:14
17:14 harrow` joined
jnthn I'll leave it running while I have dinner to see if it turns up more :) 17:16
jnthn bbl 17:17
17:19 khagan joined 17:44 lizmat joined
timotimo good blerg perst, jernerthen 18:09
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
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?
timotimo most lexical accesses to the same frame will be turned into local accesses instead 19:00
and accesses to outer frames will have to stay lexical lookups
nine_ Isn't the return_type something static, i.e. shouldn't it be the same for every invocation of a block? 19:05
jnthn nine_: Correct, there won't be more of them 19:23
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:24
nine_ Ah, makes sense of course :) 19:25
jnthn nine_: That's one of the kinds of dynamism that spesh eliminates
Um...I think it does, anyways
It certainly does it in the arg direction, and certainly does it for return values on inline
TimToady jnthn: s/forth/fourth/ 19:29
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:34
lunch & 19:35
19:36 zakharyas joined
jnthn TimToady++ # helping me pop mistakes off my stack of 'em :) 19:40
20:00 brrt joined
dalek arVM/reframe-jit: a070519 | brrt++ | src/core/ (4 files):
Make frames identifiable using a sequence number

Because frames can now be garbage-collected, they can be moved, and the identity check used in the JIT will no longer work. Thus, we'd like to have another cheap way to check if we are currently still in the same frame.
Sequence numbers are assigned to frames on allocation and assigned to the thread context on the (re)entry of a frame. Thus, they provide a per-thread identifier of the position in the call stack.		 20:05
brrt killed dalke? 20:06
dalek
anyway.... something still going wrong with the istrue boolification 20:07
will have to check that out
jnthn brrt++ 20:09
fwiw, up to S15, only one more failure since S07 20:29
timotimo neat. 20:39
jnthn And one in S15 20:42
jnthn wonders if this'll still be running this time tomorrow 20:44
We'll excise a good number of bugs from this, anyways.
Well, provided I can find 'em :)
timotimo \o/
jnthn I somewhat suspect they'll end up being more unrelated to my recent changes than not 20:45
But it doesn't really matter. Bug fixes are bug fixes.
timotimo that is true 20:49
dalek arVM: 8c7d8a9 | (A. Sinan Unur)++ | src/platform/ (2 files):
VS 2013 and later provide stdint.h and inttypes.h

Therefore, there is no need to use third party substitutes for those header files if build is on VS 2013 and later.
  See [What's New for Visual C++ in Visual Studio 2013][1] and
  [C99 library support in Visual Studio 2013][2].
  [1]: msdn.microsoft.com/library/hh40929...20%29.aspx
  [2]: blogs.msdn.com/b/vcblog/archive/201...-2013.aspx		 21:11
jnthn 'night, #moarvm :) 21:46
timotimo gnite jnthn
22:06 leont_ joined 22:14 vendethiel joined 22:59 vendethiel joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!