01:15 pyrimidine joined 01:29 lizmat joined 01:30 lizmat_ joined 01:32 zakharyas joined 02:22 pyrimidine joined 02:48 ilbot3 joined 06:25 domidumont joined 06:29 pyrimidine joined 06:35 vendethiel joined 06:56 domidumont joined 07:01 domidumont joined 08:13 vendethiel joined, domidumont joined 09:04 pyrimidine joined 09:06 brrt joined
brrt ohai #moarvm 09:06
brrt has got some writing to do
jnthn o/ brrt 09:12
09:13 lizmat joined 09:23 camelia joined
brrt \o jnthn 09:36
i enjoyed your post
jnthn :) 09:37
brrt ... unfortunately i've had very low energy levels in the past few weeks 10:16
so just getting a blog post out has been really troubling
or, 'challenging'
10:18 samcv joined
jnthn knows the feeling 10:19
I went some months without blogging for that kinda reason
Then managed 2 in the space of the last week :)
brrt well, unlike me, you did manage to write some code at least :-)
timotimo seems like google developed their own fuzzing software 11:03
oh, it's a service, not a software 11:04
11:32 lizmat joined 12:23 pyrimidine joined
nine jnthn: commit 5c659178a07d86fe73b7c506c4ea7b10ad38b0e8 breaks Inline::Perl6 13:18
^H:/
timotimo i wonder if we want synopsebot to figure out what repo a commit id belongs to and link it directly when someone mentions it?
nine It hangs during initialize in sched_yield called by MVM_gc_mark_thread_unblocked
in src/gc/orchestrate.c:270
jnthn nine: Can I see the whole call stack? 13:29
(C level one)
nine need to change trains 13:31
will post
jnthn k, thanks 13:32
Hopefully we'll be able to distill a relatively small test case form it... 13:33
*from
nine Actually I didn't have to change trains. Instead the train changed. 13:34
jnthn: gist.github.com/niner/6b0f77d66160...462add2f57 13:35
Maybe helpful link: metacpan.org/source/NINE/Inline-Pe...l6.xs#L112 13:43
jnthn What a kind train. 13:45
Hmmm
jnthn notices that a call into C land is not on the stack below this 13:46
(As in, Moar doesn't own the main loop) 13:47
nine Inline::Perl6 works by initializing Moar with code copied from Moar's main.c, running Perl 6 code that just calls Inline::Perl5's initialization. This will pass a callback routine to a Inline::Perl6's init_inline_perl6_new_callback function which stores the pointer to the callback in a global variable.
jnthn I suspect we don't have a test like that, and maybe can't have a test like that, inside of t/04-nativecall
nine That's p5_callback which is used to get back into Perl 6
jnthn Yeah, what you're doing is reasonable enough.
I think I understand how it's busted 13:48
nine :)
jnthn Lemme finish up a refactor on some $dayjob code and I can take a look
nine Many thanks :) 13:49
nine will be losing connectivity at around 17:00 on his way to LPW 13:51
14:02 pyrimidine joined
jnthn 'tis done, now I can look 14:04
dalek arVM/nine-try-this-fix: 859bcf4 | jnthn++ | src/core/nativecall_dyncall.c:
Attempted Inline::Perl6 fix.
 14:12
jnthn nine: I'm trying out a fix along these lines...could you give it a try?
14:16 pyrimidine joined
jnthn Yeah, I've scribbled myself a couple of transition diagrams for GC status and I'm pretty sure that is fine 14:22
dalek arVM: be5ed38 | jnthn++ | src/ (4 files):
Fix native callback/GC interaction when embedded.

