[00:25] *** releasable6 left [00:25] *** greppable6 left [00:25] *** committable6 left [00:25] *** notable6 left [00:25] *** shareable6 left [00:25] *** unicodable6 left [00:25] *** bloatable6 left [00:25] *** bisectable6 left [00:25] *** quotable6 left [00:25] *** sourceable6 left [00:25] *** statisfiable6 left [00:25] *** nativecallable6 left [00:25] *** squashable6 left [00:25] *** reportable6 left [00:25] *** coverable6 left [00:25] *** benchable6 left [00:26] *** squashable6 joined [00:26] *** coverable6 joined [00:26] *** sourceable6 joined [00:26] *** committable6 joined [00:26] *** reportable6 joined [00:26] *** nativecallable6 joined [00:27] *** greppable6 joined [00:27] *** benchable6 joined [00:27] *** bloatable6 joined [00:27] *** bisectable6 joined [00:27] *** notable6 joined [00:28] *** releasable6 joined [00:28] *** unicodable6 joined [00:28] *** statisfiable6 joined [00:28] *** quotable6 joined [00:28] *** shareable6 joined [00:54] *** sena_kun left [06:48] *** squashable6 left [06:50] *** squashable6 joined [07:33] *** domidumont joined [07:36] *** domidumont left [07:37] *** domidumont joined [07:43] *** domidumont left [07:45] *** domidumont joined [08:33] *** domidumont left [08:33] *** domidumont joined [08:51] *** robertle joined [09:48] *** Kaiepi joined [10:59] *** sena_kun joined [12:20] *** brrt joined [12:20] \o [12:20] 2019-12-06T16:20:51Z #moarvm brrt o/ [12:21] nine: what's been breaking? [12:22] *** pamplemousse joined [12:22] ohai pamplemousse [12:22] o/ brrt [12:22] 2019-09-06T21:08:28Z #moarvm pamplemousse I found something interesting (I think); it's possible to define the 'main' in a shared library [12:23] hehe, long time no speaking [12:24] Yeah, sorry it's definitely been a while, life got away from me a bit [12:24] no worries :-) [12:25] happy to have you back [12:25] what I meant with 'main' in a shared library, is that we could define a 'runner' library, that'd load memory from a symbol that'd be linked in later [12:26] ... which means that the build-complexity of self-containing reduces to 'create an ELF that represents that symbol', which is (I think) how far you'd already gotten [12:30] That's about where I was, I think. Right now I'm refamiliarizing myself with everything and updating my branch to be compatible with all the changes that have happened [12:34] brrt: apparently the return of a JIT compiled top most frame of a nested runloop [12:35] brrt: so the bug I discovered was that when in a nested runloop (i.e. NativeCall callback) a deopt all occurs, the frame starting the runloop will not get deoptimized but the frame's spesh info gets deleted, leading to a segfault. [12:35] hmm [12:36] I added code to propagate the new state from the nested to the outer runloop and got it to work when the JIT is disabled [12:36] I wonder if there's something clever we can do [12:36] One failure mode I'm observing right now is a "const_iX NYI" when it should actually exit the runloop [12:37] That's directly following an sp_jit_enter OP [12:37] oh, that makes some sense [12:37] the sp_jit_enter code fragment is very hacky [12:38] Apparently my changes broke its detection of when its time to exit the runloop [12:39] I may be able to help out... do you have a branch? [12:39] just a sec [12:40] ¦ MoarVM/fix_deopt_all_in_native_callback: c3b7de9e75 | (Stefan Seifert)++ | 5 files [12:40] ¦ MoarVM/fix_deopt_all_in_native_callback: Fix relocatability of modules using NativeCall [12:40] ¦ MoarVM/fix_deopt_all_in_native_callback: [12:40] ¦ MoarVM/fix_deopt_all_in_native_callback: There are cases where we actually don't want the library's path to get [12:40] ¦ MoarVM/fix_deopt_all_in_native_callback: serialized into the bytecode file, e.g. when building a module into a Staging [12:40] ¦ MoarVM/fix_deopt_all_in_native_callback: repository for packaging. The previous attempt to solve this failed because [12:40] ¦ MoarVM/fix_deopt_all_in_native_callback: we cannot keep the NativeCall site's state in sync with HLL function's state [12:40] ¦ MoarVM/fix_deopt_all_in_native_callback: due to repossession issues. The latter were the whole reason for serializing [12:40] ¦ MoarVM/fix_deopt_all_in_native_callback: <…commit message has 7 more lines…> [12:41] ¦ MoarVM/fix_deopt_all_in_native_callback: review: https://github.com/MoarVM/MoarVM/commit/c3b7de9e75 [12:41] ¦ MoarVM/fix_deopt_all_in_native_callback: 46e0577ecd | (Stefan Seifert)++ | 9 files [12:41] ¦ MoarVM/fix_deopt_all_in_native_callback: WIP [12:41] ¦ MoarVM/fix_deopt_all_in_native_callback: review: https://github.com/MoarVM/MoarVM/commit/46e0577ecd [12:41] Works with rakudo's fix_relocatability_of_modules_using_nativecall branch [12:42] (and ...... what's the relocatability of modules using nativecall?) [12:42] That gets rid of serialized absolute paths of native libs in precomp files. They are a problem when a module is installed using the Staging repo or rakudo's files are moved after installation [12:45] ah, I see [12:45] I wonder how that escalated to nested runloops and deopt_all :-D [12:47] Even with that fix I got a failure in one of Inline::Perl5's tests when run on a 32 bit build system. I used MVM_SPESH_BLOCKING and MVM_SPESH_NODELAY trying to reproduce it on my normal 64 bit dev environment and this caused a different test to fail and investigating that I found the deopt all issue [12:48] And it looks like that's actually the source of the 32 bit issue, too [12:50] Best way I've found to reproduce is: Inline-Perl5 (master =)> MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 perl6-gdb-m -Ilib t/invoke_p6_method_from_p5.t [12:51] nine: I recall having some problems installing Inline::Perl5 together with perlbrew.... [12:53] brrt: according to my README, one needs to install perl via: perlbrew install perl-stable -Duseshrplib [12:53] *** sena_kun left [12:54] aha [12:54] whats' -Dusesrhplib [13:01] Makes it compile perl with -fPIC and create a libperl.so [13:07] *** sena_kun joined [13:14] Oh, I got an idea. In my patch I changed remove_one_frame to no longer set tc->cur_frame to NULL when we are already in the outermost frame of a nested runloop. But sp_jit_enter checks tc->cur_frame to know whether to exit! [13:15] The interpreter uses remove_one_frame's return value (via MVM_frame_try_return) to make that decision [13:22] Yes, keeping that fixes a lot. Now there's just: rakudo: src/jit/expr.c:915: walk_tree: Assertion `node < tree->nodes_num' failed. [13:22] t/from.t ...................... No subtests run [13:30] *** brrt left [13:35] *** pamplemousse left [14:03] *** lucasb joined [14:53] *** sena_kun left [15:08] *** sena_kun joined [15:20] *** robertle left [15:21] *** domidumont left [15:29] *** brrt joined [15:35] *** domidumont joined [15:52] nine: (node < tree->nodes_num, that seems bad) [16:00] *** brrt left [16:42] Oh, removing the :invokish mark on the nativeinvoke* and nativecallinvoke ops seems to fix that assertion failure [16:45] but they *are* invokish, are they not ? [16:47] That's what I thought when adding those marks. But they are used by the JIT compiler and I didn't bother to look at what it does exactly. It may be about argument processing for example which is different for native calls [16:47] Adding the :deoptall and :maycausedeopt markers however is backed up by my actual understanding of the code [16:54] *** sena_kun left [17:07] *** sena_kun joined [18:22] *** zakharyas joined [18:52] *** sena_kun left [19:07] *** sena_kun joined [19:35] *** domidumont left [20:14] *** zakharyas left [20:53] *** sena_kun left [20:57] *** zakharyas joined [21:08] *** sena_kun joined [21:51] *** brrt joined [22:07] *** zakharyas left [22:43] *** sena_kun left [23:36] *** brrt left