00:02 pyrimidine joined 00:52 pyrimidine joined 01:03 yoleaux2 joined 02:01 pyrimidine joined 02:48 FROGGS joined 03:04 pyrimidine joined 03:43 FROGGS joined 05:16 zostay joined 05:17 BinGOs joined 06:30 pyrimidine joined 06:31 zostay joined 06:35 domidumont joined 07:15 domidumont joined 07:22 domidumont joined 08:02 pyrimidine joined 08:34 zakharyas joined 08:38 zakharyas joined
nwc10 good \o, #moarvm 09:11
09:13 pyrimidine joined
jnthn good moarning o/ 09:32
09:47 cygx joined
cygx o/ 09:47
jnthn: I need an opinion on the sanity of my approach to modules in my language targetting moarvm 09:49
some example code: github.com/cygx/moartools/blob/mas...rrays.tiny github.com/cygx/moartools/blob/mas...ardis.tiny
the most relevant lines are the last 3 of arrays.tiny as well as the end of moardis.tiny 09:50
modules have a load frame with a buch of lexicals
its context gets registered as a hllsym
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:51
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
it imports the exported lexicals via getlexrel into its own lexpad 09:55
jnthn Ah, I see
Do you need getlexrel, or would hash indexing into the context just do it? 09:56
(If the symbols are exactly in that frame, not in its outer one, then it would)
cygx should probably work, once I figure out how to do it ;) 09:57
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? :)
dalek arVM: 8f63407 | LemonBoy++ | src/ (2 files):
Optimize the check for negative bignums.

We save a function call for every check.
arVM: f9b283d | LemonBoy++ | src/6model/reprs/P6bigint.c:
Remove useless mp_neg calls.

Two mp_neg calls have no effect and mp_get_int64 doesn't care about the sign.
jnthn A blast from the PR past :)
github.com/MoarVM/MoarVM/pull/405 fwiw 09:59
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.
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
jnthn Yes, that's the one
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
Because you only get one of those, and it's a handy place to poke various bits
(And a bad place to poke too many bits... :)) 10:02
cygx thanks for the input so far 10:05
I'll have to think on the pros and cons of using the hllsym space as module registry...
jnthn Yeah
MoarVM doesn't really try to enforce any kind of "standard" around this
cygx how heavy is a getlexrel compared to a hash lookup? 10:06
(boothash specifically?)
jnthn It goes through each outer in the chain and does a hash lookup in it 10:09
So, it depends how long the chain is
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:10
cygx looking at the code, it would add some overhead for the chain handling (and I guess vivification as well) 10:11
however, as the alternative for now is a boothash, this means I'd have to box primitives of I went with that...
*if
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:13
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 gist.github.com/dogbert17/ba3ce040...83ec43e298 but turns out it only does it 1 in 3 runs for me or something like that
10:15 dogbert17_ joined
dalek arVM: 8404db2 | jnthn++ | src/io/asyncsocket.c:
Toss unused #define.
 10:16
dogbert17_ oh, you're investigating nwc10's ASAN barfage
jnthn Yeah...did you figure anything out on it, besides that valgrind may also show it?
dogbert17_ sadly no :( 10:17
dunno how often nwc10 runs this ASAN thingy so I wonder if it is a newly introduced problem or an old one 10:19
jnthn Think I've found a fix 10:30
10:34 zakharyas joined
brrt ooh, interesting 10:34
fwiw, I've got a diff for the breaking CORE.setting build, but not sure yet what it is 10:38
mismatching labels is very suspicious of course
dogbert17_ interesting, was it something that was introduced recently or one of 'how can this ever have worked' thingies? 10:54
jnthn I know I improved socket error handling a while back since we missed some cases 11:01
So it may have sneaked in then
UDP sockets had a similar issue but we didn't have the test coverage to show that up
(I wrote a test that also made valgrind sad, and have just patched it) 11:02
jnthn spectests fix
dogbert17_ hopes jnthn has a 32 core box :-) 11:04
jnthn Also no 11:05
dalek arVM: 0e6dabc | jnthn++ | src/io/asyncsocket.c:
Fix premature free of UV socket handles.