A while ago, we started to block a thread for GC purposes when doing a call into native code, so that long-running calls won't prevent progress of other thread in the VM by preventing their GC. In the case of callbacks, we then unblocked the thread.
Inline::Perl6 embeds MoarVM. It can therefore create a situation where a MoarVM native callback is invoked when a call into native code was not on the stack. This deals with the issue - at least somewhat - by not trying to unblock a thread that is not blocked, which would lead 5a75216 | jnthn++ | src/gc/orchestrate.h: Add GC block management functions to public API.
So that Inline::Perl6 can explore using them, as described in the previous commit.		 14:48
timotimo to a hang. 14:49
This hopefully gets things back to working as well as they did prior
to the nativecall GC blocking fixes. However, it's worth noting that
a situation where code running under Inline::Perl6 starts threads,
and then the Perl 5 code using it keeps the main thread tied up for
a while, would result in the Perl 6 threads also getting blocked.
Thus, Inline::Perl6 may want to explore marking the thread running
14:49 pyrimidine joined
timotimo the Perl 5 interpreter that embeds MoarVM as GC-blocked to prevent 14:49
such a situation.
jnthn nine: Did a cleanup of the fix I sent you to try and it's in master now. I'm fairly sure this will cover it; see the commit message for a hint on a further (not new) problem that may exist in Inline::Perl6 though :) 14:52
nine jnthn: confirmed :) Thanks for the quick fix 14:59
jnthn \o/ 15:00
nine Sounds like I should just MVM_gc_mark_thread_blocked right after the toplevel_initial_invoke? 15:03
jnthn nine: How do you "initially" run code? 15:04
To give you the callbacks?
I guess you run some setup code of some kind? 15:05
You'd need to block it *after* that can run, anyways.
(Which may be the place you're talking about)
The key thing is that, aside from callbacks, you don't get MoarVM to run code in any other way while it's marked as blocked 15:06
nine jnthn: I set up moar with lib/Inline/Perl6/Helper.pm as first Perl 6 argument. The module is just: use Inline::Perl5; Inline::Perl5::init_inline_perl6_callback(@*ARGS[0]); 15:09
jnthn nine: Yeah, so it'd be after that has run 15:10
Since presumably after that point everything else you do that calls back into MoarVM is via the callbacks 15:11
nine I can now confirm that this also works without your workaround. Now I just wonder, if there's any way to check if MVM_gc_mark_thread_blocked is available? 15:16
jnthn Yeah, though I think my workaround probably wants to stay for other embedders in the future. :) 15:17
Hmm...you could check MoarVM version at configure time and set a define?
timotimo i wonder how the ndarrayview could be implemented so it can also handle CArray ... 15:22
nine jnthn: excellent idea :) 15:33
jnthn: do I understand this correctly? Thanks to the MVM_gc_mark_thread_blocked call, we allow for another MoarVM thread to steal our GC work, while we're happily running Perl 5 code? 15:34
timotimo that's how i understand it
15:37 pyrimidine joined
jnthn nine: Yes 15:38
nine: So you could use Inline::Perl6 to do start { ...blah some Perl 6 thing... } 15:39
And get the Promise back
And later in Perl 5 code .result it to get the result
But it could compute happily in the background without the Perl 5 thread working away at stuff blocking the Perl 6 threads when they need GC
That may just be useful for something ;)
nine It's very cool in any case ;) 15:40
jnthn Aye :)
nine Inline::Perl6 v0.08 is on its way to CPAN :) 15:44
[Coke] nine++ jnthn++ 15:46
16:11 pyrimidine joined
timotimo i wonder if i'm missing something crucial in my jit implementation of the throwpayload ops 16:50
maybe the throwpayload* ops want to be marked :throwish in the oplist 16:53
well, that brings the build further
dalek arVM: 3c82b48 | timotimo++ | src/core/op (2 files):
mark throwpayload* as :throwish in oplist
 17:10
arVM: fea28ed | timotimo++ | src/jit/graph.c:
implement throwpayload* in the JIT
17:13 domidumont joined 17:25 pyrimidine joined 17:39 pyrimidine joined 18:11 pyrimidine joined 18:26 FROGGS joined 20:42 pyrimidine joined 22:43 pyrimidine joined 22:57 pyrimidine joined 22:59 pyrimidine 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!