|
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. |
16:17 | |
| 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. |
16:38 | |
| 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 | |||
| *off | |||
| 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. |
21:06 | |
| 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
|
|||