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:43 japhb left 00:44 japhb joined 01:01 japhb left 01:04 reportable6 joined 02:40 squashable6 left 02:43 squashable6 joined 02:51 squashable6 left
Geth MoarVM/new-disp: 8a34255a35 | (Timo Paulssen)++ | 2 files
implement guardnonzero in lego jit
 03:34
timo guardnonzero isn't optimized away in many cases at the moment, even when the op that sets the register that it guards is a literal const_i64 03:35
so some wins to be had there when both the const assignment and the guard can go away 03:39
03:48 kjp_ joined 03:51 kjp left 03:59 kjp_ left 04:54 squashable6 joined 05:10 kjp joined 06:02 reportable6 left 06:04 reportable6 joined 06:09 japhb joined 06:28 squashable6 left 06:30 squashable6 joined 06:32 squashable6 left, squashable6 joined
Nicholas "Good" *, #moarvm 07:22
paste.scsys.co.uk/595643 -- new-disp JIT doing out of bounds reads, causes rakudo build fail.
ASAN doesn't catch this. valgrind does. but you have to know that you want to investigate that build
don't yet know which MoarVM commit cause it, but it's not HEAD
taken a while to work out what the problem really was. 07:23
07:33 linkable6 left, linkable6 joined 07:39 linkable6 left 07:40 linkable6 joined 07:47 linkable6 left, linkable6 joined
Nicholas timo: commit 8a34255a357f93644a0801df9bb74eac6f8428b3 08:23
but the valgrind excitement is not actually the cause of my build failure
09:04 brrt joined 09:59 brrt left 11:19 sourceable6 left, quotable6 left, nativecallable6 left, notable6 left, releasable6 left, benchable6 left, unicodable6 left, bloatable6 left, greppable6 left, committable6 left, statisfiable6 left, tellable6 left, evalable6 left, shareable6 left, coverable6 left, squashable6 left, reportable6 left, linkable6 left, bisectable6 left, committable6 joined, evalable6 joined, squashable6 joined 11:20 sourceable6 joined, notable6 joined, tellable6 joined 11:21 statisfiable6 joined, benchable6 joined, reportable6 joined 11:43 brrt joined
dogbert17 I once again got one of these mysterious 'No subtests run' messages when running a spectest. This time it was t/spec/S15-nfg/mass-roundtrip-nfkd.t 11:51
this time I had compiled with --no-optimize and the gist looks like this: gist.github.com/dogbert17/2c7e49d6...487195f41b 11:54
new-disp, nursery 8k, MVM_GC_DEBUG=1 11:55
hopefully the gist contains some useful information 11:56
11:58 patrickb joined
nine dogbert17: arg_count = 51712 sounds....excessive 12:00
Ah, that's just the legacy stuff. That doesn't mean anything in new-disp
12:03 reportable6 left, reportable6 joined
nine Oh, but version is actually 1 which is MVM_ARGS_LEGACY 12:03
So that bogus data is actually relevant. Though I suspect that it's the version that's wrong. Or rather that some code treated it as version 1 and some other code as version 2 12:05
dogbert17 is there any other field/variable you want to see? 12:07
12:20 quotable6 joined, releasable6 joined, linkable6 joined
nine Is the frame in question the one we're currently dispatching to/from? 12:20
12:22 unicodable6 joined, coverable6 joined
dogbert17 how do I figure that out? 12:25
nine tc->cur_frame is of interest and any frames referenced around the dispatch_polymorphic call 12:29
dogbert17 (gdb) p tc->cur_frame
$11 = (MVMFrame *) 0x7fa42ad34628
(gdb) f 19 12:32
#19 0x00007fa42b320333 in MVM_frame_dispatch (tc=0x5596ab1cae40, code=0x5596accd59b8, args=..., spesh_cand=-1) at src/core/frame.c:670
gdb) p frame
$10 = (MVMFrame *) 0x7fa42ad34880
would it make things easier if you had the coredump file? It's 13 megs (lz4). 12:41
nine I don't think the coredump alone is of use. I think gdb needs the executable and libraries in place to decypher it 12:42
dogbert17 ah 12:47
13:21 bisectable6 joined, shareable6 joined 13:27 brrt left
Geth MoarVM/new-disp: 40f08dcf01 | (Stefan Seifert)++ | 6 files
JIT support for sp_dispatch_*
 14:04
