Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2014-07-20

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

All times shown according to UTC.

Time Nick Message
01:00 jnap joined #moarvm
01:20 FROGGS_ joined #moarvm
01:59 vendethiel joined #moarvm
07:39 brrt joined #moarvm
07:42 brrt it's possible a decont is missing, yes, but that would imply a spesh bug rather than a jit bug
07:45 FROGGS_ I don't believe in a GC bug btw
07:46 brrt me neither, anymore
07:47 brrt fwiw, i never believed that is was a GC bug per se, just that it could be a bug in how i'd hit write barriers
08:42 ren1us it seems like moar is allocating more memory as it needs it, which is fine, but does it (or rather, should it) release that memory back to the system as soon as it no longer needs so much?
08:43 brrt i'm not very sure about that, that'd typically need a page-based allocator, and i don't think that's what moarvm does
08:43 brrt i.e. i /think/ it leans on malloc
08:45 ren1us i've been trying to golf down what i believed to be a memory leak, and i just notice that memory never goes down, even if my high memory things fall out of scope
08:45 brrt that's basically how malloc works (in my memory, don't know it exactly)
08:45 ren1us then again i see no reason why it should be getting to over a gig of memory in the first place.  i blame 'is copy'
08:51 lizmat joined #moarvm
08:53 woolfy joined #moarvm
09:14 dalek MoarVM/moar-jit: c97ca8b | (Bart Wiegmans)++ | src/jit/ (4 files):
09:14 dalek MoarVM/moar-jit: Add a few ops
09:14 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/c97ca8bc6b
09:14 dalek MoarVM/moar-jit: 47f6848 | (Bart Wiegmans)++ | src/ (4 files):
09:14 dalek MoarVM/moar-jit: Add boxing operators
09:14 dalek MoarVM/moar-jit:
09:14 dalek MoarVM/moar-jit: For simplicity, this means I moved the conditional initialization
09:14 dalek MoarVM/moar-jit: of a container to a function in coerce.c. This should make the
09:14 dalek MoarVM/moar-jit: non-jitted times somewhat slower, however I feel that'd be an
09:14 dalek MoarVM/moar-jit: acceptable compromise.
09:14 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/47f6848e78
09:46 dalek MoarVM/moar-jit: 60275ae | (Bart Wiegmans)++ | src/ (6 files):
09:46 dalek MoarVM/moar-jit: Added istrue (is invokish) and isnull_s
09:46 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/60275ae57e
09:47 brrt yay, heap corruption detected
09:47 brrt seems like we're getting somewhere
09:48 FROGGS_ \o/
09:48 brrt .. or not
09:49 brrt still happens with MVM_JIT_DISABLE=1
09:49 brrt :'-(
09:50 brrt speshbug
09:50 brrt great
09:50 FROGGS_ yeah
09:52 brrt not even a spesh bug
09:52 brrt just a bug
09:54 brrt *ugh*
09:54 * brrt will check it out after lunch
09:54 brrt left #moarvm
10:32 brrt joined #moarvm
10:33 brrt ok, it's my bug in the wrapped boxing operators
10:33 FROGGS_ ohh, that sounds like progress!
10:36 brrt it's progress, but not in the same bux
10:36 brrt bug
10:37 FROGGS_ but still, progress :o)
10:37 brrt :-)
10:59 brrt ....
11:00 brrt for some reason that NOBODY WANTS TO KNOW ABOUT, boxing strings is just ... illegal
11:01 brrt that is to say, it's illegal if it's done in a function, and it's not illegal if it is done within the interpreter runloop
11:01 brrt wtf
11:06 brrt wtf wtf wtf wtf
11:07 brrt nqp_nfa_run... where's that
11:07 brrt and, is it new?
11:09 brrt why.... is any of this broken
11:09 brrt it just doesn't make sense
11:09 brrt it's a heap corruption, that's for sure
11:11 timotimo nfa_run is what handles the regex stuff that the NFA generator builds
11:17 brrt it's not that... which is broken
11:17 brrt what's broken is somehow memory is corrupted
11:17 brrt and i'm clueless as to why
11:17 timotimo yikes! :(
11:29 dalek MoarVM/moar-jit: d1b271a | (Bart Wiegmans)++ | src/ (4 files):
11:29 dalek MoarVM/moar-jit: MVM_box_str causes heap corruption, no idea why
11:29 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/d1b271aafd
11:34 FROGGS_ It think the value in here should have been MVMROOTed before allocating: https://github.com/MoarVM/MoarVM/commit/47f6848e782f8d0ee135fe947894bc5c167d3b84#diff-a6d53c5ba49dcd1d4a11424f416f2eedR405
11:34 FROGGS_ (coerce.c line 405 on this page)
11:39 FROGGS_ and I don't think you need to MVMROOT box at all
11:49 brrt hmm
11:49 brrt ok, i'll see if that changes anything
11:49 FROGGS_ I bet it will
11:49 FROGGS_ I'm pretty sure that I am right *g*
11:49 brrt i very much hope so
11:50 brrt so you advise to a): remove the whole MVMRoot thing B): move allocating in MVMRoot?
11:51 brrt ok, i don't know what you mean, i'm sorry :-)
11:51 FROGGS_ you only need to MVMROOT the value for box_s, and then move the alloc within that MVMROOT
11:52 FROGGS_ so you protect the value while you are allocating
11:52 FROGGS_ and since the other boxing function have numeric values, no MVMROOT is needed
11:52 brrt o rly
11:52 brrt well
11:52 brrt let's do that then
11:53 FROGGS_ only in the code that calls these functions of course, in case a pointer is obtained that is still used after the call to box_*
11:54 brrt you're absolutely correct; i still don't get it
11:54 brrt why shouldn't the box be MVMROOT'ed
11:54 brrt (it fixes it :-))
11:54 FROGGS_ because as long as you use box, nothing allocates
11:55 FROGGS_ and therefor the GC is not running so the pointer box still points to the right thing
11:55 brrt may initialize not allocate?
11:56 FROGGS_ look at what it does
11:56 FROGGS_ usually it just sets values to previously allocated space
11:56 FROGGS_ otherwise it would be over complex
11:57 brrt you're quite right
11:57 FROGGS_ though note, this like creating an MVMString from a C string allocates too of course
11:57 FROGGS_ things like*
11:57 carlin joined #moarvm
11:57 * brrt still doesn't understand why moving it from the interpreter to the function caused the crash]
11:58 FROGGS_ where do you call that function?
12:00 brrt https://github.com/MoarVM/MoarVM/commit/47f6848e782f8d0ee135fe947894bc5c167d3b84#diff-bb3587478c6b68f62c75192b00b05f0fR2336 here
12:00 brrt in interp.c
12:07 dalek MoarVM/moar-jit: c879b64 | (Bart Wiegmans)++ | src/core/ (2 files):
12:07 dalek MoarVM/moar-jit: Fixed issue with box_i thanks to FROGGS++
12:07 dalek MoarVM/moar-jit: review: https://github.com/MoarVM/MoarVM/commit/c879b644a5
12:07 brrt well, thanks
12:07 brrt dunno why this helps, but thanks anyway :-)
12:10 brrt hmm maybe i do understand why it helps, but that means - it seems - that the code in interp.c was just Wrong
12:19 brrt so that... at least causes a SEGV when run in the JIT
12:19 brrt but it runs well without JIT
12:20 brrt bbiab
12:22 FROGGS_ hmmm, I really don't see the need for the MVMROOT in box_i in interp.c:2338 in moar/master...
12:25 jnap joined #moarvm
13:13 brrt joined #moarvm
13:14 brrt FROGGS_: it isn't actually necessary, it seems
14:00 FROGGS_ yeah, and the MVMROOT in box_s is indeed wrong... the GET_REG(cur_op, 2).s needs to be MVMROOTed
14:00 FROGGS_ I see other ops that do that
14:08 FROGGS_ .tell jnthn Is that a valid patch about rooting? https://gist.github.com/FROGGS/534f320aa548e12f75c4
14:13 zakharyas joined #moarvm
14:31 brrt joined #moarvm
15:58 brrt lgtm :-)
15:59 brrt basically, it'd be even better to merge it with the functions in moar-jit :-)
16:12 btyler joined #moarvm
17:41 brrt joined #moarvm
17:56 brrt hmm, how do i get a null value for a string?
17:56 FROGGS_ brrt: sure, this would also avoid a conflict in git...
17:57 FROGGS_ what do you mean by null value?
17:57 brrt as in, a null pointer string
17:57 brrt (strings may be null)
18:00 FROGGS_ hmmmm, I remember something...
18:00 FROGGS_ right, there is even an nqp::isnull_s op
18:01 FROGGS_ and there is a null_s op
18:03 brrt i've got it, thanks :-)
18:07 brrt ok, and how do i repeat a string?
18:11 FROGGS_ nqp-m: say(nqp::xx("foo", 3))
18:11 camelia nqp-moarvm: OUTPUT«Error while compiling op xx (source text: "nqp::xx(\"foo\", 3)"): No registered operation handler for 'xx'␤   at gen/moar/stage2/QAST.nqp:4789  (/home/p6eval/rakudo-inst-2/languages/nqp/lib/QAST.moarvm:as_mast:72)␤ from gen/moar/stage2/QAST.nqp:4111  (/home/p6…»
18:11 FROGGS_ nqp-m: say(nqp::x("foo", 3))
18:11 camelia nqp-moarvm: OUTPUT«foofoofoo␤»
18:11 FROGGS_ brrt: ^^
18:11 brrt aahaaaah
18:11 brrt :-)
18:22 FROGGS_ that's the speshbug I get in S02-magicals/args.t: postcircumfix:<{ }> binding not defined for type Hash
18:23 brrt huh
18:27 FROGGS_ a lot of test files fail that way btw
18:31 FROGGS_ ohh, Test::Util triggers it...
18:37 FROGGS_ ummm, it still fails that way, but Test::Util is empty now
18:37 FROGGS_ O.o
18:50 brrt is there any way i can find out (for a static frame) what file it came from?
18:50 brrt oh, the CompUnit
18:51 FROGGS_ I guess the backtrace printing function might be a good place to copy from
18:55 brrt well, it is, thanks :-)
18:56 FROGGS_ I sometimes just conditionally call it to dump out my current call chain
18:57 FROGGS_ and this is where my speshbug happens btw: https://github.com/rakudo/rakudo/blob/nom/src/core/CompUnitRepo/Local/File.pm#L62
19:05 zakharyas joined #moarvm
19:10 FROGGS_ spectest passes when I turn the binding to an assignment
19:10 FROGGS_ now, how do I track this thing down?
19:10 FROGGS_ it only fails in spectests :/
20:33 tgt joined #moarvm

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