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:02 reportable6 left 00:04 reportable6 joined 01:04 squashable6 left, reportable6 left, notable6 left, bisectable6 left, coverable6 left, committable6 left, unicodable6 left, evalable6 left, quotable6 left, benchable6 left, greppable6 left, releasable6 left, shareable6 left, tellable6 left, statisfiable6 left, bloatable6 left, nativecallable6 left, sourceable6 left, linkable6 left, linkable6 joined 01:05 committable6 joined, bloatable6 joined, bisectable6 joined, quotable6 joined, releasable6 joined 01:06 benchable6 joined, evalable6 joined, coverable6 joined 01:07 nativecallable6 joined 01:20 frost joined 02:01 rakuUser left 02:04 statisfiable6 joined 02:06 tellable6 joined 02:07 unicodable6 joined 02:49 tealecloud joined 02:54 tealecloud left 03:04 squashable6 joined 03:06 sourceable6 joined, notable6 joined, shareable6 joined, reportable6 joined 04:06 greppable6 joined 04:10 nebuchadnezzar left
nine dogbert11: sorry, still no joy 05:57
06:02 reportable6 left 06:46 nebuchadnezzar joined 06:50 tealecloud joined
Nicholas good *, #moarvm 06:55
06:55 tealecloud left 06:56 patrickb joined 07:04 reportable6 joined
Nicholas nine: this "evening" thing is a myth? At least, it's not useful for progress with coding? 07:11
MasterDuke nine: dogbert11's segv in io-cathandle.t just reprod for me in the second run 07:16
took a couple more tries to get it in gdb, but just did 07:18
list
`tc=0x798912`, that's not right... 07:19
nine So...what am I doing wrong? I am up to date on new-disp in all 3 repos, set GC_DEBUG to 1 and MVM_NURSERY_SIZE to 16 * 1024 and did a debug build.
Running: while MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 gdb --ex 'set confirm' --ex run --ex quit --args /home/nine/rakudo/install/bin/moar --execname=/home/nine/rakudo/rakudo-m --libpath=/home/nine/rakudo --libpath=/home/nine/rakudo/blib --libpath=/home/nine/rakudo/install/share/nqp/lib /home/nine/rakudo/rakudo.moarvm -Ilib t/spec/S32-io/io-cathandle.t ; do true ; done
MasterDuke have you tried compiling with clang instead of gcc? 07:20
nine No. How do I do that? 07:21
MasterDuke oh, i didn't have MVM_SPESH_BLOCKING set
--compiler=clang added to MoarVM's configure 07:22
i built with gcc (like i usually do), but sometimes that's made a difference 07:24
nine Oooooh...indeed, without MVM_SPESH_BLOCKING it took only a few tries! MasterDuke++ 07:27
So we have a corrupted inline cache entry that goes away with MVM_SPESH_BLOCKING 07:30
dogbert11 MasterDuke++, Nine++
07:41 frost left
nine I'm trying to reproduce in rr by running with --chaos. Haven't succeeded so far. But, I have run into this multiple times: moar: src/spesh/deopt.c:32: uninline: Assertion `MVM_callstack_current_frame(tc) == f' failed 07:55
MasterDuke are you also running a spectest in the background? i find that usually helps trigger things 08:00
08:00 tealecloud joined
dogbert11 thought the word rr was a surefire way to wake up timo :) 08:01
Nicholas Maybe he needs to set his IRC client to "trigger" on it. I think that ilmari set his to also trigger on "lunch" 08:02
timo i am awake
Nicholas good UGT, timo 08:03
timo greetings nicholas san
nine Oooh... that assertion failure is due to a GC issue in MVM_spesh_deopt_one 08:18
It's a rather old bug, but the assertion is new, so it only surfaced now 08:19
MasterDuke github.com/apple/swift/pull/39143 is interesting
08:19 psydroid left
nine Ok, it's not _that_ old. It got introduced in fba29b5e6041a5b9fb31dd8783801823eb2a7573 Fri May 15 16:17:51 2020 +0200 08:28
08:28 psydroid joined 09:10 frost joined
Geth MoarVM/new-disp: 3306949e06 | (Stefan Seifert)++ | src/spesh/deopt.c
Fix possible access to fromspace when uninlining during deopt

With commit fba29b5e6041a5b9fb31dd8783801823eb2a7573 the code now in begin_frame_deopt was factored out into its own function. thus the MVMROOT of the frame we're deoptimizing no longer protected the local variables in begin_frame_deopt's callers. This led to potential segfaults and definite
  "Assertion `MVM_callstack_current_frame(tc) == f' failed" errors.
