Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-12-07

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

All times shown according to UTC.

Time Nick Message
00:02 pyrimidine joined #moarvm
00:52 pyrimidine joined #moarvm
01:03 yoleaux2 joined #moarvm
02:01 pyrimidine joined #moarvm
02:48 FROGGS joined #moarvm
03:04 pyrimidine joined #moarvm
03:43 FROGGS joined #moarvm
05:16 zostay joined #moarvm
05:17 BinGOs joined #moarvm
06:30 pyrimidine joined #moarvm
06:31 zostay joined #moarvm
06:35 domidumont joined #moarvm
07:15 domidumont joined #moarvm
07:22 domidumont joined #moarvm
08:02 pyrimidine joined #moarvm
08:34 zakharyas joined #moarvm
08:38 zakharyas joined #moarvm
09:11 nwc10 good \o, #moarvm
09:13 pyrimidine joined #moarvm
09:32 jnthn good moarning o/
09:47 cygx joined #moarvm
09:47 cygx o/
09:49 cygx jnthn: I need an opinion on the sanity of my approach to modules in my language targetting moarvm
09:49 cygx some example code: https://github.com/cygx/moartools/blob/master/lib/arrays.tiny https://github.com/cygx/moartools/blob/master/moardis.tiny
09:50 cygx the most relevant lines are the last 3 of arrays.tiny as well as the end of moardis.tiny
09:50 cygx modules have a load frame with a buch of lexicals
09:50 cygx its context gets registered as a hllsym
09:51 cygx the importing module gets at the exported symbols via getlexrel, stores them inits own frame and uses forceouterctx to set itself up as the outer of the mainline
09:54 jnthn Hm, it works but you'll end up with a whole chain of outers if you import a load of stuff?
09:54 cygx no, the import frame will be the single outer
09:55 cygx it imports the exported lexicals via getlexrel into its own lexpad
09:55 jnthn Ah, I see
09:56 jnthn Do you need getlexrel, or would hash indexing into the context just do it?
09:56 jnthn (If the symbols are exactly in that frame, not in its outer one, then it would)
09:57 cygx should probably work, once I figure out how to do it ;)
09:58 cygx it's asll trial and errror so far until I gain a it more of an understanding how this all works
09:58 jnthn It's probably a bit cheaper, but in the current setup I *think* you could also end up being able to import stuff that the module in turn imported as an accidental feature? :)
09:58 dalek MoarVM: 8f63407 | LemonBoy++ | src/ (2 files):
09:58 dalek MoarVM: Optimize the check for negative bignums.
09:58 dalek MoarVM:
09:58 dalek MoarVM: We save a function call for every check.
09:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8f63407d80
09:58 dalek MoarVM: f9b283d | LemonBoy++ | src/6model/reprs/P6bigint.c:
09:58 dalek MoarVM: Remove useless mp_neg calls.
09:58 dalek MoarVM:
09:58 dalek MoarVM: Two mp_neg calls have no effect and mp_get_int64 doesn't care about the
09:58 dalek MoarVM: sign.
09:58 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f9b283dac8
09:58 jnthn A blast from the PR past :)
09:59 jnthn https://github.com/MoarVM/MoarVM/pull/405 fwiw
09:59 jnthn cygx: fwiw, Rakudo/NQP don't use hllsym stuff for it, but instead the importer sets up a dynamic variable ($*FOO style thing) and the importee looks that up and registers its context with it.
10:00 jnthn Which also means we don't have to name-mangle anything to make an entry in hllsym
10:00 timotimo see also the ctxsave dynvar rakudo has
10:00 jnthn Yes, that's the one
10:01 jnthn If you don't have the complexities of Perl 6 to deal with then stashing it in hllsym is probably fine, though you may want to hang them off a hash you stick in hllsym
10:01 jnthn Because you only get one of those, and it's a handy place to poke various bits
10:02 jnthn (And a bad place to poke too many bits... :))
10:05 cygx thanks for the input so far
10:05 cygx I'll have to think on the pros and cons of using the hllsym space as module registry...
10:05 jnthn Yeah
10:05 jnthn MoarVM doesn't really try to enforce any kind of "standard" around this
10:06 cygx how heavy is a getlexrel compared to a hash lookup?
10:06 cygx (boothash specifically?)
10:09 jnthn It goes through each outer in the chain and does a hash lookup in it
10:09 jnthn So, it depends how long the chain is
10:10 jnthn But if it's in the outer scope and only has an import scope outside of it then I guess it's only a factor of 2 in it
10:11 cygx looking at the code, it would add some overhead for the chain handling (and I guess vivification as well)
10:11 cygx however, as the alternative for now is a boothash, this means I'd have to box primitives of I went with that...
10:11 cygx *if
10:13 cygx I think I'll leave it as-is for now, but introduce some syntactic sugar so I can swap out the implementation if it becomes necessary...
10:14 cygx it doesn't need to be optimal yet, just shouldn't be completely horrible
10:14 jnthn At first I couldn't get valgrind to do https://gist.github.com/dogbert17/ba3ce0403b81029965fa9983ec43e298 but turns out it only does it 1 in 3 runs for me or something like that
10:15 dogbert17_ joined #moarvm
10:16 dalek MoarVM: 8404db2 | jnthn++ | src/io/asyncsocket.c:
10:16 dalek MoarVM: Toss unused #define.
10:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8404db225f
10:16 dogbert17_ oh, you're investigating nwc10's ASAN barfage
10:16 jnthn Yeah...did you figure anything out on it, besides that valgrind may also show it?
10:17 dogbert17_ sadly no :(
10:19 dogbert17_ dunno how often nwc10 runs this ASAN thingy so I wonder if it is a newly introduced problem or an old one
10:30 jnthn Think I've found a fix
10:34 zakharyas joined #moarvm
10:34 brrt ooh, interesting
10:38 brrt fwiw, I've got a diff for the breaking CORE.setting build, but not sure yet what it is
10:38 brrt mismatching labels is very suspicious of course
10:54 dogbert17_ interesting, was it something that was introduced recently or one of 'how can this ever have worked' thingies?
11:01 jnthn I know I improved socket error handling a while back since we missed some cases
11:01 jnthn So it may have sneaked in then
11:01 jnthn UDP sockets had a similar issue but we didn't have the test coverage to show that up
11:02 jnthn (I wrote a test that also made valgrind sad, and have just patched it)
11:02 * jnthn spectests fix
11:04 * dogbert17_ hopes jnthn has a 32 core box :-)
11:05 jnthn Also no
11:11 dalek MoarVM: 0e6dabc | jnthn++ | src/io/asyncsocket.c:
11:11 dalek MoarVM: Fix premature free of UV socket handles.
11:11 dalek MoarVM:
11:11 dalek MoarVM: We need to close them properly even in the case of error, and then
11:11 dalek MoarVM: free them in the close callback.
11:11 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0e6dabc2ff
11:11 dalek MoarVM: 2c50886 | jnthn++ | src/io/asyncsocketudp.c:
11:11 dalek MoarVM: Fix premature handle free in async UDP sockets.
11:11 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2c50886bc7
11:15 brrt aha
11:15 brrt label 281 is missing in the expr jit compiled cod
11:15 brrt *code
11:21 brrt which probably means that there is a tag on the code i'm not handling correctly
11:21 jnthn So, first RT of the day down :)
11:21 lucasb joined #moarvm
11:21 brrt jnthn++
11:22 lucasb saw a commit about a UV socket thing...
11:23 lucasb just letting you know that libuv 1.10.1 is available
11:23 lucasb iirc, moar is at libuv 1.8.0
11:25 zostay joined #moarvm
11:26 lucasb also, libtommath
11:26 lucasb ... it released version 1.0
11:27 lucasb but maybe moarvm may be maintaining your own modified version of libtommath
11:37 dogbert17_ jnthn++, what RT are you attacking next?
11:40 jnthn This afternoon will look at hyper/race at long last
11:41 jnthn At the moment just adding a test for https://rt.perl.org/Ticket/Display.html?id=128985 which I can no longer provoke into any kind of crash even with GC debug stuff and regular collections turned on
11:44 jnthn Though while I've got a build that has GC stressing turned on I figured I'd do a spectest
11:44 jnthn And I think it's showed up a couple of things...will see shortly
11:47 babydrop :o
11:47 * babydrop is... .hyper excited!
11:51 cygx if you're looking for stuff to fix, https://rt.perl.org/Public/Bug/Display.html?id=129957 has gotten even more wonky for me
11:52 cygx now it sits just there, and eventually dies with a SORRY: read from dirhandle failed: 123
11:53 jnthn That...makes no sense o.O
11:53 jnthn But no, I'm not taking the bait. I've put off fixing up hyper/race for months already. :)
11:54 cygx ETOOMANYBUGSNOTENOUGHJNTHN
12:01 cygx might be something funny going on with file permissions on my end
12:01 cygx the original bug is still reproducible, though
12:12 jnthn dogbert17_: Did you mention getting some kind of crash in t/spec/S04-declarations/constant.rakudo.moar at some point?
12:19 brrt i don't think we maintain our own libtommath
12:20 jnthn lunch &
12:21 ilmari brrt: 3rdparty/libtommath is a version of tommath from 2013 with a few local commits
12:23 brrt really? what do those local commits do?
12:24 ilmari https://github.com/MoarVM/MoarVM/commits/master/3rdparty/libtommath
12:24 ilmari the debian package seems to use the system libtommath, though
12:25 ilmari $ ldd /usr/lib/moar/libmoar.so|grep tom
12:25 ilmari libtommath.so.1 => /lib/x86_64-linux-gnu/libtommath.so.1 (0x00007f85af8be000)
12:34 brrt hmmm
12:35 brrt well, you have my permission to just try and update it and see if that works
12:52 dogbert17_ jnthn: I did, but it seems to have gone away ...
13:05 cygx joined #moarvm
13:10 lizmat joined #moarvm
13:11 lizmat_ joined #moarvm
13:20 dogbert17_ guess it was a bit of a red herring, I can reproduce it but it disappears as soon as I remove rakudobrew from my path, seems to be some weird interaction between rakudobrew and my dev installation
13:36 jnthn dogbert17_: Yeah, I've got a reliable reproduction by forcing regular GC
13:37 dogbert17_ cool
13:52 jnthn It's not yielding its cause particularly easily, alas
13:57 jnthn Make the GC nursery size a step smaller by half and it vanishes
13:57 jnthn Doesn't trip any of the GC debug bits
13:57 jnthn Doesn't trip the FSA debug bits, or valgrind
14:02 timotimo cygyou're on windows? because that "read from dirhandle failed" thing happens inside a windows ifdefed block
14:03 timotimo oh, cygx isn't here any more
14:04 synopsebot6 joined #moarvm
14:23 pyrimidine joined #moarvm
14:27 jnthn So far, got it down to getdynlex returning something that's in fromspace
14:28 pyrimidine joined #moarvm
14:40 lizmat joined #moarvm
14:45 pyrimidine joined #moarvm
14:58 dogbert17_ so it's an elusive bug
14:59 jnthn Indeed
14:59 timotimo i wonder where the mvm root needs to go this time
14:59 jnthn I've even made an OMG-check-*everything* mode for MVM_GC_DEBUG to try and help find it
15:01 jnthn Sadly it...doesn't help a ton
15:01 jnthn I'm sure it will at some point some day but...not in this bug
15:06 pyrimidine joined #moarvm
15:13 jnthn Well, seems it's to do with dynlex caching so far
15:14 dalek MoarVM: 4d939e8 | jnthn++ | src/core/interp.c:
15:15 dalek MoarVM: Add some fromspace checks on lexical accesses.
15:15 dalek MoarVM:
15:15 dalek MoarVM: To catch a wider range of interesting problems.
15:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/4d939e8980
15:15 dalek MoarVM: 8dd2f63 | jnthn++ | src/ (2 files):
15:15 dalek MoarVM: Add a "check every register access" GC debug mode.
15:15 dalek MoarVM:
15:15 dalek MoarVM: Costly, but may help track down more issues.
15:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8dd2f63e19
15:15 dalek MoarVM: 22281b6 | jnthn++ | src/core/frame.c:
15:15 dalek MoarVM: Provide a way to disable dynlex caching.
15:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/22281b63f9
15:15 timotimo jesus christ :)
15:15 timotimo every GET_REG
15:17 jnthn Yes, this is not very fast :P
15:17 jnthn But it is fairly thorough
15:17 timotimo i can imagine
15:21 jnthn Oh...and MVM_SPESH_INLINE_DISABLE defeats it
15:21 jnthn Now all I need is evidence of deopt and we probably have a good idea what's going on.
15:21 timotimo oh yikes, deopt-related bugs
15:21 timotimo ain't that fun :|
15:28 jnthn Recreated frame 'EXPR' (cuid '592')
15:28 jnthn And
15:28 jnthn method EXPR(str $preclim = '') {
15:28 jnthn # Override this so we can set $*LEFTSIGIL.
15:28 jnthn my $*LEFTSIGIL := '';
15:28 jnthn And $*LEFTSIGIL is the dynlex we get a busted value for
15:29 timotimo so adding all the cache entries to the worklists might be b0rken?
15:30 jnthn Well, here's my hypothesis
15:30 dalek MoarVM: 2025f86 | jnthn++ | src/spesh/deopt.c:
15:30 dalek MoarVM: Provide a #define for deopt logging.
15:30 dalek MoarVM:
15:30 dalek MoarVM: Rather than uncommenting fprintf each time we want it.
15:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/2025f863eb
15:31 jnthn We go looking for a dynamic lexical. We find it, and it's one of the inlined lexicals.
15:31 jnthn We store the register reference in the cache
15:31 jnthn Later we deopt_all
15:31 timotimo oh, heh.
15:31 timotimo and the reference gets outdated
15:31 jnthn That register reference is now legal memory but no longer cared about because we stopped using it when we deopted the frame
15:31 jnthn So it's outdated, thus why we see the fromspace value
15:31 timotimo i see
15:32 timotimo that's a harsh one
15:32 jnthn So this is an interaction of all of inlining, deopt, GC, and the dynlex cache
15:32 jnthn And if you remove any one of those elements it won't happen.
15:32 timotimo we need fewer systems that can interact :S
15:33 jnthn Yes, that's why I spend so much time worrying about loose coupling of stuff :P
15:33 jnthn Now the interesting question is how to fix it
15:33 jnthn One obvious fix is "don't cache things that are inlined" but that'd be sad
15:33 timotimo purge all caches when we encounter a situation we don't know how to handle
15:34 jnthn Well, purge all the caches on deopt_all might be the most reasonable.
15:34 timotimo right
15:34 timotimo it's deopt "all" after all
15:36 jnthn Indeed
15:36 jnthn And this feels kinda right
15:37 jnthn In that we only lose out if we deopt
15:37 jnthn When we're losing out anyway
15:37 jnthn That does seem to help
15:45 jnthn I worry just a bit about deopt_one too though
15:56 dalek MoarVM: e674686 | jnthn++ | src/spesh/deopt.c:
15:56 dalek MoarVM: Invalidate dynlex caches during deopt.
15:56 dalek MoarVM:
15:56 dalek MoarVM: The dynlex cache may point into the lexicals buffer in a case where
15:56 dalek MoarVM: we have an inlined lexical. This is fine enough, until we deopt that
15:56 dalek MoarVM: frame. In that case, uninlining moves lexicals to live in a freshly
15:56 dalek MoarVM: created frame, leaving the dynlex cache pointing into the place the
15:56 dalek MoarVM: lexical used to be. If lexical gets rebound then we'd look up an old
15:56 dalek MoarVM: value; worse, if GC happens then we can end up with dynamic lexical
15:56 dalek MoarVM: lookups returning an out-dated pointer (e.g. into fromspace). This
15:56 dalek MoarVM: bug was uncovered first by examining an occasional failure in Rakudo
15:56 dalek MoarVM: when compiling constant.t, but could have affected various constructs
15:56 dalek MoarVM: taking similar paths through the parser.
15:56 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e674686fe9
15:57 jnthn That was quite a bug hunt...
15:59 mst oh, NEAT
16:00 mst jnthn++ # I feel like I actually understood that commit message. maybe I even did.
16:01 * geekosaur basically understands it, although understanding would be even better with more knowledge of moarvm internals...
16:04 * jnthn wonders whether that one might make an interesting one to write up on the blog...
16:06 [Coke] on the advent blog. for the 9th! :)
16:06 jnthn It...may be a tad heavy for that :P
16:06 [Coke] :)
16:09 moritz jnthn++
16:09 moritz it validates my previous impression that deopt is hard
16:10 moritz and it surprises me that we don't run into many more problems with it
16:11 jnthn heh
16:11 jnthn mp_get_double(base)
16:11 jnthn ...ok, that's now how you spell the instrument but still... :P
16:16 jnthn *not
16:16 [Coke] brrt: did I see you say you'd be willing to move your advent post up?
16:16 brrt yes
16:17 brrt you did
16:17 brrt 9th is okay with me
16:17 [Coke] woot. i will rearrange right now. :)
16:18 brrt :-)happy to help
16:22 [Coke] brrt: schedule updated. thank you for your sacrifice. :)
16:24 brrt no problem :-)
16:26 dogbert17_ jnthn++, impressive work
16:30 dalek MoarVM: d2139b5 | (Pawel Murias)++ | src/math/bigintops.c:
16:30 dalek MoarVM: Fix pow_I when it takes an exponent larger than 2**32.
16:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/d2139b52d6
16:30 dalek MoarVM: 730f285 | jnthn++ | src/math/bigintops.c:
16:30 dalek MoarVM: Merge pull request #447 from pmurias/fix-pow_I
16:30 dalek MoarVM:
16:30 dalek MoarVM: Fix pow_I when it takes an exponent larger than 2**32.
16:30 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/730f285aa4
16:35 TimToady jnthn: my old idea for a better dynvar cache might also fix that particular bug
16:35 yoleaux2 6 Dec 2016 23:55Z <babydrop> TimToady: perhaps we need a different approach than dying in leu of Failures in things that may return a list? For example this code does not throw and I only scratched the surface: dd [.elems, .pick.elems, .roll.elems, .eager.elems, .Slip.elems, .Array.elems, .List.elems, .Capture.elems, .rotor(42).elems ] given Failure.new
16:36 jnthn TimToady: Well, need to be careful not to re-introduce it when doing that... :-)
16:37 TimToady haven't measured lately, but my gut feel is that we're overusing the current cache more badly than we used to
16:39 jnthn It'd be kinda nice to have $*ACTIONS not be resolved using a dynvar
16:39 jnthn That me be a source of a huge number of the lookups
16:57 dalek MoarVM: 8e24145 | jnthn++ | src/spesh/deopt.c:
16:57 dalek MoarVM: Fix a typo; MasterDuke17++.
16:57 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8e24145daf
17:07 timotimo yeah, we wanted to have that in a parse-shared object or something
17:07 timotimo that plan is already old. maybe even a year old
17:20 domidumont joined #moarvm
17:25 pyrimidine joined #moarvm
17:47 zakharyas joined #moarvm
17:48 pyrimidine joined #moarvm
17:51 pyrimidine joined #moarvm
19:00 FROGGS joined #moarvm
19:19 domidumont joined #moarvm
19:34 zakharyas joined #moarvm
21:06 pyrimidine joined #moarvm
21:21 donaldh joined #moarvm
21:37 pyrimidine joined #moarvm
22:09 pyrimidine joined #moarvm
22:45 pyrimidine joined #moarvm
23:08 pyrimidine joined #moarvm
23:54 pyrimidine joined #moarvm

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