github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:54 Kaiepi joined 02:00 Kaiepi left 02:26 AlexDani` joined 02:28 AlexDaniel left 03:13 MasterDuke joined, MasterDuke left, MasterDuke joined 03:57 Kaiepi joined 09:27 avar joined, avar left, avar joined 10:15 harrow left 10:23 harrow joined 11:36 Kaiepi left 12:25 lucasb joined 12:35 dogbert2_ left
jnthn Curious. I've got some code (huge $dayjob app) that explodes under --profile, inside of jumplist, which crazy input/num_labels. And when I dump the current frame's bytecode there's no jumplist in there at all 13:26
timotimo sometimes dump_bytecode does get a tiny bit confused
as to what it's finding
like almost all my debug helpers, it's not absolutely precise 13:27
i should start calling them ‘debug "help"ers’
lizmat jnthn: i can sorta understand some mechanics behind that
jnthn There's no spesh_cand, so in this case it seems likely that it's dumping the tc->cur_frame
timotimo it's not 100% unlikely to have been a mis-aligned jump? 13:28
jnthn Maybe that
I wonder if we did a deopt just or something
The crash is actually in CORE.setting code, for the thread pool scheduler 13:29
Which I'd have thought many apps would hit
This does seem to happen reliably every time 13:31
Though taking forever to get to the crash point with deopt logs on
Plus non-optimized build
13:32 Kaiepi joined
timotimo i may sound like a broken record by now, but you could try "rr record" for this :) 13:34
oh!
a brroken record!
jnthn I had trouble getting it to ever work for me :( 13:35
Oh, with MVM_SPESH_DISABLE=1 it doesn't segv 13:36
So some profiler/spesh interaction perhaps 13:37
Can disable both JIT and inlining and it still explodes
timotimo there's a few cases still where the profiler can crash things; i think it's moarperf that gives me "invalid thread id in work pass" 13:38
13:40 dogbert2_ joined
jnthn MVM_SPESH_OSR_DISABLE=1 gets rid of the segv 13:40
Oh, but then after some requests... 13:41
Unhandled exception: Too many positionals passed; expected 0 arguments but got 1
at SETTING::src/core/ThreadPoolScheduler.pm6:860 (/home/jnthn/dev/MoarVM/install/share/perl6/runtime/CORE.setting.moarvm:)
I think that was around the area it segv'd in before too
Geth MoarVM: 75d5bc6e03 | (Jonathan Worthington)++ | src/spesh/inline.c
Fix memory leak in inlining
 13:51
jnthn At least ASAN found me that :)
Alas, it has no more clues 13:52
I won't look any further for now; just wanted to see if it was an easy fix, but it looks like "no" 13:53
13:53 Kaiepi left
nine Speaking of easy fixes.... any ideas for #2706? At least for fixes easier than getting to 100 % JIT coverage? :) 14:36
14:51 AlexDani` is now known as AlexDaniel 15:52 Kaiepi joined
Geth MoarVM/more-pea: b06ab8d908 | (Jonathan Worthington)++ | src/spesh/pea.c
Don't let proven guards block EA

If a guard is going to go away if analysis succeeds, then don't let it block further analysis of this object. This will be mostly applicable when we start to scalar replace objects referenced by other replaced objects.		 16:48
MoarVM/more-pea: a9f0aa39ab | (Jonathan Worthington)++ | src/spesh/pea.c
Better fact propagation on tracked set/PHI

Sometimes they're missing from the previous phase.
MoarVM/more-pea: b06ab8d908 | (Jonathan Worthington)++ | src/spesh/pea.c
Don't let proven guards block EA

If a guard is going to go away if analysis succeeds, then don't let it block further analysis of this object. This will be mostly applicable when we start to scalar replace objects referenced by other replaced objects.
jnthn huh, twice? :)
Geth MoarVM/more-pea: a9f0aa39ab | (Jonathan Worthington)++ | src/spesh/pea.c
Better fact propagation on tracked set/PHI

