| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:25 SmokeMachine left 00:26 SmokeMachine joined 00:52 Kaiepi left 00:53 Kaiepi joined 01:30 rypervenche left 01:33 rypervenche joined 01:34 sena_kun left 01:49 sena_kun joined 01:54 AlexDaniel left 02:13 MasterDuke left 03:34 sena_kun left, robertle joined 03:48 sena_kun joined 04:03 tobs left 04:28 tobs joined 05:08 Kaiepi left 05:14 squashable6 left 05:17 squashable6 joined 05:34 sena_kun left 05:47 sena_kun joined 06:19 moon-child left, moon-child joined 07:33 sena_kun left 07:37 domidumont joined 07:47 sena_kun joined
Geth MoarVM: 192f0433c8 | (Daniel Green)++ | 2 files
Make nqp::rand_I respect nqp::srand again

The upgrade to libtommath v1.2.0 brought along a new version of mp_rand that uses sources of randomness that aren't seeded with srand. So copy their mp_rand, but modify to use tinymt64 as the source of randomness.
MoarVM: 3c48ebaa95 | (Elizabeth Mattijsen)++ (committed using GitHub Web editor) | 2 files
Merge pull request #1238 from MasterDuke17/make_rand_I_respect_srand_again

Make nqp::rand_I respect nqp::srand again
08:09 colomon_ left 08:11 colomon_ joined 08:33 zakharyas joined 08:59 MasterDuke joined 09:05 zakharyas left 09:07 domidumont left, zakharyas joined 09:24 domidumont joined 09:34 sena_kun left 09:47 sena_kun joined 09:52 Kaiepi joined, Kaiepi left 09:53 Kaiepi joined
jnthn Hmm, a $dayjob project keeps getting bitten by this segv: 10:23
Thread 1 "perl6-m" received signal SIGSEGV, Segmentation fault.
MVM_spesh_arg_guard_run (tc=tc@entry=0x603d10, ag=0x50088b0, cs=0x7ffff7d06660 <inv_arg_callsite>, args=0x1d0d070, certain=certain@entry=0x0) at src/spesh/arg_guard.c:411
411 current_node = IS_CONCRETE(test) && test->st == agn->st
(gdb) p test 10:24
$1 = (MVMObject *) 0x0
Wonder where that real NULL sneaks in...
We're not in specialized code when it happens 10:25
nine But the NULL could be generated in specialized code? 10:27
jnthn Potentially, yes
We're trying to consider an OSR point at the time it blows up 10:28
10:30 patrickb joined
jnthn That looks at the caller's args buffer 10:30
And deopt wouldn't re-instate that 10:31
So I wonder if that's what happens...
jnthn turns on deopt logging, though suspects the timing changes may hide the not-always-happening bug...
aha, yes 10:34
In the preceding deopt:
Recreated frame 'pull-one' (cuid '1961')
And that's exactly where we are now:
(gdb) p MVM_string_utf8_encode_C_string(tc, tc->cur_frame->static_info->body.cuuid)
$7 = 0x99a9e90 "1961"
jnthn ponders the best thing to do about this :) 10:37
nwc10 early lunch? 10:43
jnthn ah, it seems actually cur_args_callsite is "junk" 10:50
Not int the dangly pointer sense
But in so far as an inline doesn't set it
So when we uninline, it could be about whatever non-inlined call the code last did before an OSR, for example 10:51
Oh, or just whatever non-inlined call normal spesh'd code did
Just clearing it in deopt seems to fix things nicely
jnthn spectests the patch 10:52
$dayjob program flaky test files seem happy now
Geth MoarVM: 4d7c7e1425 | (Jonathan Worthington)++ | src/spesh/deopt.c
Clear callsite of bottom frame when uninlining

