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