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:03 reportable6 left 00:32 psydroid left, AlexDaniel left 00:33 AlexDaniel joined 00:42 psydroid joined 02:04 reportable6 joined 03:44 squashable6 left 03:45 squashable6 joined 04:52 leedo left 04:53 leedo joined 05:06 jnthnwrthngtn left, jnthnwrthngtn joined 06:04 reportable6 left 06:07 reportable6 joined
nine I think this is it: Instead, a "register parameter area" [6] is provided by the caller in each stack frame. When a function is called, the last thing allocated on the stack before the return address is space for at least 4 registers (8 bytes each). This area is available for the callee's use without explicitly allocating it. 07:46
eli.thegreenplace.net/2011/09/06/s...-on-x86-64
The comment in MVM_jit_emit_prologue tried to tell me this as well: "d: reserve space for GPR registers to c calls (win64) or more space for stack arguments (posix)" 07:47
Ah, and that is why emit_win64_callargs begins counting with 4 when emitting stack args: for (; i < num_args; i++). It's just incidentally the same as the number of register arguments. 07:48
I do think however, that this comment is wrong: "layout: [ a: 0x20 | b: 0x40 | c: 0xa0 | d: 0x20 ]" as 0x20+0x40+0xa0+0x20 is 0x120, not the 0x100 bytes we have allocated. 07:57
It used to say: "layout: [ a: 0x20 | b: 0x20 | c: 0xa0 | d: 0x20 ]" which does add up to 0x100, but was changed (without explanation or visible reason) in commit github.com/MoarVM/MoarVM/commit/f2...5c5f89cf45 08:17
[Coke]: please try this patch (replaces all previous ones) gist.github.com/niner/d90fac62a3d1...63e3872451 08:24
08:27 frost joined
lizmat is it correct that t/spec/S06-multi/unpackability.t hangs on master ? 09:06
jnthnwrthngtn ^^ 09:07
jnthnwrthngtn lizmat: Uh...if it hangs on master than master has a bug that new-disp has fixed :) 09:08
lizmat ok, I guess I'll add a skip then for now 09:09
jnthnwrthngtn Yeah, sorry. I did check one of the two test cases I added using the bot, and assumed the second one should thus also be fine on master too.
A hang is...surprising 09:10
lizmat seems to hang 50% of the times it is run 09:11
jnthnwrthngtn That's even more weird 09:12
lizmat what can I say ? 09:14
it's the last test you added
jnthnwrthngtn Well, let's skip it for now, and count it as a new-disp improvement ;) 09:29
I'm not inclined to go debug code I've spent a year working out how to replace :D 09:30
jnthnwrthngtn makes a note to unskip it after the new-disp merge 09:32
I'm not surprised if master has bugs around nextcallee and lastcall also, though; the spectest coverage is a bit weak. I'll add some more, and be careful to really check them on master next time 09:33
lizmat jnthnwrthngtn: don't worry about testing on master, I can do that and add skips and todo's if necessary 09:34
dogbert17 are we looking into memory leaks yet or is that too early? 10:04
asan notices quite a few and they all seem connected to one and the same place
I could be wrong but something about this github.com/MoarVM/MoarVM/blob/new-...isp.c#L770 10:06
a gist is probably a lot better :) gist.github.com/dogbert17/5f8a0e94...c3d06baeda 10:09
10:11 linkable6 left, evalable6 left 11:13 evalable6 joined 12:02 reportable6 left 12:07 TempIRCLogger joined 12:12 linkable6 joined
[Coke] nine: just saw your patch, wil tst when dayjo permits. Thanks! 12:27
Geth MoarVM/new-disp: bd2a1212fa | (Jonathan Worthington)++ | src/spesh/disp.c
Ensure temps to release are first annotation