Fix by moving the MVMROOT back out of begin_frame_deopt and into its callers. Fix by moving the MVMROOT back out of begin_frame_deopt and into its callers.		 09:21
jnthnwrthngtn morning o/ 09:38
Nicholas \o 09:39
jnthnwrthngtn Curious. On my walk to work I saw what looked like a relatively low-flying commercial aeroplane with 2 presumably military planes escorting it, one each side. 09:40
nine Most interceptions are due to communications problems 09:42
i.e. radio issues
jnthnwrthngtn Hopefully nothing more serious than that. Or a training exercise. It's not a path I see flights on often (pretty much flying south along the river) 09:44
nine MasterDuke: can you still reproduce the segfault after my latest commit? Because I do not seem to be able to. 10:25
dogbert11: ^^^
10:28 rakuUser joined
dogbert11 nine: I'll test it ... 11:52
preliminary results are very promising :) 11:59
12:02 reportable6 left 12:05 reportable6 joined
dogbert11 nine: I'm unable to reproduce the SEGV after your change :) 12:07
nine yeah! 12:27
dogbert11 but now I'm out of bugs
a shocking development :) 12:28
jnthnwrthngtn o.O 12:41
Nicholas I'm sure you'll wake up (in the morning) and find that it was all a dream. And you have plenty of bugs for company. 12:42
timo the spesh linking we could get back once the resumption search stuff works for inlines, is that the thing that lets us preselect a spesh candidate by index for invocation? for cases where we cant inline because of non inlinable instructions or size or whatever? 13:12
nine timo: that's what I figured
jnthnwrthngtn Yes
And thus an inlining pre-req 13:13
Well, that's a lie.
We also try to inline even if that's not true :)
If the unspesh'd bytecode looks small enough to have a go
nine dogbert11: luckily I still have the t/spec/S17-promise/start.t around for such occasions. And as that one's stubborningly refusing to reproduce in rr, it may keep me busy for a while yet
It often shows as "MoarVM oops: MVM_str_hash_lvalue_fetch_nocheck called concurrently on the same hash" but sometimes as a segfault. 13:14
jnthnwrthngtn nine: If you want to figure out the final failing spectest, I wouldn't be sad ;)
dogbert11 nine: I can repro the t/spec/S17-promise/start.t quite consistently with a cut down version of the test file plus MVM_GC_DEBUG=1 and a 48k nursery 13:57
nine dogbert11: Cool! So what's the golf? 13:58
dogbert11 gist.github.com/dogbert17/77beccab...aca322e5fa 13:59
btw, I do not use MVM_SPESH_BLOCKING=1 only MVM_SPESH_NODELAY=1 14:04
nine Oooh! S17-promise/start.t is sensitive to the !rebuild_table issue, the fix for which is in master, but not yet in new-disp. 14:10
dogbert11 nine: have you already solved the mystery? 14:14
nine That remains to be seen. Rebasing everything on master to get those fixes and will then run the test again. 14:15
dogbert11 "Alas poor bug! I knew it well" 14:16
nine jnthnwrthngtn: somewhere in the AUTOTHREAD business the slash argument to !match-nth loses its container 14:21
jnthnwrthngtn nine: Curious. I wonder why that only happens on new-disp. 14:25
I don't think AUTOTHREAD itself changed
nine It didn't according to the git history
I added nqp::iscont checks to all involved Str methods and get this: gist.github.com/niner/588e0291e1b6...1580515d89 14:26
In !match-cursor we're still good. !match-nth occurs multiple times in the backtrace (presumably because of the autothreading) and fails 14:27
dogbert11: looks good so far!
14:27 frost left
dogbert11 yay 14:30
nine I've tried to reproduce any issue with nursery sizes of 4, 8, 12 and 16K with multiple runs in parallel, but so far start.t has been perfectly stable. 14:42
dogbert11 so it turned out to be a bug you had already fixed 14:43
nine No. It turns out to be a bug MasterDuke++ has already fixed :) 14:45
Well, MasterDuke et. al.
dogbert11 MasterDuke et. al. ++ 14:46
jnthnwrthngtn
.oO( that al guy is terribly productive, shows up everywhere... )
 14:51