dogbert17 nine++, that fix brought the parse stage down to 57s on my system, master is around 10s faster so it's definitely getting closer 14:09
MasterDuke 53s -> 50s here 14:10
14:20 nativecallable6 joined 14:21 bloatable6 joined 14:31 brrt joined
dogbert17 hmm, now I get another SEGV 14:34
the first four frames are ?? and then it looks like this 14:35
#4 0x00007f5309f78bda in MVM_callstack_unwind_frame (tc=0x7f5309fe15d7 <bind_attribute>, exceptional=83 'S', thunked=0x68206b915211e00) at src/core/callstack.c:477
#5 0x00007f530a0f5004 in MVM_jit_code_enter (tc=0x5648982bee40, code=0x7f52f81a7400, cu=0x564898409ce0) at src/jit/interface.c:24
#6 0x00007f5309f61b85 in MVM_interp_run (tc=0x5648982bee40, initial_invoke=0x7f530a0d272b <toplevel_initial_invoke>, invoke_data=0x5648983739b0, outer_runloop=0x0) at src/core/interp.c:6242
[Coke] kicks off a windows build on new-disp, will report back. 14:41
dogbert17 ha, I can even repro it by running 'while MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 ./rakudo-m -Ilib t/02-rakudo/07-implementation-detail-6.e.t; do :; done' 14:42
MasterDuke if anybody is interested gist.github.com/MasterDuke17/d197f...3f537a6a86 is a perf report of building CORE.c at new-disp HEAD 14:43
yesterday MVM_interp_run was at 30%, today it's 7% 14:45
dogbert17 that's a big improvement
[Coke] ... OHAI build fails: gist.github.com/coke/8bffe7f4823e2...cf07f7d782
MasterDuke github.com/MoarVM/MoarVM/blob/new-...am.c#L1970 is where it's complaining 14:47
[Coke] I'm using strawberry perl + the MS compiler
ugexe wonder if thats because gcc ignores the standard (and is likely what everyone has been using) stackoverflow.com/questions/972263...ray-in-c-c 15:00
dogbert17 aren't VLA's a c99 feature 15:02
nine Indeed, first time I see a stage parse < 40s on new-disp :)
And installing core modules < 10s
And installing core modules < 10s 15:03
dogbert17 your computer is faaast
MasterDuke no errors/warnings from clang
(just building moarvm, no extra analysis or tools) 15:04
oh, after building moarvm with clang i get a segfault in stage parse of the rakudo build 15:09
huh, the coredump backtrace is all blanks 15:13
dogbert17 nine: take a look at this - gist.github.com/dogbert17/2b4f98f6...eb0266522d 15:14
15:21 greppable6 joined
brrt \o 15:28
MasterDuke look at that, some new problems just crop up probably from new jitting of new-disp and then a wild brrt appears. good timing 15:30
brrt hehe
just-in-time.... 15:31
what issue did you run into
Nicholas o/
MasterDuke some new segvs, possibly related to the jitting of sp_dispatch_* and sp_run* 15:33
brrt ah 15:34
and where do I look at them
lizmat sometimes I wonder if an execution mode that would just inline and jit everything before actually executing anything, would maybe make these searches easier?
brrt lizmat: one of my long time aims was to have a way to just execute a piece of MoarVM bytecode in the JIT, w/o relying on spesh and making things 'hot' 15:35
lizmat ok, so it's not a crazy idea :-) 15:36
MasterDuke github.com/MoarVM/MoarVM/commit/40...6928f41d59 and github.com/MoarVM/MoarVM/commit/f5...ec57dad4a4 and github.com/MoarVM/MoarVM/commit/8a...ac6f8428b3 are the newest jit-related commits i think
brrt not at all
it speaks to the authors inexperience that we don't have such a thing yet :-)
MasterDuke: I see the stacktraces, I can probably figure out what's going on if I have assembly, though it is a painstaking process :-) 15:37
MasterDuke you don't execute assembly in your head at the speed of the cpu? 15:38
lizmat is reminded about a story about Steve Wozniak in the Apple I days :-) 15:39
brrt ooh, /me doesn't know the story :-) 15:41
what I mean to say, golf would be highly appreciated, though I will probably look at it, no sooner than tomorrow at the earliest 15:42
and probably later
lizmat basically, when Steve Jobs and him were working in the Apple I, demoing it to potential investors
brrt is getting 5g on monday
uhuh
lizmat it didn't have a BIOS yet, so the first thing Steve Wozniak would be doing when the machine started up, was basically typing in the bios from scratch
every once in a while, he'd stop for a moment, and then continue again 15:43
when asked why, he said: "forward references are a bit more tricky :-)"
brrt lol 15:44
lizmat note: he would by typing in 6502 machine code, no assembler at that stage yet :-)
brrt I almost believe it
lizmat I couldn't easily find the reference :-( 15:45
it rings true to me, as I was able to almost that on a much smaller scale for 8086 code at one point in my life :-) 15:47
*do 15:48
MasterDuke retrocomputingforum.com/t/woz-and-...rence/1230 15:50
patrickb is unsure whether brrt gets a vaccine shot on monday or faster internet...
brrt the vaccine :-) 15:51
second shot, in fact
lizmat MasterDuke: indeed, ok, so paraphrased, but still :-)
MasterDuke yeah, pretty close 15:52
brrt neat story
anyway, I sort of have to be strict; please file an issue with a reproduction and assign it to me, and I'll have a look sometime in the near future :-) 15:55
MasterDuke i haven't been able to repro mine, but maybe dogbert17 can 15:56
brrt thanks in advance :-) 15:57
Geth MoarVM: MasterDuke17++ created pull request #1525:
Silence new warnings introduced in new-disp		 16:06
16:12 brrt left
nine The segfault in t/02-rakudo/07-implementation-detail-6.e.t happens in the JIT compiled version of cclass_elem 16:32
dogbert17 nine: I posted some valgrind output above 16:40
16:41 Kaiepi left, Kaiepi joined
nine But the assembly gdb shows me for the point of the segfault doesn't match any of the newly jited instructions. Instead if fits what MVM_jit_emit_guard does. mov TMP1, WORK[obj]; followed by get_spesh_slot TMP2, spesh_idx; 16:43
dogbert17: unfortunately that's not much help, since we know nothing about the bad read besides its size 16:44
dogbert17 There were more read errors, stupidly I only posted the first one. I added a couple more. 16:45
timo sorry i made the jit a littl bit wrong and then lied down for headache reasons 16:46
Geth MoarVM/new-disp: 422347eaf5 | (Timo Paulssen)++ | src/jit/x64/emit.dasc
guardnonzero shouldn't try to read an operand that doesn't exist
 16:49
