github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:02 sena_kun joined 00:03 Altai-man_ left
timotimo i'm not totally up to speed with the whole thing, but what i saw while single-stepping was that tc->cur_frame->caller with its return_address would be an appropriate position to jump to, but instead of the frame's ->caller we're taking a value from a frame on the stack region? 01:42
ah, a helpfully placed comment says that's to do with lazy deopt 01:46
02:01 Altai-man_ joined
timotimo so the return address that's being used to jump the interpreter into oblivion gets set up by the sp_dispatch_o op? 02:01
02:03 sena_kun left
timotimo i don't get any "marked frame for lazy deopt" output, and it also doesn't go through the orig_kind thing in the callstack frame 02:10
init-array has the static "allocate on heap" bit set; could that have to do with anything? 02:25
ok 1 - No SEGV or other crash in recursive init routine on a native array 02:36
^- when i disable setting the allocate on heap flag
so make of that what you will i guess :) 02:37
i'm not entirely sure if i can ask to only see crashes rather than cases where there's failing tests? 02:46
so i wonder if we're somewhere not setting FRAME_PROMOTED when we're heap-allocating-from-the-start rather than promoting after the fact 02:50
ah, it's got its own type, which is just HEAP_FRAME 02:52
04:02 sena_kun joined 04:03 Altai-man_ left 05:29 Kaiepi joined
nwc10 good *, #moarvm 05:35
05:38 Kaiepi left 05:41 Kaiepi joined 06:01 Altai-man_ joined 06:03 sena_kun left
nwc10 what platforms does MoarVM build on currently? In that 07:34
nine I've seen x86_64, x86, PowerPC, aarch64, armv7l and MIPS. I'd guess it would build on s390x if I were to use libffi instead of dyncall. -> build.opensuse.org/project/show/ho...rakudo-git 07:41
nwc10 "we run on both kinds of OS" www.imdb.com/title/tt0080455/quotes/qt0320035
which of course can mean "Win32 and Linx"
or "RPM based and Deb based"
or "Ubuntu and Debian"
nine Ah, well Linux, OS X, Win32, FreeBSD and OpenBSD at least 07:42
nwc10 but, all of those are either "linux with gcc (anything else on linux has to fake gcc well enough" or MSVC
so, so far, only gcc, clang and MSVC
I think the limiting factor here currently is "what platforms outside of linux, *BSD(*)and Win32" does libuv support 07:43
[*](macOS diverging from *BSD)(or just jumping the shark)
nine We also have configuration support for icc, so at least at some point that worked
nwc10 icc lies hard, and claims that it's GCC
nine libuv and either dyncall or libffi
nwc10 which is really bloody annoying, because it doesn't quite fake it properly in somep laces 07:44
or did not, when I tried it
(some years ago, but I can forsee that they figure they need to lie about being gcc, and hence the problem won't never happen again)
"Mozilla (compatible MSIE (compatible (..." 07:45
I think that one of dyncall and libffi was mature enough that it supports platforms that are as dead as IRIX and Digital Unix
I suspect that libuv is the portability blocker 07:46
also, I'm not sure if I currently have access to any big endian hardware. 07:51
08:02 sena_kun joined 08:03 zakharyas joined, Altai-man_ left
nine Yep. With libffi we actually build on s390x (big endian) :) 08:48
jnthn Another question is how many folks want to run on those platforms these days. 09:55
nwc10 "probably none, but someone else is paying them" 09:56
but
more reaslistically, I'm not sure how much production use there is for some linux platforms
and whether it's partly on (say m68k) "because we can" 09:57
10:01 Altai-man_ joined
nine Well, a healthy dose of portability usually improves the quality of software and often enough helps even on the main target. Of course, like with everything one can overdo it... 10:01
nwc10 yes, indeed. EBCDIC... 10:02
jnthn Yes, the balance is the interesting part. I mean, clearly we want big endian in the mix.
ARM matters
etc.
nwc10 specific 2 things I realised where
1) I don't think I currentlty have access to big endian systems 10:03
10:03 sena_kun left
nwc10 2) not sure if libuv builds against any Unix "vendor" C compilers 10:03
(which are typically on big endian platforms, or at least, the ones on the OSes that started out big endian are usually the most "fun" (ie exacting) for finding the real bugs 10:04
nine I've done my endianness debugging in a VM which is....fine if you do it about once a decade. For testing the Open Build Service is doing fine. 10:09
nwc10 I have not tried this, but IIRC that works for endianness and suchlike, but not alignment enforcement. qemu is nt enforcing alignment traps (somewhat by design - to do so would kill performance) 10:11
11:19 zakharyas left 12:02 sena_kun joined, sena_kun left 12:03 sena_kun joined, Altai-man_ left
jnthn OK, back to my bug hunting... 12:25
nwc10 "have you looked behind the sofa? 12:26
"
one of mine was "forgetting to initialise the pointer" - I doubt that yours are that simple.
jnthn No, this one might be that I'm mismanaging the segmented stack, but if I am, I'm either too stupid to see where, or I've managed to write code that really looks convincingly correct but isn't :) 12:30
Also if it's that, I don't understand why specialization is required to trigger it 12:31
Phew, it seems deopt is *not* involved, though, because the last deopt happens long, long before the SEGV 12:32
OK, it is probably stack mis-management 12:35
Because a) if I make the stack segment huge the problem doesn't happen, and b) it's a recursion test 12:36
I don't know exactly why it only trips up with spesh enabled though 12:37
12:41 colomon_ left 12:47 colomon joined 12:51 lucasb joined 14:00 Altai-man_ joined 14:03 sena_kun left
jnthn OK, this gets interesting. Somehow when the specializer is on, a bunch of things that are stack frame records become heap frame records 14:04
14:04 statisfiable6 left, reportable6 left
jnthn Those are smaller on the callstack, which impacts the region boundaries 14:04
However it's already rather odd that it is picking heap frame records over stack frame ones 14:05
[Coke] O_o;
jnthn I hope I'm reading this diff the right way around :)
It appears I am 14:06
lizmat
.oO( have you tried rotating it 90 degrees counterclockwise? :-)
14:07 statisfiable6 joined, reportable6 joined
[Coke] O 14:10
|
o
.-
jnthn Also, if I disable the mechanism that decides to do direct heap allocations when frames largely end up being promoted, the problem goes away, but I think that's probably just hiding the issue 14:29
timotimo jnthn: when i was debugging i did notice that the problematic frame on the callstack was either made as "the first record on a new stack page" or something nearby is 14:42
i've wished for a pretty-printer of the callstack when looking at things; jnthn, would that be a thing you'd be interested in? 14:43
14:44 zakharyas joined
Geth MoarVM/new-disp: 4 commits pushed by (Jonathan Worthington)++ 14:48
jnthn The third of those seems to be the thing that fixes the problem, but I must admit I don't totally understand whey things go so wrong when they aren't done 14:49
Also, ASAN sees leaks
Good ASAN
nwc10 there were already leaks 14:51
I have been ignoring them.
jnthn Yes, I'm not saying they're new with these patches :)
nwc10 I hope to feel bad about this soon and chase them down
others are welcome to beat me
timotimo ah, well, that looks fix-y 14:52
jnthn grmbl, this doesn't make `make test` lose its hard to repro outside of running `make test` failures
timotimo i wonder if recording all runs during a "make test" will work 14:53
actually, rr could actually record the entire process tree
but i haven't done much multi-process rr debugging yet
jnthn urgh, what... :/ 14:58
timotimo though of course running it under rr may very well prevent it from actually breaking
jnthn Loads more SEGV in the spectest run now
But not when I run the things on their own
timotimo ===( 790;140 3/4 0/2 2/45 0/? 0/? 0/? )======================moar: src/6model/sc.c:401: MVM_SC_WB_OBJ: Assertion `!(obj->header.flags & MVM_CF_FORWARDER_VALID)' failed. 14:59
well, here's a kind of crash i guess
MoarVM panic: Heap corruption detected: pointer 0x7f0ff8175420 to past fromspace
ummmmmmmm
there are actually multiple of these 15:00
jnthn Hm, so why can't I get these to happen
timotimo haha, if i do nothing special, i get a response of "the target is not responding to interrupt requests." when i ctrl-c 15:06
jnthn aha...got a zeroed owner 15:10
With a small nursery it's even more easily reproduced 15:16
timotimo gist.github.com/timo/272918577ef5b...6f295ea55f - pretty fascinating; all processes that got created as part of an rr record 15:23
Geth MoarVM/new-disp: 1b62bcd597 | (Jonathan Worthington)++ | src/6model/reprs/MVMCapture.c
Fix assorted MVMCapture GC bugs
 15:35
16:01 sena_kun joined 16:03 Altai-man_ left
Geth MoarVM/new-disp: 643053fd52 | (Jonathan Worthington)++ | 4 files
Fix marking of dispatch program run temporaries

Also, make the dispatch run record smaller; in the end, we did not need to have a full outcome record in it.		 16:08
timotimo do dispatch programs have to be tiny? should we be able to invoke the compiler to build the code object that gets used? :) :) 16:20
Geth MoarVM/new-disp: 0e4330216a | (Jonathan Worthington)++ | 2 files
Mark values we track or insert into a capture

At the point that we allocate the capture or tracking object.		 16:22
timotimo also, you think dispatch programs and records have a place in the spesh log? 16:23
jnthn I don't think so; they already can be dumped 16:24
timotimo that's fair
jnthn Those patches help quite a bit with the crashes 16:25
timotimo \o/
there's dispatch programs that are simple enough that i should totally be able to generate spesh from it 16:27
without breaking a sweat
Dispatch program (1 temporaries)
Guard arg 0 (type=ObjAt, concrete)
Load argument 0 into temporary 0
Set result object value from temporary a
jnthn Yup :) 16:29
timotimo "Skip first 0 args of incoming capture; callsite from 0" 16:36
oof, how do skip 0
timotimo goes back to algorithms & datastructures book
jnthn :) 16:39
timotimo mhh, i need one mode where it outputs guards and one where it outputs checks and BBs, for when multiple programs are concatenated into one spesh graph 16:40
though i can do the first part first and leave the second part for later™
alternatively, do the second one first and on the else branch sp_dispatch_o instead
also, interested in that patch that subtracts 2 from the bytecode addresses that the dispatch ops log at? :) 16:42
jnthn you probably depend on it for the bit you're looking at now, no? 16:43
'cus you need to know if it's monomorphic or polymorphic 16:44
timotimo right, it'll otherwise "not dispatched ever" everywhere
jnthn Anyway, it sounds reasonable enough 16:45
timotimo \o/
jnthn I'm actually going to have to implement basic multi dispatch stuff to get a good idea of how faily things really are at this rate.
'cus a bunch of the spectests fail over that now
Let's see if I've got any more SEGVs though 16:46
Geth MoarVM/new-disp: 02b9591920 | (Timo Paulssen)++ | src/core/interp.c
account for opcode length in dispatch log address calc
 16:47
MoarVM/new-disp: 4cf73c4bc1 | (Jonathan Worthington)++ | 2 files
Change how chosen dispatch program is put in place

  * Don't need to waste time on it when it's just a value result
  * Do need to have it done ahead of calling a C function, otherwise if we
   end up doing GC marking as a result of that, chosen_dp would be junk
   and thus blow up		 16:48
MoarVM/new-disp: 2b52b73027 | (Timo Paulssen)++ | src/spesh/disp.c
fix off-by-one in monomorphic vs polymorphic calc
 16:57
timotimo another bugfix that was basically free :)
jnthn Hm, still some GC invariant bustage bug remains 16:58
timotimo looks like the inline cache will want an API that spesh can use to get at the dispatch programs stored inside the PIC at a slot, since checking what kind of struct is used for storage depends on what function pointer is stored as the run_dispatch? 17:04
jnthn Yes 17:05
timotimo should be EZ :)
thinking of MVM_INLINE_CACHE_KIND_ + a chunk of the struct name in question 17:06
but first the api will just return a dp 17:07
mh, later when flattening becomes part of the spesh codegen, more of the stuff in the structs will be necessary 17:08
so the api will actually have to return the right kind to cast the struct to
jnthn Somehow we end up with a frame that has a totally bogus code ref and outer 17:18
What's really odd is the static code is fine
So it was probably fine when it was set up
I wonder if this is continuation-y
If it is, it ain't obvious 17:22
Also I suspect 7:30pm on a Friday is not the time to be debugging this :) 17:23
nwc10 have you considered giving a keynote instead? :-) 17:24
timotimo where does it blow up? i could give rr another go
it'[l be much easier to get a handle on the explosion if i don't have to learn how to handle multi-process recordings
we may want to put MVM_PUBLIC in front of some of the new functions we put out 17:26
jnthn t/spec/S17-supply/syntax.t with MVM_SPESH_BLOCKING on and a small nursery (I have 32KB)
OK, home time 17:27
timotimo good "travels" :)
jnthn Yeah, hope I don't get rained on :)
nwc10 I hope that you don't get rained on
(snap. there was a massive rain and then hailstorm here) 17:28
timotimo i hope your place of residence cools down soon, if it's anywhere near our local levels of warmth earlier today
nwc10 jnthn: OK, odd, so, problem is that my NQP checkout is on a detached head 17:45
but I never "loiter" there - I end up either in the MoarVM or the rakudo checkouts 17:46
and so I didn't raelise
I believe that I was missing the last two commits
problem no longer exists between keyboard and chair 17:47
17:59 zakharyas left 18:00 Altai-man_ joined 18:03 sena_kun left
timotimo oh, ah, i need not just manipulate_split_version, i should probably use almost a copy of insert_arg_type_guard 18:20
it also needs the synthetic deopt annotation i imagine
oh, interesting, guardjustconc and guardjusttype take sslot even though they don't need one. probably a copy-paste mistake i made long ago 18:36
sp_guardconc r6(7), r6(5), sslot(1), litui32(4) # [002] inserted dispatch program guard 19:00
sp_dispatch_o r5(3), lits(raku-rv-decont-6c), callsite(0x7fc574f961c0, 1 arg, 1 pos, nonflattening, interned), sslot(4), litui32(1), r6(7) 19:03
^- there's only a single op implemented yet, and nothing to "undo" when an NYI got encountered, so right now it only rewrites the sp_dispatch_o argument, and the sp_dispatch_o still remains
only spent about 30 seconds being confused why i don't see the "set" op i thought i had added to the graph 19:24
before realizing it was surely tossed out by spesh
19:39 zakharyas joined
timotimo finally got some codegen beginning to end 19:57
for programs made up of exactly three different opcodes :) 19:58
lizmat
.oO( baby steps )
 19:59
nwc10 three ops? Decadent. My understanding was that "subtract and branch if less than or equal to zero" alone is Turing complete. 20:00
timotimo absolutely 20:01
we do torture the implementors on behalf of the users, though
nwc10 but what I did not know was this: github.com/jbangert/trapcc
"This is a proof by construction that the Intel MMU's fault handling mechanism is Turing complete."
20:01 sena_kun joined
timotimo whee! 20:02
20:03 Altai-man_ left 20:13 MasterDuke joined
MasterDuke even just mov is turing complete 20:16
20:18 patrickb joined
timotimo "just" mov is perhaps slightly misguided, since mov has such a huge variety of meanings 20:19
MasterDuke true. iirc it was mov-in-the-x86-isa is turing complete, or something like that 20:21
timotimo oh no, all the "Rewritten from a dispatch_* op" comments have disappeared! 20:28
(because all ops from inside the disp program have been eliminated by the optimization)
sp_bind_o r5(9), liti16(32), r7(3)
[Annotation: INS Deopt One (idx 4 -> pc 240; line 1555)] 20:29
set r6(3), r5(9)
return_o r6(3)
this used to be
bindattr_o, then 20:30
dispatch_o r7(4), lits(raku-rv-decont-6c), callsite(0x7fb38caa91c0, 1 arg, 1 pos, nonflattening, interned), r5(9)
then a wval and then
20:30 colomon left
timotimo dispatch_o r6(3), lits(raku-rv-typecheck), callsite(0x2124240, 2 arg, 2 pos, nonflattening, interned), r7(4), r5(10) 20:30
so it actually code-genned and then tossed out two dispatch programs here 20:31
MasterDuke nice, right?
timotimo the wval was only there to feed the second dispatch program
(and of course return_o was also in the before)
20:33 colomon joined, colomon left
timotimo just a tiny patch later, 20:38
encoderepconf r12(2), r2(1), r8(1), r10(1), r7(8), r11(2) # [005] Rewritten from a dispatch_o op 20:39
return_o r12(2)
comes out of another pair of rv-decont-6c + rv-typecheck
nwc10 you're missing (or not, you can rewind) www.youtube.com/watch?v=O-U1lv9SU_w
timotimo it's running on the side :) 20:40
nwc10 I'm playing catchup at 1.5
timotimo i'll later re-watch the intro i imagine
MasterDuke i usually watch talks/streams/etc at 1.5x 20:46
nwc10 damian was clear that I could watch at 1.75 easily, and 2.0 was bit rushed. 20:47
was so clear
I was surprised 20:48
but rewind is also awesome.
21:21 zakharyas left
timotimo aha! looks like the deopt in this translated program is deopting to behind the dispatch op, not in front of it 21:29
so the set that takes the value and puts it into the register that is to be returned is skipped (because it's part of the dispatch program to be run "in general") 21:30
i have far too little clue about how to do deopting correct with synthetic stuff, so maybe i'll branch off of jn's branch and ask for his wiseness here 21:48
Geth MoarVM/disp-prog-spesh-codegen: c19db6368e | (Timo Paulssen)++ | 2 files
API for getting the kind of a DispInlineCacheEntry
 21:55
MoarVM/disp-prog-spesh-codegen: 9ebd381d95 | (Timo Paulssen)++ | 3 files
first impl of spesh codegen of disp program

currently the guards deopt to after the dispatch op rather than before, so failing a guard from a return type check (for example Mu from pull-one) will leave you without any value put into the .o register that is to be returned (-> crash)
MoarVM/disp-prog-spesh-codegen: b82d6e327d | (Timo Paulssen)++ | src/spesh/facts.c
catch one forgotten op from facts (encoderepconf same as encoderep)
22:01 Altai-man_ joined 22:03 sena_kun left
timotimo i will assume that this means dereference: Deference object attribute at offset 8 in temporary 0 22:04
jnthn That or defenstrate :) 22:05
tellable6 2020-06-26T17:39:29Z #raku <ShimmerFairy> jnthn I couldn't find a problem in the code I tried with Comma months ago, so either the highlighting was a freak error or has since been fixed (or my code changed the problem area since then).
timotimo anyway, how am i supposed to know if my implementation of the code gen is right if all the ops get deleted immediately after i generate them? :D 22:09
jnthn Write something more morphic :) 22:10
timotimo i'm currently not handling more-than-monomorphic yet :)
i put a big fat output in when it sees that and it doesn't trigger in my current example program with nodelay or without 22:20
22:22 patrickb left
timotimo [Inferior 1 (process 5216) exited normally] 22:31
le gasp
segfaults if i remove NODELAY however, which also makes sense 22:35
Geth MoarVM/disp-prog-spesh-codegen: 4 commits pushed by (Timo Paulssen)++ 23:33
timotimo may actually want to put a little env var in to en- or disable the code-gen of dispatch programs 23:44
since it's a big NYI with no cleanup at the moment :D

Powered by Cro and the Raku® Programming Language.

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

Thank you!