nine So, AUTOTHREAD is first called with a containerized Junction as argument 1, then 4 layers deeper again with an uncontainerized Match object 14:55
dogbert11 m: "aa" ~~ m:nth(1|2)/a/; "aa" ~~ m:nth(1^2)/a/;
camelia ( no output )
nine On master however, it's only called once - and with an uncontainerized Regex argument instead 15:00
jnthnwrthngtn: there's an importent difference to master that hits closer to home: master picks the match(Regex:D $pattern, :$nth!, *%_) candidate, which does make sense for m:nth(1^2) while new-disp picks the method match(Regex:D $pattern, *%_) candidate with %_ containing: Hash element = {:nth(one(1, 2))} according to dd 15:20
jnthnwrthngtn Ohhh. 15:22
Then it's relying on the implementation accident mentioned in github.com/rakudo/rakudo/commit/bd...4cbbe90474 15:23
Note the type of :$nth is Any, not Mu 15:24
But still, I'd expect the *%_ candidate (the more general one that handles many adverbs) to work 15:25
nine But...shouldn't it then call match(Regex:D $pattern, :$nth!, *%_) with the individual Junction values?
jnthnwrthngtn Only if we want to reinstate the difference between positionals and nameds 15:26
The candidate with *%_ slurping them up is a matching candidate
m: multi m($a) { 1 }; multi m(*@s) { 2 }; say m(1&2) 15:27
camelia 2
nine When I remove the $nth! candidate on master to force it to go through the general one, I get the exact same error
jnthnwrthngtn m: multi m(:$a) { 1 }; multi m(*%s) { 2 }; say m(a => 1&2)
camelia all(1, 1)
jnthnwrthngtn On new-disp, that second eval would also output 2 15:28
m: "aa" ~~ m:i:nth(1|2)/a/; "aa" ~~ m:i:nth(1^2)/a/;
camelia ( no output )
jnthnwrthngtn m: "aa" ~~ m:p(0):nth(1|2)/a/; "aa" ~~ m:p(0):nth(1^2)/a/; 15:29
camelia Cannot modify an immutable Match (ļ½¢aļ½£)
in block <unit> at <tmp> line 1
jnthnwrthngtn Aha! Le bug on master.
Can be exposed without even removing a candidate, just with using multiple adverbs and giving one a junction 15:30
lizmat I guess /me will have a look at that then?
jnthnwrthngtn Unless nine is already at a soluiton :) 15:31
I'm guessing it fails to bind/propagate $/
nine Isn't $/ that uncontainerized Match object? 15:32
jnthnwrthngtn Dunno, I thought it was binding $/ to the caller's $/ in various places 15:35
nine It seems to be passing $/ down (as argument \slash) and at some point assign into slash. So when I see a Match object in slash I figure $/ was deconted along the way 15:36
lizmat nine: that was the idea I think, yes
jnthnwrthngtn At startup a huge amount of time (25%) is spent doing deserialization of meta-objects (which we do lazily, on first request). It turns out that deserializing the meta-object of Perl6::Grammar results in the allocation of now less than 279855 objects. 15:50
*no less
1) Holy shit! 2) It seems I know where to look to win some startup performance back. :) 15:51
However, presumably we're doing this on master also
nine Wait a minute.... When passing a Junction like 1^2 as :nth to .match, what we essentially expect as result is a Junction of Match objects, right? .match also implicitly sets $/ to _the_ Match object. But, this time we get multiple. That's why $/ contains that Junction. But how is this supposed to work? Who would create those containers to assign into?
We'd basically need a Junction of containers for the assignment to work. But there are no containers in m:nth(1^2) 15:53
m: "ab".match(:nth(1^2), /\w/); dd $/ 16:16
camelia Nil $/ = Nil
Geth MoarVM/new-disp: 8e71d3259e | (Jonathan Worthington)++ | 5 files
Make MVM_bytecode_get_validated_op_info an inline

