[00:14] *** klapperl joined [01:03] *** nwc10 left [04:34] *** nativecallable6 left [04:34] *** sourceable6 left [04:34] *** committable6 left [04:34] *** greppable6 left [04:34] *** bisectable6 left [04:34] *** tellable6 left [04:34] *** releasable6 left [04:34] *** statisfiable6 left [04:34] *** reportable6 left [04:34] *** coverable6 left [04:34] *** linkable6 left [04:34] *** unicodable6 left [04:34] *** squashable6 left [04:34] *** bloatable6 left [04:34] *** notable6 left [04:34] *** quotable6 left [04:34] *** evalable6 left [04:34] *** shareable6 left [04:34] *** benchable6 left [04:34] *** linkable6 joined [04:34] *** shareable6 joined [04:34] *** committable6 joined [04:34] *** reportable6 joined [04:34] *** tellable6 joined [04:35] *** releasable6 joined [04:35] *** quotable6 joined [04:35] *** nativecallable6 joined [04:36] *** benchable6 joined [04:36] *** statisfiable6 joined [04:36] *** squashable6 joined [04:36] *** unicodable6 joined [04:36] *** sourceable6 joined [04:36] *** bloatable6 joined [04:37] *** evalable6 joined [04:37] *** greppable6 joined [04:37] *** notable6 joined [04:37] *** bisectable6 joined [04:37] *** coverable6 joined [05:12] *** nwc10 joined [05:13] good *, #moarvm [06:37] *** Altai-man joined [07:03] *** sena_kun joined [07:05] *** Altai-man left [07:27] *** zakharyas joined [07:33] *** zakharyas1 joined [07:36] *** zakharyas left [07:42] *** zakharyas1 left [07:46] *** zakharyas joined [08:06] *** domidumont joined [08:09] *** zakharyas1 joined [08:11] *** Kaiepi joined [08:12] *** zakharyas left [08:38] *** brrt joined [09:14] hey hey hey. is https://github.com/MoarVM/MoarVM/pull/1344/files#diff-7921ea0553dcc7034f8f73c63ed6d622L1466-L1481 correct? are those comparisons still valid if the gc has moved the candidate that `g->cand` points to? [10:00] *** leont joined [10:23] *** brrt left [11:02] *** Altai-man joined [11:05] *** sena_kun left [11:27] *** zakharyas1 left [11:45] ah, interesting [11:47] i think since we turned cand into a collectable, the graph would never own the memory any more [11:48] hm [11:48] the point is that there may not be a candidate at all [11:49] in which case a destroyed spesh graph needs to clear its memory [11:54] hm. what i wasn't sure about was e.g., `g->lexical_types = cand->body.lexical_types;` in MVM_spesh_graph_create_from_cand and then `g->cand->body.lexical_types != g->lexical_types` in MVM_spesh_graph_destroy [12:03] we only have a few spots where gc is allowed to run in spesh [12:03] perhaps we just need a little refresh function that we call in those places [12:31] *** zakharyas joined [12:39] i'm not sure if we can just always create the MVmSpeshCandidate object; we probably have to create them in the middle of speshing when we want to inline something, and that's currently not possible [12:39] *** zakharyas1 joined [12:39] i.e. if we would allocate in the middle of speshing, GC would blow up in our faces [12:41] where's it being created? [12:42] *** zakharyas left [12:42] that's problematic? if it was currently blowing up because of that there would be a different error, right? [12:43] should `g->cand = cand` be an MVM_ASSIGN_REF? [12:44] Doubt it, because the graph is not a collectable [12:44] 2020-09-17T16:49:51Z #raku <[Coke]> jnthn: can you make me an admin on rakudo/rakudo, if you're OK with that? [12:44] oh, right [12:44] *** brrt joined [12:48] *** zakharyas joined [12:49] *** brrt` joined [12:50] *** zakharyas1 left [12:51] *** brrt left [12:52] *** Kaiepi left [13:31] Finally, I have time to work on MoarVM stuff :) [13:32] MasterDuke: I'm a bit out of sync on the spesh candidate refactor; is there something I can help debug at this point? [13:32] woohoo [13:33] jnthn: cool. well, nqp builds, but rakudo panics just about right away compiling core.c [13:34] https://colabti.org/irclogger/irclogger_log/moarvm?date=2020-09-13#l55 [13:35] branch has been rebased to master, just pushed it [13:39] ¦ MoarVM: 50d3311c75 | (Jonathan Worthington)++ | 8 files [13:39] ¦ MoarVM: Better specialize boolification of boxed Num [13:39] ¦ MoarVM: [13:39] ¦ MoarVM: Previously this wasn't specialized at all, and so fell back on the [13:39] ¦ MoarVM: late-bound `istrue` instruction. Now it optimizes into an unbox and a [13:39] ¦ MoarVM: truth test on the unboxed float, which in turn can be JIT-compiled into [13:39] ¦ MoarVM: a relatively short sequence of instructions. [13:39] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/50d3311c75 [13:39] ¦ MoarVM: 21992e6f0b | (Jonathan Worthington)++ (committed using GitHub Web editor) | 8 files [13:39] ¦ MoarVM: Merge pull request #1346 from MoarVM/optimize-boxed-float-boolification [13:39] ¦ MoarVM: [13:39] ¦ MoarVM: Better specialize boolification of boxed Num [13:39] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/21992e6f0b [13:40] Goodness, I'm behind on PR review. [13:49] ah, should do some other task [13:49] afk for a bit, back soon [14:29] *** vrurg_ is now known as vrurg [14:32] *** ggoebel joined [14:38] *** Kaiepi joined [14:49] * jnthn back [14:51] Stage start : 0.000 [14:51] MoarVM panic: Internal error: zeroed target thread ID in work pass [14:51] Yup, repro'd :) [14:57] cool [15:00] *** brrt` left [15:03] *** sena_kun joined [15:05] *** Altai-man left [15:14] Didn't find the issue so far, alas... [15:17] But hm, this is a bit fishy [15:17] oh? [15:17] (gdb) p *(MVMSpeshCandidate *)0x7fffec5a9bc0 [15:17] $4 = {common = {header = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, st = 0x0}, owner = 3, flags1 = 0 '\000', flags2 = 42 '*', size = 208}, [15:17] 42 = 32 + 8 + 2 [15:17] Oh, maybe it's OK [15:18] Yeah, I guess we don't clear MVM_CF_REF_FROM_GEN2 upon gen2 promotion 'cus we don't really need to [15:59] ¦ MoarVM/oops-for-FSA-of-0: ed19b20dc3 | (Nicholas Clark)++ | src/core/fixedsizealloc.c [15:59] ¦ MoarVM/oops-for-FSA-of-0: oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. [15:59] ¦ MoarVM/oops-for-FSA-of-0: [15:59] ¦ MoarVM/oops-for-FSA-of-0: Previously this wasn't trapped. With FSA_SIZE_DEBUG enabled (not the default) [15:59] ¦ MoarVM/oops-for-FSA-of-0: everything works (it can allocate "0" bytes, as it adds its debugging record [15:59] ¦ MoarVM/oops-for-FSA-of-0: keeping to the size requested). With default settings, we corrupt the malloc [15:59] ¦ MoarVM/oops-for-FSA-of-0: heap, which doesn't get reported at the time, and may or may not get reported [15:59] ¦ MoarVM/oops-for-FSA-of-0: in any useful way later. [15:59] ¦ MoarVM/oops-for-FSA-of-0: review: https://github.com/MoarVM/MoarVM/commit/ed19b20dc3 [16:00] ¦ MoarVM: nwc10++ created pull request #1349: oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. [16:00] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1349 [16:02] er, pun seems unavoidable - oops, I didn't rebase that first. [16:03] no release is tagged yet, is it? [16:04] not to my knowledge [16:12] So, at the point that we produce the candidate, the spesh slots seem OK. But if I put a loop into invoke over the spesh slots of the selected candidated and check none are in fromspace, a bunch of them turn out to be [16:14] However, the chosen candidate itself is not in fromspace [16:24] some are terrestrial, some aren't? doesn't sound like a great situation [16:30] Well, it means that somehow, somewhere, the spesh slots are getting messed up [16:31] Or rather, not marked [16:31] But how/why/where is quite a mystery [16:42] It's also odd just how persistent/stable the problem is over all kinds of different changes I attempt [16:46] *** domidumont left [16:47] guess i don't feel so bad i haven't found it yet myself [16:55] Yeah, I think I'll have to give up on it for today. Odd. :/ [16:56] thanks for looking. any suggestions for where i should experiment around? [17:04] I'm really out of ideas (if I had another one I'd alreaedy be trying it...) [17:04] *** domidumont joined [17:04] Only to try and trace if the inter-gen set from the spesh thread is being mishandled somehow but I can't see how that could happen [17:05] I mean, it's as if the spesh slots just don't get GC marked in some GC run [17:05] But how exactly is quite the mystery [17:10] yeah, harder to debug the absence of something [17:18] ¦ MoarVM/oops-for-FSA-of-0: 29052d4dfa | (Nicholas Clark)++ | src/core/fixedsizealloc.c [17:18] ¦ MoarVM/oops-for-FSA-of-0: oops if MVM_fixed_size_alloc() is called for a size of 0 bytes. [17:18] ¦ MoarVM/oops-for-FSA-of-0: [17:18] ¦ MoarVM/oops-for-FSA-of-0: Previously this wasn't trapped. With FSA_SIZE_DEBUG enabled (not the default) [17:18] ¦ MoarVM/oops-for-FSA-of-0: everything works (it can allocate "0" bytes, as it adds its debugging record [17:18] ¦ MoarVM/oops-for-FSA-of-0: keeping to the size requested). With default settings, we corrupt the malloc [17:18] ¦ MoarVM/oops-for-FSA-of-0: heap, which doesn't get reported at the time, and may or may not get reported [17:18] ¦ MoarVM/oops-for-FSA-of-0: in any useful way later. [17:18] rebase! [17:18] ¦ MoarVM/oops-for-FSA-of-0: review: https://github.com/MoarVM/MoarVM/commit/29052d4dfa [17:34] *** zakharyas left [17:45] *** domidumont left [17:45] jnthn: FWIW I've looked through the code systematically and have spent considerable time in rr to trace things and still haven't found the real reason. And yes, I'm baffled as well why all the clear fixes didn't change the behaviour a bit [18:16] *** brrt` joined [18:24] ¦ MoarVM/hash-single-allocation: 16 commits pushed by (Nicholas Clark)++ [18:24] ¦ MoarVM/hash-single-allocation: review: https://github.com/MoarVM/MoarVM/compare/3663fcba8d69^...cd8c07baf825 [18:29] ¦ MoarVM: nwc10++ created pull request #1350: Hash allocation as a single memory block [18:29] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1350 [18:31] *** brrt` is now known as brrt [18:32] nwc10: I'll have a look at it [18:33] you might need peril sensitive sunglasses [18:41] .oO( but but but brrt only has one head ? ) [18:42] usually [18:44] *** zakharyas joined [19:02] *** Altai-man joined [19:05] *** sena_kun left [19:21] *** brrt left [19:25] does build on sparc64 so can't be *that* crack fuelled. [19:25] I can't spell [20:17] Yet another Rakudo Weekly News hits the Net: https://rakudoweekly.blog/2020/09/21/2020-38-council-results/ [20:39] *** zakharyas left [20:57] *** brrt joined [21:08] https://github.com/MoarVM/MoarVM/issues/1351 [21:27] *** Altai-man left [21:30] *** brrt left