|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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. |
07:59 | |
| 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). |
11:07 | |
| 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 |
14:20 | |
| MoarVM: 657b536cf6 | (Elizabeth Mattijsen)++ | 3rdparty/dyncall Update dyncall submodule |
14:21 | ||
| 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
|
|||