|
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:04
reportable6 joined
00:27
sourceable6 joined,
bisectable6 joined
00:28
evalable6 joined,
linkable6 joined,
greppable6 joined
01:26
benchable6 joined
01:28
shareable6 joined
02:25
rakuUser left
03:27
nativecallable6 joined
03:40
squashable6 left
04:09
lizmat_ joined
04:11
RakuIRCLogger left,
Geth left
04:12
TempIRCLogger left,
lizmat left
04:57
kjp left
05:03
kjp joined
05:40
frost joined
05:41
squashable6 joined
06:02
reportable6 left
06:04
reportable6 joined
08:58
lizmat_ left,
lizmat joined
|
|||
| nine | jnthnwrthngtn: indeed! Many thanks for that fix. Probably safed my whole day today | 08:58 | |
|
08:59
Geth joined
09:00
TempIRCLogger joined
|
|||
| Nicholas | so what are you going to do instead? Weather doesn't look *that* nice | 09:00 | |
| tellable6 | 2021-08-27T20:13:10Z #moarvm <MasterDuke47> Nicholas here's a valgrind log of compiling CORE.e with --full-cleanup and it has a bunch of hash-related leaks gist.github.com/MasterDuke17/3afad...b1ec9fbb4d | ||
| nine | Work on other bugs :D | 09:01 | |
| Nicholas | I'm not sure if that's more fun than my next job - the washing up backlog | 09:02 | |
|
09:17
MasterDuke23 joined
|
|||
| MasterDuke23 | Nicholas: ignore what i said about hash stuff leaking from CORE.e compilation with --full-cleanup. turns out i had the --full-cleanup in the wrong spot, and it wasn't being applied. with it in the right location there aren't any leaks | 09:19 | |
| Nicholas | \o/ | 09:20 | |
| thanks for the update | |||
| I shall return to the washing up... | |||
| nine | MasterDuke23: did you salvage the --full-cleanup support for nqp::exit from moar_asan_fixes? | 09:29 | |
|
09:30
MasterDuke23 left
|
|||
| Geth | MoarVM/container_registry-to-MVMFixKeyHashTable: b33d1cb793 | (Nicholas Clark)++ | 2 files Remove `MVM_6model_add_container_config` from MoarVM's public API. Rakudo eliminated its Scalar container descriptor in April 2020, which was the only remaining external user for this (rakudo/rakudo/@4221f8225fea). Hence we no longer need to expose or export this. As the only MoarVM callers are in the same file, we can go further and convert it to a static function. |
09:46 | |
| MoarVM/container_registry-to-MVMFixKeyHashTable: 9c71064ed1 | (Nicholas Clark)++ | 4 files Simplify `add_container_config` and remove `mutex_container_registry`. MVM_6model_containers_setup() is the only code that writes to `container_registry`. It is only called from `MVM_6model_bootstrap` which is called from `MVM_vm_create_instance`, meaning modification only happens during VM instance setup, which is single threaded. After this `container_registry` is immutable. Hence it no longer needs a mutex to protect access, so remove `mutex_container_registry` and all the code that supports it. |
|||
| MoarVM/container_registry-to-MVMFixKeyHashTable: 2f0d0cd417 | (Nicholas Clark)++ | 6 files Convert `container_registry` to an MVMFixKeyHashTable `container_registry` is now an MVMFixKeyHashTable with static storage. Add a `name` member to `MVMContainerConfigurer`, and the three instances of it are no longer `const` As the hash keys can now be permarooted, this eliminates an iterator loop from `MVM_gc_root_add_instance_roots_to_worklist`. |
|||
| Nicholas | Spotted two fixups needed in commit messages, so there's about to be a --force-with-lease | 09:52 | |
| Geth | MoarVM: nwc10++ created pull request #1533: Container registry to MVMFixKeyHashTable |
||
| MoarVM/container_registry-to-MVMFixKeyHashTable: 1d2091cd2b | (Nicholas Clark)++ | 2 files Remove `MVM_6model_add_container_config` from MoarVM's public API. Rakudo eliminated its Scalar container descriptor in April 2020, which was the only remaining external user for this (rakudo/rakudo@4221f8225fea). Hence we no longer need to expose or export this. As the only MoarVM callers are in the same file, we can go further and convert it to a static function. |
09:53 | ||
| MoarVM/container_registry-to-MVMFixKeyHashTable: 52d1e553bf | (Nicholas Clark)++ | 4 files Simplify `add_container_config` and remove `mutex_container_registry`. `MVM_6model_containers_setup` is the only code that writes to `container_registry`. It is only called from `MVM_6model_bootstrap` which is called from `MVM_vm_create_instance`, meaning modification only happens during VM instance setup, which is single threaded. After this `container_registry` is immutable. Hence it no longer needs a mutex to protect access, so remove `mutex_container_registry` and all the code that supports it. |
|||
| MoarVM/container_registry-to-MVMFixKeyHashTable: 26b2d6fa31 | (Nicholas Clark)++ | 6 files Convert `container_registry` to an MVMFixKeyHashTable. `container_registry` is now an MVMFixKeyHashTable with static storage. Add a `name` member to `MVMContainerConfigurer`, and the three instances of it are no longer `const`. As the hash keys can now be permarooted, this eliminates an iterator loop from `MVM_gc_root_add_instance_roots_to_worklist`. |
|||
|
09:55
MasterDuke_ joined
|
|||
| MasterDuke_ | nine: nope, I completely missed that there were any exit()-related changes in that | 09:56 | |
|
10:07
MasterDuke_ left
|
|||
| nine | PSA: I know what causes the segfault in t/spec/S03-operators/short-circuit.t:101 dogbert11++ reported (empty BB). Fix is probably simple (just look further for instructions) but I'm investigating if we couldn't do better in the first place (avoid those empty BBs) | 10:11 | |
|
10:19
rakuUser joined
|
|||
| dogbert11 | impressive amount of action here today | 10:54 | |
| nine | The weekend can't stop us! | 11:15 | |
| jnthnwrthngtn | nine: Glad to trade in one bug fix from me for a bunch from you :D | 12:00 | |
| nine: Is all that remains with hllize now to rip out the legacy implementation? | 12:01 | ||
|
12:02
reportable6 left
|
|||
| jnthnwrthngtn | Hmm, why on earth did no checks run on github.com/MoarVM/MoarVM/pull/1533 ? | 12:03 | |
| Geth | MoarVM/new-disp: 4 commits pushed by (Nicholas Clark)++, (Jonathan Worthington)++ | 12:04 | |
| jnthnwrthngtn | I trust Nicholas++ to have made sure it all compiles, anyways :) | ||
| nine | jnthnwrthngtn: there's still this one instance to get rid of: github.com/rakudo/rakudo/blob/mast...s.nqp#L192 | 12:05 | |
| jnthnwrthngtn | ah, ok | 12:09 | |
| nine | The deeper I dig into the segfault, the more I wonder how MoarVM can execute anything at all successfully... | 12:11 | |
| So, the segfault happens, because an inlined graph is followed by an empty basic block. I figure, it'd be nicer to just get rid of those after we eliminate instructions (thus getting a simpler graph). I can use merge_bbs which not only gets rid of those empty BBs but makes the graph even simpler, right? | 12:13 | ||
| Only that merge_bbs apparently does not know anything about instructions that have to end a BB like throwish or invokish ops. It relies solely on having multiple successors to stop merging. | 12:14 | ||
| But an MVM_OP_sp_runbytecode_v doesn't require multiple successors. And ah, there's return_o as well, which definitely needs to end a BB. | 12:15 | ||
| So why don't merge_bbs' shortcomings cause explosions all the time? | 12:16 | ||
| jnthnwrthngtn | nine: Probably because nothing that happens after the point they are merged actually cares. I mean, there's no concept of basic blocks in bytecode or machine code. | 12:21 | |
| So this all innevitably gets erased anyway. It's just a question of when | 12:22 | ||
| iirc, merge_bbs happens as one of the final steps | 12:23 | ||
| (If you decide to start calling it at an earlier time, this may of course have consequences.) | 12:24 | ||
|
12:28
squashable6 left
12:46
frost left
|
|||
| Nicholas | jnthnwrthngtn: something recently fixed the Rakudo setting build - it now works (again) with MVM_SPESH_NODELAY=1 | 13:23 | |
| I'm guessing that it was your most recent commit, but I have not checked | |||
|
14:05
reportable6 joined,
TempIRCLogger left
|
|||
| nine | jnthnwrthngtn: merge_bbs is kind of in the middle. It's still followed by pea and the post_inline_pass | 14:09 | |
|
14:14
cognominal left,
cognominal joined
14:32
squashable6 joined
|
|||
| dogbert11 | nine: there's another bug waiting if you manage to fix that SEGV :) | 14:40 | |
| Nicholas | jnthnwrthngtn: yes, fixed. *Before*, setting build failed like this: | 14:54 | |
| Stage start : 0.002 | |||
| Error while compiling, type X::Comp::NYI | |||
| feature: is default on shaped Scalar | |||
| at line 79755, near ";\n\n if " | |||
| at gen/moar/stage2/NQPHLL.nqp:1053 (/home/nick/Sandpit/moar-SAN/share/nqp/lib/NQPHLL.moarvm:panic) | |||
| ... | |||
| commit 7566af62b2093947b48c6646d95134a3ce16f04f fixes this | 14:55 | ||
| nine | So, I now got both the trivial fix and the supposedly more elegant fix by way of merge_bbs working. I'm not sure how to proceed though. I like the merge_bbs fix more, but I'm not 100 % sure it will work in all cases. If the empty BB has multiple predecessors, merge_bbs can still not eliminate it. | 15:08 | |
| I'm inclined to commit both. The trivial fix for making it 100 % safe and the merge_bbs fix because I really do like the shorter spesh dumps. | 15:09 | ||
| dogbert11: what's the other SEGV? | 15:27 | ||
| dogbert11 | it's not a SEGV this time | 15:28 | |
| lang-call cannot invoke object of type 'VMNull' belonging to no language | |||
| to repro, set the nursery to, say 16k, and run 'MVM_SPESH_NODELAY=1 ./rakudo-m -Ilib t/spec/S02-types/range.t' a few times | 15:29 | ||
| the error should show up rather quickly ... | 15:35 | ||
| Geth | MoarVM/new-disp: d678b12069 | (Stefan Seifert)++ | src/spesh/inline.c Fix segfault when inlined frame is followed by an empty BB Successful optimization can lead to basic blocks that are void of any instructions. When we inline a callee and the BB containing the call was followed by such an empty BB, we would run into a segfault when trying to add an INLINE_END annotation onto the instruction following the inlined call. Fix by looping through the BB chain until we find an instruction to annotate. |
15:51 | |
| MoarVM/new-disp: 507fa884db | (Stefan Seifert)++ | 3 files Fix overzealous merge_bbs merge_bbs did not take into account that some instructions like invocations, returns, etc. have to end a BB. This did not lead to any verifyable bugs yet, but it seems prudent to make it more correct, so we don't stumble when rearranging things at some point in the future. |
|||
|
17:56
linkable6 left,
evalable6 left
17:57
linkable6 joined
18:02
reportable6 left
18:04
reportable6 joined
18:28
rakuUser left
18:29
rakuUser joined
18:30
rakuUser left
18:34
MasterDuke92 joined
|
|||
| MasterDuke92 | the weekend might not be able to stop us, but maybe the sheriff of Nottingham can (on holiday at Sherwood Forest) | 18:38 | |
| nine: my approach in github.com/MoarVM/MoarVM/pull/1532 is a bit different than yours in more-asan-fixes, do you have a preference for which? | 18:39 | ||
|
18:58
evalable6 joined
19:24
TempIRCLogger joined
19:41
MasterDuke92 left
20:38
rakuUser joined
21:03
rakuUser1 joined
21:06
rakuUser1 left
21:16
rakuUser left
22:19
shareable6 left,
linkable6 left,
benchable6 left,
squashable6 left,
nativecallable6 left,
notable6 left,
quotable6 left,
bloatable6 left,
releasable6 left,
committable6 left,
reportable6 left,
unicodable6 left,
evalable6 left,
bisectable6 left,
sourceable6 left,
greppable6 left,
tellable6 left,
coverable6 left,
statisfiable6 left,
sourceable6 joined,
notable6 joined,
squashable6 joined
22:20
nativecallable6 joined,
greppable6 joined
22:21
linkable6 joined,
benchable6 joined,
releasable6 joined
22:22
committable6 joined,
bisectable6 joined
22:36
rakuUser joined
22:37
rakuUser joined
23:19
bloatable6 joined,
unicodable6 joined,
coverable6 joined
23:20
tellable6 joined,
quotable6 joined
23:21
statisfiable6 joined
|
|||