nine Cool, so I was on the right track after all :) timo: did my findings help? 16:51
timo it was nicholas' valgrind output that told me 16:54
i hope i didn't force you onto a long goose chase 16:58
nine Not really 17:22
Had rr in a loop while under the shower. A watchpoint on the bytecode itself revealed which frame the bytecode was part of. And finding the guard wasn't that hard, since dereferencing the same register 3 times in a row happens probably only when reading spesh slots and there's only the one place that reads a spesh slot into rdx 17:23
timo good good 17:26
nine I wonder: does this fix all the segfaults that were reported today? 17:40
17:41 evalable6 left, linkable6 left 17:44 linkable6 joined
dogbert17 I haven't seen any since the fix came out 17:46
timo oh no did i make a whole load of segfaults >_< 17:48
i'm sure i would have recovered much more quickly had there not been four different times when the doorbell violently threw me out of bed 17:49
18:02 reportable6 left 18:04 reportable6 joined
nine Well, all's well that ends well :) 18:07
18:43 evalable6 joined
nine jnthnwrthngtn: I have a lead on the Inline::Perl5 breakage on new-disp. Seems to be caused by Inline::Perl5::ClassHOW's find_method returning the code objects in Scalar containers. 19:16
19:17 Kaipi joined, Kaiepi left 19:22 linkable6 left, linkable6 joined
lizmat it shouldn't right ? 19:25
nine Well it doesn't matter on master 19:26
19:44 Merfont joined, Kaipi left 19:48 Merfont left, Merfont joined
nine jnthnwrthngtn: is it possible that overriding a Routine's find_best_dispatchee doesn't have any effect anymore? That seems to cause the remaining Inline::Perl5 issues 19:57
20:02 Merfont left 20:03 Merfont joined 20:31 Merfont left 20:34 Kaiepi joined 20:46 Kaiepi left 21:02 Kaiepi joined 21:13 Kaiepi left, Kaiepi joined 21:28 Kaiepi left 21:30 Kaiepi joined
jnthnwrthngtn nine: Yes, find_best_dispatchee is not used with new-disp 21:43
timo looks like i forgot to call optimize_guard when there's a guardnonzero, even though i put the handling for guardnonzero into optimize_guard 21:44
so that'll be an easy fix
jnthnwrthngtn nine: It's possible we need to stick some deconts somewhere around find_method calls in the dispatchers, although given methods decont on return by default, I'm a little surprised the container ends up escaping. 21:45
timo ha, now guardnonzero doesn't exist any more in the speshlog of this random nqp build command
jnthnwrthngtn nine: But nqp::decont around find_method calls will work
Geth MoarVM/new-disp: 06545de685 | (Timo Paulssen)++ | src/spesh/optimize.c
actually handle sp_guardnonzero in spesh optimize
 21:46