It's called 230,000 times during startup while we setup inline caches, but does very little work most of the time (just calls MVM_op_get_op); marking it as possible to inline saves us around 3 CPU instructions per call (and the jumps).		 17:08
MoarVM/new-disp: 654aa3fbbf | (Jonathan Worthington)++ | src/core/frame.c
Don't validate instructions in context only frames

When we deserialize closures, we need to create an MVMFrame for each step along the outer chain. However, we may never actually run such a frame. In that case, there's no point validing bytecode and doing a bunch of other setup work (such as building inline caches). If we do actually run the frame, we just validate it later.
This saves ~12.8 million instructions (nearly 2%) at Rakudo startup.
MoarVM/new-disp: 241538de2c | (Jonathan Worthington)++ | src/core/callsite.c
Minor optimizations to callsite insert/drop arg

These are relatively hot in new-disp when recording dispatch programs, and so worth a little attention; this is a saving of nearly a million cycles off Rakudo startup.
lizmat
.oO( making things faster now )
 17:16
jnthnwrthngtn Was too tired from $other-tasks today to do anything tricky, but there was some LHF from reading callgrind output :) 17:17
home, dinner, etc. & 17:18
[Coke] Š”Š¾Š±Ń€Ń‹Š¹ Š“ŠµŠ½ŃŒ 17:48
nine [Coke]: and some appropriate greeting to you if my cyrillic and barely existing Slavic know how don't betray me 17:51
Altai-man .oO( Š“Š¾Š±Ń€Ń‹Š¹ Š²ŠµŃ‡ŠµŃ€ ) 17:52
17:59 linkable6 left, evalable6 left
[Coke] I figured den was more time-agnostic, but vecher is more accurate for those who could read it. 18:01
18:02 reportable6 left, linkable6 joined
Altai-man [Coke], I'd not consider "day" to be any more time-agnostic than "morning" or "evening". OTOH if you are in US, then it's still day for you indeed, and the rules about what to do in the case when time zones differ are non-existent. 18:09
[Coke] Ah. in english, I find "good day" to be agnostic, but yah, the russian may very well be more like "afternoon". is there something time agnostic, or should I just go with ŠŸŃ€ŠøŠ²ŠµŃ‚? 18:10
(or Š“Š¾Š±Ń€Ń‹Š¹ *, I guess. :) 18:11
18:25 timo left 18:27 timo joined 19:01 evalable6 joined 20:01 evalable6 left, sourceable6 left, benchable6 left, coverable6 left, statisfiable6 left, shareable6 left, committable6 left, bloatable6 left, squashable6 left, nativecallable6 left, linkable6 left, tellable6 left, notable6 left, greppable6 left, bisectable6 left, unicodable6 left, quotable6 left, releasable6 left, committable6 joined, bloatable6 joined 20:02 bisectable6 joined, evalable6 joined, shareable6 joined, coverable6 joined 20:03 unicodable6 joined, notable6 joined, greppable6 joined, releasable6 joined, linkable6 joined 20:04 squashable6 joined, nativecallable6 joined
Nicholas good *able6, #moarvm 20:10
Geth MoarVM/new-disp: 8b611db6e1 | (Jonathan Worthington)++ | src/disp/syscall.c
Eliminate duplicate arg checking in syscalls

