Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-29

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

All times shown according to UTC.

Time Nick Message
00:26 hoelzro anyone still around?
00:26 hoelzro I'm trying to debug this stupid issue, but it's proving...difficult.
00:27 timotimo oh hey
00:27 timotimo i wouldn't be much use, i bet
00:27 timotimo but i can be a rubber duck
00:31 hoelzro well
00:31 timotimo perf says the hottest instruction is atkey_o
00:31 hoelzro timotimo: do you remember the issue I was seeing this morning?
00:31 timotimo i don't think i do
00:31 timotimo segv on stack frames?
00:31 hoelzro yeah
00:31 timotimo ah, yes
00:31 hoelzro well, I thought it was a GC issue
00:32 hoelzro which it still *could* be
00:32 hoelzro if I log MVM_exception_backtrace and what it's putting into the annotations hash, it doesn't match up with the WHERE of $caller.file
00:32 hoelzro which strikes me as odd
00:32 hoelzro but I probably just don't understand Moar very well
00:33 timotimo i don't know how that part works either :(
00:33 hoelzro heh
00:33 hoelzro then I'm in good company =)
00:34 timotimo i only know the part that goes "whoooosh"
00:34 hoelzro I like the whooosh
00:34 timotimo i bet you do :3
00:35 timotimo i have to say, moar is pretty cool.
00:35 hoelzro it is
00:35 timotimo i understand how parts of it work
00:35 hoelzro I think it's an important step forward
00:35 hoelzro do you know if there's a function to create a copy of a string? =)
00:36 timotimo depends; do you want to copy the P6str or the MVMString that's contained inside?
00:36 diakopter can moar run on this https://www.tindie.com/products/bateske/arduboy/
00:36 hoelzro the MVMString
00:36 timotimo we don't copy those :P
00:36 timotimo let me has a look
00:37 hoelzro well, I had an idea about the callframe thing
00:37 hoelzro I was thinking of copying the MVM string before setting it
00:37 timotimo i think we just refer to the same MVMString from multiple places
00:37 timotimo and then we have gc roots from locals, registers, ... that point at them
00:40 hoelzro I'm just wondering if, for some reason, these strings are being collected
00:41 timotimo i'd think these strings you'd be seeing are actually coming from a/the constant string pool or something
00:42 timotimo like, the filename has to come from somewhere
00:42 timotimo the string is probably allocated way earlier than the point you're looking at happens
00:42 timotimo if you have the address of the string, you ought to be able to figure out if it's in gen2 or the nursery
00:42 hoelzro that makes sense
00:42 timotimo actually, won't it have a flag set?
00:42 * hoelzro doesn't know
00:43 hoelzro the thing is
00:43 hoelzro I don't know if it's a GC issue anymoar
00:43 timotimo mhm
00:43 hoelzro because I stubbed *out* the GC
00:43 hoelzro and it still broke in the same way
00:44 timotimo oh wow :)
00:44 timotimo how well does moarvm handle not having a gc? :3
00:44 hoelzro well, it just keeps allocating memory =)
00:48 hoelzro huh.
00:48 hoelzro I think I fixed it!
00:49 hoelzro hmm
00:49 hoelzro well, I certainly prevented the segfault
00:49 hoelzro but a far more insidious bug has now crept in
00:50 timotimo oh
00:50 timotimo yikes
00:51 timotimo well, i'm getting pretty sleepy
00:51 timotimo probably too sleepy to think straight anyway :)
00:51 timotimo good luck with your bug!
00:51 hoelzro thanks
00:51 hoelzro and good night timo
00:51 TimToady \o here too :)
00:52 hoelzro night TimToady
00:52 TimToady no, I was saying night to timotimo++
00:52 hoelzro oh, ah ha =)
00:52 * TimToady might have to go to dinner soon though :)
00:53 TimToady "too" because I just said o/ in #perl6
00:54 hoelzro ooo
00:54 hoelzro it all makes sense now!
01:54 FROGGS__ joined #moarvm
02:33 jnap joined #moarvm
03:01 njmurphy joined #moarvm
03:20 ventica joined #moarvm
03:48 ventica2 joined #moarvm
04:42 ventica joined #moarvm
07:04 zakharyas joined #moarvm
07:28 Ven joined #moarvm
07:49 ventica2 joined #moarvm
08:11 woosley left #moarvm
08:25 brrt joined #moarvm
08:26 brrt \o
08:26 nwc10 o/
08:26 FROGGS o7
08:26 brrt wow, radical
08:33 nwc10 brrt: All tests successful.
08:33 nwc10 (spectests. With JIT. With ASAN)
08:34 nwc10 for me
08:34 brrt awesome :-)
08:34 nwc10 ship it!
08:34 brrt no
08:34 nwc10 What I don't know is whether it's actually faster
08:34 nwc10 joke alert!
08:34 nwc10 it's like "negative setting parse time"
08:34 nwc10 there was a silent smiley at the end
08:35 brrt there's somehow something that causes an infinite loop :-)
08:35 brrt oh :-)
08:35 * brrt may be overprotective of the project
08:35 nwc10 it's good that you care for it
08:37 brrt i've found another prove of Apple's Evilness
08:43 brrt proof
08:43 FROGGS do tell
08:44 brrt basically, you know how apps can't use their javascript JIT compiler, but the browser (safari) can?
08:45 brrt official reason is that the JIT compiler requires executable memory (correct), and this is a security liability (also correct)
08:45 brrt but on the other hand, mobile safari does have JIT compiler support
08:46 brrt now why would something be insecure for an app but not for a browser? that doesn't make any sense.
08:46 xiaomiao it's not evil when you earn money ;)
08:47 brrt apps can be checked before they ever get on users' devices; websites can load and run code coming from everywhere
08:47 brrt if i had to put my money on the safest possible use of dynamic executable memory, it wouldn't be my web browser
08:47 xiaomiao apple also includes lots of weird stuff
08:47 brrt indeed :-)
08:48 xiaomiao remote tcp traffic logging? why would you expose that on a mobile device?
08:48 xiaomiao the only reason for that I can think of is industrial espionage
08:48 brrt that is weird indeed
08:48 tgt joined #moarvm
08:49 brrt anyway, my point is that the real reason apple doesn't want JIT for javascript in their apps (or JITtted anything for that matter, although i wonder how they stand towards something like luajit) - is probably that they just don't want you to use javascript + html for apps at all
08:49 xiaomiao because then you could use the same app on android too!
08:50 tgt Apps will be able to use the faster JS engine in iOS 8.
08:50 brrt precisely
08:50 brrt o really?
08:50 brrt then my argument is invalid :-)
08:52 * brrt brb
10:57 brrt joined #moarvm
11:12 FROGGS[mobile] joined #moarvm
11:18 brrt ok, so it's not eqat_s
11:25 brrt and... it doesn't seem to be iter
11:48 * brrt keeps on removing ops until it works
11:59 brrt hmm
12:00 brrt it seems now that moar-jit also loops forever
12:08 brrt or, my configure is broken
12:11 brrt ok, seems that was it
12:11 brrt brb
12:30 brrt joined #moarvm
12:40 jnap joined #moarvm
12:48 nwc10 brrt: I have a suspicion that some of the makefile dependency rules are incomplete or wrong
12:48 nwc10 I'm doing a full clean build each time, so I don't hit this
12:48 brrt such as?
12:49 nwc10 no great idea, but someone here or on #perl6 found that updating NQP and then doing "make install" didn't fail (when it should have) because the newer NQP source they had just updated to had bumped the Moar revision
12:49 nwc10 the dependencies *are* correct from clean to build in parallel
12:49 nwc10 or, the races are so rare I never hit them, even on 24 cores.
12:49 nwc10 which is getting really unlikely
12:53 brrt the dependencies are correct, that i'm sure of; i think it moe likely i had misspelled my prefix
12:54 brrt ok, the problem is iter
12:54 brrt or iterkey_s
12:56 jnthn Getting iter wrong would be a pretty good way to infiloop :)
12:57 brrt i have a suspicion
12:58 brrt but i'll have to check it
12:58 brrt i suspect iter is throwish?
13:01 brrt hmm, or that may not be it
13:04 brrt i'll just see what the jit log says
13:06 brrt what, i have isnull, why not isnonnull?
13:10 brrt iter is used in quite a few places
13:19 brrt how do you create a hash literal in nqp?
13:24 timotimo you don't; you always do nqp::hash( k, v, k, v, k, v )
13:24 timotimo ... right?
13:25 brrt ok, i'll try that then
13:25 moritz is {} always a block?
13:25 FROGGS yes, that is how you hash in nqp
13:25 FROGGS moritz: {} is only a hash when it is empty
13:32 Ven joined #moarvm
13:45 brrt obviously, if i try iter directly, it doesn't break
13:57 btyler joined #moarvm
14:17 dalek MoarVM: e19695a | jimmy++ | src/io/dirops.c:
14:17 dalek MoarVM: change to use instance->str_consts.empty
14:17 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e19695a9a3
14:39 jnap1 joined #moarvm
15:04 woolfy joined #moarvm
15:33 cognome joined #moarvm
15:36 brrt joined #moarvm
16:03 rurban joined #moarvm
16:04 btyler_ joined #moarvm
16:04 brrt joined #moarvm
16:15 tgt_ joined #moarvm
16:17 tgt joined #moarvm
16:19 tgt_ joined #moarvm
16:21 tgt joined #moarvm
16:27 timo joined #moarvm
16:30 flussence aha, finally got around to doing that moar bisect from yesterday.
16:30 flussence (lot easier than I thought...)
16:31 flussence anyway, “f23408b0dcd221fe12e70e246dffe0ca35bc3424 is the first bad commit”...
16:46 timotimo did commenting out my implementation of iter* not help the jit?
16:58 nwc10 brrt: the bad news - JIT is doing something undefined, hence SEGV in some cases. This is what valgrind makes of it: http://paste.scsys.co.uk/410729
18:01 * jnthn back
18:05 brrt joined #moarvm
18:06 nwc10 jnthn: as you might have already seen, that paste is a SEGV buildng the setting on Linux with JIT
18:07 jnthn Hmmmmm
18:07 nwc10 so it's demonstrably not all unicorns and rainbows yet
18:07 jnthn That's the one I got rid of on Windows by disabling an optimization
18:07 jnthn Also the one timotimo was seeing
18:07 jnthn So yeah, something very fishy
18:07 nwc10 OK, good, in that I can replicate what timotimo is seeing
18:07 brrt yes, very good indeed
18:07 brrt i'll look at the code again
18:08 brrt but it seems quite rare nevertheless?
18:08 nwc10 that's not "good" in the sense that I'm going to fix it. But that I can show that timotimo is not special
18:08 brrt or do you have this always
18:08 nwc10 repeatably for the compiler flags I'm using
18:08 nwc10 with or without --optimize
18:08 brrt which are?
18:08 nwc10 perl Configure.pl --prefix=/home/nicholas/Sandpit/moar-g-jit --enable-jit --cc=ccache\ /usr/local/gcc49/bin/gcc --ld=/usr/local/gcc49/bin/gcc --debug --optimize=0
18:09 brrt it isn't bad, because there's only a single place this ever gets called
18:09 brrt oh, thats gcc49
18:09 brrt hmmm
18:09 brrt but timo saw it with gcc48 already
18:09 nwc10 gcc (GCC) 4.9.0
18:09 brrt oh, i see
18:10 brrt *ahem*
18:10 nwc10 same gcc building with ASAN does not go SEGV. So I
18:10 * brrt now wonders how this ever even worked
18:10 nwc10 I'm guessing that the ASAN flags end up doing something different to the code gen
18:10 brrt wait, i'll show you the line, and you'll see what's wrong
18:11 nwc10 I think I'm stating the obvious here :-/
18:11 nwc10 OK
18:11 brrt https://github.com/MoarVM/MoarVM/blob/moar-jit/src/jit/emit_x64.dasc#L1169
18:12 brrt first one to spot the error gets a 100 kudos
18:12 nwc10 well, I can't, because I don't know the ABI. (I don't know x86_64 assembler, but I can guess it)
18:13 nwc10 aha, but if the commentis correct, then the arguments are transposed
18:13 brrt it's in the comment, in fact
18:13 brrt well, yes :-)
18:13 brrt i /used/ to push TMP6 (the callsite pointer) to the stack, leaving rsp being the address of tmp6
18:13 nwc10 oh, no, I can't guess assembler enough - I don't know which is source and which is dest
18:14 nwc10 but comment has [] and code does not
18:14 brrt but, i don't push anymore since that makes keepking the call stack properly aligned challing
18:14 nwc10 so code is loading a register, but it's supposed to be writing to memory addressed by that register?
18:14 brrt the first is the destination, the second is the source
18:14 brrt well, no, &cur_callsite is the pointer to the top of the stack, which is rarely if ever assigned to anything
18:15 brrt i.e. i pass 4 arguments to find_invokee_multi_ok, namely threadcontext, the code object (which i only then load from the work register) , &cur_callsite, args
18:16 brrt but &cur_callsite /used/ to be top of the stack, since i used to push it 3 instructions earlier
18:17 brrt so setting arg3 = rsp (top of stack) was ok, but i don't do that anymore, since that ultimately causes stack-walking, and that causes callee-save-register gibberish, and that ultimately causes a crash
18:19 nwc10 "can you fix it?"
18:19 brrt :-)
18:19 brrt i'm testing a fix now
18:20 * brrt finds it still amazing that this ever used to work and that jnthn++'s patch did anything
18:20 nwc10 it's scary how much buggy code doesn't crash early enough
18:20 jnthn Wow
18:20 jnthn brrt++
18:23 jnthn And nwc10++ for finding it, of course
18:23 * brrt concurs with nwc10
18:23 brrt nwc10++ indeed
18:24 nwc10 I didn't find the fix. Just got tools to produce a plausible backtrace
18:24 brrt and timotimo++ for insisting, by the way
18:24 nwc10 *now* can we ship it? :-)
18:24 * brrt suspects my processor may have been doing something really funky that hid the crash
18:26 dalek MoarVM/moar-jit: 730f8cd | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
18:26 dalek MoarVM/moar-jit: cur_callsite is no longer top of stack
18:26 dalek MoarVM/moar-jit:
18:26 dalek MoarVM/moar-jit: MVM_frame_find_invokee_multi_ok expects to take the
18:26 dalek MoarVM/moar-jit: address of the current callsite. I used to push the
18:26 dalek MoarVM/moar-jit: pointer to this object on the stack, so that the stack
18:26 dalek MoarVM/moar-jit: pointer was in fact the address of this object. However,
18:26 dalek MoarVM/moar-jit: I don't use push and pop anymore, instead using a statically
18:26 dalek MoarVM/moar-jit: allocated stack frame of 96 bytes large. Since this
18:27 dalek MoarVM/moar-jit: means the cur_callsite pointer is stored somewhere else, the
18:27 dalek MoarVM/moar-jit: 3rd argument is gibberish. Fix by loading the current location
18:27 dalek MoarVM/moar-jit: into the 3rd argument.
18:27 dalek MoarVM/moar-jit:
18:27 dalek MoarVM/moar-jit: nwc10++ and timotimo++ for getting good backtraces.
18:27 brrt i just keep on making dumb mistakes so i can reap the rewards of fixing them :-)
18:27 timotimo ooooh
18:28 dalek MoarVM/jit-moar-ops: 730f8cd | (Bart Wiegmans)++ | src/jit/emit_ (3 files):
18:28 dalek MoarVM/jit-moar-ops: cur_callsite is no longer top of stack
18:28 dalek MoarVM/jit-moar-ops:
18:28 dalek MoarVM/jit-moar-ops: MVM_frame_find_invokee_multi_ok expects to take the
18:28 dalek MoarVM/jit-moar-ops: address of the current callsite. I used to push the
18:28 dalek MoarVM/jit-moar-ops: pointer to this object on the stack, so that the stack
18:28 dalek MoarVM/jit-moar-ops: pointer was in fact the address of this object. However,
18:28 dalek MoarVM/jit-moar-ops: I don't use push and pop anymore, instead using a statically
18:28 dalek MoarVM/jit-moar-ops: allocated stack frame of 96 bytes large. Since this
18:28 dalek MoarVM/jit-moar-ops: means the cur_callsite pointer is stored somewhere else, the
18:28 dalek MoarVM/jit-moar-ops: 3rd argument is gibberish. Fix by loading the current location
18:28 dalek MoarVM/jit-moar-ops: into the 3rd argument.
18:28 dalek MoarVM/jit-moar-ops:
18:28 dalek MoarVM/jit-moar-ops: nwc10++ and timotimo++ for getting good backtraces.
18:28 brrt please check if this fixes it for you timotimo :-)
18:28 brrt and nwc10 as well
18:29 timotimo will do
18:35 brrt still hangs on nqp building, unfortunately
18:37 timotimo yes, it does :(
18:41 timotimo hangs in grammar.nqp, too
18:45 nwc10 brrt: through the rakudo sanity tests and into the spectests
18:45 timotimo and in stage parse, too
18:45 brrt \o/
18:45 brrt yes, i know
18:45 timotimo good to know :)
18:45 timotimo AFK, food
18:47 * brrt brb
18:48 nwc10 All tests successful.
18:48 nwc10 Files=908, Tests=31963, 199 wallclock secs (14.95 usr  3.85 sys + 3477.11 cusr 173.58 csys = 3669.49 CPU)
18:48 nwc10 Result: PASS
18:51 jnthn That's a fast box :)
18:52 nwc10 it's fastest when it has 24 things to do in parallel
18:52 jnthn Oh :)
18:52 jnthn "Core blimey"
18:52 nwc10 the future is multicore
18:53 nwc10 which, as my daughter likes to say "I know that already"
18:54 brrt joined #moarvm
18:54 btyler joined #moarvm
18:55 nwc10 re-running the setting build under valgrind is not the fastest
18:55 nwc10 22076 nicholas  20   0  497m 423m  11m R 100.0  0.4   7:00.44 memcheck-amd64-
19:02 Ven joined #moarvm
19:02 brrt nqp testsuite interestingly enough burns in jit-moar-ops with /only/ iter
19:06 brrt and without, it seems
19:12 brrt :-o only two weeks left or so
19:12 FROGGS PANIC
19:17 brrt and no support for extops yet
19:18 brrt ok, no panic
19:19 brrt nwc10: you're sure the sanity test runs for you?
19:19 nwc10 All tests successful.
19:19 nwc10 Files=22, Tests=271,  3 wallclock secs ( 0.14 usr  0.03 sys + 35.62 cusr  2.23 csys = 38.02 CPU)
19:19 nwc10 Result: PASS
19:19 nwc10 yes, for me
19:20 nwc10 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           22076 nicholas  20   0 1101m 1.0g  11m R 100.0  1.1  31:40.82 memcheck-amd64-
19:20 brrt hmmm
19:22 nwc10 no, I don't know why I get lucky
19:25 nwc10 Stage parse      : 2062.728
19:25 nwc10 OK, so progress
19:27 nwc10 so, expect about 240 seconds for stage optimize and 800 for mast
19:27 nwc10 Stage optimize   : 227.126
19:27 nwc10 OK, 800 more before it finishes
19:31 brrt ok, moar-jit proper also runs testsuite fine
19:31 brrt (for me)
19:35 nwc10 22076 nicholas  20   0 1414m 1.3g  11m R 99.7  1.4  47:09.09 memcheck-amd64-
19:36 nwc10 still chugging. probably 5 more minutes
19:40 nwc10 22076 nicholas  20   0 1545m 1.4g  11m R 99.6  1.5  52:01.54 memcheck-amd64-
19:40 nwc10 and done
19:41 nwc10 so, yes, I can build the setting with the JIT under valgrind. But it takes a while
19:41 nwc10 ==22076==     in use at exit: 808,365,911 bytes in 2,627,380 blocks
19:41 nwc10 ==22076==   total heap usage: 21,434,309 allocs, 18,806,929 frees, 12,397,083,759 bytes allocated
19:43 jnthn So allocation...
19:43 nwc10 "so allocation, very churn, sigh" ?
19:43 jnthn yeah
19:43 jnthn Though I know one source I can elimiante easy enough.
19:43 nwc10 exterminate! extermiate!
19:44 timotimo i'd be interested to know where that is
19:44 timotimo we could perhaps just keep blocks used for spesh around
19:44 timotimo no need to free the memory if we end up speshing something else a few miliseconds later ...
19:45 jnthn I don't think spesh is the big cause
19:45 jnthn I was more thinking the NFA
19:46 timotimo oh
19:46 timotimo right, they have to allocate, too
19:47 jnthn Yeah
19:47 jnthn But a given thread can only be evaluating one NFA at a time
19:48 timotimo and we run lots and lots and lots and lots of nfa
19:48 jnthn So we can just keep the memory around hung off le tc
19:48 nwc10 please be keeping an option to disable this, so that we don't do a heartblead
19:48 timotimo hmm, nfas will only leak data very indirectly
19:49 nwc10 yes, I was really joking about the seriousness
19:49 timotimo as in you can only really gleam what text was being matched if you get a dump of the nfa storage
19:49 nwc10 but the unerlying thing is that it's useful to be able to disable a custom allocator, to enable the use of memory sanitsing tools
19:50 jnthn nwc10: In this case we're not allocating multiple different things in the block, just keeping a block around for next time. So it's less of an issue than, say, the fixed size allocator, which really does need a disable switch.
19:55 timotimo btw, there's a gcc attribute for "this function is malloc-like"
19:57 colomon joined #moarvm
20:04 nwc10 JIT ASAN spectest PASS.
20:05 nwc10 now, back to the thing I was actally trying, which caused the bug hunt - optimised JIT build
20:10 nwc10 oooh, t/spec/S32-io/IO-Socket-Async.rakudo.moar failed for  me on the re-run
20:10 nwc10 not ok 4 - Echo server
20:10 * nwc10 asks everyone to imagine the blank line here
20:10 nwc10 # Failed test 'Echo server'
20:10 nwc10 # at lib/Test.pm line 75
20:10 FROGGS master also does
20:10 nwc10 it flaps
20:11 nwc10 but it rarely fails on a re-run
20:11 FROGGS you were lucky :o)
20:13 nwc10 anway, optimised JIT build passes
20:22 * flussence goes file a proper bug report for this thing that's been bugging me
20:22 hoelzro flussence: what's that?
20:23 flussence since moar f23408b0, one of my modules dies after *exactly* 17/50 tests with the error @ src/gc/collect.c l421
20:24 hoelzro flussence: any useful output from the test?
20:24 hoelzro like a segfault or something?
20:25 jnthn The error there is basically saying "if we go on we're gonna SEGV"
20:25 flussence no other output, just "Internal error: zeroed target thread ID in work pass" and it abruptly exits... jnthn is right though, I was poking at it in gdb and the next thing that would've happened is a null pointer deref.
20:26 flussence ...aaaaand it works in current rakudo head... oh well.
20:27 jnthn Hm
20:28 timotimo d'oh
20:31 hoelzro ok, different from my error
20:31 brrt joined #moarvm
20:31 hoelzro which has been really hard to figure out
20:37 flussence hm, I might've been using a stale install and it may not actually be fixed... one sec
20:39 brrt timotimo: wrt to your plans to write a jit log analyser, i'm planning to refactor that code a bit (so less analysis may be needed)
20:42 timotimo that sounds good
20:42 timotimo so, did we figure out that iter is not to blame for our hanging problems?
20:45 brrt good news btw
20:45 brrt well, it is to 'blame' somehow, but not in the way you'd typically think of it
20:45 brrt it's probably not broken but it allows brokennes, is what i mean
20:46 brrt anyway, good news again, i've singled out a failing spectest that fails with iter (but not without)
20:46 timotimo great!
20:51 flussence well I'm confused... I get that MVM_panic message if I try running my p6 code under gdb but it works fine normally.
20:52 flussence I guess as long as it works well enough I can get on with doing stuff, so that's good. :)
20:56 timotimo brrt: when that bug is found and fixed, what's next on your roadmap? :)
20:56 brrt uh...
20:56 brrt well....
20:56 brrt :-)
20:56 timotimo sp_findmeth seems to be at the top of the bail list by far
20:56 brrt extops
20:56 timotimo mhm
20:56 brrt yes, that's a big one
20:56 brrt ok, sp_findmeth before that
20:57 brrt :-)
20:57 timotimo do you think lt/gt/eq/ne _n and not_i would be quickly doable, too? :3
20:58 jnthn I hate to throw this one in, but jumptable will also be rather critical-path
20:58 timotimo moarvm has jumptables?
20:58 jnthn Sure
20:58 jnthn Used in every single regex/rule/token. :)
20:59 timotimo ah, is that for the nfa?
20:59 timotimo like, the result of the nfa gives us the index into a jumptable?
20:59 jnthn No
20:59 jnthn Well
20:59 jnthn Yes for alts
20:59 timotimo would it be enough to implement "die" as a call to the right function to make it throw correctly, or does it need special treatment to work with the jit and stuff?
20:59 jnthn But more generally it's used for the backtrack stack
20:59 timotimo ah, good
20:59 jnthn Well, it's a throwy operation
21:00 jnthn In other news, I'll have Fri/Sat/Sun for Perl 6 things. :)
21:00 timotimo \o/
21:02 timotimo getattr_o seems to be hot, too. i can probably implement that esaily-ish
21:03 brrt yes, num comparisons are conceptually simple
21:03 brrt \o/
21:04 brrt although i have fri/sat/sun for social things, but i'll try to be there
21:04 brrt well... how hard is jumptable, really?
21:05 brrt also, i do in fact think that throwy operations need quite a bit more work
21:05 brrt but i've been in bughunt mode so long now
21:06 jnthn brrt: Doin't expect jumptable will be that hard. It's what it says.
21:06 jnthn brrt: In the worst case you can spit out an if ladder :P
21:06 brrt that's true
21:07 brrt but, all jumptable exits are basic blocks, right?
21:07 brrt then they already have a label
21:07 jnthn Yeah
21:08 brrt ok, then i'm not too afraid of it
21:08 brrt :-)
21:08 brrt then it's 'just a branch'
21:12 timotimo aaw, there is no bindattr to copy code from
21:12 timotimo i hope the getattr code is copyable :P
21:13 brrt i suppose it is, as long as you ensure proper guards are in place :-)
21:14 jnthn If you mean wbs then I think they're all in the reprconv.c function
21:14 jnthn And bindattr canny invoke
21:14 jnthn So not sure what guards are needed...unless I'm forgetting something :)
21:16 brrt well, yeah, these are what i mean :-)
21:16 brrt write barriers
21:16 jnthn k
21:16 brrt and yes, feel free to work further so long as i'm still trying to squash our current one
21:16 brrt (and unearth more bugs at the same time :-))
21:19 [Coke] oh. I wonder if I can incorporate the rakudo-jvm-in-eclipse work to run perl6 from coldfusion.
21:19 [Coke] ww
21:20 jnthn #moarvm loves Rakudo JVM too :)
21:22 Ven joined #moarvm
21:26 dalek MoarVM: 5df280f | jnthn++ | src/ (2 files):
21:26 dalek MoarVM: Avoid repeatedly allocating memory for NFAs.
21:26 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/5df280f007
21:28 timotimo bindattr can invoke?
21:29 timotimo i thought repr ops never invoke?
21:29 jnthn timotimo: no, it can't
21:29 jnthn And you're right, they don't
21:29 timotimo ah, so canny == cannot :)
21:29 jnthn yes :)
21:29 timotimo okeh
21:29 jnthn ETOOSLANG
21:39 jnthn m: say 790566 * 7 * 8
21:39 camelia rakudo-moar c00999: OUTPUT«44271696␤»
21:39 jnthn m: say (790566 * 7 * 8) / 4194304
21:39 camelia rakudo-moar c00999: OUTPUT«10.5551949␤»
21:42 jnthn Hmm. This might be a nice win...
21:43 brrt oh, i think i've found something truly nasty
21:43 jnthn brrt: Uh-oh...what?
21:44 jnthn btw, above calcs relate to alternations. We currently build the labels array every alternation, even though it's static information. Which was expedient when doing the initial code gen, but now accounts for 10 GC runs while building CORE.setting.
21:44 brrt well, the qregex bug, right?
21:44 jnthn brrt: Is that the iter one?
21:44 brrt it seems it only appears when nqp was /built/ using the iter
21:44 brrt it seems so
21:44 brrt but let me check again
21:45 jnthn Ah, so somehow the iter causes a mis-code-gen?
21:45 jnthn Got a link for me to the patch that added iter and related ops to the JIT?
21:47 brrt uhm, yeah, i suppose
21:48 brrt this one did, but it's nothing funky as far as i can see
21:50 timotimo now i have a single function that covers bindattr_i, _n, _s and _o
21:50 timotimo yay
21:51 jnthn "this one"? :)
21:56 brrt oh, sorry :-)
21:57 TimToady "that one" :)
21:57 brrt https://github.com/MoarVM/MoarVM/commit/d22e36de34ea75e320c4da2399532ad963b749a0
21:59 brrt what does nqp::getcodename doe?
21:59 brrt do?
22:00 jnthn Gets the name of a code object
22:00 timotimo with an implementation of the bindattr ops NQPHLL and NQPP6Regex both hang
22:01 brrt do you have iter?
22:01 brrt other way to phrase that question
22:02 brrt do they still hang when removing iter?
22:05 * brrt can't get the hang of this weird iter bug
22:06 jnthn Why are iterkey_s and iter handled differently in the code-gen from iterval, when the code-gen looks the same?
22:07 lizmat joined #moarvm
22:07 brrt no reason
22:07 brrt all of these can be collapsed into one for all i care
22:09 brrt also, fwiw, register indices are 16 bits wide
22:13 timotimo er, huh?
22:13 timotimo no, iterkey_s returns a string, iter and iterkey return obj
22:13 timotimo that's the difference
22:13 timotimo oh
22:14 timotimo but ptr is str
22:14 timotimo so they *are* the same
22:14 timotimo oops :)
22:18 timotimo without iter and friends nqp gets through the build completely
22:20 timotimo seems like so does rakudo
22:20 timotimo aye.
22:26 timotimo wow, 96 bails from islist
22:26 timotimo when do we generate that code %)
22:27 jnthn brrt: One thing that occurs to me
22:27 jnthn brrt: Iterators use boolification to see if we're at the end
22:27 jnthn brrt: I don't suppose there's any chance we could be looking at an istrue bug in disguise?
22:28 timotimo brrt: indexat and indexnat are both branchy, but indexat only happens 42 times in core setting now ...
22:28 dalek MoarVM/jit-moar-ops: 18c6ecb | (Timo Paulssen)++ | src/ (3 files):
22:28 dalek MoarVM/jit-moar-ops: support bindattr_inso
22:28 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/18c6ecba9c
22:29 timotimo and indexnat happens even less often
22:50 dalek MoarVM/jit-moar-ops: 9f86dda | (Timo Paulssen)++ | src/ (3 files):
22:50 dalek MoarVM/jit-moar-ops: implement all the getattr ops: inso.
22:50 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/9f86dda975
22:50 * timotimo hunts the jit log some more
22:51 flussence oh, things are getting interesting. I just built everything from master and that GC bug I was getting before is now a segfault *sometimes*.
22:52 flussence https://gist.github.com/flussence/0eeb33d93f24946b8ca8 now with actual gdb backtrace :D
22:54 brrt jnthn, i agree, but tbh... i find that rather unlikely given that boolification is already used extensively
22:55 brrt anyway, i'm of for tonight
22:55 brrt left #moarvm
22:55 jnthn 'night, brrt
22:56 timotimo gnite jnthn
22:56 timotimo gnite brrt
23:02 timotimo why does newlexotic cur_op += 6? does it have some storage next to it or something?
23:02 jnthn It's a reg + a 32-bit offset iirc
23:03 timotimo oh?
23:03 timotimo it uses GET_UI32(cur_op, 2)
23:03 timotimo so ... i'm confused
23:04 timotimo oh, that's 32bit ... duh
23:06 timotimo it must be late ...
23:09 FROGGS it is
23:17 ashleydev joined #moarvm
23:22 timotimo tomorrow i'd like to know if i can safely ignore the if (ctx->callsite->num_pos != ctx->callsite->arg_count) that is part of paramnamesused (because we've spesh'd this callsite already)
23:32 ashleydev joined #moarvm
23:42 dalek MoarVM/jit-moar-ops: eb19462 | (Timo Paulssen)++ | src/jit/graph.c:
23:42 dalek MoarVM/jit-moar-ops: implement newlexotic
23:42 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/eb19462df1
23:42 dalek MoarVM/jit-moar-ops: 5ab4b4b | (Timo Paulssen)++ | src/ (3 files):
23:42 dalek MoarVM/jit-moar-ops: setelemspos for le jit
23:42 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/5ab4b4b215
23:42 dalek MoarVM/jit-moar-ops: 4cae0f9 | (Timo Paulssen)++ | src/jit/graph.c:
23:42 dalek MoarVM/jit-moar-ops: iter, iterval and iterkey make stuff hang in compilation :(
23:42 dalek MoarVM/jit-moar-ops: review: https://github.com/MoarVM/MoarVM/commit/4cae0f9411
23:43 timotimo https://gist.github.com/timo/f92ff69eb404592b3a51
23:44 timotimo about 1150 frames we couldn't jit
23:46 timotimo hmm. had i put the bail log into a git after implementing each op, we could have fun stats to look at
23:48 timotimo https://gist.github.com/timo/f92ff69eb404592b3a51/revisions
23:49 timotimo "32 bindpos_i turned into 10 sp_findmeth, 20 islist, 1 indexat, 1 iscclass"

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