[00:03] *** reportable6 left [00:32] *** psydroid left [00:32] *** 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 [05:06] *** jnthnwrthngtn joined [06:04] *** reportable6 left [06:07] *** reportable6 joined [07:46] 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] https://eli.thegreenplace.net/2011/09/06/stack-frame-layout-on-x86-64 [07:47] 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:48] 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:57] 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. [08:17] 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 https://github.com/MoarVM/MoarVM/commit/f23e56a5c401c66ae4b849e8eaa87c5c5f89cf45 [08:24] [Coke]: please try this patch (replaces all previous ones) https://gist.github.com/niner/d90fac62a3d1a9f09612f763e3872451 [08:27] *** frost joined [09:06] is it correct that t/spec/S06-multi/unpackability.t hangs on master ? [09:07] jnthnwrthngtn ^^ [09:08] lizmat: Uh...if it hangs on master than master has a bug that new-disp has fixed :) [09:09] ok, I guess I'll add a skip then for now [09:09] 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. [09:10] A hang is...surprising [09:11] seems to hang 50% of the times it is run [09:12] That's even more weird [09:14] what can I say ? [09:14] it's the last test you added [09:29] Well, let's skip it for now, and count it as a new-disp improvement ;) [09:30] I'm not inclined to go debug code I've spent a year working out how to replace :D [09:32] * jnthnwrthngtn makes a note to unskip it after the new-disp merge [09:33] 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:34] jnthnwrthngtn: don't worry about testing on master, I can do that and add skips and todo's if necessary [10:04] 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 [10:06] I could be wrong but something about this https://github.com/MoarVM/MoarVM/blob/new-disp/src/spesh/disp.c#L770 [10:09] a gist is probably a lot better :) https://gist.github.com/dogbert17/5f8a0e944e7f00c6bbe508c3d06baeda [10:11] *** linkable6 left [10:11] *** evalable6 left [11:13] *** evalable6 joined [12:02] *** reportable6 left [12:07] *** TempIRCLogger joined [12:12] *** linkable6 joined [12:27] <[Coke]> nine: just saw your patch, wil tst when dayjo permits. Thanks! [12:33] ¦ MoarVM/new-disp: bd2a1212fa | (Jonathan Worthington)++ | src/spesh/disp.c [12:33] ¦ MoarVM/new-disp: Ensure temps to release are first annotation [12:33] ¦ MoarVM/new-disp: [12:33] ¦ MoarVM/new-disp: This should hopefully avoid memory leaks due to the annotation not being [12:33] ¦ MoarVM/new-disp: found and the temps not being released. [12:33] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/bd2a1212fa [12:34] dogbert17: Maybe ^^ will help with it [12:48] jnthnwrthngtn: I'm sure it will but I'll check anyway :) [12:53] jnthnwrthngtn: asan is still sad :( https://gist.github.com/dogbert17/5f8a0e944e7f00c6bbe508c3d06baeda [12:53] I have updated the previous gist so a page refresh might be necessary [12:56] Less leaks, or the same amount? [13:00] Same-ish, 6240 bytes before, 6336 after. Perhaps it changes a bit from run to run [13:12] *** evalable6 left [13:12] *** linkable6 left [13:13] *** evalable6 joined [13:52] <[Coke]> nine: build started. [13:55] *** kjp left [13:56] <[Coke]> died. firing up debugger... [13:57] *** kjp joined [13:58] <[Coke]> new error! [14:02] *** frost left [14:02] <[Coke]> updated https://gist.github.com/coke/55ba508f67e8e4d2e1856a3e795a215b - let me know what vars you need. [14:03] *** reportable6 joined [14:05] <[Coke]> new crash in MVM_args_proc_setup [14:13] *** linkable6 joined [15:23] [Coke]: arg_info in boolify_iter_impl could be interesting [15:25] *** evalable6 left [15:25] *** linkable6 left [15:26] [Coke]: oh, I think I see an error in MVM_jit_emit_dispatch [15:26] *** evalable6 joined [15:27] [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 [15:39] <[Coke]> sure, one sec. [15:41] <[Coke]> You mean x64? [15:41] yes [15:48] <[Coke]> looks like the same call stack [15:54] Ok. TMP6 was definitely a bug, but a different one [16:10] <[Coke]> added arg_info [16:11] <[Coke]> not a lot in there [16:12] <[Coke]> wonder why stacktrace has "external code" in it. [16:13] 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:14] <[Coke]> gotcha. [16:15] [Coke]: ooooh...got another lead! Line 3130 should be "| lea ARG2, [rsp+0x20];" instead of "| lea ARG3, [rsp+0x20];" [16:17] <[Coke]> sure. [16:24] * nine is getting a glimpse of what debugging in the age of punch cards must have been like... [16:25] <[Coke]> and you don't even get to touch your own punch cards. :) [16:25] <[Coke]> I am just young enough to have missed that. I have peers a few years older who went through it. [16:25] <[Coke]> I did, however, learn how to use vi on the Michigan Terminal System [16:28] <[Coke]> ... wow. used by an entire *eight* universities! [16:29] I've been using vim for 20 years. I've never really learned it though :/ [16:31] <[Coke]> [6~ [16:31] <[Coke]> vim was released while I was in college, I think. [16:32] <[Coke]> holy shit, we got past the first file in nqp! [16:32] wooohooo! [16:34] <[Coke]> nqp tests all pass. [16:37] <[Coke]> added current windows diff to the gist [16:41] <[Coke]> was that particular jit file *just* for windows? [16:42] No, it's the one [16:42] <[Coke]> ah, or embedded inn if I didn't see in the scope of the diff [16:42] <[Coke]> "in an .if" [16:43] <[Coke]> mostly OK, but several rakudo test failures [16:44] <[Coke]> 18-psuedostash, which I've seen on mac on master, and a dozen nativecall failures [16:47] <[Coke]> updated gist with failures. Removing debug output... [16:51] <[Coke]> if I run the first 2 nativecall failures with .\install\bin\raku ... they work [16:51] <[Coke]> (wish prove had a 'retest' option that just ran the previous failures) [16:56] 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] ¦ MoarVM/new-disp: 28cdc89017 | (Stefan Seifert)++ | 2 files [16:56] ¦ MoarVM/new-disp: Fix build issues on MSVC [16:56] ¦ MoarVM/new-disp: [16:56] ¦ MoarVM/new-disp: MSVC doesn't support C99 variable sized automatic arrays, so use malloc [16:56] ¦ MoarVM/new-disp: instead. It also requires at least one value for struct initializers. [16:56] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/28cdc89017 [16:56] ¦ MoarVM/new-disp: 5f563ba1a0 | (Stefan Seifert)++ | src/jit/x64/emit.dasc [16:56] ¦ MoarVM/new-disp: Fix JIT code on Windows [16:56] ¦ MoarVM/new-disp: [16:56] ¦ MoarVM/new-disp: The area just below (higher addresses) the stack pointer is reserved for the [16:56] ¦ MoarVM/new-disp: callee to store registers, so we cannot use it to pass an MVMArgs struct. [16:56] ¦ MoarVM/new-disp: Need to go a little lower and tap into the actual argument space (which is [16:56] ¦ MoarVM/new-disp: available, since we do not need to pass any stack args). [16:56] ¦ MoarVM/new-disp: [16:56] ¦ MoarVM/new-disp: Simplify the code for POSIX while we're at it. emit_stack_arg emits a single [16:56] ¦ MoarVM/new-disp: line of assembly. Avoid mixing C, assembly and DynASM too much by just writing [16:56] ¦ MoarVM/new-disp: that line directly. [16:56] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/5f563ba1a0 [16:57] [Coke]++. Thanks for sticking to it :) [17:40] *** evalable6 left [17:40] *** linkable6 left [17:41] *** linkable6 joined [17:41] *** evalable6 joined [17:47] <[Coke]> nine++ [18:02] *** reportable6 left [18:05] *** reportable6 joined [18:31] *** raydiak_ is now known as raydiak [20:13] nine++ [Coke]++ [20:17] <[Coke]> figured the sooner we did that, the less painful it would be. :) [20:18] <[Coke]> I'll do a build every few days going forward. [20:18] *** evalable6 left [20:18] *** linkable6 left [20:19] *** evalable6 joined [20:42] has someone already put some thought into how nativecallinvoke should be dispatchified? [20:44] 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:49] 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:54] perhaps with more aggressive guards on types we can do a better job at jitting serialization and deserialization related things? [21:18] *** Kaipi joined [21:19] *** Kaiepi left [21:19] <[Coke]> Should the nativecall tests be passing right now? Seeing behavior where they fail under make test but pass when run individually [21:19] <[Coke]> (new-disp, windows) [21:20] i've seen the occasional flap on master, but it's pretty infrequent [21:21] *** linkable6 joined [22:21] *** evalable6 left [22:21] *** tellable6 left [22:21] *** linkable6 left [22:24] *** evalable6 joined [23:24] *** MasterDuke left [23:24] *** tellable6 joined