Sometimes they're missing from the previous phase.
MoarVM/more-pea: 073331ce95 | (Jonathan Worthington)++ | src/spesh/pea.c
First steps towards transitive scalar replacement

So far, in a program like:
   my $x = 0e0;
   my $y = 4e2;
   for ^10_000_000 {
... (20 more lines)
jnthn That last commit is the interesting one; the other two just break out some prep work to make it effective 16:50
nine: Umm...what needs JITting for this to work out?
nine: Can we only produce the specialized nativecall bodies if JIT is available, or is it not that simple
Of course, 'cus of the things it doesn't do, it's utterly broken on non-toy programs still. :) 16:54
nwc10 jnthn: meaning it can't even bootstrap NQP yet? 16:58
jnthn Haven't tried; if I do, I end up with no NQP :P 16:59
(Without switching commit)
nine jnthn: we already do that. The problem is with a JIT compiled nativeinvoke_o instructions. As with normal invocations, the JIT won't generate any code for arg_i instructions as spesh already knows in what WORK registers we can find the values. So optimize_getarg will replace the getarg_i with a simple set with the WORK register as the source. But sometimes the JIT compiler actually bails.
Now we end up with arg_i instructions still there, but the getarg_i (for reading back rw values) already being removed. 17:00
What optimize_getarg would need is to know whether JIT compilation of the frame will succeed or not, before we try to actually compile.
Worse, at that point we don't even know the final look of the code we're trying to JIT compile yet. Further optimizations may very well remove impendiments, most notably those getarg_i instructions... 17:03
jnthn Why can't the JIT of getarg transform getarg_i instead of doing it in the optimize phase?
nine That may be the way out. Too bad we're losing set elimination that way 17:04
jnthn I'm a bit confused about how this works. I'd kinda expected native rw things would be being passed native refs...
And we'd perhaps dig an appropriate location out of those 17:05
nine And maybe that's the real issue? Me actually not having a clue about how this native ref stuff works and instead building something that works...mostly 17:06
jnthn A native ref is a safe reference to a native lexical, attribute, or array element, that holds the stuff to keep the target object alive and do the lookup within it 17:07
The problem we will still have, though, is on width: if you declare a `my int $x` and pass it to a `int16 $foo is rw` is that allowed today? 17:08
nine jnthn: this is the code for assembling the native sub body QAST: github.com/rakudo/rakudo/blob/mast...l.pm6#L330 17:09
Probably explains what I do better than me trying to describe :)
A sucky part is that we need to turn type objects into default values for parameters 17:11
jnthn ah, I see... 17:14
@assigns.push: QAST::Op.new(
:op<assign>,
QAST::Var.new(:scope<lexicalref>, :name($name)),
QAST::Op.new(:op<getarg_i>, QAST::IVal.new(:value($args - 1))),
That answers what I was wondering about
nine So is there a way without a getarg_i? 17:15
jnthn I can see why this is painful; we've not really considered the args buffer as being something you ever touch post-call... 17:16
I wonder if we can introduce a argrw_i and argrw_n, that may only be used together with a nativeinvoke (check it in bytecode validation) 17:18
Though...urgh
That'll be SSA-horrid
I think maybe move it to the JIT, keep track of what registers were used for the args, and then if getarg updates the same one, then eliminate it, otherwise make it into a set 17:21
Where by "the same one" I mean "unversioned"
Which if the code-gen is careful might also avoid the sets 17:22
On the other hand...
Maybe don't worry about the set elimination, and once this gets expr-JITted then maybe we can clean it up in the expr-JIT optimizer?
nine Yeah, that's probably a good plan. I'd rather lose set elimination than inlining. Sets are only so expensive anyway. The real benefit will come once we can get rid of the native ref itself for inlined calls 17:24
jnthn Indeed
Wonder if I should handle that in the EA 17:25
It's probably a fairly natural fit
Oh, hmm...maybe not :)
I guess the answer is "yes for positional and attribute ones, maybe we need to think through lexical ones a bit more" 17:33
17:54 Kaiepi left
Geth MoarVM/more-pea: b585349d50 | (Jonathan Worthington)++ | 2 files
Deal with transitive escapes

