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.
MasterDuke47 all the the current leaks shown by `valgrind --leak-check=full raku --full-cleanup -e ''` are from github.com/MoarVM/MoarVM/blob/new-...am.c#L2323 00:23
timo gist.github.com/timo/6063038e9518a...0688bdd176 - look at all these "set" instructions that helpfully come with deopt point annotations 01:20
(put the rest of the spesh log piece in there as well) 01:26
MasterDuke47 timo: what's the code? i see a bunch of missing *_n templates 02:09
MasterDuke47 huh, why don't we a div template expression op? 02:21
Nicholas I saw the exact same failure as timo on a run with the commit 1 *before* timo's 06:07
good *, #moarvm
Nicholas .tell [Coke] ASAN is very excited by MoarVM/jit-vla (and I also spot that there's no free() after the loop). Hopefully I'll spot the problem before you read this. 06:27
tellable6 Nicholas, I'll pass your message to [Coke]
Nicholas jnthnwrthngtn: ebfd4d5d6e (Jonathan Worthington 2021-09-10 18:31:56 +0200 705) MVMint32 operands[MAX(2, ins->info->num_operands)]; /* At least 2 for inc_i hack */ 07:52
Oh, I didn't manage to highlight any of that
surely "at least 2" implies MIN(2, ins->info->num_operands) ? 07:53
oh, pick the maxiumum... 07:54
anyway, I'm suspicious that the bug is exposed by the branch, rather than being on the branch. 07:55
clearly the coffee is weak today... 07:58
pointer arithmetic, etc ... - missing multiplying by sizeof(MVMint32) in the malloc 08:08
Geth MoarVM/jit-vla-v2: fef6205f49 | Coke++ (committed by Nicholas Clark) | src/jit/expr.c
Don't use Variable Length Arrays, as MSVC forbids them.

Instead of allocating each time through the loop, keep a small array to reuse each time through the loop. Expand the size of the array when necessary.		 09:20
jnthnwrthngtn moarning o/ 09:56
Nicholas \o 09:58
Geth MoarVM/jit-vla-v2: 088bc9cd96 | (Nicholas Clark)++ | src/jit/expr.c
Use the FSA instead of malloc in `MVM_jit_expr_tree_build`

The Fixed Size Allocator should be slightly faster than malloc for the small allocations we need, and possibly much faster than free, because we know the size of the memory we are deallocating.		 10:36
dogbert17 good morning 10:38
Geth MoarVM: nwc10++ created pull request #1542:
Convert the use of a Variable Length Array to a regular allocation
dogbert17 it seems as if the error in t/spec/S06-advanced/callframe.t is caused by github.com/MoarVM/MoarVM/commit/e3...c059a8ce88 10:39
jnthnwrthngtn dogbert17: Is that one OK under nodelay/blocking on master also? 10:52
dogbert17 jnthnwrthngtn: as far as I can tell yes 11:12
celo_duro Nicholas: msvc doesn’t support alloca? 11:31
It compiles to a sum and a subtraction on the stack pointer 11:33
or maybe, depending on optimization levels, not even that: it compiles to nothing. 11:35
Nicholas jnthnwrthngtn: we're already using alloca() left right and centre, (it seems), without problems. 12:08
Should MoarVM/jit-vla-v2 just be ditched, and a "v3" appear with alloca?
jnthnwrthngtn Nicholas: That could also work, yes 12:19
And avoids having to free 12:20
Nicholas I think it would be better. For that reason :-)
need to go AFK, but will have a go at it soon.
dogbert17 I have now run t/spec/S06-advanced/callframe.t om master with MVM_SPESH_NODELAY=1 and MVM_SPESH_BLOCKING=1 for an hour, no failures 12:40
dogbert17 it seems so be this specific change: github.com/MoarVM/MoarVM/commit/e3...4L551-R561 12:54
dogbert17 reverting that seemingly fixes the problem 12:55
timo jnthnwrthngtn: how do you currently deal with reading spesh logs? especially the pretty-huge registers / facts section and it being so far away from the BBs? 12:56
do you have like a vertical split where you independently scroll?
[Coke] Nicholas: thanks for fixing up my WIP, appreciate it.
tellable6 2021-09-17T06:27:13Z #moarvm <Nicholas> [Coke] ASAN is very excited by MoarVM/jit-vla (and I also spot that there's no free() after the loop). Hopefully I'll spot the problem before you read this.
[Coke] and I think you did! thanks. 12:57
Nicholas I did. Eventually. You failed to multiply by sizeof(MVMuint32) 12:58
But *eventually*. It hid from us both for quite a while.
[Coke] Nicholas: this is because I am not a C programmer. I had only committed it to a branch so I could easily do a full build from rakudo and test it out.
Sorry to drag you in early, but glad you found it! 12:59
re-confirming that it's faster to commit (say) something and wrong and get a correction! :)
s/and wrong/wrong/
brrt I somehow thought that the ASAN runner was a bot, too 13:38
timo hey brrt did you see my first steps for per-repr exprjit stuff? 13:40
timo d'oh :D 13:40
[Coke] Nicholas: did your PR get merged to new-disp? 13:52
Nicholas no, I rejected it because v3 is coming instead
who is (was) celo_duro who appeared breifly and suggestd alloca?
[Coke] ahhhh 13:53
ok. Thanks for getting sucked into fixing it for me! :)
perhaps "suckered" is a better word. :)
[6~
Nicholas I thought it looked fairly easy, and I thought I could fit it in between tweaking GitHub workflow runs 14:00
[Coke] I owe you a beer. 14:04
Nicholas Pretty sure I owe you a beer in return for stuff you've tested for me 14:05
Geth MoarVM/jit-vla-v3: 18d98df054 | Coke++ (committed by Nicholas Clark) | src/jit/expr.c
Don't use Variable Length Arrays, as MSVC forbids them.

Instead use `alloca` to explicitly allocate storage.		 14:06
MoarVM: nwc10++ created pull request #1543:
Convert the use of a Variable Length Array to alloca		 14:09
[Coke] That is much shorter, nice. Does alloca do something behind the scenes like what jnthn was suggesting? 14:13
I see the stack vs. heap distinction. 14:15
Nicholas and the "returns NULL on failure" vs "undefined behaviour" distinction 14:20
[Coke] build succeeded on your v3 branch, doing rakudo make test now 15:01
(windows) 15:02
still getting nativecall failures when concurrent testing. 15:04
only nativecall failures; psuedohash error didn't recur. 15:06
Nicholas: Thanks.
Nicholas at the start of the week I was fixing bugs on VMS. Now it's Win32. Two platforms I know little about and don't use. :-) 15:40
(the M1 mac mini on the gcc compiler farm is seriously fast. I'm wondering what the *real* performance CPUs from Apple will be like) 15:41
I'm guessing "goes like shit off a shovel" but I doubt that that's how they will officially describe them 15:44
[Coke] ... I wonder how many people in this chat have actually had to shovel shit at one point. (I had to muck stables a few times one summer) 15:59
if that branch looks good on non-win, looks good to merge to me. 16:00
Nicholas I was going to say "never shit". But then I remembered that one day my parents collected free horse manure, and I was involved. But I think I was too young then to be efficient at shovelling. 16:01
I've shovelled but plenty of earth, sand and similar.
That branch worked on "my" machine. (ie has been tested by me on exactly one x86_64 system running debian) 16:02
[Coke] I'll do a run on my old mac mini... 16:04
[Coke] Any m1 build issues? I assume lizmat would be our canary there. 16:13
(on master or new-disp)
lizmat does not have an M1 yet 16:14
Nicholas me neither. This might change when laptops with 16G or greater appear. 16:16
[Coke] looks like at this point you can have 16G *OR* M1. 16:18
patrickz I actually do have an M1 that I'd be very willing to make available via ssh. Would that help? 16:21
Nicholas but I want both! And a pony.
Darwin minimac.moose.housegordon.com 20.4.0 Darwin Kernel Version 20.4.0: Thu Apr 22 21:46:41 PDT 2021; root:xnu-7195.101.2~1/RELEASE_ARM64_T8101 arm64
I have access to that one
trying new-disp first. It doesn't like t/04-nativecall/02-simple-args.t 16:27
but IIRC it never "liked" that
IIRC it's actually whichever dyncall library that we use that is buggy, and doesn't handle unsigned chars and unsigned shorts correctly - assumes it can cast them to signed and just use the signed "thing" code. 16:28
this fails when the ABI treats the sign extension (or not) differently. 16:29
actually, I think that both our options are making the same buggy assumptions, but one of them ends up truncating the data again, which undoes the damage. 16:30
[Coke] jit-vla-v3 looks good on win & mac here. 16:48
timo oh, did we look for new libuv versions? 18:20
Nicholas releasable6: next release? 18:24
releasable6 Nicholas, I cannot recognize this command. See wiki for some examples: github.com/Raku/whateverable/wiki/Releasable
Nicholas /win 1
that *used* to be very fast way to learn of the next release date 18:25
releasable6: status
releasable6 Nicholas, Next release in ≈1 day and ≈0 hours. There are no known blockers. Changelog for this release was not started yet
Nicholas, Details: gist.github.com/33431e85962f001e4d...983ac6babc
Nicholas releasable6: botsnack
releasable6 Nicholas, I cannot recognize this command. See wiki for some examples: github.com/Raku/whateverable/wiki/Releasable
sena_kun please no new libraries 19:21
Nicholas sorry, this was my implied point, but I failed to be explicit 19:24
actually, more - we aren't hurting on any existing bugs are we? So logically we should 19:25
ugexe i have a M1 with 16G ram 19:26
Nicholas 1) release (thanks for everyone who does this. I really appreciate your work, as I like releases to happen but I don't enjoy doing them personally)
2) merge new-disp
3) fix all the things
4) *then* new libraries
sena_kun is in another city with different conditions and kinda sorta vacationing (while sorting out private stuff), but the release is to be done so it'd be nice to pass it safely this time 19:27
lizmat as in libuv ?
Nicholas M1 with 16G RAM is a desktop?
lizmat MacMini I assume?
ugexe ah i was wondering what i was missing
sena_kun Nicholas, hmm, merge new-disp? were the last modules fixed? I remember there were 4 maybe with very complex fixes to do.
ugexe mac pro
timo www.pypy.org/posts/2021/09/jit-aut...-code.html leasure reading 20:07
Nicholas oh my, I slack. timo finds a pypy blog entry before I do
timo is any project taking "faJITa"? 20:12
OnePlus has a device called (or code-named) "fajita" 20:19
Geth MoarVM/new-disp: a66754871d | Coke++ | build/setup.pm
Turn VLA usage into a compiler error

VLA fails on windows, this allows us to catch it on other platforms first.
Resolves #1537		 20:52
MoarVM/new-disp: 18d98df054 | Coke++ (committed by Nicholas Clark) | src/jit/expr.c
Don't use Variable Length Arrays, as MSVC forbids them.

Instead use `alloca` to explicitly allocate storage.
MoarVM/new-disp: 8413e9dd5a | (Jonathan Worthington)++ (committed using GitHub Web editor) | 2 files
Merge pull request #1543 from MoarVM/jit-vla-v3

Convert the use of a Variable Length Array to alloca

Powered by Cro and the Raku® Programming Language.

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

Thank you!