| IRC logs at
Set by AlexDaniel on 12 June 2018.
00:25 releasable6 left, greppable6 left, committable6 left, notable6 left, shareable6 left, unicodable6 left, bloatable6 left, bisectable6 left, quotable6 left, sourceable6 left, statisfiable6 left, nativecallable6 left, squashable6 left, reportable6 left, coverable6 left, benchable6 left 00:26 squashable6 joined, coverable6 joined, sourceable6 joined, committable6 joined, reportable6 joined, nativecallable6 joined 00:27 greppable6 joined, benchable6 joined, bloatable6 joined, bisectable6 joined, notable6 joined 00:28 releasable6 joined, unicodable6 joined, statisfiable6 joined, quotable6 joined, 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, domidumont joined 08:51 robertle joined 09:48 Kaiepi joined 10:59 sena_kun joined 12:20 brrt joined
brrt \o 12:20
tellable6 2019-12-06T16:20:51Z #moarvm <nwc10> brrt o/
brrt nine: what's been breaking? 12:21
12:22 pamplemousse joined
brrt ohai pamplemousse 12:22
pamplemousse o/ brrt
tellable6 2019-09-06T21:08:28Z #moarvm <brrt> pamplemousse I found something interesting (I think); it's possible to define the 'main' in a shared library
brrt hehe, long time no speaking 12:23
pamplemousse Yeah, sorry it's definitely been a while, life got away from me a bit 12:24
brrt no worries :-)
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
... 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:26
pamplemousse 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:30
nine brrt: apparently the return of a JIT compiled top most frame of a nested runloop 12:34
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
brrt hmm
nine 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
brrt I wonder if there's something clever we can do
nine One failure mode I'm observing right now is a "const_iX NYI" when it should actually exit the runloop
That's directly following an sp_jit_enter OP 12:37
brrt oh, that makes some sense
the sp_jit_enter code fragment is very hacky
nine Apparently my changes broke its detection of when its time to exit the runloop 12:38
brrt I may be able to help out... do you have a branch? 12:39
nine just a sec
Geth MoarVM/fix_deopt_all_in_native_callback: c3b7de9e75 | (Stefan Seifert)++ | 5 files
Fix relocatability of modules using NativeCall

There are cases where we actually don't want the library's path to get serialized into the bytecode file, e.g. when building a module into a Staging repository for packaging. The previous attempt to solve this failed because we cannot keep the NativeCall site's state in sync with HLL function's state due to repossession issues. The latter were the whole reason for serializing ... (7 more lines)
MoarVM/fix_deopt_all_in_native_callback: 46e0577ecd | (Stefan Seifert)++ | 9 files
nine Works with rakudo's fix_relocatability_of_modules_using_nativecall branch
brrt (and ...... what's the relocatability of modules using nativecall?) 12:42
nine 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
brrt ah, I see 12:45
I wonder how that escalated to nested runloops and deopt_all :-D
nine 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:47
And it looks like that's actually the source of the 32 bit issue, too 12:48
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:50
brrt nine: I recall having some problems installing Inline::Perl5 together with perlbrew.... 12:51
nine brrt: according to my README, one needs to install perl via: perlbrew install perl-stable -Duseshrplib 12:53
12:53 sena_kun left
brrt aha 12:54
whats' -Dusesrhplib
nine Makes it compile perl with -fPIC and create a 13:01
13:07 sena_kun joined
nine 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:14
The interpreter uses remove_one_frame's return value (via MVM_frame_try_return) to make that decision 13:15
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
brrt nine: (node < tree->nodes_num, that seems bad) 15:52
16:00 brrt left
nine Oh, removing the :invokish mark on the nativeinvoke* and nativecallinvoke ops seems to fix that assertion failure 16:42
lizmat but they *are* invokish, are they not ? 16:45
nine 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