Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:03 reportable6 left 00:04 reportable6 joined 00:35 jgaz joined 01:21 jgaz left 02:18 Kaiepi left, Kaipi joined 04:11 japhb left 04:14 japhb joined 05:14 sourceable6 left, bloatable6 left, greppable6 left, statisfiable6 left, unicodable6 left, reportable6 left, evalable6 left, tellable6 left, committable6 left, squashable6 left, linkable6 left, reportable6 joined 05:15 evalable6 joined, squashable6 joined, tellable6 joined, statisfiable6 joined, greppable6 joined 05:16 sourceable6 joined, linkable6 joined, unicodable6 joined, bloatable6 joined, committable6 joined 06:02 reportable6 left 06:04 reportable6 joined 07:02 gfldex joined
Nicholas good *, #moarvm 07:43
08:10 patrickb joined 08:12 dogbert17 joined, dogbert11 left 08:35 squashable6 left 08:37 squashable6 joined
jnthnwrthngtn moarning o/ 09:27
Nicholas \o
jnthnwrthngtn Uff, what a hack, but I can get NQP to rebootstrap on new-disp 09:45
Seems we're going to need two rebootstraps also to fully eliminate things 09:57
nine The joys of bootstrapping when not all parts of the program are actually bootstrapped... 10:00
jnthnwrthngtn I'm making sure I didn't break the JVM build before I rebootstrap on MoarVM
It might not be hard to untangle later but it might well be 10:01
Seems all's well, so rebootstrapped and now some stuff can start being removed :) 10:14
Although I should stop working on this and prepare for this afternoon's job... :) 10:15
We've lost one spectest, but turns out it's because of a missing change from master. 10:24
11:08 sena_kun joined 12:02 reportable6 left 12:05 reportable6 joined 12:26 dogbert11 joined 12:28 dogbert17 left 12:53 MasterDuke joined
dogbert11 spectest run with asan and 4k nursery completed 13:54
jnthnwrthngtn That must take a while 14:00
dogbert11 it did indeed. I see one heap buffer overflow. 14:02
jnthnwrthngtn And that was it, or some panics/segvs too? 14:03
dogbert11 interested parties can take a peek here: gist.github.com/dogbert17/3cc91104...2612b50a24
a few panics as well, not too many though 14:04
jnthnwrthngtn ooh, interesting
dogbert11 Dunno if it's enough information but hopefully it is
jnthnwrthngtn It's a very good lead, at least 14:05
dogbert11 Let me know if more info is needed
MasterDuke realloc of wrong size?
dogbert11 I guess that you both have timos' linikify script installed 14:06
MasterDuke i do 14:07
dogbert11 it's very useful 14:08
nine I've found a nasty GC issue in push_resumption. It calls resume_init_capture which will allocate an MVMCapture, but resume_data holding the arguments is not anchored anywhere, so those args won't get marked
dogbert11 hello nine 14:09
jnthnwrthngtn nine: Hm, they're not part of something (e.g. a register set) that is marked?
dogbert11 MasterDuke: but then again I think it assumes master so it won't show new-disp code :( 14:10
jnthnwrthngtn Need to work on something else for a little bit, but will glance later
nine Not yet. We're in the process of setting up.
MasterDuke yeah, wondered why the line number wasn't right at first
we have an MVM_recalloc, but there are a bunch of cases of MVM_realloc+immediate memset 0 14:12
dogbert11 nine: stumbled upon a GC error which seems to point towards MVM_args_slurpy_positional
the stacktrace look like this: 14:13
#0 MVM_panic (exitCode=exitCode@entry=1, messageFormat=messageFormat@entry=0x7ffff68401e0 "Collectable %p in fromspace accessed") at src/core/exceptions.c:854
#1 0x00007ffff64d6c23 in MVM_VMArray_push (tc=<optimized out>, st=<optimized out>, root=<optimized out>, data=0x621000005fb8, value=..., kind=<optimized out>) at src/6model/reprs/VMArray.c:496
#2 0x00007ffff633ab42 in MVM_args_slurpy_positional (tc=0x618000000080, ctx=<optimized out>, pos=<optimized out>) at src/core/args.c:1092
nine dogbert11: that may not mean anything. As long as outdated values make it into registers, they will show up in all sorts of places 14:15
dogbert11 so the trace could be a red herring then 14:18
MasterDuke ha! `git checkout -b convert_realloc_plus_memset_0_to_recalloc` 14:28
`fatal: A branch named 'convert_realloc_plus_memset_0_to_recalloc' already exists.`
from 2017. apparently i have very consistent naming 14:29
[Coke] HA 15:10
jnthnwrthngtn OK, I'm back to new-disp 15:33
MasterDuke "guess who's back, back again, jnthnwrthngtn's back, tell a friend" 15:36
Geth MoarVM/new-disp: 9d7314a2fd | (Jonathan Worthington)++ | 22 files
Remove the multiple dispatch cache

