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.
timo (this module is only used by tools that want to properly parse the instructions in a spesh dump, which so far i think is only moarvm's tools/graph_spesh.raku) 00:02
Geth MoarVM/main: 17c62f129b | (Timo Paulssen)++ | tools/graph_spesh.raku
freshen up graph_spesh.raku

  - deprecated "path" method -> IO
  - support lines with comments, show them in output
  - support uint literals
  - support coderefs to closures
  - support more than one unparsed line
  - mark each FH's Goto block in overview
00:07
timo and obviously i've been the only one who used this tool :P
MasterDuke nice. i always forget about the various scripts/tools in the repos 00:32
timo spesh_goggles (my new project) is going to om nom the majority of graph_spesh.raku
MasterDuke cool beans 00:34
timo /* Make a post-inline pass through the graph doing things that are better 00:47
* done after inlinings have taken place. Note that these things must not
* add new fact dependencies.
.... uh oh? i don't think i've paid attention to this last note? and i'm not sure i understand why it exists?
2bab220aff0be5f979218d761b3a9ed9507a445e put this in 00:52
MasterDuke what does it mean to add (or not) a new fact dependency? 00:55
timo be56234ee03f150cf750d88ee98ca0b8b9e8328b might actually have removed the need for the comment in question 00:56
when we set a fact in an optimization that requires another fact, the one fact can set the other fact as a dependency
some facts are set by guards created from things we logged during regular execution 00:57
if the facts that these guards are giving us are not used for any optimizations, they stay "unused", and then we can throw out the guard instructions
bedtime o/ 01:01
MasterDuke later... 01:03
02:10 kjp left 02:11 kjp joined 02:12 kjp left, kjp joined
MasterDuke when building CORE.c, 9959354 VMArray's are garbage collected with 0 elems 02:22
that seems inefficient, why did we create all those? 02:23
here's an example github.com/MoarVM/MoarVM/blob/main...#L878-L891 03:23
378962 times total_fates was 0
but just returning NULL in that case breaks things 03:24
same with VMNull
should there be a `tc->instance->array_consts.(int|str|hll)_empty` like there is for strings? 03:28
06:09 sugarbeet left, sugarbeet joined
nine Arrays are mutable 06:53
Geth MoarVM/main: 5e52422f43 | (Stefan Seifert)++ | src/io/procops.c
Add missing MVMROOT to spawn_setup

MVM_repr_box_int can allocate which can trigger the GC. This would move the freshly allocated arr which outdates our pointer.
07:04
07:46 harrow left 07:49 harrow joined 07:57 evalable6__ joined
timo we do have a potential mechanism that we can use to cause a violent explosion if any code ever tries to add anything to the "empty array" constant. but do we actually allocate the storage for the VMArray in question? 08:01
08:02 evalable6 left
timo but making the code cope properly with a VMNull returned from nfa_run would also be a good idea so we can leave these allocations out entirely 08:02
it requires a rebootstrap :D 08:17
08:22 lizmat left, gfldex left, ingy left, coleman left, JRaspass left 08:34 lizmat joined, gfldex joined, ingy joined, coleman joined, JRaspass joined 14:14 MasterDuke left 17:42 sena_kun joined 20:55 sena_kun left
timo m: say 7566820 * 100 / (7566820 + 9483189) 21:03
camelia 44.380152527
timo m: say 7557710 * 100 / (7557710 + 9863325)
camelia 43.38266928
timo i put a fprintf with 0 or 1 if the elems of a VMArray had 0 elems at time of gc_free, and when returning VMNull from nfa_run with an empty fates array, these are the numbers i get from core setting compilation 21:04
the number starting in 7 is the number of non-empty arrays 21:05
lizmat so most of them remain empy ? 21:07
timo yeah, the biggest source of arrays that end up empty is not the NFA runs
actually, this also includes arrays that have had all their elems popped or shifted out
that's not what i wanted to measure 21:08
m: say 9742214 * 100 / (9742214 + 7307728) 21:17
camelia 57.13927942
timo m: say 9734298 * 100 / (9734298 + 7731185)
camelia 55.73449071
timo now the number with the 9 is when an array had slots allocated, the number with the 7 is when it had no slots allocated, so it was empty at the end and never had anything in it in the first place 21:20
21:21 MasterDuke joined
timo with rr i can take an array at the time it's freed, set a watchpoint for when it was created, and travel back in time to get a stack trace of its creation 21:25
MasterDuke nine, timo: yeah, i was thinking last night about how arrays are containers and that makes this analysis harder. especially since there might be a lot of `while (@a.shift) {}` or `while (@a.pop) {}` throwing my numbers off 21:26
timo thankfully we have not just elems but also sslots 21:29
no ssize is the name
MasterDuke right, i mean to rerun and print that out also... 21:31
7731257 gc_free of 0 elems and 0 ssize 21:32
so i guess those are the candidates for trying to not even MVM_repr_alloc_init() 21:35
btw. why do we adjust the nursery for bigints and the buffers used in async io, but not for arrays or hashes? 21:37
afk for a while 21:38
timo i guess for hashes we usually also get pressure from MVMObjects we put in? arrays on the other hand can of course be native int arrays and such 21:43