[00:02] *** reportable6 left [00:43] *** japhb left [00:44] *** japhb joined [01:01] *** japhb left [01:04] *** reportable6 joined [02:40] *** squashable6 left [02:43] *** squashable6 joined [02:51] *** squashable6 left [03:34] ¦ MoarVM/new-disp: 8a34255a35 | (Timo Paulssen)++ | 2 files [03:34] ¦ MoarVM/new-disp: implement guardnonzero in lego jit [03:34] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/8a34255a35 [03:35] guardnonzero isn't optimized away in many cases at the moment, even when the op that sets the register that it guards is a literal const_i64 [03:39] so some wins to be had there when both the const assignment and the guard can go away [03:48] *** kjp_ joined [03:51] *** kjp left [03:59] *** kjp_ left [04:54] *** squashable6 joined [05:10] *** kjp joined [06:02] *** reportable6 left [06:04] *** reportable6 joined [06:09] *** japhb joined [06:28] *** squashable6 left [06:30] *** squashable6 joined [06:32] *** squashable6 left [06:32] *** squashable6 joined [07:22] "Good" *, #moarvm [07:22] http://paste.scsys.co.uk/595643 -- new-disp JIT doing out of bounds reads, causes rakudo build fail. [07:22] ASAN doesn't catch this. valgrind does. but you have to know that you want to investigate that build [07:22] don't yet know which MoarVM commit cause it, but it's not HEAD [07:23] taken a while to work out what the problem really was. [07:33] *** linkable6 left [07:33] *** linkable6 joined [07:39] *** linkable6 left [07:40] *** linkable6 joined [07:47] *** linkable6 left [07:47] *** linkable6 joined [08:23] timo: commit 8a34255a357f93644a0801df9bb74eac6f8428b3 [08:23] but the valgrind excitement is not actually the cause of my build failure [09:04] *** brrt joined [09:59] *** brrt left [11:19] *** sourceable6 left [11:19] *** quotable6 left [11:19] *** nativecallable6 left [11:19] *** notable6 left [11:19] *** releasable6 left [11:19] *** benchable6 left [11:19] *** unicodable6 left [11:19] *** bloatable6 left [11:19] *** greppable6 left [11:19] *** committable6 left [11:19] *** statisfiable6 left [11:19] *** tellable6 left [11:19] *** evalable6 left [11:19] *** shareable6 left [11:19] *** coverable6 left [11:19] *** squashable6 left [11:19] *** reportable6 left [11:19] *** linkable6 left [11:19] *** bisectable6 left [11:19] *** committable6 joined [11:19] *** evalable6 joined [11:19] *** squashable6 joined [11:20] *** sourceable6 joined [11:20] *** notable6 joined [11:20] *** tellable6 joined [11:21] *** statisfiable6 joined [11:21] *** benchable6 joined [11:21] *** reportable6 joined [11:43] *** brrt joined [11:51] I once again got one of these mysterious 'No subtests run' messages when running a spectest. This time it was t/spec/S15-nfg/mass-roundtrip-nfkd.t [11:54] this time I had compiled with --no-optimize and the gist looks like this: https://gist.github.com/dogbert17/2c7e49d61833cc1f566ea3487195f41b [11:55] new-disp, nursery 8k, MVM_GC_DEBUG=1 [11:56] hopefully the gist contains some useful information [11:58] *** patrickb joined [12:00] dogbert17: arg_count = 51712 sounds....excessive [12:00] Ah, that's just the legacy stuff. That doesn't mean anything in new-disp [12:03] *** reportable6 left [12:03] *** reportable6 joined [12:03] Oh, but version is actually 1 which is MVM_ARGS_LEGACY [12:05] So that bogus data is actually relevant. Though I suspect that it's the version that's wrong. Or rather that some code treated it as version 1 and some other code as version 2 [12:07] is there any other field/variable you want to see? [12:20] *** quotable6 joined [12:20] *** releasable6 joined [12:20] *** linkable6 joined [12:20] Is the frame in question the one we're currently dispatching to/from? [12:22] *** unicodable6 joined [12:22] *** coverable6 joined [12:25] how do I figure that out? [12:29] tc->cur_frame is of interest and any frames referenced around the dispatch_polymorphic call [12:29] (gdb) p tc->cur_frame [12:29] $11 = (MVMFrame *) 0x7fa42ad34628 [12:32] (gdb) f 19 [12:32] #19 0x00007fa42b320333 in MVM_frame_dispatch (tc=0x5596ab1cae40, code=0x5596accd59b8, args=..., spesh_cand=-1) at src/core/frame.c:670 [12:32] gdb) p frame [12:32] $10 = (MVMFrame *) 0x7fa42ad34880 [12:41] would it make things easier if you had the coredump file? It's 13 megs (lz4). [12:42] I don't think the coredump alone is of use. I think gdb needs the executable and libraries in place to decypher it [12:47] ah [13:21] *** bisectable6 joined [13:21] *** shareable6 joined [13:27] *** brrt left [14:04] ¦ MoarVM/new-disp: 40f08dcf01 | (Stefan Seifert)++ | 6 files [14:04] ¦ MoarVM/new-disp: JIT support for sp_dispatch_* [14:04] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/40f08dcf01 [14:09] nine++, that fix brought the parse stage down to 57s on my system, master is around 10s faster so it's definitely getting closer [14:10] 53s -> 50s here [14:20] *** nativecallable6 joined [14:21] *** bloatable6 joined [14:31] *** brrt joined [14:34] hmm, now I get another SEGV [14:35] the first four frames are ?? and then it looks like this [14:35] #4 0x00007f5309f78bda in MVM_callstack_unwind_frame (tc=0x7f5309fe15d7 , exceptional=83 'S', thunked=0x68206b915211e00) at src/core/callstack.c:477 [14:35] #5 0x00007f530a0f5004 in MVM_jit_code_enter (tc=0x5648982bee40, code=0x7f52f81a7400, cu=0x564898409ce0) at src/jit/interface.c:24 [14:35] #6 0x00007f5309f61b85 in MVM_interp_run (tc=0x5648982bee40, initial_invoke=0x7f530a0d272b , invoke_data=0x5648983739b0, outer_runloop=0x0) at src/core/interp.c:6242 [14:41] * [Coke] kicks off a windows build on new-disp, will report back. [14:42] ha, I can even repro it by running 'while MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./rakudo-m -Ilib t/02-rakudo/07-implementation-detail-6.e.t; do :; done' [14:43] if anybody is interested https://gist.github.com/MasterDuke17/d197f0c4086ca66458f7a03f537a6a86 is a perf report of building CORE.c at new-disp HEAD [14:45] yesterday MVM_interp_run was at 30%, today it's 7% [14:45] that's a big improvement [14:45] <[Coke]> ... OHAI build fails: https://gist.github.com/coke/8bffe7f4823e2ff99d0f7dcf07f7d782 [14:47] https://github.com/MoarVM/MoarVM/blob/new-disp/src/disp/program.c#L1970 is where it's complaining [14:47] <[Coke]> I'm using strawberry perl + the MS compiler [15:00] wonder if thats because gcc ignores the standard (and is likely what everyone has been using) https://stackoverflow.com/questions/9722632/what-happens-if-i-define-a-0-size-array-in-c-c [15:02] aren't VLA's a c99 feature [15:02] Indeed, first time I see a stage parse < 40s on new-disp :) [15:02] And installing core modules < 10s [15:03] And installing core modules < 10s [15:03] your computer is faaast [15:03] no errors/warnings from clang [15:04] (just building moarvm, no extra analysis or tools) [15:09] oh, after building moarvm with clang i get a segfault in stage parse of the rakudo build [15:13] huh, the coredump backtrace is all blanks [15:14] nine: take a look at this - https://gist.github.com/dogbert17/2b4f98f60ca0e77be64a4aeb0266522d [15:21] *** greppable6 joined [15:28] \o [15:30] look at that, some new problems just crop up probably from new jitting of new-disp and then a wild brrt appears. good timing [15:30] hehe [15:31] just-in-time.... [15:31] what issue did you run into [15:31] o/ [15:33] some new segvs, possibly related to the jitting of sp_dispatch_* and sp_run* [15:34] ah [15:34] and where do I look at them [15:34] sometimes I wonder if an execution mode that would just inline and jit everything before actually executing anything, would maybe make these searches easier? [15:35] lizmat: one of my long time aims was to have a way to just execute a piece of MoarVM bytecode in the JIT, w/o relying on spesh and making things 'hot' [15:36] ok, so it's not a crazy idea :-) [15:36] https://github.com/MoarVM/MoarVM/commit/40f08dcf01a7d50a5d33cfc53e640c6928f41d59 and https://github.com/MoarVM/MoarVM/commit/f597e4053cd10d5f1b8aa1515a7aa5ec57dad4a4 and https://github.com/MoarVM/MoarVM/commit/8a34255a357f93644a0801df9bb74eac6f8428b3 are the newest jit-related commits i think [15:36] not at all [15:36] it speaks to the authors inexperience that we don't have such a thing yet :-) [15:37] MasterDuke: I see the stacktraces, I can probably figure out what's going on if I have assembly, though it is a painstaking process :-) [15:38] you don't execute assembly in your head at the speed of the cpu? [15:39] * lizmat is reminded about a story about Steve Wozniak in the Apple I days :-) [15:41] ooh, /me doesn't know the story :-) [15:42] what I mean to say, golf would be highly appreciated, though I will probably look at it, no sooner than tomorrow at the earliest [15:42] and probably later [15:42] basically, when Steve Jobs and him were working in the Apple I, demoing it to potential investors [15:42] * brrt is getting 5g on monday [15:42] uhuh [15:42] it didn't have a BIOS yet, so the first thing Steve Wozniak would be doing when the machine started up, was basically typing in the bios from scratch [15:43] every once in a while, he'd stop for a moment, and then continue again [15:43] when asked why, he said: "forward references are a bit more tricky :-)" [15:44] lol [15:44] note: he would by typing in 6502 machine code, no assembler at that stage yet :-) [15:44] I almost believe it [15:45] I couldn't easily find the reference :-( [15:47] it rings true to me, as I was able to almost that on a much smaller scale for 8086 code at one point in my life :-) [15:48] *do [15:50] https://retrocomputingforum.com/t/woz-and-the-forward-reference/1230 [15:50] * patrickb is unsure whether brrt gets a vaccine shot on monday or faster internet... [15:51] the vaccine :-) [15:51] second shot, in fact [15:51] MasterDuke: indeed, ok, so paraphrased, but still :-) [15:52] yeah, pretty close [15:52] neat story [15:55] anyway, I sort of have to be strict; please file an issue with a reproduction and assign it to me, and I'll have a look sometime in the near future :-) [15:56] i haven't been able to repro mine, but maybe dogbert17 can [15:57] thanks in advance :-) [16:06] ¦ MoarVM: MasterDuke17++ created pull request #1525: Silence new warnings introduced in new-disp [16:06] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/pull/1525 [16:12] *** brrt left [16:32] The segfault in t/02-rakudo/07-implementation-detail-6.e.t happens in the JIT compiled version of cclass_elem [16:40] nine: I posted some valgrind output above [16:41] *** Kaiepi left [16:41] *** Kaiepi joined [16:43] But the assembly gdb shows me for the point of the segfault doesn't match any of the newly jited instructions. Instead if fits what MVM_jit_emit_guard does. mov TMP1, WORK[obj]; followed by get_spesh_slot TMP2, spesh_idx; [16:44] dogbert17: unfortunately that's not much help, since we know nothing about the bad read besides its size [16:45] There were more read errors, stupidly I only posted the first one. I added a couple more. [16:46] sorry i made the jit a littl bit wrong and then lied down for headache reasons [16:49] ¦ MoarVM/new-disp: 422347eaf5 | (Timo Paulssen)++ | src/jit/x64/emit.dasc [16:49] ¦ MoarVM/new-disp: guardnonzero shouldn't try to read an operand that doesn't exist [16:49] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/422347eaf5 [16:51] Cool, so I was on the right track after all :) timo: did my findings help? [16:54] it was nicholas' valgrind output that told me [16:58] i hope i didn't force you onto a long goose chase [17:22] Not really [17:23] Had rr in a loop while under the shower. A watchpoint on the bytecode itself revealed which frame the bytecode was part of. And finding the guard wasn't that hard, since dereferencing the same register 3 times in a row happens probably only when reading spesh slots and there's only the one place that reads a spesh slot into rdx [17:26] good good [17:40] I wonder: does this fix all the segfaults that were reported today? [17:41] *** evalable6 left [17:41] *** linkable6 left [17:44] *** linkable6 joined [17:46] I haven't seen any since the fix came out [17:48] oh no did i make a whole load of segfaults >_< [17:49] i'm sure i would have recovered much more quickly had there not been four different times when the doorbell violently threw me out of bed [18:02] *** reportable6 left [18:04] *** reportable6 joined [18:07] Well, all's well that ends well :) [18:43] *** evalable6 joined [19:16] jnthnwrthngtn: I have a lead on the Inline::Perl5 breakage on new-disp. Seems to be caused by Inline::Perl5::ClassHOW's find_method returning the code objects in Scalar containers. [19:17] *** Kaipi joined [19:17] *** Kaiepi left [19:22] *** linkable6 left [19:22] *** linkable6 joined [19:25] it shouldn't right ? [19:26] Well it doesn't matter on master [19:44] *** Merfont joined [19:44] *** Kaipi left [19:48] *** Merfont left [19:48] *** Merfont joined [19:57] jnthnwrthngtn: is it possible that overriding a Routine's find_best_dispatchee doesn't have any effect anymore? That seems to cause the remaining Inline::Perl5 issues [20:02] *** Merfont left [20:03] *** Merfont joined [20:31] *** Merfont left [20:34] *** Kaiepi joined [20:46] *** Kaiepi left [21:02] *** Kaiepi joined [21:13] *** Kaiepi left [21:13] *** Kaiepi joined [21:28] *** Kaiepi left [21:30] *** Kaiepi joined [21:43] nine: Yes, find_best_dispatchee is not used with new-disp [21:44] looks like i forgot to call optimize_guard when there's a guardnonzero, even though i put the handling for guardnonzero into optimize_guard [21:44] so that'll be an easy fix [21:45] nine: It's possible we need to stick some deconts somewhere around find_method calls in the dispatchers, although given methods decont on return by default, I'm a little surprised the container ends up escaping. [21:45] ha, now guardnonzero doesn't exist any more in the speshlog of this random nqp build command [21:45] nine: But nqp::decont around find_method calls will work [21:46] ¦ MoarVM/new-disp: 06545de685 | (Timo Paulssen)++ | src/spesh/optimize.c [21:46] ¦ MoarVM/new-disp: actually handle sp_guardnonzero in spesh optimize [21:46] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/06545de685 [21:55] I see y'all have been busy while I've been having an afk day :) [22:03] The JIT of sp_disaptch is indeed a nice win [22:03] nine++ [22:18] m: say 23358176 - 22399208 [22:18] rakudo-moar 54f1b7a5f: OUTPUT: «958968␤» [22:18] We'll save almost 1MB from CORE.c.setting alone thanks to not having the pre-calculate method caches in there [22:18] *** linkable6 left [22:20] We can't actually do it yet, becuase istype still ends up relying on legacy method caches as a circularity saw [22:20] That's the only spectest that breaks, though [22:20] afaict [22:24] ¦ MoarVM/new-disp: a3c1c0ea45 | (Daniel Green)++ | 3 files [22:24] ¦ MoarVM/new-disp: Silence new warnings introduced in new-disp [22:24] ¦ MoarVM/new-disp: [22:24] ¦ MoarVM/new-disp: Seen with gcc 11.1.0. [22:24] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/a3c1c0ea45 [22:24] ¦ MoarVM/new-disp: 1aa76bed47 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 3 files [22:24] ¦ MoarVM/new-disp: Merge pull request #1525 from MasterDuke17/silence_new_warnings_introduced_in_new-disp [22:24] ¦ MoarVM/new-disp: [22:24] ¦ MoarVM/new-disp: Silence new warnings introduced in new-disp [22:24] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/1aa76bed47 [22:26] jnthnwrthngtn: nqp::istype? That's used a *lot*. (So far) it seems to be the fastest way to inspect arbitrary data structures by a fairly large margin, and is thus used by both JSON::Fast and CBOR::Simple. [22:28] Though perhaps that advantage will be smaller in new-disp, since the only reason not to use `when SomeType` is that a couple layers of overhead swamp the actual istype cost. [22:28] (But it eventually ends up just doing that.) [22:29] (Er, and I'm assuming new-disp will reduce that overhead.) [22:32] japhb: nqp::istype won't go away, it just needs re-working to not depend on legacy method caches [22:33] Code using it shouldn't need any changes or notice any differences. [22:33] Other than maybe a speedup in the case that it's non-nominal [22:39] oh, do we get speedup for Any.isa(Str:D)? [22:40] based on dispatchers? [22:40] might be possible, haven't written any dispatchers yet so not entirely certain [22:42] i guess we can guard on the exact type passed and when it matches return true otherwise dispatch to a more complicated implementation that walks the inheritance hierarchy and grabs names from types [22:48] *** Kaiepi left [22:48] *** Kaiepi joined [23:20] *** linkable6 joined [23:48] *** patrickz joined [23:50] *** patrickz left [23:52] *** patrickb left [23:53] *** patrickb left