We need to close them properly even in the case of error, and then free them in the close callback.		 11:11
arVM: 2c50886 | jnthn++ | src/io/asyncsocketudp.c:
Fix premature handle free in async UDP sockets.
brrt aha 11:15
label 281 is missing in the expr jit compiled cod
*code
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
brrt jnthn++ 11:21
lucasb saw a commit about a UV socket thing... 11:22
just letting you know that libuv 1.10.1 is available 11:23
iirc, moar is at libuv 1.8.0
11:25 zostay joined
lucasb also, libtommath 11:26
... it released version 1.0
but maybe moarvm may be maintaining your own modified version of libtommath 11:27
dogbert17_ jnthn++, what RT are you attacking next? 11:37
jnthn This afternoon will look at hyper/race at long last 11:40
At the moment just adding a test for 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:41
Though while I've got a build that has GC stressing turned on I figured I'd do a spectest 11:44
And I think it's showed up a couple of things...will see shortly
babydrop :o 11:47
babydrop is... .hyper excited!
cygx if you're looking for stuff to fix, rt.perl.org/Public/Bug/Display.html?id=129957 has gotten even more wonky for me 11:51
now it sits just there, and eventually dies with a SORRY: read from dirhandle failed: 123 11:52
jnthn That...makes no sense o.O 11:53
But no, I'm not taking the bait. I've put off fixing up hyper/race for months already. :)
cygx ETOOMANYBUGSNOTENOUGHJNTHN 11:54
might be something funny going on with file permissions on my end 12:01
the original bug is still reproducible, though
jnthn dogbert17_: Did you mention getting some kind of crash in t/spec/S04-declarations/constant.rakudo.moar at some point? 12:12
brrt i don't think we maintain our own libtommath 12:19
jnthn lunch & 12:20
ilmari brrt: 3rdparty/libtommath is a version of tommath from 2013 with a few local commits 12:21
brrt really? what do those local commits do? 12:23
ilmari github.com/MoarVM/MoarVM/commits/m...libtommath 12:24
the debian package seems to use the system libtommath, though
$ ldd /usr/lib/moar/libmoar.so|grep tom 12:25
libtommath.so.1 => /lib/x86_64-linux-gnu/libtommath.so.1 (0x00007f85af8be000)
brrt hmmm 12:34
well, you have my permission to just try and update it and see if that works 12:35
dogbert17_ jnthn: I did, but it seems to have gone away ... 12:52
13:05 cygx joined 13:10 lizmat joined 13:11 lizmat_ joined
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:20
jnthn dogbert17_: Yeah, I've got a reliable reproduction by forcing regular GC 13:36
dogbert17_ cool 13:37
jnthn It's not yielding its cause particularly easily, alas 13:52
Make the GC nursery size a step smaller by half and it vanishes 13:57
Doesn't trip any of the GC debug bits
Doesn't trip the FSA debug bits, or valgrind
timotimo cygyou're on windows? because that "read from dirhandle failed" thing happens inside a windows ifdefed block 14:02
oh, cygx isn't here any more 14:03
14:04 synopsebot6 joined 14:23 pyrimidine joined
jnthn So far, got it down to getdynlex returning something that's in fromspace 14:27
14:28 pyrimidine joined 14:40 lizmat joined 14:45 pyrimidine joined
dogbert17_ so it's an elusive bug 14:58
jnthn Indeed 14:59
timotimo i wonder where the mvm root needs to go this time
jnthn I've even made an OMG-check-*everything* mode for MVM_GC_DEBUG to try and help find it
Sadly it...doesn't help a ton 15:01
I'm sure it will at some point some day but...not in this bug
15:06 pyrimidine joined
jnthn Well, seems it's to do with dynlex caching so far 15:13
dalek arVM: 4d939e8 | jnthn++ | src/core/interp.c:
Add some fromspace checks on lexical accesses.

To catch a wider range of interesting problems.		 15:14
arVM: 8dd2f63 | jnthn++ | src/ (2 files):
Add a "check every register access" GC debug mode.