This should hopefully avoid memory leaks due to the annotation not being found and the temps not being released.		 12:33
jnthnwrthngtn dogbert17: Maybe ^^ will help with it 12:34
dogbert17 jnthnwrthngtn: I'm sure it will but I'll check anyway :) 12:48
jnthnwrthngtn: asan is still sad :( gist.github.com/dogbert17/5f8a0e94...c3d06baeda 12:53
I have updated the previous gist so a page refresh might be necessary
jnthnwrthngtn Less leaks, or the same amount? 12:56
dogbert17 Same-ish, 6240 bytes before, 6336 after. Perhaps it changes a bit from run to run 13:00
13:12 evalable6 left, linkable6 left 13:13 evalable6 joined
[Coke] nine: build started. 13:52
13:55 kjp left
[Coke] died. firing up debugger... 13:56
13:57 kjp joined
[Coke] new error! 13:58
14:02 frost left
[Coke] updated gist.github.com/coke/55ba508f67e8e...3e795a215b - let me know what vars you need. 14:02
14:03 reportable6 joined
[Coke] new crash in MVM_args_proc_setup 14:05
14:13 linkable6 joined
nine [Coke]: arg_info in boolify_iter_impl could be interesting 15:23
15:25 evalable6 left, linkable6 left
nine [Coke]: oh, I think I see an error in MVM_jit_emit_dispatch 15:26
15:26 evalable6 joined
nine [Coke]: src/jit/x86/emit.dasc lime 3188 should read "| mov ARG6, TMP5;" instead of "| mov ARG6, TMP6;" 15:27
Might be worth trying before digging deeper
15:27 linkable6 joined
[Coke] sure, one sec. 15:39
You mean x64? 15:41
nine yes
[Coke] looks like the same call stack 15:48
nine Ok. TMP6 was definitely a bug, but a different one 15:54
[Coke] added arg_info 16:10
not a lot in there 16:11
wonder why stacktrace has "external code" in it. 16:12
nine That's usually JIT frames. gdb displays those as ?????????. The code generated by the JIT lacks debug information, so the debugger has no idea what code that is or even where its boundaries are. 16:13
[Coke] gotcha. 16:14
nine [Coke]: ooooh...got another lead! Line 3130 should be "| lea ARG2, [rsp+0x20];" instead of "| lea ARG3, [rsp+0x20];" 16:15
[Coke] sure. 16:17
nine is getting a glimpse of what debugging in the age of punch cards must have been like... 16:24
[Coke] and you don't even get to touch your own punch cards. :) 16:25
I am just young enough to have missed that. I have peers a few years older who went through it.
I did, however, learn how to use vi on the Michigan Terminal System
... wow. used by an entire *eight* universities! 16:28
nine I've been using vim for 20 years. I've never really learned it though :/ 16:29
[Coke] [6~ 16:31
vim was released while I was in college, I think.
holy shit, we got past the first file in nqp! 16:32
nine wooohooo!
[Coke] nqp tests all pass. 16:34
added current windows diff to the gist 16:37
was that particular jit file *just* for windows? 16:41
nine No, it's the one 16:42
[Coke] ah, or embedded inn if I didn't see in the scope of the diff
"in an .if"
mostly OK, but several rakudo test failures 16:43
18-psuedostash, which I've seen on mac on master, and a dozen nativecall failures 16:44
updated gist with failures. Removing debug output... 16:47
if I run the first 2 nativecall failures with .\install\bin\raku ... they work 16:51
(wish prove had a 'retest' option that just ran the previous failures)
nine It actually has. You have to run prove with --state=save normally and when you want to re-run failures you run it with --state=failed 16:56
Geth MoarVM/new-disp: 28cdc89017 | (Stefan Seifert)++ | 2 files
Fix build issues on MSVC

MSVC doesn't support C99 variable sized automatic arrays, so use malloc instead. It also requires at least one value for struct initializers.
MoarVM/new-disp: 5f563ba1a0 | (Stefan Seifert)++ | src/jit/x64/emit.dasc
Fix JIT code on Windows

The area just below (higher addresses) the stack pointer is reserved for the callee to store registers, so we cannot use it to pass an MVMArgs struct. Need to go a little lower and tap into the actual argument space (which is available, since we do not need to pass any stack args).
Simplify the code for POSIX while we're at it. emit_stack_arg emits a single line of assembly. Avoid mixing C, assembly and DynASM too much by just writing that line directly.
nine [Coke]++. Thanks for sticking to it :) 16:57
17:40 evalable6 left, linkable6 left 17:41 linkable6 joined, evalable6 joined
[Coke] nine++ 17:47
18:02 reportable6 left 18:05 reportable6 joined 18:31 raydiak_ is now known as raydiak
jnthnwrthngtn nine++ [Coke]++ 20:13
[Coke] figured the sooner we did that, the less painful it would be. :) 20:17
I'll do a build every few days going forward. 20:18
20:18 evalable6 left, linkable6 left 20:19 evalable6 joined
timo has someone already put some thought into how nativecallinvoke should be dispatchified? 20:42
i assume the dispatcher would go through the capture (and/or the sub's signature) and do the unboxing and leave all the necessary guards for that, then the args would be right there for boot-c-call or similar 20:44
i'm not 100% sure how we can do better than code-genning the native subs, but on the other hand, not having to 1) have bytecode for every native sub in all our precomp files and 2) run the compiler for these things ... that may be a win even if the result is about the same? though there would be a bit more warmup at run time perhaps!? 20:49
perhaps with more aggressive guards on types we can do a better job at jitting serialization and deserialization related things? 20:54
21:18 Kaipi joined 21:19 Kaiepi left
[Coke] Should the nativecall tests be passing right now? Seeing behavior where they fail under make test but pass when run individually 21:19
(new-disp, windows)
MasterDuke i've seen the occasional flap on master, but it's pretty infrequent 21:20
21:21 linkable6 joined 22:21 evalable6 left, tellable6 left, linkable6 left 22:24 evalable6 joined 23:24 MasterDuke left, tellable6 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!