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:07 reportable6 left 00:09 reportable6 joined 00:44 frost joined, frost left 01:40 Colt left 01:41 Colt joined 02:49 japhb joined 03:02 nine left, nine joined 04:02 linkable6 left, evalable6 left 05:03 evalable6 joined, linkable6 joined 05:47 frost joined 06:08 reportable6 left 06:10 reportable6 joined 07:16 Colt left, Colt joined
Geth MoarVM: 38349ce4d0 | (Stefan Seifert)++ | src/core/nativecall_libffi.c
Fix possible access to fromspace in libffi native calls

Follow up on commit f4aa22ad03f1d98cd70ec9f5ce5d82e5cb06e51e which missed two places where we accessed the body after the pointer may have become outdated.
  MasterDuke++ for noticing!		 08:37
08:39 TheAthlete joined
Nicholas good *, * 09:05
I'm glad that MasterDuke asked, because I looked (earlier) and thought "all these changes are only in the dyncall specific macros". And clearly that wasn't 100% true
nine Looks like the errors were mostly in dyncall. That's probably how I overlooked the 2 in libffi. Things just looked too well so I didn't do the thorough search 09:21
09:57 linkable6 left, evalable6 left
MasterDuke after the release i plan to merge github.com/MoarVM/MoarVM/pull/1618 and github.com/rakudo/rakudo/pull/4672 which have had some comments and approvals. and then hopefully someone can put some eyes on github.com/MoarVM/MoarVM/pull/1619 (and its related nqp+rakudo prs) 09:59
Nicholas this is a bit of a cheeky question - how is the release? Will it happen before or after JSWT launches? 10:00
er, JWST. bad fingers 10:01
MasterDuke jdv said it was planned for ~9am EST today, iirc
Geth MoarVM: 4d411987e8 | (Stefan Seifert)++ | src/core/nativecall.c
Assure memory write order in native call race condition fix

Commit 207db4bb5b75e86466fc63ec23f7f0c58fc45ed4 changed the order of initialization of native call sites so concurrently running code won't read uninitialized data. However the compiler didn't know that this order was important and was free to re-order when optimizing. Add a memory barrier to force the compiler to do things in the order we want it to.
  Thanks to zhuomingliang++ for the suggestion!		 10:20