It may carry a current callsite, but this will not be about the code that was inlined, but rather about some previous non-inlined callee. It can cause confusion if we later try to look at it in order to do OSR in an uninlined frame (this doesn't make us able to do it, it just means we won't do it bogusly or segfault trying, which is what led to this problem being uncovered).
lizmat jnthn: is a bump in place, or are you planning more Moar goodies today? 11:21
jnthn Maybe more
Not sure it needs a special bump tbh 11:22
lizmat ok, I'll hold
jnthn I've found precisely one application that tripped it
lizmat well, in the past days I've had some flappers in 'make spectest' 11:23
so all is not well, I'd say :-)
jnthn At least one of them might have been to do with the (already fixed) s/// thing 11:24
lizmat possibly, yes... :-) 11:25
nine The rakudo bug I fixed today may have caused issues with concurrently running tests as well
Compilation errors to be precise, i.e. those odd test failures where apprently we didn't even run tests 11:26
lizmat aah! ok
11:33 sena_kun left 11:37 squashable6 left
Geth MoarVM/derived-specializations: 4 commits pushed by (Jonathan Worthington)++ 11:38
jnthn Just a rebase 11:39
11:39 squashable6 joined 11:47 sena_kun joined 12:04 Kaiepi left 12:07 Kaiepi joined 12:34 lucasb joined 12:44 zakharyas left 13:04 patrickb left 13:14 patrickb joined 13:33 sena_kun left 13:35 tadzik joined 13:48 sena_kun joined 14:07 brrt joined
jnthn You know, I'm really tempted to try and stop being clever and incrementally add to the guard guard tree, and just rebuild the whole thing every time 14:17
*arg guard tree
We have to copy it anyway 'cus it's immutable for thread safety reasons
Geth MoarVM/expr-jit-devirtualize: 5 commits pushed by (Bart Wiegmans)++
brrt do we add incrementally to the guard tree now? 14:18
14:18 zakharyas joined
jnthn Yes 14:18
brrt hmmm
jnthn And the code doing so is...uh..."clever"
brrt yeah, why not drop it and rebuild
probably a minor inefficiency anyway
jnthn And I think trying to do it with derived specializations too may be a case of "too clever for me to trust it's right"
brrt I'm fairly sure it can be done... but do you want to debug it :-P 14:19
jnthn Well, that's what I'm about to have to do, and... :)
Geth MoarVM/derived-specializations: 72c1d55f48 | (Jonathan Worthington)++ | 3 files
More information in dupe arg guard add error
MoarVM: 657b536cf6 | (Elizabeth Mattijsen)++ | 3rdparty/dyncall
Update dyncall submodule
jnthn btw, in an example where I make an array and push 5 different types to it, the time reduction is from 2.87s to 1.45s 14:24
Which is quite nice
So it's worth trying to get this to properly work 14:25
But yeah, I think I want a new arg guard tree building approach 14:26
Trouble is, I don't know if we keep the info around to rebuild it
In fact, I'm pretty sure we don't
So step one is probably doing that
Yeah, I guess the candidate needs to carry the type tuple 14:28
14:32 zakharyas left 14:33 zakharyas joined
lizmat MoarVM bumped, was make test and make stresstest clean 14:36
jnthn Uff, yes, just working out the algorithm to get the tree built right when we *do* have all of the information is difficult enough that I'm convinced incremental tweaking and handling all possible orderings we might choose to make specializations in is pretty nuts :) 14:42
14:46 MasterDuke left 14:49 brrt left
jnthn finally has a sketch of an algorithm that may just build the right tree 15:02
Not enough time left at $dayjob today to implement it, alas. 15:03
Guest4508 jnthn: have you stopped cherry picking rakudo bugs now? 15:10
jnthn Guest4508: Yeah, I feel "warmed up" enough to pick up one of my MoarVM branches again :)
Guest4508 very cool 15:11
jnthn Working up to continuing with the PEA
Perhaps with p6o-setup inbetween, since PEA depends on that 15:12
sena_kun .oO ( p6o-setup? )
Guest4508 moar speed is always welcome :) 15:13
jnthn sena_kun: An alternative approach to object initialization that gets rid of a lot of the auto-viv, which in turn can lead to cheaper JIT output and more success for the EA
That said, while I'm doing the arg guards, it'll be somewhat tempting to try and JIT the guard tree also
Because evaluating those can be somewhat hot in profiles
15:33 sena_kun left 15:35 brrt joined 15:47 sena_kun joined 16:25 brrt left 16:36 domidumont left 16:42 patrickb left 17:34 sena_kun left
lizmat datapoint: the dyncall update did not fix the Lock::Async: MoarVM panic: Corrupt multi dispatch cache: cur_node != 0, re-check == 0x0 issue 17:37
*not* 17:38
17:48 sena_kun joined 17:50 dogbert11 left 18:44 zakharyas left 19:32 sena_kun left 19:48 sena_kun joined
jnthn lizmat: I don't think it was every going to; it's the MacOS build thing that it might have helped. 20:05
nwc10 jnthn: ASAN considers derived-specializtions to be very boring and unworthy of comment 20:07
jnthn So far... ;) 20:09
20:19 MasterDuke joined
nwc10 jnthn: yes, but, but, "may you live in interesting times" is not something to aspire to. 20:20
20:22 zakharyas joined
japhb ... and yet somehow the plot of all the most interesting movies. 20:27
20:43 dogbert17 joined 21:04 brrt joined 21:12 zakharyas left 21:32 sena_kun left
jnthn nwc10: tbh, the interesting times that ASAN can find are generally less "interesting" than those it cannot... 21:38
21:47 sena_kun joined 22:44 brrt left 23:34 sena_kun left 23:48 sena_kun joined