[00:02] *** reportable6 left [00:04] *** tellable6 joined [00:04] *** squashable6 joined [00:04] *** bisectable6 joined [01:03] *** statisfiable6 joined [01:03] *** releasable6 joined [01:03] *** reportable6 joined [01:04] *** sourceable6 joined [02:05] *** evalable6 joined [03:05] *** bloatable6 joined [04:51] *** MasterDuke left [05:20] *** frost joined [06:03] *** reportable6 left [07:03] *** evalable6 left [07:03] *** notable6 left [07:03] *** statisfiable6 left [07:03] *** unicodable6 left [07:03] *** releasable6 left [07:03] *** quotable6 left [07:03] *** greppable6 left [07:03] *** bloatable6 left [07:03] *** linkable6 left [07:03] *** sourceable6 left [07:03] *** committable6 left [07:03] *** tellable6 left [07:03] *** coverable6 left [07:03] *** nativecallable6 left [07:03] *** shareable6 left [07:03] *** benchable6 left [07:03] *** squashable6 left [07:03] *** bisectable6 left [07:03] *** linkable6 joined [07:04] *** tellable6 joined [07:04] *** shareable6 joined [07:04] *** reportable6 joined [07:04] *** Kaiepi left [07:04] *** unicodable6 joined [07:04] *** notable6 joined [07:04] *** coverable6 joined [07:04] *** evalable6 joined [07:06] *** committable6 joined [07:06] *** statisfiable6 joined [07:24] *** MasterDuke joined [08:04] *** benchable6 joined [08:04] *** bisectable6 joined [08:05] *** quotable6 joined [08:41] *** patrickb joined [08:51] *** patrickb left [08:53] good *, #moarvm [08:53] new-disp can't build the Rakudo setting with MVM_SPESH_NODELAY=1 [08:53] without that (but with everythign else) it can [09:02] Hm, I thought it could pre-vacation... [09:03] Though I may mis-remember [09:03] *** greppable6 joined [09:03] *** nativecallable6 joined [09:03] I *thought* that it could too. But at times I've manged to get my checkouts all muddled [09:04] *** squashable6 joined [09:20] how multi-threading safe are the metamethods supposed to be in general? https://github.com/rakudo/rakudo/pull/4501 is a fix for parsing a grammar in multiple threads, which does seem like something that could reasonably happen [09:21] but what about https://github.com/rakudo/rakudo/blob/master/src/Perl6/Metamodel/AttributeContainer.nqp#L9-L24 (just as a random example)? [09:24] or https://github.com/rakudo/rakudo/blob/master/src/Perl6/Metamodel/ConcretizationCache.nqp [09:28] There's a general expection that they should be used from a single thread during construction, and effectively immutable after compose. Should a meta-object want to have mutable state post-compose then it should take care of threading concerns. [09:29] oops. general *expectation* [09:30] So add_attribute clearly is construction time (pre-compose), so it's user error to call it in parallel. [09:30] The concretization cache I've no idea about; it claims it's used only at compile time (which I guess would mean pre-compose too), but if it's causing bother when parsing grammars from multiple threads, that's clearly not quite the whole story. [09:31] ok, i think that makes sense to me [09:31] I don't quite understand what it's achieving, tbh. [09:31] ConcretizationCache.nqp wasn't the problem, that was just another (somewhat) random example [09:31] ah, k [09:32] *ok [09:34] the PR is a further fix for MVM_oops in https://github.com/Raku/roast/blob/master/S17-promise/start.t#L151-L168 [09:34] follow on to https://github.com/rakudo/rakudo/pull/4496 [09:49] as a foolow up to what Nicholas wrote, there's a bug which leads to compilations errors when MVM_SPESH_NODELAY is enabled [09:50] arghh, crap spelling :( [09:52] ===SORRY!=== Error while compiling /home/dogbert/repos/rakudo/t/spec/S04-statements/with.t [09:52] is default on shaped Scalar not yet implemented. Sorry. [09:52] the above is the error and it is 100 percent reproducible, just set nursery to e.g. 12k and use MVM_SPESH_NODELAY [10:56] Hm, this is curious. --profile-compile on CORE.c.setting seems to record stuff, but then fails to spit out the SQL file at the end (and doens't mention that it's writing profiling data either) [11:05] yeah, it's been doing that for a while [11:06] i successfully did a --profile-compile of CORE.c on 2020-12-12, but i don't know when after that it broke [11:08] CORE.e succeeds [11:08] 47mb sql file [12:02] *** reportable6 left [12:03] *** TempIRCLogger left [12:03] *** TempIRCLogger joined [12:21] Seems it's writing the SQL if I remove --target and --output [12:21] Now I just have to hope it finishes without running out of memory... [12:25] how much do you have? [12:33] 64GB. It finished fine in the end [12:33] *** jgaz joined [12:35] *** jgaz left [12:36] *** jgaz joined [12:37] Then had to tell Comma it could use more memory in order to get it loaded into the profiler UI there :) [12:37] *** jgaz left [12:41] *** JimmyZ joined [12:43] https://github.com/MoarVM/MoarVM/blob/master/src/core/vector.h#L25-L34 # two MVM_VECTOR_ELEMS definded here [12:43] defined [12:47] interesting, i'll have to try removing those two flags, though i do only have 32gb [12:47] find anything interesting in the profile? [13:04] *** moon-child left [13:12] *** reportable6 joined [13:12] Was looking to see if dispatchers show up high in profiling [13:12] *** sourceable6 joined [13:12] *** bloatable6 joined [13:12] The answer to that seems to be "no" [13:12] It's a bit hard to spot them, but I know what files they are in, and looking for things in those files shows that almost no time is spent there. [13:12] *** moon-child joined [13:12] And it's a very similar story for the Raku ones; they're all in BOOTSTRAP, very little time is spent in there [13:24] *** jnthnwrthngtn left [13:24] *** rypervenche left [13:24] *** Util_ left [13:24] *** cognominal_ left [13:24] *** bloatable6 left [13:24] *** sourceable6 left [13:24] *** reportable6 left [13:24] *** JimmyZ left [13:24] *** TempIRCLogger left [13:24] *** squashable6 left [13:24] *** nativecallable6 left [13:24] *** greppable6 left [13:24] *** quotable6 left [13:24] *** bisectable6 left [13:24] *** benchable6 left [13:24] *** MasterDuke left [13:24] *** statisfiable6 left [13:24] *** committable6 left [13:24] *** evalable6 left [13:24] *** coverable6 left [13:24] *** notable6 left [13:24] *** unicodable6 left [13:24] *** shareable6 left [13:24] *** tellable6 left [13:24] *** linkable6 left [13:24] *** frost left [13:24] *** camelia left [13:24] *** moon-child left [13:24] *** japhb left [13:24] *** Nicholas left [13:24] *** JRaspass left [13:24] *** lizmat left [13:24] *** bartolin_ left [13:24] *** raydiak left [13:24] *** Altai-man left [13:24] *** dogbert11 left [13:24] *** kjp left [13:24] *** jdv left [13:24] *** vrurg left [13:24] *** leont left [13:24] *** nine left [13:24] *** Voldenet left [13:24] *** gfldex left [13:24] *** rba left [13:24] *** [Coke] left [13:24] *** AlexDaniel left [13:24] *** leedo left [13:24] *** timo left [13:24] *** discord-raku-bot left [13:24] *** nebuchadnezzar left [13:24] *** Geth left [13:24] *** harrow left [13:24] *** tbrowder left [13:24] *** psydroid left [13:24] *** ugexe left [13:24] *** samcv left [13:28] *** moon-child joined [13:28] *** bloatable6 joined [13:28] *** sourceable6 joined [13:28] *** reportable6 joined [13:28] *** JimmyZ joined [13:28] *** TempIRCLogger joined [13:28] *** squashable6 joined [13:28] *** nativecallable6 joined [13:28] *** greppable6 joined [13:28] *** quotable6 joined [13:28] *** bisectable6 joined [13:28] *** benchable6 joined [13:28] *** MasterDuke joined [13:28] *** statisfiable6 joined [13:28] *** committable6 joined [13:28] *** evalable6 joined [13:28] *** coverable6 joined [13:28] *** notable6 joined [13:28] *** unicodable6 joined [13:28] *** shareable6 joined [13:28] *** tellable6 joined [13:28] *** linkable6 joined [13:28] *** frost joined [13:28] *** japhb joined [13:28] *** camelia joined [13:28] *** Nicholas joined [13:28] *** JRaspass joined [13:28] *** bartolin_ joined [13:28] *** raydiak joined [13:28] *** Altai-man joined [13:28] *** dogbert11 joined [13:28] *** leont joined [13:28] *** lizmat joined [13:28] *** kjp joined [13:28] *** jnthnwrthngtn joined [13:28] *** timo joined [13:28] *** jdv joined [13:28] *** nine joined [13:28] *** discord-raku-bot joined [13:28] *** psydroid joined [13:28] *** AlexDaniel joined [13:28] *** nebuchadnezzar joined [13:28] *** vrurg joined [13:28] *** ugexe joined [13:28] *** gfldex joined [13:28] *** rba joined [13:28] *** Voldenet joined [13:28] *** [Coke] joined [13:28] *** leedo joined [13:28] *** Geth joined [13:28] *** tbrowder joined [13:28] *** harrow joined [13:28] *** rypervenche joined [13:28] *** Util_ joined [13:28] *** cognominal_ joined [13:28] *** samcv joined [13:32] On the upside, I spotted some LHF places to reduce boxing allocations [13:33] And that's 7 million or so GC allocations less when compiling CORE.setting [13:33] m: say 1819 - 1721 [13:33] rakudo-moar 5c74b4053: OUTPUT: «98␤» [13:33] Nearly 100 less GC runs. Too bad most GC runs are fast so I don't see much wallcock speedup :) [13:34] Shall I introduce some O(n³) to the GC? I'm sure I can find something... [13:36] that's a misspelling i've never seen before... [13:37] I had to read what I wrote like 4 times to see it :P [13:41] i wonder if ram prices have come down any [13:44] huh, i thought i tried using list_s in sorted_keys and something broke. maybe it was some other sorting routine [13:45] *** JimmyZ left [13:46] and nope, the same 32gb i bought for $160 almost exactly two years ago is now $200 [13:47] Sell! Sell! Sell! [13:49] Curiously, among the new-disp changes, I've made stage mbc be 0.88s rather than 1.4s in master :) [13:50] Alas, that's the only state that's better [13:50] *stage [13:50] 44.4s parse on new-disp, 37.0s on master [13:51] 9.37s mast on new-disp, 7.93s on master [13:52] *** Guest7810 joined [13:53] nine: have you looked at https://github.com/rakudo/rakudo/pull/4501 ? [13:53] that's probably very obvious, but I recall e.g. inlining / spesh not working at its full power, is it already back? [13:55] MasterDuke: the patch looks good. But as the discussion shows its hard to find the right layer for putting in concurrency safeguards. So I'm a bit reluctant to give judgement... [13:56] Altai-man: In theory, for NQP code - which is what dominates - it's back. [13:57] Altai-man: For Raku code not, but that isn't what's running at compile time of the setting [13:57] OK, this is weird, CORE.setting profiling the compile on master gets killed [13:57] as OOM [13:58] And really does use much more than on new-disp [13:58] That's a bit odd. I can't guess why. [13:58] yeah. i feel a little bit better because i'd started to do something similar to the latest commit, but then switched to just the clone->modify->replace when that fixed the MVM_oops'es and was a smaller change [13:59] So I can't easily get that kind of profile. I can get a callgrind of master for comparison purposes, which will nicely run while I have a short meeting :) [14:00] jnthnwrthngtn: i'm running profile on master now, but had to create a 64gb swapfile, which is almost completely filled (and it's been running for 7 min now) [14:01] i was just recently reading about how good zram is on linux nowadays, i may give that a try next instead of the swapfile [14:13] *** Guest7810 left [14:14] *** Guest6661 joined [14:39] Back [14:39] 2.7gb sql file and still writing [14:40] I think there's a significant inlining difference after all. On master I see 95 million calls to MVM_frame_invoke. On new-disp, 111 million to MVM_frame_dispatch. [14:42] That's about the same ratio as the times for stage parse [14:46] *** frost left [14:48] Curiously, MVM_SPESH_INLINE_LOG=1 doesn't look unusual. [14:48] (It's doing the inlines I'd expect) [14:50] So, do we have other optimizations besides inlining that reduce the number of executed calls? [14:55] Don't think so [14:57] finally finished with a 3.1gb sql file [15:01] dumb question warning: should MVM_spesh_osr_poll_for_result be called even if MVM_SPESH_DISABLE=1 ? [15:04] dogbert11: MVM_spesh_osr_poll_for_result checks whether spesh (including osr) is enabled, so calling it is ok. After all the osrpoint ops will still be in the bytecode. [15:08] nine: thx, I became confused when I saw two spesh related functions among the top ten when doing a callgrind_annotate on a program where spesh was disabled [15:08] Comparing callgrind further: we make a lot less inlining attempts, but we also end up with a lot less calls to optimize_runbytecode, which is the successor to optimize_call, and so perhaps we're missing translating more dispatch programs than I think [15:14] doh. tried to read the sql in sqlite3 and got `Error: near line 180950: out of memory` [15:15] which is only 7 lines from the end of the file [15:24] ugh [15:27] I found one easy NYI that was causing quite a few missed dispatch program translations: when we were monomorphic in a given specialization but there was a polymorphic inline cache entry, we didn't translate the dispatch program [15:31] ¦ MoarVM/new-disp: 0a3e14cc29 | (Jonathan Worthington)++ | src/spesh/disp.c [15:31] ¦ MoarVM/new-disp: Handle missed monomorphism in specializations [15:31] ¦ MoarVM/new-disp: [15:31] ¦ MoarVM/new-disp: We may have a polymorphic callsite according to the inline cache, but [15:31] ¦ MoarVM/new-disp: also have statistics indicating that, for the specialization we are [15:31] ¦ MoarVM/new-disp: producing, only one of the dispatch programs tends to be hit. In this [15:31] ¦ MoarVM/new-disp: case, translate that dispatch program. [15:31] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/0a3e14cc29 [15:41] Hm, a more general restructuring is warranted in this area, in fact. :) [15:52] dogbert11: I think you were right. That spesh issue seems to be new. It doesn't occur at the commit before my hllize dispatcher work. [15:53] Question now is: is it the hllize dispatcher that's wrong or does it just uncover some spesh oddity? [15:58] nine: what does your gut tell you? [16:04] *** releasable6 joined [16:08] Nine's debug rule #1: the bug is always in your own code [16:17] Even weirder: the original exception that happens is: Malformed UTF-8 near bytes 20 4c 8b at line 1 col 53 [16:17] ¦ MoarVM/new-disp: a4bbc1b5d6 | (Jonathan Worthington)++ | src/spesh/disp.c [16:17] ¦ MoarVM/new-disp: Use inline cache entry to drive optimization [16:17] ¦ MoarVM/new-disp: [16:17] ¦ MoarVM/new-disp: If we see that the inline cache entry indicates a callsite we cannot [16:17] ¦ MoarVM/new-disp: translate, there's no point doing further analysis. Similarly, if it is [16:17] ¦ MoarVM/new-disp: monomorphic then we don't need to consider the chosen dispatch program [16:17] ¦ MoarVM/new-disp: statistics; just translate it right off. (This also gets us better [16:17] ¦ MoarVM/new-disp: outcomes in some cases where we miss statistics for whatever reason.) We [16:17] ¦ MoarVM/new-disp: thus only look at the logged outcomes when we have a polymorphic inline [16:17] ¦ MoarVM/new-disp: cache entry and might be able to use the stats to turn it monomorphic. [16:17] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/a4bbc1b5d6 [16:21] And the Malformed UTF-8 is the debug name of a class. Because the class_handle in the getattr is totally bogus [16:25] Since the speshed version of the broken frame doesn't have a getattr_o op anymore, I assume we deopted [16:25] *** dogbert11 left [16:27] Oh, the "object" getattr_o is trying to get the STable from is already an STable [16:27] Taking a bit of a leap here: maybe my hllization dispatcher needs to guard on concreteness as well? [16:28] Looks like it already does: nqp::dispatch('boot-syscall', 'dispatcher-guard-concreteness', $arg); [16:31] But, the lang_hllize dispatcher doesn't! [16:31] And adding the guard there as well seems to fix the test case [16:34] nine: If you use dispatcher-track-attr, it automatically adds guards on type and concreteness [16:34] To ensure that such can't be forgotten [16:36] jnthnwrthngtn: the missing guard is in lang_hllize, i.e. in MoarVM. The getattr thing is just a victim of a wrong hllize result. [16:38] ah [16:39] So with the above commits I certainly see an improvement [16:39] Although still not enough [16:41] The problem with taking such leaps (despite the success) is....I don't really know what to write in the commit message :D I actually don't know how the missing guard led to the STable getting where an object should be. [16:44] ¦ MoarVM/new-disp: 4b5a965c95 | (Stefan Seifert)++ | src/disp/boot.c [16:44] ¦ MoarVM/new-disp: Guard for concreteness of lang_hllize arg [16:44] ¦ MoarVM/new-disp: [16:44] ¦ MoarVM/new-disp: Otherwise we may end up with an STable where we expect an MVMObject [16:44] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/4b5a965c95 [16:44] In a pinch...write what you know [16:48] *** dogbert17 joined [16:48] What the?! I tested the settings build with MVM_SPESH_BLOCKING and MVM_SPESH_NODELAY and even with a smaller nursery before committing. But now the build fails with "Cannot call trait_mod:; no signatures match" [16:48] And it's clearly the added guard. How can that be? [16:50] nine: FWIW, your fix removed one of the problems I had, the other one is still present [16:51] i.e. MVM_SPESH_NODELAY=1 ./rakudo-m -Ilib t/spec/S32-io/utf16.t tends to hang [16:55] ¦ MoarVM/new-disp: ff8a2d8e7c | (Stefan Seifert)++ | src/disp/boot.c [16:55] ¦ MoarVM/new-disp: Revert "Guard for concreteness of lang_hllize arg" [16:55] ¦ MoarVM/new-disp: [16:55] ¦ MoarVM/new-disp: This reverts commit 4b5a965c95054e28ffb6c5fc1b7b1707c69b41e1. [16:55] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/ff8a2d8e7c [16:56] oops [16:56] I think the change had a GC issue anyway [17:01] "we'll fix it in post", er, on a rebase... [17:14] Hm, 5 million less frames created according to callgrind [17:15] Down from ~112 million to ~107 million. master still at 95 million. [17:18] Quite a lot more optimize_runbytecode calls, though [17:19] dogbert17: ah yes, that was one that hangs for me like that too [17:43] *** dogbert17 left [17:43] *** dogbert17 joined [17:53] *** dogbert17 left [18:01] *** dogbert17 joined [18:02] *** reportable6 left [18:03] *** reportable6 joined [18:57] wow, i just did a profile-compile of core.c on new-disp and it's only 1gb (compared to master's 3.1gb) [19:01] wow, how is that [19:01] arg. but still `Error: near line 59273: out of memory`, only 5 lines from the end this time [19:01] ahahaha [19:01] sqlite says that? [19:02] yeah [19:02] if i do a .read of the file [19:02] you can possibly just toss out the garbage collector runs [19:02] they aren't quite as important as the rest [19:02] and you can also almost read them just from the sql [19:06] huh, i just did `grep -v 'INSERT INTO gcs' >new_prof` and sqlite3 didn't like .reading new_prof. lots of `Error: near line 2997: UNIQUE constraint failed: calls.id` [19:06] oh, hum [19:06] are they spread over multiple lines perhaps? [19:06] guess so [19:07] but that could be more a syntax error [19:07] btw, i wonder if it would be better to wrap each individual section in BEGIN/END, rather than the entire file [19:11] oh, and weird, they aren't spread over multiple lines [19:12] the only lines that don't have 'INSERT INTO' are the BEGIN/END and the 'CREATE TABLE' lines [19:13] oh did you make sure to restart the sqlite shell in between .read? [19:13] oh, but the deallocations table has a `FOREIGN KEY(gc_seq_num, gc_thread_id) REFERENCES gcs(sequence_num, thread_id)` [19:14] oh, ok, that's not helpful then [19:14] nothing references the deallocations table, so i can just exclude those too [19:15] right [19:15] no, same error... [19:17] doh, nm. that works [19:20] Error: near line 59271: out of memory [19:21] well, it did populate a bunch of stuff [19:24] hm, not sure i trust what's there [19:25] i don't believe that https://github.com/rakudo/rakudo/blob/new-disp/src/core.c/set_proper_subset.pm6#L116 is the top by exclusive time [19:25] for core setting? [19:26] I would be surprised that it is even used in the core setting? [19:28] yeah, maybe those last three lines i'm missing are important [19:34] huh, sqlite doesn't appear to be filling my memory. it must be some internal thing? [19:37] probably using shared memory with a five on disk or perhaps in /tmp [19:38] and it forces it to be resident in memory maybe? [19:42] *** dogbert17 left [19:42] *** dogbert11 joined [19:46] *** Guest6661 left [19:48] *** TempIRCLogger left [19:48] *** TempIRCLogger joined [19:52] huh. i stuck a `END;BEGIN;` in the middle of the file and it finished reading it [19:52] but it still give wacky results [19:53] :o [19:58] maybe we should have it write `END;BEGIN;` every 10k lines or so [20:06] *** dogbert17 joined [20:09] *** dogbert11 left [20:10] *** dogbert17 left [20:13] *** dogbert17 joined [20:49] fwiw, I shoved the sql output from new-disp CORE.setting into Comma's profile viewer and the data looked sane, so I think the SQL itself is alright [20:50] huh [20:50] `select case when r.name = "" then "" else r.name end as name, r.file, r.line, sum(entries) as entries, sum(case when rec_depth = 0 then inclusive_time else 0 end) as inclusive_time, sum(exclusive_time) as exclusive_time from calls c, routines r where c.id = r.id group by c.id order by exclusive_time desc limit 30;` is what i was running [20:52] *** dogbert17 left [20:54] i'm not sure i've used comma's profile viewer, how do i do that? [20:57] i'm not sure if it lets you import an existing sql file or only lets you record stuff anew [20:57] oh lol [20:58] heh, maybe if i just copy it to '/tmp/comma-profiler.sql' [20:59] no [21:00] *** dogbert17 joined [21:01] probably needs exact timing [21:08] timo: No released version lets you do that, it's a new feature we're adding for the next release :) [21:08] Which I needed to do some testing of today anyway. [21:08] ah, nice [21:09] :+1: [21:27] Seems much of the opt shortcoming that remains is because we're ending up with missing typle tuples and static frame info in the spesh stats for some calls [21:27] I'm really not sure why [21:28] anything related to OSR? which is what i saw, but that was in raku code, not nqp code inside rakudo [21:29] No, I see lots of non-OSR cases [21:29] Weird [21:29] afk for a bit [21:30] i've always wanted a little thermal printer, i should hook that up to spesh logs [21:30] (not the dumps, the actual logs that threads sumbit to the spesh thread) [22:39] *** dogbert11 joined [22:43] *** dogbert17 left [23:13] ¦ MoarVM/new-disp: 725cad0bbc | (Jonathan Worthington)++ | 4 files [23:13] ¦ MoarVM/new-disp: Reinstate building arg tuples from facts [23:13] ¦ MoarVM/new-disp: [23:13] ¦ MoarVM/new-disp: This can give us some further opportunities for specialization linking [23:13] ¦ MoarVM/new-disp: and inlining. [23:13] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/725cad0bbc [23:13] ¦ MoarVM/new-disp: cd30dcbc6d | (Jonathan Worthington)++ | 3 files [23:13] ¦ MoarVM/new-disp: Stub in callstack record for calls set up in C [23:13] ¦ MoarVM/new-disp: [23:13] ¦ MoarVM/new-disp: For the case where we will pass them arguments. Today we steal the [23:13] ¦ MoarVM/new-disp: arguments buffer of the current frame, however that is going away, so [23:13] ¦ MoarVM/new-disp: we'll need another way to store the arguments being passed and keep them [23:13] ¦ MoarVM/new-disp: marked. [23:13] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/cd30dcbc6d [23:27] ¦ MoarVM/new-disp: 7b09353220 | (Jonathan Worthington)++ | src/core/interp.c [23:27] ¦ MoarVM/new-disp: Use local for bytecode offset calculation [23:27] ¦ MoarVM/new-disp: [23:27] ¦ MoarVM/new-disp: Rather than going through a level of indirection. [23:27] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/7b09353220 [23:28] Still haven't got to the bottom of why it seems to miss so many things [23:29] Enough for today, though.