If object O1 is referenced by object O2, then make sure if O2 escapes after we've considered O1's assignment into it, then O1 escapes too. We'll revisit this when doing handling of partial escapes.		 18:06
jnthn NQP builds/tests and Rakudo builds/tests with that, surprisingly enough
I'm sure it's still not quite right in its deopt handling though
Though I'm out of brane for that. 18:07
Amazingly, it passes spectest with MVM_SPESH_BLOCKING=1 too 18:12
So I'll have to look harder for a failing case
Maybe NODELAY will find me one 18:15
I think the materialization algo needs to become two-pass: first create all the objects and shove them in registers, and then write all of their attributes 18:19
Then if we get the deopt materializations table right, so that it has entries for the replacement registers holding the trasitively escaped objects, it should all just work 18:20
18:20 patrickb joined
jnthn And this way we don't need any special handling of the transitive stuff in deopt beyond that (e.g. it doesn't have to care, jsut chug through the work) 18:21
Annoyingly, spectest on NODELAY is also looking quote good; only two fails so far are the line numbers etc. ones busted by inlining 18:22
So I probably have to work out a synthetic case
Or blin :P
OK, enough for now :) o/ 18:26
19:28 MasterDuke left 19:50 Kaiepi joined
patrickb o/ 21:40
Is it important for the moar executable to work without being installed? (Called in the installation directory?) 21:41
I ask because in my relocatable branch that is not the case when moar is build relocatable, because it searches for libmoar.so in EXEC_PATH/../lib/libmoar.so 21:42
I could build two executables: moar and moar-reloc and only copy moar-reloc during make install. Would that be acceptable? 21:43
timotimo that ought to be fine. i don't think we ever use moar during build before it'd be installed 22:06
(however, at one point we'll want to be able to build moar + nqp + rakudo before installing any one of them)
patrickb hm... 22:19
timotimo we've been hoping to get that for years, it wouldn't be a problem to have to wait for another year :) 22:20
especially if we get relocateable rakudo for that
patrickb Kaiepi: I got an OpenBSD VM running on my end and tried building and running moar. 22:31
Kaiepi ok 22:32
patrickb Kaiepi: The reloc branch worked out of the box.
Kaiepi hm
lemme try building it again
patrickb Did you try to run the moar executable in the build directory or did you 'make install' and run the moar from there?
Kaiepi make install
patrickb hm. Then I'm sort of out of clues on what might be wrong... 22:33
I do still have the OpenBSD VM running though ;-)
Kaiepi ld.so: moar: can't load library 'libmoar.so' 22:34
are you running -stable or -current?
patrickb I downloaded the 6.4 ISO. 22:35
Kaiepi -stable then
what happens when you pkg_add libtommath and pass --has-libtommath to Configure.pl?
patrickb will try 22:36
can you do a `objdump -x moar` again?
over here the dynamic section lists: "NEEDED libmoar.so" and "RPATH $ORIGIN/../lib"
Kaiepi RUNPATH $ORIGIN/../lib and NEEDED libmoar.so are there 22:37
patrickb and libmoar.so actually is located in ../lib relative to the executable, right? 22:39
Did you compile with clang or gcc
it picked clang on my system...
Kaiepi i tried both 22:40
libmoar.so isn't in lib
patrickb huh?
ok
Kaiepi oh wait 22:41
i'm forgetting it installs to /install when there's no prefix
it's there
yeah it works
patrickb and you called the moar executable from that folder?
it did? 22:42
Kaiepi i wasn't earlier, i was calling it from the main folder
patrickb Ah, that's what I thought.
So it's working. Great!
(Whoot! Now only finishing up mac and we are good to go!) 22:43
Kaiepi :)
patrickb Thank you!
22:54 lucasb left 23:07 Kaiepi left 23:40 manchicken joined 23:48 manchicken left 23:52 manchicken joined 23:59 manchicken left

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!