nine C is hard...
Nicholas I get the point of the barrier (but would have missed it) in the context of "ensure we have properly populated arrays before setting num" but in the original commit, 207db4bb5b75e86466fc63ec23f7f0c58fc45ed4 10:25
I'm not sure what the race is, or more, why it's safe for this code in MVM_nativecall_build to be running concurrently on one thread while a second thread is doing things in getattr_o referencing the callsite 10:26
lizmat nine: I feel another bump is necessary ?
nine lizmat: I figure that the release process takes care of the bump? 10:27
lizmat I guess :-)
nine Nicholas: the situation is this: the native call site is an attribute of a routine. One thread is currently busy doing MVM_nativecall_build. Another thread is asking "is the native callsite already initialized or do I have to run !setup?" The latter is nqp::unbox_i($!call). Reading $!call is performed by nqp::getattr_o. The $!call attribute is flattened into the Routine's body. Since getattr cannot return a 10:30
pointer into the P6opaque's body, it has to create a freestanding copy the NativeCall object.
Before the fix the copy contained arg_types and arg_info arrays with copies of uninitialized data. This would later on trip up the GC when it was collecting the freestanding object. Not having those arrays was not an issue because we only asked $!call for whether it's library pointer got a value or not. 10:32
Nicholas "so, it needs to copy (all of) an incomplete object, to be able to read a part of it that is already initialised" ?
nine yes
Which sounds very unoptimal now that I know what really happens there.
Nicholas yes :-)
nine On the bright side, this check only happens once per callsite. 10:33
Nicholas but also, if you don't fix *that* LTA-ness, I'm wondering about writing up your answer as a comment in the C and sending a PR to you
it does seem a very expensive "are we nearly there yet?" implementation
nine It is, indeed. Don't have a better idea though 10:42
Nicholas the thing in nqp doing the nqp::unbox_i($!call) - it's only ever *reading* the value? And it only cares about boolean truth/falsehood? 10:44
nine Yes: github.com/rakudo/rakudo/blob/mast...kumod#L364 10:45
And: github.com/rakudo/rakudo/blob/mast...kumod#L296
Nicholas surely there some other (existing?) op that could be called on a NativeCall object (that currently has no meaning) that returns something true/false (or any form of two values) ? 10:48
even defined :-) 10:49
nine That's the thing: if you need to call it on the NativeCall object, you have already lost. unbox_i is as lean as it gets (just a call to the get_int pointer in the REPR's vtable) but at that point we've already created the copy. 10:50
So it'd have to be an op on the P6opaque, i.e. the Routine object
Nicholas or a syscall? 10:51
nine Yes, yes, indeed!
10:58 linkable6 joined 10:59 evalable6 joined 11:49 sena_kun left 11:50 sena_kun joined 12:08 reportable6 left, reportable6 joined
nine Though I wonder if a syscall is actually cheaper than the unbox_i(getattr_o) combo. 12:33
Nicholas it creates less GC work? 12:42
13:08 evalable6 left, linkable6 left, evalable6 joined 13:53 discord-raku-bot left, discord-raku-bot joined 14:11 linkable6 joined 14:23 frost left
jdv well, i overslept and didn't sleep well but starting soon. 14:54
15:29 ggoebel joined
ggoebel jdv: break a leg! 15:29
15:48 ggoebel left 16:06 [Coke] left
jdv could i get write on the moarvm repo and the moarvm.org repos? i'm about ready to start pushing. 16:11
lizmat jdv: I've also pinged jnthnwrthngtn in a privmsg 16:13
sena_kun ^^ 16:14
jdv thanks, no rush:)
MasterDuke doesn't moritz also have admin?
lizmat possibly... I most definitely have not 16:17
16:23 kjp left
sena_kun jdv, perhaps it'd be better to push in a branch so that it can be reviewed first? 16:25
I can give the rights, but since we're here anyway.
I also have no admin for moarvm.org, so it's PR only too. 16:26
jdv i guess. i'm just following the guide. can't PR a tag, right? 16:34
having a changelog issue though - just a moment
sena_kun jdv, you can add a tag to a commit even if it's a branch. But I don't recommend pushing tags until you know the commit is alright, so you can document the release, open a PR, if it's alright you tag the commit, push the tag, merge the PR. 16:37
jdv yup. the releases.html gen is giving me grief. 16:40
sena_kun jdv, what's with it? 16:46
jdv i got it - my fault - bad formatting - redoing it all now 16:49
i'll get you a pr in a moment
sena_kun jdv, as a quick tip, you can check if releases.html looks alright just opening it locally, say `firefox releases.html`. had saved me numerous times. 16:51
Geth MoarVM: jdv++ created pull request #1625:
2021.12 release		 16:56
jdv i'm doing the release not locally but i did copy the site files locally and spotted it, thanks:) 16:57
16:59 kjp joined
jdv github.com/MoarVM/moarvm.org/pull/14 17:07
so i believe those are the 2 PRs 17:08
nine: that was the pr and branch but i'll change it 17:13
ok, so both the moarvm and moarvm.org PRs are updated so i guess i'm blocked. maybe lunch time. 17:35
18:00 ggoebel joined
Geth MoarVM: ed82fb3c63 | (Justin DeVuyst)++ | docs/ChangeLog
Update ChangeLog for 2021.12 release
 18:02
MoarVM: 9d632b43dd | (Justin DeVuyst)++ | VERSION
Bump VERSION for release
MoarVM: 52aa63120c | niner++ (committed using GitHub Web editor) | 2 files
Merge pull request #1625 from jdv/2021.12

2021.12 release
nine Too bad I don't have write access to moarvm.org either 18:03
lizmat I think I can merge PRs
sena_kun I can 18:04
sena_kun is back from a lesson
merged 18:05
18:07 reportable6 left
jdv cool. so that leaves the moarvm tag and gh release. how do we do that? 18:14
sena_kun jdv, if you're on your branch, sign it (`git tag -as 2021.12 -m '2021.12 release'`) then erm... `git push origin --tags`? 18:16
jdv i was implying i think i still don't have perms for those 18:17
sena_kun jdv, just gave write rights, can you check? 18:18
jdv it appears so. thanks. 18:19
sena_kun jdv, welcome! 18:20
now rakudo time I guess.
aaaah, by the way, github release
I usually do them when all 3 are done though, but can be done either way 18:21
so there is this script: github.com/rakudo/rakudo/blob/mast...release.p6
you call it like `raku github-release.p6 --repo=MoarVM/MoarVM --tag=2021.10 --token=github_token_here... --asset=MoarVM-2021.10.tar.gz --asset=MoarVM-2021.10.tar.gz.asc`
same for nqp and rakudo afterwards
jdv yeah, its in the guide, thanks 18:22
sena_kun then it fails and you add artifacts manually via github interface. :)
jdv nice 18:23
sena_kun another alternative is de-bitrotting the script. 18:25
jdv ok, moarvm release done afaik, moving back into rakudo release mode 18:39
sena_kun yup 18:42
19:08 reportable6 joined 20:08 linkable6 left 20:10 linkable6 joined 21:14 TheAthlete left 22:12 [Coke] joined 22:39 Voldenet left 23:12 Voldenet 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!