github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo it'll be the wrapture 00:28
nine Wait a minute. If I can use a hypothetical deserialization fixup mechanism to replace Inline::Perl5's INIT phasers, doesn't that mean that I could use such INIT phasers to replace NativeCall's deserialization code? 09:00
In the end, all I need is reinitialization of the native call site before native functions are run. 09:01
lizmat nine: that feels a bit weird to me... I mean, should the HLL even know about deserialization ? 09:09
nine In my case: yes. It needs to bring back some external state. 09:31
Precompiled code using Inline::Perl5 expects a perl interpreter running having loaded all the modules that were loaded during compilation. 09:32
nine Trying to find a quick fix that has a chance of making it into the upcoming release, I figure that I could actually defer running the resolve_lib_name callback to the first call of the native function. All it needs is a check for handle being non-NULL. 10:42
sena_kun I don't see modules with Fail status, so it seems to safe to cut a moarvm release. 11:18
nine Well, it seems to work just as well as running the callback during deserialization - including the issues we still have 11:37
And no wonder! It's not actually running resolve_lib_name that's causing those issues but my callback deopt fix! 11:46
Huh... can't reproduce it with MVM_SPESH_BLOCKING=1 and MVM_SPESH_NODELAY=1 12:10
Scrap that. It just took a lot of tries 12:13
nine So, not writing back interp_cur_op, interp_bytecode_start and interp_reg_base to the outer runloop fixes csv-ip5xs.pl, but of course would bring back the deopt issue 16:10
The issue is very sensitive to GC. I can make it fail reliably with a 16K nursery 16:18
nine It's destructors! 17:33
Thing is: remove_one_frame is responsible for running special_return or special_unwind code attached via a frame's extras. That's usually code that will free some malloc'ed memory or like in my case: destructors queued by the GC. 17:36
Before my deopt fix, remove_one_frame would not do so for the top most frame of a runloop. That's OK behaviour for the outermost runloop as the program is going to end anyway and a little sloppyness on cleanup can be forgiven. 17:37
My fix changed this as a side effect, now such handlers are also run for top most frames in nested runloops. That's by itself an improvement as it will fix memory leaks and missed destructor calls for callbacks from native code. 17:38
But this will currently also leave the outer runloop in an inconsistent state, though I don't know why exactly yet.
Actually, I do have an idea: calling destructors means calling MVM_frame_invoke which will set up the runloop's state so it will execute the called frame. However the nested runloop is at its end and we'll change tc->cur_frame back to the outer runloop's. 17:44
Thus we end up with a mix of interp variables. 17:45
nine Solution: keep that inner runloop running until those handlers are fully processed. We'll get another chance at returning to the outer runloop when the finalizer returns. 18:03
nine Damn...accidentally pushed the change to when resolve_library's called as well. 18:14
Apparently geth's down?
Geth_ MoarVM: eb13ccad13 | (Stefan Seifert)++ | src/core/nativecall.c
Fix NativeCall body's resolve_lib_name getting outdated on GC

Need a write barrier on the object when assigning the resolve_lib_name to an attribute in the NC body.
20:36
nine With this things seem to be quite stable again :) 20:37
Would love to see a release now!
sena_kun nine, can you clarify if github.com/rakudo/rakudo/commit/55...ec6783337a and github.com/rakudo/rakudo/commit/0e...d3865a2d85 are "fixing" the same issue, as in, should they be a single entry in the changelog? 20:40
nine sena_kun: yes, they are indeed about the same issue. My first attempt at fixing had unwanted side effects 20:42
sena_kun nine, thanks!
sena_kun notes 20:43
travis-ci MoarVM build errored. Stefan Seifert 'Fix NativeCall body's resolve_lib_name getting outdated on GC 20:58
travis-ci.org/MoarVM/MoarVM/builds/628187730 github.com/MoarVM/MoarVM/compare/3...13ccad1395