The boot-syscall dispatcher already makes sure that the callsite is in the shape expected, so we can pull the args directly out of the arg info rather than messing around with a processing context. Shaves 0.7% of the CPU cycles off Rakudo startup, and may have a bigger impact on programs that make a lot of such calls.		 20:24
20:36 tellable6 joined
nine m: "aa" ~~ m:p(0):nth(1^2)/a/; 20:38
camelia ( no output )
20:38 unicodable6 left
nine m: "aa" ~~ m:p(0):nth(1^2)/a/; "aa" ~~ m:p(0):nth(1^2)/a/; 20:38
camelia Cannot modify an immutable Match (ļ½¢aļ½£)
in block <unit> at <tmp> line 1
nine Huh....it's weirder than expected. It doesn't fail the first time?!
20:41 unicodable6 joined
Geth MoarVM/new-disp: db6ab4883a | (Jonathan Worthington)++ | src/disp/program.c
Allocate dispatch program parts more lazily

In some cases we don't have constants, GC constants, or temps, so it's better not to presume we do - especially as the memory stays around as we attach it to the dispatch program.		 20:41
nine Because the autothreading trouble only starts if $/ is a Junction already before the call
jnthnwrthngtn Ah, maybe it's because if it's a Junction it auto-threads it
Rather than passing along a Scalar that we can assign into? 20:42
nine exactly
jnthnwrthngtn Hm, but `Mu \slash` looks like it'd not do that
Maybe that's forgotten somewhere?
MasterDuke jnthnwrthngtn: think that most recent commit will help the leaks in `raku --full-cleanup -e ''` on new-disp? 20:43
jnthnwrthngtn MasterDuke: Unlikely; it just eliminates wastage, but I think dispatch program cleanup should be freeing all of those 20:44
MasterDuke ok
Geth MoarVM/new-disp: a1450d7790 | (Jonathan Worthington)++ | 2 files
Make some tiny GC functions static inlines

These are not inlined, at least not by all C compilers; they are tiny, and the calling cost is about as many cycles as they perform. Another 5 million cycles off Rakudo startup, and one of these three is called regularly throughout program execution, so there'll be savings beyond startup too.		 20:57
jnthnwrthngtn It's interesting to learn what C compilers ain't inlining.
nine It's because there are actually 2 Junctions! 20:58
The first Junction is in $/ and the second one in the :nth argument
jnthnwrthngtn These would all be more impressive ratio wise if I did them after the more difficult improvements :) 20:59
[Coke] nine++
nine It's probably the second Junction that triggers the autothreading and then the autothreading does not distinguish between Mu and Any args
jnthnwrthngtn No, it blindly expands junctions, and in the case of multiple dispatch, that's kinda all it can do 21:00
nine In this case it's not actually multiple dispatch 21:01
jnthnwrthngtn I guess we could say that if you want to control it over multis you'd stick the constraints on the proto 21:03
21:04 reportable6 joined
nine So, I have a fix, but it somehow turns dd 42.any; into an infinite recursion 21:36
[Coke] O_o; 21:39
MasterDuke huh. gist.github.com/MasterDuke17/07eaa...f898dda43c still results in the same `MoarVM panic: Tried to garbage-collect a locked mutex` 21:50
and the backtraces look the same 21:51
22:03 sourceable6 joined, statisfiable6 joined 22:35 patrickb left 23:40 benchable6 joined

Powered by Cro and the RakuĀ® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!