[00:17] Sounds like it [01:29] *** MasterDuke left [01:34] *** leont left [06:55] *** squashable6 left [06:58] *** squashable6 joined [06:58] good *, #moarvm [07:05] Five minutes ago I was thinking about beer. Now I'm thinking about coffee. That's probably a better choice at this time of day [07:06] (not sure why I'm thinking about beer. This doesn't usually happen in the morning. And I didn't drink any yesterday) [07:40] The latter may be the explanation ;) [08:06] *** MasterDuke joined [08:19] if i dreamt about spesh candidate removal i don't remember it, so no nocturnal inspiration to work with this morning [08:39] *** Geth joined [08:47] *** domidumont joined [09:08] *** leont joined [09:19] *** sena_kun left [09:26] *** patrickb joined [09:33] *** zakharyas joined [09:35] *** sena_kun joined [09:46] just confirmed that the two specializations of reify-at-least (one before there was an eventual spesh candidate removed, one after) are identical. same callsite, same positional flags, same type tuple, same code in the befores and afters [10:26] *** patrickb26 joined [10:27] *** patrickb left [10:35] the impression i'm getting is that simply removing the candidate isn't enough if it's getting recreated exactly as it was before [10:42] If it's getting recreated exactly as before then apparently the data that was used for its creation is apparently now pretty similar. [10:42] I wonder if there's any left-behind statistics somewhere [10:43] yeah, either there's some weird cycle of initial condition, new condition causing deopts and removal, similar-to-initial condition, another new condition causing deopts [10:44] should removing the candidate clear some statistics somewhere? [10:45] /* Specialization statistics assembled by the specialization worker thread [10:45] * from logs. */ [10:45] MVMSpeshStats *spesh_stats; [10:45] It's those [10:45] And no, they're held at the frame level, not the candidate level [10:46] Since they're used to decide what candidates to produce [10:51] oh ha, a candidate for reify-at-least is removed twice [10:52] so actually a candidate is created three times [11:18] *** Geth left [11:57] *** zakharyas left [12:21] *** sena_kun left [12:40] *** sena_kun joined [12:55] *** sena_kun left [12:56] *** sena_kun joined [13:09] *** zakharyas joined [13:56] *** Altai-man_ joined [13:58] *** sena_kun left [14:06] *** sena_kun joined [14:08] *** Altai-man_ left [14:11] ugh, i just keep looking at the same code over and over. think it might be time to switch to some other project [14:14] Was there any effect from clearning out the spesh stats hanging of the static frame spesh at the point of doing the deopt? [14:15] oh, i thought you meant they shouldn't be cleared since it was the frame that owned them. heh, i'll give that a try [14:15] Ah, sorry. I was only trying to point out where they are, not to imply they aren't worth clearning. :) [14:20] hm, adding `MVM_spesh_stats_destroy(tc, spesh->body.spesh_stats);` at the end of MVM_spesh_candidate_discard_one causes an instant segfault in MVM_spesh_stats_gc_mark [14:20] You may need to NULL it out also [14:21] yay, Ryzen arrives tomorrow evening, it seems [14:22] nice. you're getting a pretty beefy one, right? [14:23] no segv, but still 688k deopts... [14:27] Yes, Ryzen 9 5950X [14:27] i think it's getting cleared. spesh log shows an opt removal because of 949 deopts, but then the next stats shows only 389 hits [14:27] OK, that's probably a sensible thing to have done [14:28] (Clearing the stats, that is. Not rebuilding the very same deopting code over again.) [14:37] nice. no way i can justify upgrading from zen 2 to zen 3, but maybe when the 4s come out... [14:48] oh, but now there are some minor differences between the first speshialization made and the third [14:51] Hm, and are they in the right place? :) [14:53] i don't think so [15:03] after an sp_resolvecode, first had sp_guardsf then sp_guardconc. third has just the sp_guardsf. this happened twice [15:04] in "Facts, first had a `r10(45): usages=0, flags=8     Concr`, `r24(14): usages=0, flags=0`, and `r24(14): usages=0, flags=0` that the third didn't [15:07] fwiw, the deopts are all from an sp_guardtype [15:08] What do the stats that the sp_guardtype is based on look like? [15:08] (Should be able to correlate it by bytecode index) [15:12] you mean something like `[Annotation: INS Deopt One (idx 16 -> pc 512; line 54)]` should have numbers that match up with `Will deopt 120 -> 132`? [15:13] does it have a Logged annotation on there? [15:13] Ah, well, yes [15:13] oh yes [15:13] I guess it's two steps, first find the correct sp_guardtype, then Logged should have a bytecode index [15:13] `[Annotation: Logged (bytecode offset 506)]` [15:14] Though it may be the same as the pc (512 in your case) [15:14] OK, that 506 should appear in the stats [15:14] Assuming we're looking at the correct sp_guardtype, it can tell us why it's deciding the guard is wrth it [15:14] *worth [15:15] 506: 260 x type Any (TypeObj) [15:16] or 126: 4 x type Iterator (TypeObj) [15:17] not sure exactly which sp_guardtype it was [15:20] oh, but now there's a segv building nqp [15:24] `MVM_spesh_args (tc=0x5555555aa8e0, g=0x7ffff0063dc0, cs=0x100000027, type_tuple=0x7ffff0015430) at src/spesh/args.c:316` that's not a valid `cs` [15:24] *** patrickb joined [15:26] *** patrickb26 left [15:28] seems to be the stats destroying+NULLing. doesn't happen every time [15:31] Oh hmm [15:32] I wonder if it can happen if we are destroying a candidate and creating one in the same pass [15:32] Maybe we should only discard them after we've done this set of work [15:32] so far MVM_spesh_candidate_add has always been somewhere in the backtrace [15:32] e.g. last step in the worker [15:32] After producing all specializations [15:35] here? https://github.com/MoarVM/MoarVM/pull/1426/files#diff-49135fd5981f051672e02174f1ee1b08f69b104c461565e02e33107ae6ae6695L156 [15:38] oh, there is a `MVM_spesh_stats_cleanup(tc, previous_static_frames);` just a couple lines below there [15:42] which does do an MVM_spesh_stats_destroy if `tc->instance->spesh_stats_version - ss->last_update > MVM_SPESH_STATS_MAX_AGE` [15:42] Yeah, that means throw the stats away if we got no new ones for a while [15:43] It'd be nice if we could throw them away if we also deopt'd a candidate for that static frame [15:46] set some sort of flag on the frame when discarding the candidate and add a check for that to the if? [15:53] Yes, probably clearing it after since we only care about it in the current specialization run [16:01] hm, that'd actually be tricky for MVM_spesh_stats_cleanup, since it takes the previously updated frames, not the ones that were just updated (currently updated become previously updated after MVM_spesh_stats_cleanup is called) [16:03] ah [16:03] Maybe it needs doing separately then (go through the candidates we updated this time) [16:04] k [16:14] oh, or the plan, maybe [16:15] ? [16:17] The plan entries have the candidate to remove and the sf to remove it from, thus we can also find in the plan the sfs we should delete stats for too [16:18] right [16:21] we have `previous_static_frames` and `updated_static_frames`, could add a `static_frames_to_remove_stats_from` and push onto it in the MVM_spesh_candidate_discard_one branch, then at the end just loop through it [16:22] That would also work too [16:22] And avoid having to figure it out again later [16:23] oh, or just loop through the plan a second time before it's destroyed calling MVM_spesh_plan_destroy if `kind == MVM_SPESH_PLANNED_REMOVE_OPT` [16:24] s/plan/stats/ [16:27] whoops. `malloc(): invalid next->prev_inuse (unsorted) [16:27] Aborted (core dumped)` [16:27] Yes, that's what I was suggesting with the plan [16:43] https://github.com/MoarVM/MoarVM/pull/1426/commits/ee458d9e9faad20dfc506edbe8f9d560ddcccf5b seems to work [16:44] still all the deopts, but no segvs, etc [16:44] afk for a bit [18:21] *** domidumont left [19:14] *** zakharyas left [19:25] *** patrickb left [19:45] I have beer. This feels like a more appropriate time of the morning for beer [20:21] Oh, beer. That's a good idea. [20:50] *** MasterDuke left [21:05] *** zakharyas joined [21:27] *** zakharyas left [21:55] *** MasterDuke joined [21:57] i had a very interesting golden, milk, double chocolate, stout earlier today. very good, pretty strong too, 8% abv [22:15] *** cog__ joined [22:18] *** cog_ left [23:26] *** squashable6 left [23:28] *** squashable6 joined