hoelzro | anyone still around? | 00:26 | |
I'm trying to debug this stupid issue, but it's proving...difficult. | |||
timotimo | oh hey | 00:27 | |
i wouldn't be much use, i bet | |||
but i can be a rubber duck | |||
hoelzro | well | 00:31 | |
timotimo | perf says the hottest instruction is atkey_o | ||
hoelzro | timotimo: do you remember the issue I was seeing this morning? | ||
timotimo | i don't think i do | ||
segv on stack frames? | |||
hoelzro | yeah | ||
timotimo | ah, yes | ||
hoelzro | well, I thought it was a GC issue | ||
which it still *could* be | 00:32 | ||
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 | |||
which strikes me as odd | |||
but I probably just don't understand Moar very well | |||
timotimo | i don't know how that part works either :( | 00:33 | |
hoelzro | heh | ||
then I'm in good company =) | |||
timotimo | i only know the part that goes "whoooosh" | 00:34 | |
hoelzro | I like the whooosh | ||
timotimo | i bet you do :3 | ||
i have to say, moar is pretty cool. | 00:35 | ||
hoelzro | it is | ||
timotimo | i understand how parts of it work | ||
hoelzro | I think it's an important step forward | ||
do you know if there's a function to create a copy of a string? =) | |||
timotimo | depends; do you want to copy the P6str or the MVMString that's contained inside? | 00:36 | |
diakopter | can moar run on this www.tindie.com/products/bateske/arduboy/ | ||
hoelzro | the MVMString | ||
timotimo | we don't copy those :P | ||
let me has a look | |||
hoelzro | well, I had an idea about the callframe thing | 00:37 | |
I was thinking of copying the MVM string before setting it | |||
timotimo | i think we just refer to the same MVMString from multiple places | ||
and then we have gc roots from locals, registers, ... that point at them | |||
hoelzro | I'm just wondering if, for some reason, these strings are being collected | 00:40 | |
timotimo | i'd think these strings you'd be seeing are actually coming from a/the constant string pool or something | 00:41 | |
like, the filename has to come from somewhere | 00:42 | ||
the string is probably allocated way earlier than the point you're looking at happens | |||
if you have the address of the string, you ought to be able to figure out if it's in gen2 or the nursery | |||
hoelzro | that makes sense | ||
timotimo | actually, won't it have a flag set? | ||
hoelzro doesn't know | |||
the thing is | 00:43 | ||
I don't know if it's a GC issue anymoar | |||
timotimo | mhm | ||
hoelzro | because I stubbed *out* the GC | ||
and it still broke in the same way | |||
timotimo | oh wow :) | 00:44 | |
how well does moarvm handle not having a gc? :3 | |||
hoelzro | well, it just keeps allocating memory =) | ||
huh. | 00:48 | ||
I think I fixed it! | |||
hmm | 00:49 | ||
well, I certainly prevented the segfault | |||
but a far more insidious bug has now crept in | |||
timotimo | oh | 00:50 | |
yikes | |||
well, i'm getting pretty sleepy | 00:51 | ||
probably too sleepy to think straight anyway :) | |||
good luck with your bug! | |||
hoelzro | thanks | ||
and good night timo | |||
TimToady | \o here too :) | ||
hoelzro | night TimToady | 00:52 | |
TimToady | no, I was saying night to timotimo++ | ||
hoelzro | oh, ah ha =) | ||
TimToady might have to go to dinner soon though :) | |||
"too" because I just said o/ in #perl6 | 00:53 | ||
hoelzro | ooo | 00:54 | |
it all makes sense now! | |||
01:54
FROGGS__ joined
02:33
jnap joined
03:01
njmurphy joined
03:20
ventica joined
03:48
ventica2 joined
04:42
ventica joined
07:04
zakharyas joined
07:28
Ven joined
07:49
ventica2 joined
08:11
woosley left
08:25
brrt joined
|
|||
brrt | \o | 08:26 | |
nwc10 | o/ | ||
FROGGS | o7 | ||
brrt | wow, radical | ||
nwc10 | brrt: All tests successful. | 08:33 | |
(spectests. With JIT. With ASAN) | |||
for me | 08:34 | ||
brrt | awesome :-) | ||
nwc10 | ship it! | ||
brrt | no | ||
nwc10 | What I don't know is whether it's actually faster | ||
joke alert! | |||
it's like "negative setting parse time" | |||
there was a silent smiley at the end | |||
brrt | there's somehow something that causes an infinite loop :-) | 08:35 | |
oh :-) | |||
brrt may be overprotective of the project | |||
nwc10 | it's good that you care for it | ||
brrt | i've found another prove of Apple's Evilness | 08:37 | |
proof | 08:43 | ||
FROGGS | do tell | ||
brrt | basically, you know how apps can't use their javascript JIT compiler, but the browser (safari) can? | 08:44 | |
official reason is that the JIT compiler requires executable memory (correct), and this is a security liability (also correct) | 08:45 | ||
but on the other hand, mobile safari does have JIT compiler support | |||
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 ;) | ||
brrt | apps can be checked before they ever get on users' devices; websites can load and run code coming from everywhere | 08:47 | |
if i had to put my money on the safest possible use of dynamic executable memory, it wouldn't be my web browser | |||
xiaomiao | apple also includes lots of weird stuff | ||
brrt | indeed :-) | ||
xiaomiao | remote tcp traffic logging? why would you expose that on a mobile device? | 08:48 | |
the only reason for that I can think of is industrial espionage | |||
brrt | that is weird indeed | ||
08:48
tgt joined
|
|||
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! | ||
tgt | Apps will be able to use the faster JS engine in iOS 8. | 08:50 | |
brrt | precisely | ||
o really? | |||
then my argument is invalid :-) | |||
brrt brb | 08:52 | ||
10:57
brrt joined
11:12
FROGGS[mobile] joined
|
|||
brrt | ok, so it's not eqat_s | 11:18 | |
and... it doesn't seem to be iter | 11:25 | ||
brrt keeps on removing ops until it works | 11:48 | ||
hmm | 11:59 | ||
it seems now that moar-jit also loops forever | 12:00 | ||
or, my configure is broken | 12:08 | ||
ok, seems that was it | 12:11 | ||
brb | |||
12:30
brrt joined
12:40
jnap joined
|
|||
nwc10 | brrt: I have a suspicion that some of the makefile dependency rules are incomplete or wrong | 12:48 | |
I'm doing a full clean build each time, so I don't hit this | |||
brrt | such as? | ||
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 | |
the dependencies *are* correct from clean to build in parallel | |||
or, the races are so rare I never hit them, even on 24 cores. | |||
which is getting really unlikely | |||
brrt | the dependencies are correct, that i'm sure of; i think it moe likely i had misspelled my prefix | 12:53 | |
ok, the problem is iter | 12:54 | ||
or iterkey_s | |||
jnthn | Getting iter wrong would be a pretty good way to infiloop :) | 12:56 | |
brrt | i have a suspicion | 12:57 | |
but i'll have to check it | 12:58 | ||
i suspect iter is throwish? | |||
hmm, or that may not be it | 13:01 | ||
i'll just see what the jit log says | 13:04 | ||
what, i have isnull, why not isnonnull? | 13:06 | ||
iter is used in quite a few places | 13:10 | ||
how do you create a hash literal in nqp? | 13:19 | ||
timotimo | you don't; you always do nqp::hash( k, v, k, v, k, v ) | 13:24 | |
... right? | |||
brrt | ok, i'll try that then | 13:25 | |
moritz | is {} always a block? | ||
FROGGS | yes, that is how you hash in nqp | ||
moritz: {} is only a hash when it is empty | |||
13:32
Ven joined
|
|||
brrt | obviously, if i try iter directly, it doesn't break | 13:45 | |
13:57
btyler joined
|
|||
dalek | arVM: e19695a | jimmy++ | src/io/dirops.c: change to use instance->str_consts.empty |
14:17 | |
14:39
jnap1 joined
15:04
woolfy joined
15:33
cognome joined
15:36
brrt joined
16:03
rurban joined
16:04
btyler_ joined,
brrt joined
16:15
tgt_ joined
16:17
tgt joined
16:19
tgt_ joined
16:21
tgt joined
16:27
timo joined
|
|||
flussence | aha, finally got around to doing that moar bisect from yesterday. | 16:30 | |
(lot easier than I thought...) | |||
anyway, “f23408b0dcd221fe12e70e246dffe0ca35bc3424 is the first bad commit”... | 16:31 | ||
timotimo | did commenting out my implementation of iter* not help the jit? | 16:46 | |
nwc10 | brrt: the bad news - JIT is doing something undefined, hence SEGV in some cases. This is what valgrind makes of it: paste.scsys.co.uk/410729 | 16:58 | |
jnthn back | 18:01 | ||
18:05
brrt joined
|
|||
nwc10 | jnthn: as you might have already seen, that paste is a SEGV buildng the setting on Linux with JIT | 18:06 | |
jnthn | Hmmmmm | 18:07 | |
nwc10 | so it's demonstrably not all unicorns and rainbows yet | ||
jnthn | That's the one I got rid of on Windows by disabling an optimization | ||
Also the one timotimo was seeing | |||
So yeah, something very fishy | |||
nwc10 | OK, good, in that I can replicate what timotimo is seeing | ||
brrt | yes, very good indeed | ||
i'll look at the code again | |||
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 | ||
brrt | or do you have this always | ||
nwc10 | repeatably for the compiler flags I'm using | ||
with or without --optimize | |||
brrt | which are? | ||
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 | ||
brrt | it isn't bad, because there's only a single place this ever gets called | 18:09 | |
oh, thats gcc49 | |||
hmmm | |||
but timo saw it with gcc48 already | |||
nwc10 | gcc (GCC) 4.9.0 | ||
brrt | oh, i see | ||
*ahem* | 18:10 | ||
nwc10 | same gcc building with ASAN does not go SEGV. So I | ||
brrt now wonders how this ever even worked | |||
nwc10 | I'm guessing that the ASAN flags end up doing something different to the code gen | ||
brrt | wait, i'll show you the line, and you'll see what's wrong | ||
nwc10 | I think I'm stating the obvious here :-/ | 18:11 | |
OK | |||
brrt | github.com/MoarVM/MoarVM/blob/moar...dasc#L1169 | ||
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) | ||
aha, but if the commentis correct, then the arguments are transposed | 18:13 | ||
brrt | it's in the comment, in fact | ||
well, yes :-) | |||
i /used/ to push TMP6 (the callsite pointer) to the stack, leaving rsp being the address of tmp6 | |||
nwc10 | oh, no, I can't guess assembler enough - I don't know which is source and which is dest | ||
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 | ||
nwc10 | so code is loading a register, but it's supposed to be writing to memory addressed by that register? | ||
brrt | the first is the destination, the second is the source | ||
well, no, &cur_callsite is the pointer to the top of the stack, which is rarely if ever assigned to anything | |||
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:15 | ||
but &cur_callsite /used/ to be top of the stack, since i used to push it 3 instructions earlier | 18:16 | ||
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:17 | ||
nwc10 | "can you fix it?" | 18:19 | |
brrt | :-) | ||
i'm testing a fix now | |||
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 | ||
jnthn | Wow | ||
brrt++ | |||
And nwc10++ for finding it, of course | 18:23 | ||
brrt concurs with nwc10 | |||
nwc10++ indeed | |||
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 | ||
nwc10 | *now* can we ship it? :-) | ||
brrt suspects my processor may have been doing something really funky that hid the crash | |||
dalek | MoarVM/moar-jit: 730f8cd | (Bart Wiegmans)++ | src/jit/emit_ (3 files): | 18:26 | |
MoarVM/moar-jit: cur_callsite is no longer top of stack | |||
MoarVM/moar-jit: | |||
MoarVM/moar-jit: MVM_frame_find_invokee_multi_ok expects to take the | |||
MoarVM/moar-jit: address of the current callsite. I used to push the | |||
MoarVM/moar-jit: pointer to this object on the stack, so that the stack | |||
MoarVM/moar-jit: pointer was in fact the address of this object. However, | |||
MoarVM/moar-jit: I don't use push and pop anymore, instead using a statically | |||
MoarVM/moar-jit: allocated stack frame of 96 bytes large. Since this | |||
MoarVM/moar-jit: means the cur_callsite pointer is stored somewhere else, the | 18:27 | ||
MoarVM/moar-jit: 3rd argument is gibberish. Fix by loading the current location | |||
MoarVM/moar-jit: into the 3rd argument. | |||
MoarVM/moar-jit: | |||
MoarVM/moar-jit: nwc10++ and timotimo++ for getting good backtraces. | |||
brrt | i just keep on making dumb mistakes so i can reap the rewards of fixing them :-) | ||
timotimo | ooooh | ||
dalek | MoarVM/jit-moar-ops: 730f8cd | (Bart Wiegmans)++ | src/jit/emit_ (3 files): | 18:28 | |
MoarVM/jit-moar-ops: cur_callsite is no longer top of stack | |||
MoarVM/jit-moar-ops: | |||
MoarVM/jit-moar-ops: MVM_frame_find_invokee_multi_ok expects to take the | |||
MoarVM/jit-moar-ops: address of the current callsite. I used to push the | |||
MoarVM/jit-moar-ops: pointer to this object on the stack, so that the stack | |||
MoarVM/jit-moar-ops: pointer was in fact the address of this object. However, | |||
MoarVM/jit-moar-ops: I don't use push and pop anymore, instead using a statically | |||
MoarVM/jit-moar-ops: allocated stack frame of 96 bytes large. Since this | |||
MoarVM/jit-moar-ops: means the cur_callsite pointer is stored somewhere else, the | |||
MoarVM/jit-moar-ops: 3rd argument is gibberish. Fix by loading the current location | |||
MoarVM/jit-moar-ops: into the 3rd argument. | |||
MoarVM/jit-moar-ops: | |||
MoarVM/jit-moar-ops: nwc10++ and timotimo++ for getting good backtraces. | |||
brrt | please check if this fixes it for you timotimo :-) | ||
and nwc10 as well | |||
timotimo | will do | 18:29 | |
brrt | still hangs on nqp building, unfortunately | 18:35 | |
timotimo | yes, it does :( | 18:37 | |
hangs in grammar.nqp, too | 18:41 | ||
nwc10 | brrt: through the rakudo sanity tests and into the spectests | 18:45 | |
timotimo | and in stage parse, too | ||
brrt | \o/ | ||
yes, i know | |||
timotimo | good to know :) | ||
AFK, food | |||
brrt brb | 18:47 | ||
nwc10 | All tests successful. | 18:48 | |
Files=908, Tests=31963, 199 wallclock secs (14.95 usr 3.85 sys + 3477.11 cusr 173.58 csys = 3669.49 CPU) | |||
Result: PASS | |||
jnthn | That's a fast box :) | 18:51 | |
nwc10 | it's fastest when it has 24 things to do in parallel | 18:52 | |
jnthn | Oh :) | ||
"Core blimey" | |||
nwc10 | the future is multicore | ||
which, as my daughter likes to say "I know that already" | 18:53 | ||
18:54
brrt joined,
btyler joined
|
|||
nwc10 | re-running the setting build under valgrind is not the fastest | 18:55 | |
22076 nicholas 20 0 497m 423m 11m R 100.0 0.4 7:00.44 memcheck-amd64- | |||
19:02
Ven joined
|
|||
brrt | nqp testsuite interestingly enough burns in jit-moar-ops with /only/ iter | 19:02 | |
and without, it seems | 19:06 | ||
:-o only two weeks left or so | 19:12 | ||
FROGGS | PANIC | ||
brrt | and no support for extops yet | 19:17 | |
ok, no panic | 19:18 | ||
nwc10: you're sure the sanity test runs for you? | 19:19 | ||
nwc10 | All tests successful. | ||
Files=22, Tests=271, 3 wallclock secs ( 0.14 usr 0.03 sys + 35.62 cusr 2.23 csys = 38.02 CPU) | |||
Result: PASS | |||
yes, for me | |||
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 | ||
nwc10 | no, I don't know why I get lucky | 19:22 | |
Stage parse : 2062.728 | 19:25 | ||
OK, so progress | |||
so, expect about 240 seconds for stage optimize and 800 for mast | 19:27 | ||
Stage optimize : 227.126 | |||
OK, 800 more before it finishes | |||
brrt | ok, moar-jit proper also runs testsuite fine | 19:31 | |
(for me) | |||
nwc10 | 22076 nicholas 20 0 1414m 1.3g 11m R 99.7 1.4 47:09.09 memcheck-amd64- | 19:35 | |
still chugging. probably 5 more minutes | 19:36 | ||
22076 nicholas 20 0 1545m 1.4g 11m R 99.6 1.5 52:01.54 memcheck-amd64- | 19:40 | ||
and done | |||
so, yes, I can build the setting with the JIT under valgrind. But it takes a while | 19:41 | ||
==22076== in use at exit: 808,365,911 bytes in 2,627,380 blocks | |||
==22076== total heap usage: 21,434,309 allocs, 18,806,929 frees, 12,397,083,759 bytes allocated | |||
jnthn | So allocation... | 19:43 | |
nwc10 | "so allocation, very churn, sigh" ? | ||
jnthn | yeah | ||
Though I know one source I can elimiante easy enough. | |||
nwc10 | exterminate! extermiate! | ||
timotimo | i'd be interested to know where that is | 19:44 | |
we could perhaps just keep blocks used for spesh around | |||
no need to free the memory if we end up speshing something else a few miliseconds later ... | |||
jnthn | I don't think spesh is the big cause | 19:45 | |
I was more thinking the NFA | |||
timotimo | oh | 19:46 | |
right, they have to allocate, too | |||
jnthn | Yeah | 19:47 | |
But a given thread can only be evaluating one NFA at a time | |||
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 | ||
nwc10 | please be keeping an option to disable this, so that we don't do a heartblead | ||
timotimo | hmm, nfas will only leak data very indirectly | ||
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 | ||
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 | ||
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:50 | |
timotimo | btw, there's a gcc attribute for "this function is malloc-like" | 19:55 | |
19:57
colomon joined
|
|||
nwc10 | JIT ASAN spectest PASS. | 20:04 | |
now, back to the thing I was actally trying, which caused the bug hunt - optimised JIT build | 20:05 | ||
oooh, t/spec/S32-io/IO-Socket-Async.rakudo.moar failed for me on the re-run | 20:10 | ||
not ok 4 - Echo server | |||
nwc10 asks everyone to imagine the blank line here | |||
# Failed test 'Echo server' | |||
# at lib/Test.pm line 75 | |||
FROGGS | master also does | ||
nwc10 | it flaps | ||
but it rarely fails on a re-run | 20:11 | ||
FROGGS | you were lucky :o) | ||
nwc10 | anway, optimised JIT build passes | 20:13 | |
flussence goes file a proper bug report for this thing that's been bugging me | 20:22 | ||
hoelzro | flussence: what's that? | ||
flussence | since moar f23408b0, one of my modules dies after *exactly* 17/50 tests with the error @ src/gc/collect.c l421 | 20:23 | |
hoelzro | flussence: any useful output from the test? | 20:24 | |
like a segfault or something? | |||
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. | ||
...aaaaand it works in current rakudo head... oh well. | 20:26 | ||
jnthn | Hm | 20:27 | |
timotimo | d'oh | 20:28 | |
hoelzro | ok, different from my error | 20:31 | |
20:31
brrt joined
|
|||
hoelzro | which has been really hard to figure out | 20:31 | |
flussence | hm, I might've been using a stale install and it may not actually be fixed... one sec | 20:37 | |
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:39 | |
timotimo | that sounds good | 20:42 | |
so, did we figure out that iter is not to blame for our hanging problems? | |||
brrt | good news btw | 20:45 | |
well, it is to 'blame' somehow, but not in the way you'd typically think of it | |||
it's probably not broken but it allows brokennes, is what i mean | |||
anyway, good news again, i've singled out a failing spectest that fails with iter (but not without) | 20:46 | ||
timotimo | great! | ||
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:51 | |
I guess as long as it works well enough I can get on with doing stuff, so that's good. :) | 20:52 | ||
timotimo | brrt: when that bug is found and fixed, what's next on your roadmap? :) | 20:56 | |
brrt | uh... | ||
well.... | |||
:-) | |||
timotimo | sp_findmeth seems to be at the top of the bail list by far | ||
brrt | extops | ||
timotimo | mhm | ||
brrt | yes, that's a big one | ||
ok, sp_findmeth before that | |||
:-) | 20:57 | ||
timotimo | do you think lt/gt/eq/ne _n and not_i would be quickly doable, too? :3 | ||
jnthn | I hate to throw this one in, but jumptable will also be rather critical-path | 20:58 | |
timotimo | moarvm has jumptables? | ||
jnthn | Sure | ||
Used in every single regex/rule/token. :) | |||
timotimo | ah, is that for the nfa? | 20:59 | |
like, the result of the nfa gives us the index into a jumptable? | |||
jnthn | No | ||
Well | |||
Yes for alts | |||
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? | ||
jnthn | But more generally it's used for the backtrack stack | ||
timotimo | ah, good | ||
jnthn | Well, it's a throwy operation | ||
In other news, I'll have Fri/Sat/Sun for Perl 6 things. :) | 21:00 | ||
timotimo | \o/ | ||
getattr_o seems to be hot, too. i can probably implement that esaily-ish | 21:02 | ||
brrt | yes, num comparisons are conceptually simple | 21:03 | |
\o/ | |||
although i have fri/sat/sun for social things, but i'll try to be there | 21:04 | ||
well... how hard is jumptable, really? |
|