jnthnwrthngtn I see y'all have been busy while I've been having an afk day :) 21:55
The JIT of sp_disaptch is indeed a nice win 22:03
nine++
m: say 23358176 - 22399208 22:18
camelia 958968
jnthnwrthngtn We'll save almost 1MB from CORE.c.setting alone thanks to not having the pre-calculate method caches in there
22:18 linkable6 left
jnthnwrthngtn We can't actually do it yet, becuase istype still ends up relying on legacy method caches as a circularity saw 22:20
That's the only spectest that breaks, though
afaict
Geth MoarVM/new-disp: a3c1c0ea45 | (Daniel Green)++ | 3 files
Silence new warnings introduced in new-disp

Seen with gcc 11.1.0.		 22:24
MoarVM/new-disp: 1aa76bed47 | (Jonathan Worthington)++ (committed using GitHub Web editor) | 3 files
Merge pull request #1525 from MasterDuke17/silence_new_warnings_introduced_in_new-disp

Silence new warnings introduced in new-disp
japhb jnthnwrthngtn: nqp::istype? That's used a *lot*. (So far) it seems to be the fastest way to inspect arbitrary data structures by a fairly large margin, and is thus used by both JSON::Fast and CBOR::Simple. 22:26
Though perhaps that advantage will be smaller in new-disp, since the only reason not to use `when SomeType` is that a couple layers of overhead swamp the actual istype cost. 22:28
(But it eventually ends up just doing that.)
(Er, and I'm assuming new-disp will reduce that overhead.) 22:29
jnthnwrthngtn japhb: nqp::istype won't go away, it just needs re-working to not depend on legacy method caches 22:32
Code using it shouldn't need any changes or notice any differences. 22:33
Other than maybe a speedup in the case that it's non-nominal
timo oh, do we get speedup for Any.isa(Str:D)? 22:39
based on dispatchers? 22:40
might be possible, haven't written any dispatchers yet so not entirely certain
i guess we can guard on the exact type passed and when it matches return true otherwise dispatch to a more complicated implementation that walks the inheritance hierarchy and grabs names from types 22:42
22:48 Kaiepi left, Kaiepi joined 23:20 linkable6 joined 23:48 patrickz joined 23:50 patrickz left 23:52 patrickb left 23:53 patrickb left

Powered by Cro and the Raku® Programming Language.

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

Thank you!