The new-disp branches of NQP and Rakudo no longer rely upon it. Also go a little further in spesh and remove invocation protocol handling also.
jnthnwrthngtn huh, how on earth did istrue/isfalse ended up getting compiled into the new bootstrap 16:30
16:36 patrickb left
jnthnwrthngtn is confused 16:37
Maybe it needed another trip around the bootstrap loop to get rid of entirely
Geth MoarVM/remove-istrue: 353fb90e70 | (Jonathan Worthington)++ | 11 files
Remove if_o, unless_o, istrue, and isfalse

And the boolification routine that underlies them. They are all replaced by a new-disp based mechanism.
jnthnwrthngtn Guess it can wait :)
MasterDuke admits /me sometimes runs `make m-bootstrap-files; <re-configure and rebuild>; make m-bootstrap-files` a couple times before committing the new files 16:42
is(true|false)_s aren't being removed? 16:43
and sp_istrue_n? 16:45
timo well, the istrue|false_s and n are not polymorphic 16:46
nine The good news is that the push_resumption bug seems to be the actual source of the GC issues. Bad news is that so far I haven't come up with a pretty way to solve it.
Just a working one
timo those work on registers that cannot have types of things
jnthnwrthngtn MasterDuke: Correct, those are staying, for the reason timo said 16:49
MasterDuke ah. so it does make sense to jit them then? 16:50
is(true|false)_s 16:51
jnthnwrthngtn I think we do JIT istrue_s and isfalse_s 16:52
timo dispatchers are a superpower when you want to find some code to run where the choice depends on the details of the type something has and that can be "always the same" or "usually the same" in consecutive executions
jnthnwrthngtn Tracking down the last things that rely on the invocation protocol stuff in MoarVM. Turns out...p6capturelex does, in order to find the code attribute in order to capturelex it 17:08
MasterDuke we have templates for is(true|false)_s, but they're not implemented in the lego jit 17:10
jnthnwrthngtn ah, ok. I thought I'd just seen them in jit stuff somewhere :)
urgh, p6capturelex is kinda horrible 17:13
Though I wonder if any of the things it's defending against ever actually go wrong. If they do something is weird
p6capturelexwhere is worse 17:14
I guess both could become a dispatchers and the VM glue can become a syscall and then both extops can go away 17:15
MasterDuke how many extops left then? 17:16
jnthnwrthngtn Oh my, and then there's two further ops dabbling in weird scoping stuff too
There's currently 12 in total 17:17
So we're not that far of getting rid of 'em
MasterDuke nice
jnthnwrthngtn Goodness, this lot will be quite the pain 17:19
Guess it'll be tomorrow's task 17:22
I'm tired 17:23
But pushed the invocation protocol removal so I'll have that work to hand tomorrow (will probably work from the office tomorrow, thus why I'm not just keeping these various "still need other work first" bits locally)
I'm kinda figuring that if I can eliminate the invocation protocol stuff in MoarVM also, and also the classic invoke ops (and getting rid of the one caes of invokewithcapture that remains) then I might have an easier time of adapting spesh 17:25
lizmat m: dd "a b" cmp ("a","b") # do we consider that to be correct ? 17:37
camelia Order::Same
Nicholas jnthnwrthngtn: you feel the need for a change of coffee? 17:38
MasterDuke lizmat: that doesn't seem right 17:41
lizmat yeah, feels meh to me as well
17:52 sena_kun left 18:02 reportable6 left 18:05 reportable6 joined
jnthnwrthngtn Nicholas: I'm not sure dal counts as a coffee... :) 18:09
19:49 japhb left 19:56 japhb joined
Geth MoarVM/new-disp: a15aa367d2 | (Jonathan Worthington)++ | 14 files
Remove smrt_[int|num|str]ify ops

A mostly straightforward removal. However, the configuration program generator will need a tweak for this; I think it will be a simple one.
jnthnwrthngtn timo: ^^ tweaked the conf program ops, in a way that I think will be OK (at least easy to adapt)
If anybody wants an LHF-ish, I suspect that we can get away with deprecating the tryfindmeth op at this point 21:10
(In MoarVM. In NQP the op exists but compiles into a dispatcher.) 21:11
There's actually two ops, tryfindmeth and tryfindmeth_s 21:12
Also likely can and can_s can go away too
timo kick the can_s down the road, or off the bridge, or something 21:14
jnthnwrthngtn m: say 4119400 - 4080584 21:20
camelia 38816
jnthnwrthngtn 38KB smaller NQP build output from not building the legacy method caches on MoarVM, it seems. I expected maybe a bit more. Though probably will be more dramatic in Rakudo 21:21
ooh, intersting, and some test fails
Well, time to be afk
22:33 evalable6 left, linkable6 left, evalable6 joined 22:34 linkable6 joined 23:54 evalable6 left, linkable6 left 23:55 linkable6 joined 23:57 evalable6 joined