Costly, but may help track down more issues.
arVM: 22281b6 | jnthn++ | src/core/frame.c:
Provide a way to disable dynlex caching.
timotimo jesus christ :)
every GET_REG
jnthn Yes, this is not very fast :P 15:17
But it is fairly thorough
timotimo i can imagine
jnthn Oh...and MVM_SPESH_INLINE_DISABLE defeats it 15:21
Now all I need is evidence of deopt and we probably have a good idea what's going on.
timotimo oh yikes, deopt-related bugs
ain't that fun :|
jnthn Recreated frame 'EXPR' (cuid '592') 15:28
And
method EXPR(str $preclim = '') {
# Override this so we can set $*LEFTSIGIL.
my $*LEFTSIGIL := '';
And $*LEFTSIGIL is the dynlex we get a busted value for
timotimo so adding all the cache entries to the worklists might be b0rken? 15:29
jnthn Well, here's my hypothesis 15:30
dalek arVM: 2025f86 | jnthn++ | src/spesh/deopt.c:
Provide a #define for deopt logging.

Rather than uncommenting fprintf each time we want it.
jnthn We go looking for a dynamic lexical. We find it, and it's one of the inlined lexicals. 15:31
We store the register reference in the cache
Later we deopt_all
timotimo oh, heh.
and the reference gets outdated
jnthn That register reference is now legal memory but no longer cared about because we stopped using it when we deopted the frame
So it's outdated, thus why we see the fromspace value
timotimo i see
that's a harsh one 15:32
jnthn So this is an interaction of all of inlining, deopt, GC, and the dynlex cache
And if you remove any one of those elements it won't happen.
timotimo we need fewer systems that can interact :S
jnthn Yes, that's why I spend so much time worrying about loose coupling of stuff :P 15:33
Now the interesting question is how to fix it
One obvious fix is "don't cache things that are inlined" but that'd be sad
timotimo purge all caches when we encounter a situation we don't know how to handle
jnthn Well, purge all the caches on deopt_all might be the most reasonable. 15:34
timotimo right
it's deopt "all" after all
jnthn Indeed 15:36
And this feels kinda right
In that we only lose out if we deopt 15:37
When we're losing out anyway
That does seem to help
I worry just a bit about deopt_one too though 15:45
dalek arVM: e674686 | jnthn++ | src/spesh/deopt.c:
Invalidate dynlex caches during deopt.

The dynlex cache may point into the lexicals buffer in a case where we have an inlined lexical. This is fine enough, until we deopt that frame. In that case, uninlining moves lexicals to live in a freshly created frame, leaving the dynlex cache pointing into the place the lexical used to be. If lexical gets rebound then we'd look up an old value; worse, if GC happens then we can end up with dynamic lexical lookups returning an out-dated pointer (e.g. into fromspace). This bug was uncovered first by examining an occasional failure in Rakudo when compiling constant.t, but could have affected various constructs taking similar paths through the parser.		 15:56
jnthn That was quite a bug hunt... 15:57
mst oh, NEAT 15:59
jnthn++ # I feel like I actually understood that commit message. maybe I even did. 16:00
geekosaur basically understands it, although understanding would be even better with more knowledge of moarvm internals... 16:01
jnthn wonders whether that one might make an interesting one to write up on the blog... 16:04
[Coke] on the advent blog. for the 9th! :) 16:06
jnthn It...may be a tad heavy for that :P
[Coke] :)
moritz jnthn++ 16:09
it validates my previous impression that deopt is hard
and it surprises me that we don't run into many more problems with it 16:10
jnthn heh 16:11
mp_get_double(base)
...ok, that's now how you spell the instrument but still... :P
*not 16:16
[Coke] brrt: did I see you say you'd be willing to move your advent post up?
brrt yes
you did 16:17
9th is okay with me
[Coke] woot. i will rearrange right now. :)
brrt :-)happy to help 16:18
[Coke] brrt: schedule updated. thank you for your sacrifice. :) 16:22
brrt no problem :-) 16:24
dogbert17_ jnthn++, impressive work 16:26
dalek arVM: d2139b5 | (Pawel Murias)++ | src/math/bigintops.c:
Fix pow_I when it takes an exponent larger than 2**32.
 16:30
arVM: 730f285 | jnthn++ | src/math/bigintops.c:
Merge pull request #447 from pmurias/fix-pow_I

Fix pow_I when it takes an exponent larger than 2**32.
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
jnthn TimToady: Well, need to be careful not to re-introduce it when doing that... :-) 16:36
TimToady haven't measured lately, but my gut feel is that we're overusing the current cache more badly than we used to 16:37
jnthn It'd be kinda nice to have $*ACTIONS not be resolved using a dynvar 16:39
That me be a source of a huge number of the lookups
dalek arVM: 8e24145 | jnthn++ | src/spesh/deopt.c:
Fix a typo; MasterDuke17++.
 16:57
timotimo yeah, we wanted to have that in a parse-shared object or something 17:07
that plan is already old. maybe even a year old
17:20 domidumont joined 17:25 pyrimidine joined 17:47 zakharyas joined 17:48 pyrimidine joined 17:51 pyrimidine joined 19:00 FROGGS joined 19:19 domidumont joined 19:34 zakharyas joined 21:06 pyrimidine joined 21:21 donaldh joined 21:37 pyrimidine joined 22:09 pyrimidine joined 22:45 pyrimidine joined 23:08 pyrimidine joined 23:54 pyrimidine joined

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!