Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-05-12

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

All times shown according to UTC.

Time Nick Message
00:47 timotimo joined #moarvm
01:39 vendethiel joined #moarvm
01:55 diakopter CACKLE "learn the c"
01:56 zakharyas joined #moarvm
01:56 konobi arnsholt: portableumem is really useful for memory testing
01:57 konobi and for use during production!
02:04 timotimo can you tell more about why it's cool to have?
02:54 konobi timotimo: https://blogs.oracle.com/dlutz/entry/memory_leak_detection_with_libumem
03:15 timotimo for some reason, the version of the variable is incremented by one after the guardconc happens ... and that makes removing the guard problematic if i want to also reduce the usages
03:15 timotimo because then the writer of that variable/version gets exploded, but the readers of the variable/version+1 don't get their variable set to something sensible and *bam*
03:16 timotimo huh, or am i wrong about this ...
03:17 timotimo could also be we've got a "known concrete" flag that's wrong
03:20 timotimo need to sleep before i can properly figure out what's going on
03:23 timotimo OH!
03:24 timotimo of course it's known concrete when we have a guard guarding it
03:24 timotimo but that's "known from a log guard"
03:24 timotimo damn, this'd require some extra cleverness
05:56 domidumont joined #moarvm
05:58 vendethiel- joined #moarvm
06:00 domidumont joined #moarvm
06:43 pyrimidine joined #moarvm
06:52 domidumont joined #moarvm
07:42 brrt joined #moarvm
09:17 nwc10 jnthn: ASAN still tolerates you(r branch)
09:17 nwc10 also, setting built under valgrind
09:22 jnthn Nice :)
10:37 brrt joined #moarvm
12:19 MadcapJake joined #moarvm
12:50 brrt joined #moarvm
12:51 brrt hey, #moarvm
12:51 brrt any idea why in reframe-jit, i get a SEGV in nativecall on getlex
12:51 brrt actually,waitaminute
12:59 brrt who assign tc->cur_frame
13:02 jnthn brrt: Well, various things can
13:02 brrt it's fairly evident we've jumped up in the frame
13:02 jnthn brrt: Anything that invokes, and anything that causes stack -> heap promotion
13:03 jnthn Where you don't really move frame, but the frame moves.
13:03 brrt basically, my cur_frame points to a frame that was generated 200 alloc_frames ago
13:03 brrt however, and here is the point, tc->current_frame_nr does /not/
13:04 brrt i've taken some care to make sure that tc->current_frame_nr is updated on entry (MVM_frame_invoke, iirc) and in exceptions (unwind_to, iirc)
13:05 brrt actually, that's in remove_one_frame
13:19 brrt evidently, we're somehow in the NativeCall tests jumping up the stack and not assigning the current_frame_nr
13:20 brrt and that probably causes the invokish to fail...
13:20 brrt continuations....
13:21 jnthn brrt: NativeCall does funky things if you've got callbacks
13:21 brrt how does it do them
13:24 jnthn Well, it needs a "nested" interpreter
13:24 jnthn Look in nativecall_dyncall.c and search for backup_
13:24 jnthn But that'd only explain bustage in the callback tests, not all of nativecall tests
13:24 brrt uhuh
13:25 brrt i'm looking at assignments to tc->cur_frame... the cur_frame is set in uninline
13:25 jnthn Continuations are used all over the place
13:25 jnthn Yeah, but after an uninline you'd have fallen out of the JIT?
13:25 jnthn 'cus that's part of deopt
13:31 brrt ehm, yeah....
13:31 brrt true
13:31 brrt still, it ought to be assigned there
13:31 brrt (i see the nativecall thing)
13:41 * brrt wonders why he didn't think of ack 'tc->cur_frames+=' before
13:47 dalek MoarVM/reframe-jit: 13666ec | brrt++ | src/core/ (4 files):
13:47 dalek MoarVM/reframe-jit: Make frames identifiable using a sequence number
13:47 dalek MoarVM/reframe-jit:
13:47 dalek MoarVM/reframe-jit: Because frames can now be garbage-collected, they can be moved, and
13:47 dalek MoarVM/reframe-jit: the identity check used in the JIT will no longer work. Thus, we'd
13:47 brrt sorry dalek...
13:47 dalek joined #moarvm
13:49 dalek MoarVM/reframe-jit: 246c941 | brrt++ | src/ (5 files):
13:49 dalek MoarVM/reframe-jit: Update the tc current_frame_nr in all cases
13:49 dalek MoarVM/reframe-jit:
13:49 dalek MoarVM/reframe-jit: There were a number of cases which I missed, causing 'weird'
13:49 dalek MoarVM/reframe-jit: errors. This makes rakudo pass sanity checks.
13:49 dalek MoarVM/reframe-jit: review: https://github.com/MoarVM/MoarVM/commit/246c9416dc
13:49 dalek MoarVM/reframe-jit: 529e061 | brrt++ | src/jit/emit_x64.dasc:
13:49 dalek MoarVM/reframe-jit: Add DynASM definition for our frame_nr
13:49 dalek MoarVM/reframe-jit: review: https://github.com/MoarVM/MoarVM/commit/529e06123c
13:50 brrt t/spec/S17-supply/syntax.t .................................... Failed 9/60 subtests :-(
13:51 brrt otherwise cleanish
13:51 brrt so far
13:54 vendethiel joined #moarvm
13:57 jnthn brrt: That may not be your fault
13:57 brrt let's hope :-)
13:58 brrt i've sent a PR
13:58 brrt for reframe-jit on top of reframe
14:34 * jnthn will look at the PR shortly :)
15:04 [Coke] jnthn: are you doing the moar release this month? Should we get someone else to do one of them?
15:14 jnthn [Coke]: I don't mind doing it but it'd be good to scale it :)
15:18 [Coke] ok. I hoelzro++ is doing the rakudo/nqp releases this month.
16:26 diakopter I wish dalek could report pull requests
16:26 diakopter well, not to mention issues as well
16:36 domidumont joined #moarvm
17:53 [Coke] diakopter: https://developer.github.com/v3/activity/events/types/#pullrequestevent
17:54 [Coke] seems like we could sub to those too. (might need dalek code change to lsiten)
18:08 dalek MoarVM: e7031d0 | niner++ | src/core/compunit.c:
18:08 dalek MoarVM: Fix Windows build broken by pointer arithmetic on void*
18:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e7031d0cba
18:08 dalek MoarVM: b441c94 | jnthn++ | src/core/compunit.c:
18:08 dalek MoarVM: Merge pull request #366 from niner/master
18:08 dalek MoarVM:
18:08 dalek MoarVM: Fix Windows build broken by pointer arithmetic on void*
18:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b441c949cb
18:19 dalek MoarVM: 3198112 | tomboy64++ | / (3 files):
18:19 dalek MoarVM: update the build system to autodetect system provided libs
18:19 dalek MoarVM:
18:19 dalek MoarVM: - uses raw pkg-config to determine include directories
18:19 dalek MoarVM: - failover to the old behaviour when errors occur
18:19 dalek MoarVM: - fix DT_RPATH when @libdir@ has no / prepended
18:19 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3198112031
18:19 dalek MoarVM: 126cb2a | tomboy64++ | Configure.pl:
18:19 dalek MoarVM: small updates to the patch
18:19 dalek MoarVM:
18:19 dalek MoarVM: - test for existence of $config{pkgconfig} before attempting to run it
18:19 dalek MoarVM: - adding \n to error messages
18:19 dalek MoarVM: - re-adding entry to create include dir for libtommath
18:19 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/126cb2a8ca
18:19 timotimo ah, cool, the pkgconfig stuff landed?
18:20 brrt joined #moarvm
18:23 timotimo how expensive actually are guards that are 100% superfluous?
18:24 nine infinite
18:25 jnthn timotimo: Yeah, I gave it the promised "does this bust Windows" test, noted it didn't, and merged it
18:25 timotimo in that case i can just remove a single guard that i can prove will never fail and moar will be infinitely better
18:30 travis-ci joined #moarvm
18:30 travis-ci MoarVM build errored. Jonathan Worthington 'Merge pull request #366 from niner/master
18:30 travis-ci https://travis-ci.org/MoarVM/MoarVM/builds/129807202 https://github.com/MoarVM/MoarVM/compare/8ce7e8a39e5e...b441c949cb11
18:30 travis-ci left #moarvm
18:30 * jnthn is giving reframe-jit a spin
18:31 timotimo W: Failed to fetch http://downloads-distro.mongodb.org/repo/debian-sysvinit/dists/dist/10gen/i18n/Translation-en_US  Unable to connect to downloads-distro.mongodb.org:http:
18:31 timotimo noooooo, not mongodb %)
18:31 jnthn bah
18:32 timotimo so our travis builds are failing because mongodb's repositories are down, eh? fantastic
18:32 jnthn It'll work eventually :D
18:32 timotimo maybe "apt-get update" isn't the right thing to have in our travis configuration
18:32 jnthn Immediate working is overrated
18:32 timotimo i *guess* the travis images they're spinning up for testing are updated "in the background" every now and then
18:39 jnthn reframe-jit looking good so far
18:39 timotimo jnthn: do you have an intuition if it's correct that going through a guard will increment the version of a register? or is it just that there was something there in the past that actually sensibly caused the increment and it just got kicked out in the mean time?
18:39 jnthn (up to S05)
18:39 brrt \o/
18:39 jnthn timotimo: No, I highly doubt it
18:39 jnthn Guards are inserted after SSA is formed
18:39 jnthn And they only read
18:40 jnthn Usage across a guard bumps the number of uses though
18:40 timotimo yup
18:40 timotimo the more i consider "rebuild between successive passes", the more i gravitate towards "just do a complete, full rebuild, rediscover all facts, re-number all register versions" %)
18:41 timotimo that speaks volumes about how confident i am about making spesh transformations that keep up a lot of useful invariants
18:49 dalek MoarVM/reframe: 13666ec | brrt++ | src/core/ (4 files):
18:49 dalek MoarVM/reframe: Make frames identifiable using a sequence number
18:49 dalek MoarVM/reframe:
18:49 dalek MoarVM/reframe: Because frames can now be garbage-collected, they can be moved, and
18:49 dalek MoarVM/reframe: the identity check used in the JIT will no longer work. Thus, we'd
18:50 jnthn brrt: Merged; there's one comment on it from vendethiel that I'm not smart enough to understand right now, and I spotted a typo... :)
18:50 dalek joined #moarvm
18:50 jnthn (Which is second comment)
18:50 jnthn Feel free to look at those :)
18:50 brrt oh, will look
18:50 jnthn (If you do any changes, just do them direct in reframe :))
18:52 jnthn Otherwise, I think I'm good to merge reframe to master :)
18:52 vendethiel jnthn: uh, I don't remember being "smart" at all recently. or even a long time ago
18:53 jnthn vendethiel: I'm generally exhausted this week, so if I don't understand something I'm defaulting to assuming it's me not having the brane for it. :-)
18:54 brrt vendethiel: i think your comment is about the sizeof (MVMReturnType)
18:54 vendethiel yes
18:54 brrt hmmm
18:55 brrt well, i'd rather have it at compile time , but i'm not sure that's possible
18:55 vendethiel why not?
18:55 brrt how?
18:55 jnthn sizeof(MVMReturnType) is a compile-time constant.
18:56 brrt #if sizeof(MVMReturnType) != 4 - not a preprocesor constant surely?
18:56 vendethiel that's allowed
18:56 vendethiel sizeof() is compile-time, since the struct is compile-time
18:56 jnthn But yeah, now I see what the commnet was about. But I think it'll get constant folded
18:56 vendethiel well, not #if, because it's the CPP
18:56 jnthn Seems highly likely
18:57 vendethiel jnthn: thought so as well, but just making sure :)
18:57 jnthn I can imagine something like Rakudo not nailing such a thing
18:57 jnthn But C compilers have had some decades to get smart enough :)
18:57 vendethiel well, yeah
18:57 vendethiel but having a check here seemed... weird
18:58 brrt i agree
18:58 brrt it's an old check though
18:59 jnthn Can't cash that...
18:59 jnthn Time for a walk, I think :)
18:59 jnthn bbl
19:09 timotimo wait what, reframe goes into master, master goes into this month's release?
19:13 nwc10 yes, if it's merged, it ends up in the release. So the question is "is it good enough to be in the release (or fixable by then)?"
19:17 jnthn nwc10: I think "yes", in that the more risky of the two parts has been stress-tested to the point that we've fixed bugs that were in master too
19:18 jnthn And we've a week to understand any fallout.
19:19 timotimo well, i've checked it out locally in any case, so ... :)
19:19 timotimo i'll be trying it out
19:20 jnthn Anyone against pulling the trigger?
19:20 timotimo wether or not it'll end up in this month's release
19:22 * brrt afk for now
19:28 nwc10 jnthn: ASAN is somewhere in th emiddle of a spectest
19:29 nwc10 I think about 5 more minutes to go
19:35 dalek joined #moarvm
19:35 nwc10 jnthn: flapping assertion abort in t/spec/S17-supply/syntax.t
19:35 nwc10 otherwise perfect
19:36 nwc10 http://paste.scsys.co.uk/513650
19:36 nwc10 and not a new flapper
19:37 timotimo \o/
19:37 timotimo it's about a mutex escaping the wrath of our code-gen again
19:38 nwc10 (and double checked, JIT was enabled)
19:40 nwc10 that was MoarVM origin/reframe, nqp at 73befe524cde66b663e5c339e5304b973a8c71dc and rakudo at origin/moar/reframe
19:40 nwc10 I see from dalek's temporary departure that rakudo has moved on a bit
19:41 jnthn :)
19:41 timotimo right, that seems to be nine's merge for load bytecode api work
19:41 jnthn Hm, maybe I should wait until tomorrow unless there's a little dust to settle from that :)
19:41 nine Yes, we now load modules without having to lock the files :)
19:41 jnthn uh, in case, not unless :)
19:41 jnthn nine++ \o/
19:42 nwc10 I think wiser to wait until tomorrow morning
19:42 jnthn Aye
19:42 jnthn OK, will do it then :)
19:42 jnthn Thanks for testing
19:42 nine aaah...and I was so curious about the performance impact of reframe
19:42 nwc10 I've merged things locally - will re-run the ASAN build
19:43 jnthn nine: So significant difference for most programs yet, but this is mostly the big scary chance before a bunch of smaller optimization-focused changes.
19:43 jnthn um, *no significant
19:43 jnthn Parallel programs are likely to get a more immediate win
19:44 jnthn And things that keep thousands and thousands of closures around also.
19:45 nine Actually it may be wise to not merge right before going to bed anyway. I thought I had already learned that :)
19:53 timotimo oh, reframe doesn't have the new bytecode op yet
20:03 timotimo i don't remember what code i recently discovered was crashy with reframe and which was heavily slowed down by competing to allocate frames
20:05 timotimo ah, the logic puzzle with the prime numbers in the square
20:07 timotimo it seems like there was another, different one, too
20:07 timotimo ah, on my desktop!
20:17 nwc10 ASAN happy merged MoarVM and merged Rakudo and nqp master
20:18 timotimo oh, we still go through the FSA?
20:26 jnthn timotimo: Not for frames themselves, for env and work, yes
20:26 nwc10 Ooh, I can disable the FSA and try ASAN again...
20:26 jnthn timotimo: env looks like it'll be a fairly easy move to the stack
20:30 timotimo cool
21:13 * timotimo has already forgotten what the difference between env and work is; is env about things like autoviv and such?
21:13 timotimo oh, probably lexicals vs locals
21:16 jnthn yeah, env is the lexical *env*ironment
21:16 jnthn work is working space, and the only time it ever outlasts a frame being on the stack is with continuations.
21:17 mst continuations overcomplicate everything
21:17 mst (I <3 continuations, but still)
21:17 jnthn That's probably why Perl 6 doesn't actually expose them directly :)
21:18 jnthn (We have 'em for gather/take, and - in 6.d - await)
21:21 mst ah, so your continuations are only resume-once?
21:21 jnthn Yes
21:21 jnthn Which simplifies things.
21:21 mst the one use I've put continuations to that wasn't basically 'await' was ... the moral equivalent of the 'amb' operator from original lisp
21:22 mst but that was because I was implementing a prolog derivative in an fexpr (i.e. operative) microlisp written in perl
21:22 jnthn Fun!
21:23 mst I'm now doing something more like minikanren's stream composition approach, which removes the need for multiple-resume
21:23 mst well, it does and it doesn't, but it pushes the problems into different corners of the design that cause me less pain
21:28 timotimo do we actually skip allocating a lexical environment for frames that don't have lexicals?
21:30 jnthn yes
21:30 timotimo nice, so when work moves away from FSA, we might have a bunch of frames that don't contend on the FSA at all
21:30 jnthn Should do
21:30 jnthn Well, ->env will not need it either
21:30 timotimo it's still a bit hard to come by those in complex code, however
21:31 jnthn env is actually a far easier more than work
21:31 jnthn *move
21:31 timotimo oh! env is the one that's easier to move, not work
21:31 timotimo i confused the two, sorry
21:31 jnthn Yup :)
21:31 timotimo so we should be optimizing our code to use only lexicals, no locals at all
21:31 jnthn I'll probably do it shortly after the monthly :)
21:31 jnthn heh, it doesn't work like that :P
21:31 timotimo to make it work faster in multi-threaded situations :D
21:31 jnthn It's only good if you don't end up with a heap promotion
21:32 timotimo right
21:32 timotimo will we be getting any kind of diagnostic for that?
21:33 jnthn Yeah, in the normal allocation profiler, I expect. But not totally sure how to do it yet :)
21:33 timotimo sounds good so far
21:34 timotimo there's no way to make the locks on the FSA more fine-grained, right?
21:34 timotimo like, one lock per size group or something silly like that
21:34 jnthn We can surely do better
21:35 cognominal joined #moarvm
21:35 jnthn Though need to do so very carefully. The original "better" lock-free implementation I did ended up with a really nasty AB bug. :/
21:36 jnthn (Which, you might imagine, was hard to find.)
21:38 timotimo oh, yeah, that's pretty terrible :(
21:41 * jnthn wanders of to some hopefully non-terrible sleep
21:41 jnthn *off
21:41 jnthn &
21:41 timotimo good luck!

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