Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-05-12

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

All times shown according to UTC.

Time Nick Message
01:00 btyler joined #moarvm
01:09 dalek MoarVM: 7e3f970 | jimmy++ | src/ (2 files):
01:09 dalek MoarVM: Use MVM_platform_unlink on Win32, which is more CJK-friendly
01:09 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/7e3f970d5d
01:10 FROGGS_ joined #moarvm
01:19 woosley joined #moarvm
01:51 TimToady joined #moarvm
01:52 nwc10 joined #moarvm
01:52 japhb_ joined #moarvm
01:52 lee_ joined #moarvm
02:03 daxim joined #moarvm
04:18 hoelzro joined #moarvm
06:42 FROGGS joined #moarvm
06:45 zakharyas joined #moarvm
08:24 nwc10 good UGT, *
08:28 FROGGS morning nwc10
08:28 FROGGS JimmyZ++ # I forgot about unlink :/
10:23 odc joined #moarvm
12:02 btyler joined #moarvm
12:06 zakharyas joined #moarvm
12:50 nwc10 jnthn: with that first i16 fix, NQP builds on PPC64, but Rakudo bombs out like this during the setting:
12:50 nwc10 Stage mbc        : At Frame 2027, Instruction 839, op 'getlexstatic_o' has invalid number (1) of operands; needs 2. at gen/moar/stage2/QAST.nqp:5082  (/home/nick/Sandpit/moar-g/languages/nqp/lib/QAST.moarvm:assemble_to_file:13)
12:51 nwc10 I don't know where to start looking for the cause. It still happens with MVM_SPESH_DISABLE=1
13:02 FROGGS I think it is good that it also happens when spesh is disabled
13:02 nwc10 it is and it isn't
13:02 nwc10 if it only happens with SPESH, I know where to start looking
13:04 FROGGS yeah, true :/
13:14 FROGGS hmm, we have duplicate code to do read_int32 and friends in bytecode.c and serialization.c
13:18 nwc10 I noticed this
13:19 nwc10 IIRC there's duplicate writing code too
13:19 FROGGS yes, and I'd need read_ref in bytecode.c, but it looks like pain to get it :o(
14:05 jnthn nwc10: That error comes from src/mast/compiler.c. It may be bogus (the data structure is fine) or it may be that the data structure is wrong (e.g. it really does only contain one operand)
14:11 dalek MoarVM: 024b994 | jimmy++ | src/spesh/optimize.c:
14:11 dalek MoarVM: Fixed MSVC build
14:11 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/024b994630
14:14 nwc10 jnthn: I'd located the source of the error, and checked that it wasn't getting confused by 64 bit values being truncated, but it wasn't, and that's where I got stuck
14:14 nwc10 I didn't try figuring out if the data structure is OK, and the C code is confused
14:19 jnap joined #moarvm
14:25 jnthn Well, it should have 2 args.
14:26 jnthn And thing is, asking how many it has is just an elems call which really should work out.
14:52 timotimo jnthn: got a suggestion what i could look at to figure out what exactly prevents get_i/get_s/get_n from being speshable?
14:53 timotimo more precisely: i know it won't do it because we don't know the type at spesh-time, but maybe there's a way to ensure that?
14:53 jnthn Well, the facts dump could be wroth a look
14:53 jnthn (that is now dumped after the CFG)
14:53 timotimo .o( like a global flag that tells us if there even is a second class with repr p6int/p6num/p6str)
14:56 FROGGS hmpf, I'd need write_ref in compiler.c also...
14:57 jnthn um...?
14:57 FROGGS jnthn: you know, I should attach the label's object to a handler, not its mem address, so all is safe in case it gets moved
14:58 FROGGS but I can't write the ref, nor read the ref because compiler.c/bytecode.c only has read/wrint_int* stuff
14:58 FROGGS write*
14:58 FROGGS serialization.c has what I'd need, and also duplicates of the read/write_int* functions
14:58 jnthn Uh yes, well I'm happy when the code stops people making architectural mess :P
14:59 jnthn They're decoupled for a reason.
14:59 FROGGS ahh, so we need three version of memcpy_endian()? :o)
15:00 jnthn No, I'm pretty sure if you want to call write_ref in compiler.c then soemthing is happening that I don't want.
15:00 JimmyZ FROGGS: I'm trying removing [read|write]_int[16|32], but blocked by x84 build problem
15:00 FROGGS jnthn: ahh
15:00 jnthn FROGGS: If you put the label statically in the handler, will it not make issues for recursion and the map situation?
15:01 FROGGS jnthn: I'm not putting the label in a handler in case it is about map
15:01 FROGGS putting in*
15:01 FROGGS err, no, was correct as I wrote it :o)
15:01 FROGGS (kinda)
15:02 FROGGS in case for map (aka nqp::handle) the handler is always run, and rethrows if we have the wrong label
15:03 FROGGS in case of while loops for example, we always have new handlers, so I attach the label to it
15:06 JimmyZ >moar.exe!shift(MVMThreadContext * tc, MVMSTable * st, MVMObject * root, void * data, MVMRegister * value, unsigned short kind) 行 55C moar.exe!MVM_interp_run(MVMThreadContext * tc, void (MVMThreadContext *, void *) * initial_invoke, void * invoke_data) 行 4053C moar.exe!MVM_vm_run_file(MVMInstance * instance, const char * filename) 行 165C moar.exe!main(int argc, char * * argv) 行 165C moar.exe!__tmainCRTStartup() 行 240C
15:06 FROGGS I mean, I can do the same for 'while' as we do for 'map', but that means that we run all handlers that are about labels, and rethrow in most/all cases
15:06 JimmyZ argh
15:07 JimmyZ jnthn: https://gist.github.com/zhuomingliang/02eb9635b46f62e3bb23
15:07 timotimo jnthn: maybe you have another idea for something i could try to spesh?
15:08 timotimo now that i kinda sorta know how it works :)
15:08 JimmyZ turns out it's easy to get debug info by using static build :P
15:11 JimmyZ looks target is null
15:11 JimmyZ *looks like
15:13 jnthn Will have a look later; decommute &
15:29 dalek MoarVM/cleanups: 98f54f7 | jimmy++ | src/6model/ (5 files):
15:29 dalek MoarVM/cleanups: Removed [read|write]_int[16|32] code from serialization
15:29 dalek MoarVM/cleanups: review: https://github.com/MoarVM/MoarVM/commit/98f54f70c0
15:33 JimmyZ jnthn: Would you mind I merge it?
15:35 rurban_ joined #moarvm
16:10 timotimo hm. maybe my set removal code is having problems with deopt?
16:13 timotimo since i think the code it emits seems right
16:13 timotimo it crashes right after visit_var gets specialized and the diff seems correct at least
16:32 timotimo https://gist.github.com/timo/49014d9c469d85ed7350  -  would this be wrong?
16:32 FROGGS joined #moarvm
16:33 timotimo see how the set + decont turns into one set
16:34 timotimo i don't even know if that's where it goes wrong, though
16:34 timotimo this is hard to debug :(
16:34 FROGGS jnthn: so, you want me to change exception handling so that blocks with labels always run their exception handlers?
16:35 FROGGS pro: we wouldn't need to find a way to write/read that label object, contra: we can't skip handlers like we skip when it is the wrong category
17:50 jnap joined #moarvm
17:59 nwc10 jnthn: for the annoying PPC64 "only 1", it does seem that the MVMArray genuinely has only 1 element
17:59 nwc10 (gdb) p body->slots.o[0]
17:59 nwc10 $11 = (MVMObject *) 0x33be02f0
17:59 nwc10 (gdb) p body->slots.o[1]
17:59 nwc10 $12 = (MVMObject *) 0x0
18:07 timo joined #moarvm
18:19 jnthn nwc10: What's body->elems?
18:20 nwc10 1
18:20 nwc10 says gdb
18:20 nwc10 and says the C logic
18:20 jnthn Yeah...
18:21 jnthn OK, so the thing was wrongly constructed...
18:21 jnthn wtf...
18:21 nwc10 so everything is consistent at the C level, it seems.
18:21 nwc10 yes, wtf
18:21 nwc10 I can give you two other patches that aren't wrong :-)
18:22 jnthn :)
18:22 * jnthn should probably cook dinner before looking at much else :)
18:22 nwc10 yes, go eat
18:23 jnthn I decommaught via the pub, which had a 7% IPA for me to try... :)
18:23 nwc10 they are cruel to you
18:24 timotimo jnthn: feel at all like hunting my set optimization problem?
18:24 timotimo the code merges cleanly onto latest matser (though locally i rebased it onto master)
18:27 brrt joined #moarvm
18:28 brrt \o #moarvm
18:31 brrt i think i've figured out how dynamic labels work in dasm
18:33 FROGGS hi brrt
18:39 brrt hi FROGGS
18:48 jnap joined #moarvm
19:05 timotimo panda explodes in sp_guardcontconc
19:05 timotimo when trying to compile Buialder.pm
19:06 timotimo it seems like the "check" object is null and we don't check for that
19:08 tadzik timotimo++ #tracking it down
19:16 timotimo when adding a null check, i get the same read past the end of the string heap thingie
19:26 jnthn o/ brrt
19:27 jnthn timotimo: It seems like there's some corruption earlier on than that, then...
19:28 jnthn What's the op before the sp_guardcontconc?
19:28 timotimo how do i know? :(
19:28 timotimo what's the function to print a stack trace again?
19:28 timotimo from inside gdb?
19:29 jnthn Well, could look back a bit in the bytecode stream from the current location
19:32 brrt hi jnthn :-)
19:33 jnthn timotimo: uhhh
19:33 jnthn +        else if (override_second_argument == OVERRIDE_WITH_32)
19:33 jnthn +            write_int16(ws->bytecode_seg, ws->bytecode_pos, MVM_OP_const_i64_32);
19:34 jnthn There we write_int16 where the op reads 32 bits, no?
19:34 jnthn oh, no, I misread...
19:34 jnthn duh
19:36 jnthn oh...
19:36 jnthn It's the ops that are wrong
19:36 jnthn OP(const_i64_16):
19:36 jnthn GET_REG(cur_op, 0).i64 = GET_I16(cur_op, 2);
19:36 jnthn cur_op += 4;
19:36 jnthn goto NEXT;
19:36 jnthn gah, wrong again :)
19:36 jnthn *sigh*
19:37 * jnthn is clearly a bit tired for this...
19:37 nwc10 go to bed?
19:37 jnthn Not quite tired enough for that :)
19:38 * brrt wonders how he is ever going to cope with moarvm dev speed
19:38 nwc10 jnthn: OK, patch the first is http://paste.scsys.co.uk/372051  :-)
19:38 nwc10 has no commit message. sorry
19:41 nwc10 jnthn: Patch the second is http://paste.scsys.co.uk/372053
19:47 [Coke] moar doesn't like being run under a ulimit... got a segfault in the daily roast because of it.
19:47 [Coke] S17-promise/allof.t
19:48 [Coke] bumping up the required memory for rakudo.moar...
19:51 [Coke] that clears 2 failures in roast; there are 30 other failures that are happening in S17-*
19:51 [Coke] https://github.com/coke/perl6-roast-data/blob/master/log/rakudo.moar_summary.out#L2232
19:54 jnthn nwc10: Thanks, they look good. Will apply.
20:19 dalek MoarVM: 80cc8e6 | nicholas++ | src/spesh/facts.c:
20:19 dalek MoarVM: Correct size of read from spesh log.
20:19 dalek MoarVM:
20:19 dalek MoarVM: Should read a 16-bit integer from the operand, not a 64-bit one.
20:19 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/80cc8e6398
20:19 dalek MoarVM: 1f22a12 | jnthn++ | src/spesh/graph.c:
20:19 dalek MoarVM: Ensure spesh_alloc aligns on platforms needing it.
20:19 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1f22a12a52
20:19 jnthn d'oh, forgot to --author the second one :(
20:19 jnthn nwc10++, anyways
20:30 nwc10 don't worry
20:34 nwc10 the alluded-to other thing for ARM is that P6opaque.c is fragile still. I noticed that with the first fix to get ARM working.
20:34 nwc10 one part has
20:34 nwc10 MVMuint32 cur_offset = sizeof(MVMP6opaque);
20:35 nwc10 another part has
20:35 nwc10 cur_alloc_addr   = sizeof(MVMP6opaqueBody);
20:35 nwc10 and at the time ("last week"), sizeof(MVMP6opaque) was a multiple of 8
20:35 brrt jnthn, i was wondering (wrt jit-ing)
20:35 nwc10 or at least, sizeof(MVMP6opaque) % 8 == sizeof(MVMP6opaqueBody) % 8
20:36 nwc10 and I hoped that that didn't matter
20:36 nwc10 but it does
20:36 brrt you perhaps know that as far as dynasm is concerned, it just returns a void* to some executable memory?
20:36 nwc10 because now you've fixed the O(n**2), the object header is larger, and the P6opaque stuff breaks alignment again
20:36 brrt anyway, you call into that as if it were a c pointer
20:36 nwc10 so I can get ARM to build like this:
20:36 nwc10 } sc_forward_u;
20:36 nwc10 +  void *hack;
20:37 nwc10 maybe putting that in MVMCollectable is why it's swapping like a swappy thing
20:37 nwc10 and it should have been in MVMP6opaque
20:37 brrt i /think/ it might be a good idea to pass something of (threadcontext, register base, etc) into that compiled code
20:38 jnthn brrt: Yes, and perhaps a "jump to" also.
20:38 nwc10 anyway, that's not the real fix. I think that the real fix is me understanding it better, and ideally needs a whiteboard
20:38 brrt that would change nothing except that the jit-ed code gets (e.g.) the pointer to MVMThreadContext always in the RDI argument
20:38 nwc10 but failing that, I'll try to have a think
20:38 brrt registe
20:38 brrt jump to? as in, continuation address?
20:38 nwc10 but I think that the body always needs to have consistent alignment, and be assumed to start at offset 0
20:42 brrt hmm
20:42 nwc10 jnthn: I did this (patch) as a the pre-cursor to trying somethign else, and I *think* that it showed a nearly 1% speedup in setting time compilation: http://paste.scsys.co.uk/372090
20:42 nwc10 but I'm not sure that I trust that
20:42 nwc10 "nearly 1%" is too close to noise
20:42 nwc10 (That was nearly 1%, as measured by dumbbench with 20 runs)
20:43 jnthn brrt: Well, like we were running JITted code, and then we had to fall back to the interpreter for something we call 'cus the callee isn't JITted yet, and when we return we need to re-enter the JITted code at a certain point
20:43 jnthn brrt: Or continuations, yes.
20:44 jnthn brrt: Or on-stack replacement.
20:44 brrt me is thinking
20:45 brrt hmm
20:46 brrt i think i see what you mean
20:46 brrt we could use a stack that held in-jit-continuations
20:47 brrt i.e. we'd pass a jit-ed function a pointer to MVMThreadContext and a pointer to the top of our stack
20:47 brrt no, that won't work
20:47 brrt :-(
20:49 brrt ok, i think the basic question is this: how to compile a sequence of: native, interpreted, native (using the interpreted result)
20:50 jnthn brrt: fwiw, I think at least initially we really should have the JIT stick close to the frame structure that we use when interpreting (more)
20:50 jnthn deopt is a really important part of making this stuff all work out, and this does simplify it a bit.
20:51 brrt meaning all variables in reg_base?
20:51 jnthn Yes.
20:51 brrt that is not so different from stack allocation
20:51 brrt :-)
20:51 jnthn Then *after* that works, we can start looking at points between which deopt or other falling out of JIT can never happen.
20:51 jnthn It's also a GC thing.
20:52 brrt ... yes
20:52 brrt hmm
20:52 jnthn As in, if we trigger GC and there's a pointer sat in a CPU register...well...ouch :)
20:52 brrt and here i was with great hopes for register allocation
20:52 brrt i see what you mean
20:52 jnthn I'm not saying we shoudln't do that eventually
20:53 jnthn I'm just saying I can see a bunch of things that make it rather hard.
20:53 brrt are gc runs concurrent? or - how are they triggered?
20:53 jnthn That is, we should probably walk before we try running.
20:53 jnthn No, not concurrent. Triggered when we allocate.
20:53 brrt ok
20:54 brrt well.. long story short, when allocationg, i should call, when calling, registers must be saved
20:54 jnthn About interp -> native, I think in that case we could just point the interp at a "call into the JITted code" magical op
20:54 jnthn For native -> interp, I pondered that invocation always ends up calling something from the JIT that returns a memory address of JITted code to jump to in the event having it, and a NULL to indicate "no, not JITted, just return to the interp"
20:55 jnthn And since the interp is where we called into the JIT from, just having the JITted code to the equivalent to a C "return" at that point will be sufficient to find ourselves back in the interpreter.
20:55 jnthn That is to say, JITted code always runs a frame deeper than the interpreter.
20:55 brrt huh, jitting code without a 'ret' instruction is a way to crash real fast ;-)
20:56 brrt agreed
20:56 jnthn Yes, but I mean more like
20:56 jnthn oh, I think you got it :)
20:56 brrt not entirely though
20:56 jnthn Oh :)
20:56 jnthn timotimo: I reproduced that SEGV in sp_garudcontconc locally
20:57 brrt suppose we have code: $foo++; $bar *= 2; # nicely jittable
20:57 jnthn Depending on the types of $foo and $bar... :)
20:57 brrt and then: my $quix := multi_call($foo, $bar); # unknown at spesh time?
20:57 brrt and we then want to use the value of $quix in jit-ed code
20:58 brrt how do we proceed then?
20:58 brrt i suppose that since we're the ones generating the jitted code we might as well generate the interpreted code along with it
21:00 brrt as in - we'd generate a sequence (on moarvm level) of: enterjit $first_portion; call $multi_call, $foo, $bar; enterjit $second_portion
21:00 jnthn Note that something like multi-call is actually a sequence of instructions at VM level
21:01 brrt i would suppose so, but you get the point :-)
21:02 brrt i think i'll have to defer an actual strategy for later
21:02 jnthn Sure, what I'm (badly, 'cus I'm tired) trying to get accross is that I'm expecting that "make a VM-level call" will - at least initially - probably want to do something like invoke does today.
21:02 brrt continuation pointers seem like a good idea but i'm wondering what problem they solve that can't be solved by clever codegen
21:02 brrt seems good to me :-)
21:03 jnthn Maybe it'd help if I wrote up what I've pondered so far on how the JITted/interpreted stuff could hang together.
21:03 jnthn Which you don't have to take as an absolute plan, of course. :)
21:03 brrt that would  help
21:03 jnthn But it may make a few things clearer.
21:04 brrt i won't :-P but i could really use all forms of ideas
21:04 jnthn OK. I can't sensibly do it tonight; I slept badly last night (like, 4 hours) and taught all day today :/
21:05 brrt i'm thinking about a half-baked blog post myself :-)
21:07 * brrt is off for sleep
21:07 brrt left #moarvm
23:11 btyler joined #moarvm

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