|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm 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) |
12:40 | |
| MoarVM/fix_deopt_all_in_native_callback: 46e0577ecd | (Stefan Seifert)++ | 9 files WIP |
|||
| 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 libperl.so | 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
|
|||