github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
00:09
lucasb left
01:19
anatofuz left
01:43
anatofuz joined
02:40
Kaiepi left
03:46
squashable6 left,
evalable6 left,
reportable6 left
03:47
bloatable6 joined,
bisectable6 joined,
statisfiable6 joined,
reportable6 joined,
notable6 joined,
nativecallable6 joined,
releasable6 joined
03:48
benchable6 joined,
quotable6 joined,
shareable6 joined,
squashable6 joined
03:49
unicodable6 joined,
committable6 joined
03:50
evalable6 joined,
greppable6 joined
03:51
coverable6 joined,
tellable6 joined
04:08
anatofuz left
04:29
anatofuz joined
04:38
anatofuz left
04:48
anatofuz joined
05:08
anatofuz left
05:24
anatofuz joined
05:28
anatofuz left
05:52
anatofuz joined
05:57
anatofuz left
06:05
anatofuz joined
06:09
anatofuz left
06:10
anatofuz joined
07:15
anatofuz left
07:16
anatofuz joined
07:17
anatofuz left,
anatofuz joined
07:25
sena_kun joined
08:22
brrt joined
08:27
anatofuz_ joined
08:28
anatofu__ joined
08:30
anatofuz left
08:31
anatofuz_ left
08:36
anatofu__ left
08:37
anatofuz joined
08:38
anatofuz left,
anatofuz joined
|
|||
brrt | \o | 08:46 | |
09:04
brrt left
09:07
anatofuz left
|
|||
nine | Oh boy....I think there's a race condition in spesh plugin guard resolution | 09:40 | |
That's the only explanation I can find for the ps pointer in resolve_using_guards to become outdated (0x7f2428467550 vs. 0x7f2428467500 in tc->cur_frame->static_info->body.spesh->body->plugin_state) | 09:43 | ||
I don't think I can fix this without invoking the jnthn++ | 09:44 | ||
Of course, I could simply add a lock, but I also think that's precisely what jnthn wanted to avoid. And I know too little about possible alternatives. | 09:46 | ||
moritz | .oO( now you have two problems. ) |
10:40 | |
10:43
dogbert17 joined
|
|||
dogbert17 | nine: have you found any more bugs? | 10:43 | |
nine | dogbert17: make test is still working through the 02-rakudo tests. Got 3 core dumps so far. One is the *item_ptr != item->sc_forward_u.forwarder assertion for which I suspect that it's not really an issue in multi threaded programs. One's the race condition in spesh plugin guard resolution I mentioned. | 10:49 | |
dogbert17 | very cool, there seems to be quite a few gremlins hiding in the codebase | 10:55 | |
nine | Yeah. Unfortunately runtimes measured in hours make it impractical to test stuff. So all I can do is look at data in gdb and read code | 10:57 | |
timotimo: I'm pretty sure you need to MVMROOT log_obj there: github.com/MoarVM/MoarVM/blob/mast...rker.c#L46 | 11:15 | ||
11:20
chloekek joined
|
|||
timotimo | oh, good call | 11:45 | |
MasterDuke | huh. a profile of `my $a; $a = $_.starts-with("1").Int for ^1_000_000; say now - INIT now; say $a;` shows that `starts-with` isn't being jitted at all. but it doesn't have any 'bailed completely' in a spesh log | 11:50 | |
timotimo | explicitly casting $_.Str.starts-with makes it a whole lot faster | 12:11 | |
find_best_dispatchee is doing a whole lot of work | |||
also, add_to_cache is called a million times | 12:12 | ||
so what exactly goes into the multi cache there ... | 12:13 | ||
the callsite that's being used isn't interned, which makes it not add the result to the cache | 12:16 | ||
it's just a two-flag callsite with the two flags being 1 | 12:18 | ||
which is just "two objects" | 12:19 | ||
MasterDuke | why wouldn't it be interned? | 12:36 | |
this seems like a bug (in the sense that performance is not what it should be) | 12:37 | ||
timotimo | i'll have to trrace the callsite back to where it's allocated and see why it isn't attempted to be interne | 12:56 | |
13:03
lucasb joined
|
|||
Geth | MoarVM/master: 5 commits pushed by (Bart Wiegmans)++ | 13:33 | |
MoarVM/expr-jit-devirtualize: 5 commits pushed by (Bart Wiegmans)++ | 13:36 | ||
13:45
dogbert17 left
15:58
Kaiepi joined
16:22
dogbert17 joined
|
|||
dogbert17 | \o | 16:22 | |
it seems as if one of the latest commits have introduced a bug which shows up when running with a small nursery | 16:23 | ||
Thread 1 "moar" received signal SIGSEGV, Segmentation fault. | 16:24 | ||
0x00007ffff74e3b72 in MVM_multi_cache_find_callsite_args (tc=0x604ac0, cache_obj=0x2aa5b40, cs=0x7ffff7c874e0 <two_args_callsite>, args=0x3c04b10) at src/6model/reprs/MVMMultiCache.c:417 | |||
it could in fact be one of brrt's recent commits | 16:26 | ||
17:44
domidumont joined
18:34
domidumont left
18:35
domidumont joined
18:38
reportable6 left
18:40
domidumont left
18:41
reportable6 joined
18:53
zakharyas joined
20:18
sena_kun left
20:23
domidumont joined
20:25
domidumont left
21:10
Kaiepi left,
Kaiepi joined
21:14
squashable6 left
21:17
squashable6 joined
21:47
chloekek left
21:53
anatofuz joined
21:56
zakharyas left
22:53
lucasb left
22:55
anatofuz left
22:57
anatofuz joined
23:25
anatofuz left,
anatofuz joined
23:32
anatofuz left
23:45
anatofuz joined
23:47
anatofuz left,
anatofuz joined
23:52
anatofuz left
|