Geth MoarVM: MasterDuke17++ created pull request #647:
Remove impossible check		 00:02
01:52 ilbot3 joined 03:35 pharv_ joined 05:00 pharv_ joined 05:45 brrt joined
brrt ohai moarvm 06:02
nwc10 good *, brrt 06:03
brrt nwc10, any thoughts about the W^X debacle 06:05
(yes, that did keep me up at night)
nwc10 er, none useful.
brrt shall i explain the issue 06:06
or would that not help :-)
nwc10 I'm sort of aware of what the problem is
well, technical, and political
and my head is full of trying to work out how to test some work code 06:07
brrt then i won't bother you :-)
but i will figure out how dlmalloc gives us double-mapped memory 06:14
06:18 domidumont joined 06:25 domidumont joined 06:48 brrt joined
samcv so i implemented Knuth-Morris-Pratt string search 07:13
my $string = 'a' x 100000000 ~ 'b'; nqp::index($string, 'aaaaaaaaaaaaaaaaab', 0);# before 28.0579458s after 2.94111041s 07:14
spectest pass as well ????
not sure how to name anything though 07:15
brrt … that's impressive 07:18
samcv++
samcv idk i have it named knuth_morris_pratt_index now
static since meant to be used from the other function
brrt (that's the one in which you build a jump table to seek forward (or backward) when you see a single character, right?) 07:19
samcv uh
brrt i'm not sure, i'm going of memory :-) 07:20
samcv yeah
that's how it seems to work 07:21
brrt .ask markmont where, if anywhere, can he find a netbsd 8 vm 07:32
yoleaux brrt: I'll pass your message to markmont.
Geth MoarVM: samcv++ created pull request #648:
Implement the Knuth-Morris-Pratt string search algorithm		 07:40
samcv if you want to take a look at my implementation ^ 07:41
brrt thanks 07:54
08:12 zakharyas joined
nine Oh, 2/3 program committee members of the vm meetup are actually from Linz 08:12
yoleaux 15 Aug 2017 12:28Z <AlexDaniel> nine: OK, thank you!
brrt (linz?) 08:15
oh, a city
nwc10 where nine lives
samcv what/when is this vm meetup 08:23
lizmat samcv: vmmeetup.github.io/2017/ 08:51
samcv cool 08:52
jnthn morning o/ 08:56
samcv morning jnthn 08:57
08:59 nebuchadnezzar joined
brrt \o jnthn 09:11
jnhtn, i'm still trying to get netbsd-current installed in a VM
jnthn That sounds...fun :P 09:13
brrt yes 09:14
jnthn I'm hunting a SEGV
brrt it is isn't :-P
aha
that sounds funner
jnthn Outdated GC pointer
samcv jnthn, when you get the time check out my PR implementing knuth-morris-pratt algorithm natively 09:26
jnthn ahh...turns out that between a new thread object being created and it being run, the ->tc it points to isn't yet being marked 09:29
Because the thread ain't yet running
samcv what does marked mean? 09:30
GC marked? 09:31
for collection?
jnthn Yes.
Oh...there's already code trying to take care of this situation though
Geth MoarVM/atomics: d00d829b8a | (Jonathan Worthington)++ | src/core/frame.c
Add GC debug check on frame heap promotion.

To make sure nothing in the promoted chain is in fromspace.		 09:45
MoarVM/atomics: e32eec6a5a | (Jonathan Worthington)++ | src/core/threads.c
Move thread to starting after running list insert.

There is code to mark the thread contexts of not-yet-started threads in the MVMThread REPR's gc_mark function. Once it's in starting state it participates in GC "as normal". Recent refactors changed the way the insertion into this list is handled, but didn't move the location of the thread state update. This moves it to happen only after the thread has been placed into the running list, thus avoid a period when the thread context would go unmarked.
jnthn Glad ot catch that one. Alas, it's not the only one. 09:47
*to
And the new check added in d00d829b doesn't trip 09:48
The problem manifests as a frame with an outdated ->caller
Hm, and it seems spesh-sensitive 09:50
Happens with both JIT and inline disabled 09:52
nwc10 does that make it easier to chase down, or harder?
jnthn Well, I suspect deopt a bit 09:53
But...uh...inlining is gone
So it can't be uninlining
Which does create/insert frames
Wonder if my runs with spesh fully disabled just got lucky
hah, OK, got it to finally happen with spesh disabled 09:55
nwc10 oooh, interesting. latent bug 09:56
jnthn Well, it's at least somewhat interseting that this only shows up (so far at least) in my newly added atomic ops tests 10:04
oh 10:13
Turns out a gen2 frame points to a fromspace caller
How does that even happen?!
I guess it could on promotion 10:15
But that seems to be write-barriering properly anyway
dogbert17_ there are only one SEGV/fromspace bug in MoarVM left that I know of in the main code, i.e. not the atomic branch, and that is github.com/MoarVM/MoarVM/issues/554 10:19
yoleaux 15 Aug 2017 23:52Z <MasterDuke> dogbert17_: irclog.perlgeek.de/moarvm/2017-08-15#i_15021638 if you're interested
dogbert17_ s/are/is/
geekosaur "that [you] know of" 10:20
it's not the known bugs that are the problem, usually :p
dogbert17_ indeed :)
currently it SEGV's in MVM_gc_root_add_frame_registers_to_worklist ... 10:21
it is probably not what jnthn is currently chasing 10:22
jnthn Uh...that's fairly close 10:24
dogbert17_ here's more detail: gist.github.com/dogbert17/0561c562...3428050538 10:27
jnthn Hm, mighta found the missing wb 10:29
Somewhere I hadn't expected to need it
Test seems to be running happily now though
Will leave it looping for a bit
But got it running wiht spesh etc. turned on now 10:30
forgot to set the env vars in a new debug session
But those made it show up quicker
So, looks promising
oh wait, argh
I forgot to breakpoint MVM_panic :/
grr, it hit 10:31
dogbert17_ grumble :)
jnthn Same structure though 10:34
gen2 frame with fromspace caller
This could happen with continuations
But again, that is barriering 10:36
dogbert17_ now I got the nonblockingawait test to panic instead 'Collectable %p in fromspace accessed', perhaps that is more informative given that we're looking at the same bug 10:40
s/given that/if/
jnthn oh, interesting...it now doesn't seem to happen with spesh disabled
So maybe my patch so far did help that case 10:42
oh no
Was just lucky
or "unlucky"
dogbert17_ jnthn: FWIW, I updated gist.github.com/dogbert17/0561c562...3428050538 10:44
jnthn ohhh 10:47
Something in continuation was wrong 10:48
Geth MoarVM/atomics: f57b35eac9 | (Jonathan Worthington)++ | src/core/continuation.c
Correct MVM_ASSIGN to barrier the right target.
 10:54
jnthn Sadly that doesn't fix it, but it needed fixing anyway
dogbert17_ jnthn++
jnthn Woulda explained it perfectly though :/ 11:12
brrt so at least i'm installing netbsd 7.1 now 11:17
dogbert17_ jnthn: sorry if I'm leading you astray by postings gist relating to a different bug 11:23
jnthn dogbert17_: Could be related, dunno 11:24
Also coulda been helped by the fix above
Not found anything further on the one I'm hunting yet
Added various extra sanity checks but they pass
dogbert17_ ok, could you reload gist.github.com/dogbert17/0561c562...3428050538 again, time permitting, I believe that I have been more thorough this time 11:27
jnthn Have you tried with f57b35eac9 ? 11:31
It's not impossible that the fix I did a moment ago mighta dealt with that
Well, 40 minutes ago... 11:32
Lunch now; will continue looking after
11:37 markmont joined
dogbert17_ according to my gdb session (still running btw): (gdb) l continuation.c:151 11:38
151 MVM_ASSIGN_REF(tc, &(cont->body.root->header), cont->body.root->caller, tc->cur_frame);
dogbert17_ figures that the lunch concept has merit :) 11:39
nwc10 wonders which timezone ilmari's stomach is in 11:41
markmont brrt: For instructions on installing NetBSD 8, see blog.netbsd.org/tnf/entry/netbsd_8...se_process 11:45
yoleaux 07:32Z <brrt> markmont: where, if anywhere, can he find a netbsd 8 vm
markmont brrt: I set up my own VM on my laptop using those instructions. 11:46
brrt: Also, dlmalloc doesn't have much to do with the double-mapped memory. That's all handled by closure.c. dlmalloc is just used to parcel out chunks to the program -- and reclaim them -- from within the double-mapped memory region. 11:48
.tell brrt: irclog.perlgeek.de/moarvm/2017-08-16#i_15024158
yoleaux markmont: What kind of a name is "brrt:"?!
markmont .tell brrt irclog.perlgeek.de/moarvm/2017-08-16#i_15024158 11:49
yoleaux markmont: I'll pass your message to brrt.
jnthn back 12:18
Sadly, no great ideas of what the bug might be during lunch
Geth MoarVM/atomics: 4eeb82c124 | (Jonathan Worthington)++ | src/core/frame.c
Correct a comment.
 12:19
12:29 zakharyas joined
dogbert17_ is it enough to check out the atomics branch in MoarVM to get your new stuff running or do I need a Rakudo branch as well? 12:51
brrt markmont: thanks, but i've basically been there, and i don't understand it yet 12:53
but at least i have 7.1 installed 12:55
timotimo dogbert17_: the ops have to at least be mapped through changes in nqp 13:12
the tests for the ops are potentially in nqp, too. otherwise in rakudo 13:13
jnthn There's atomics branches in both NQP and Rakudo 13:17
I've got the issue golfed fairly far 13:18
Still isn't making much sense though :S
Though it's looking like something goes bad in new threads
dogbert17_ sounds promising 13:23
Geth MoarVM/atomics: 5b3318f1b8 | (Jonathan Worthington)++ | src/core/threads.c
Root thread object while creating TC.

Just in case that should end up doing GC allocation.		 13:24
jnthn That wasn't it, alas
language class; bbiab 13:25
markmont brrt: you should be able to boot using daily-builds.netbsd.org/pub/NetBSD-...m/boot.iso 13:44
bttr: you'll need to configure networking manually in the installer and then point the installer at the install sets at daily-builds.netbsd.org/pub/NetBSD-...nary/sets/ 13:45
More details are at daily-builds.netbsd.org/pub/NetBSD-...STALL.html
14:06 domidumont joined
brrt aha 14:12
timotimo my face when business insider puts a tweet i wrote in one of their articles: :/ 14:14
brrt did they? 14:15
timotimo yeah, it had almost no impact on the tweet itself :P 14:16
www.businessinsider.de/save-418-sav...S&IR=T
i wouldn't have known if it weren't for a friend who pointed it out
Zoffix :o you're internet famous \o/ :D 14:19
timotimo the tweet got fewer impressions than most of my others
Zoffix lol
timotimo 302 impressions, 47 engagements 14:21
dogbert17_ timotimo: does this provide any useful information? gist.github.com/dogbert17/a09452b8...5ed5edea59 14:26
timotimo i haven't spent any time on this problem yet 14:30
14:41 TimToady joined
jnthn back 15:05
15:05 brrt joined
timotimo amusing, since the eliminate_pointless_gotos opt never found an inlined block it didn't care about keeping annotations from the last instructions around 15:12
i made it through code-gen and now the resulting code blows up \o/ 15:15
jnthn Hmm, this is so confusing 15:16
It panics about adding a pointer from fromspace into the worklist
But when I compare the pointer myself with the fromspace locations it's OK?! 15:17
And actually in gen2
o.O
dogbert17_ explaining something to others might sometimes make the solution appear :)
timotimo is one of the tc's fromspace size messed up? 15:18
jnthn No, they look OK 15:21
It only tests it against current TC anyway
There are other threads but this is thread 1 dealing with a frame it owns
timotimo "there are other threads like this, but this 1 is mine" 15:23
huh, how did i end up with an invalid sc index 15:25
jnthn Wow, this time I got it blowing up in scan_lexicals
Which is just like the one dogbert17_ had
dogbert17_ does it provide any new clues? 15:27
15:36 lizmat joined
jnthn I'm just starting to wonder if two threads are trying to GC the smae thing 15:38
Or somehow claimed the same thing
15:40 dogbert17 joined
dogbert17 like this? gist.github.com/dogbert17/a09452b8...5ed5edea59 15:40
brrt jnthn, markmont: i commented on the PR. I hope I'm being reasonable: github.com/MoarVM/MoarVM/pull/643#...-322812008 15:41
jnthn dogbert17: Looks very similar to that, eys 15:42
*yes
No, the ->gc_work lists look fine 15:43
It wasn't both stolen and marking itself
15:46 ggoebel joined
timotimo disabling inlining after one inline has been done gets me a lot further into the nqp build 16:03
Geth MoarVM/atomics: 5d346b8dfb | (Jonathan Worthington)++ | src/core/interp.c
Correct invokewithcapture GC handling.

Make sure we never let the stored capture become outdated, and also be sure to write barrier it just in case.		 16:04
jnthn That seems to help a good bit 16:05
dogbert17 so you found something 16:06
jnthn Yeah 16:25
Well, can't get the atomics tests exploding any more
16:28 zakharyas joined
timotimo since handlers are based on bytecode order, i can probably throw out the whole "duplicate handlers inside the inlinee" business? 16:36
jnthn timotimo: yeah, I guess so :)
timotimo wow, holy wat 16:39
i have here a PHI that has the same version of its register show up a whole bunch of times
jnthn o.O 16:40
timotimo it also has a crapton of predecessors
is this our "make all blocks in the scope of a handler be predecessors of the target block"?
PHI r29(9), r29(1), r29(1), r29(1), r29(1), r29(1), r29(1), r29(1), r29(2), r29(2), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3),
r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(3), r29(4), r29(4), r29(6), r29(6), r29(6), r29(6), r29(6), r29(6), r29(6), r29(7), r29(8)
jnthn Maybe 16:41
Though dunno why it'd dupe PHI nodes entries...
timotimo investigates 16:43
jnthn I mean, the CFG arrows are put in waaaay before we do the dominance and SSA
timotimo it's already there in the "before" part 16:46
jnthn Yeah, so it's presumably somehting going on when computing SSA 16:47
Hey, I wonder if we somehow get dupe entries in the pred/succ?
timotimo looks
Successors: 130, 131, 129, 163
Predeccessors: 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150,
151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162
so no, no duplicates
16:51 robertle joined
timotimo hm, it really just makes a phi with as many entries as there are pred bbs 16:58
dogbert17 jnthn: I'm not 100% certain but it looks like your last commit might have nailed github.com/MoarVM/MoarVM/issues/554 16:59
jnthn dogbert17: hmm, nice :) 17:00
17:04 zakharyas joined
nwc10 jnthn: ASAN refuses to make any comment on your branch :-( 17:43
18:28 ggoebel joined
jnthn That's...good, no? :) 18:41
samcv you guys have seen this RT right? rt.perl.org/Public/Bug/Display.htm...et-history 18:51
Bug #131857 for perl6: [REGRESSION] Aliased named parameters broke in a recent MoarVM commit 18:52
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=131857
samcv no bug with MVM_SPESH_DISABLE=1
jnthn Yup 19:03
Bit of an odd one... 19:04
Will see if I can figure it out tomorrow
nwc10 jnthn: ish - it does mean that it doesn't offer you a smoking gun 19:21
jnthn nwc10: Ah, but it seemed like my fixes nailed it :) 19:22
nwc10 excellent
19:33 ZofBot joined
samcv jnthn, so with our current string search and how i have knuth-morris-pratt done i use MVM_string_get_grapheme_at_nocheck 20:24
but since KMP never backtracks but sometimes checks the same thing in the haystack. we need a grapheme iterator that you can tell it (iterate forward to this point) or whatever 20:28
is like get_grapheme_at_nocheck except that it can only go forward and is optimized
21:25 markmont joined
jnthn samcv: So it can skip some graphemes, effectively? 21:36
samcv yes
jnthn samcv: I think the grapheme iter already has a move to or whatever
samcv does it?
jnthn Though I can't remember if it works relatively
samcv hm
jnthn I thought so..
samcv: github.com/MoarVM/MoarVM/blob/mast...iter.h#L54 21:37
samcv luckiliy the collation algorithm seems to be fairly fast. actually it's faster than `cmp` 23:29
haha
i was pretty suprised though 23:30
cmp: 0.228676s unicmp: 0.072635 for "\c[173568]" x 10000000 unicmp "\c[173568]" x 10000000;
suprisingly...
so i guess that means my code is good :)
jnthn, thanks for the link to that :) 23:31
wonder how much effect that will have on it
jnthn, i think the reason unicmp is faster than cmp is because i use codepoint iterators rather than get_grapheme_at_unchecked 23:33
well that's the only thing I can think of
well also the ring buffer means that it's actually only slightly slower than other methods of sorting strings, going down it very fast until it finds a difference 23:34
TimToady samcv: btw, was very nice to finally meet you in person at TPCiA 23:37
samcv you too :)
it was really great to meet the community, as it was my first programming conference ever. but i thought it turned out great :-) 23:38
TimToady yes, I remember the very first Perl conference, where a whole bunch of already close friends met each other for the first time, weird feeling... 23:39
TimToady hopes all your conferences go as well
jnthn samcv: Wow, nice! More correct *and* more fast :)
TimToady
.oO(does that mean we should be thinking about slipping it in in place of cmp?)
 23:40
samcv well i would have said no if you saked me a month ago 23:41
but since then...
TimToady something to think about, anyway
samcv but since then now it's faster
but i can make cmp faster as well though
TimToady or maybe cmp isn't fast enoug
samcv maybe 23:42
TimToady yeah, that :)
well, maybe a 6.d decision
jnthn
.oO( Last time I got saked was in a Japanese restaurant... )
TimToady conceivably there are people depending on current cmp order
jnthn Making cmp faster is probably good
TimToady oh, I can do that at home
samcv maybe i will stop being impressed with my results but i've only been programming as a perl 6 dev for just under a year. so maybe i will get used to it
TimToady I mean, saked, not cmp
samcv since before joining the team i had never had the opportunity to do something really important with my coding 23:43
jnthn is impressed with samcv++'s results
TimToady by the time you're my age you'll start hitting some of the mental limits :)
samcv hah
it's a weird feeling though. just wondering if it wears off 23:44
but i'm probably also getting better and that's part of it
TimToady there are plenty of other weird feelings you can explore in this space :)
samcv but maybe i shuold just see it as feeling of getting better
but i'm not a very good accessor of my own ability, but when i finish it then it becomes more clear that i was able to do it all along :P 23:45
TimToady me, I'm getting the feeling of losing control over the whole project, but since that already happened to me once with Perl 5, I'm rather enjoying it this time, since it turned out pretty well before :)
samcv heh
23:47 stmuk_ joined
jnthn Yeah, I remember the time I could keep track of all the Perl 6 stuff that was going on. 23:47
TimToady ducks back out to figure out why !dba isn't called at all from P6-level grammars, even when there's an explicit :dba()
jnthn Now? No chance. :) 23:48
I can't even keep track of the bits I'm meant to be doing :P
Can't even remember to go to bed. D'oh. :) 23:49
Well, back tomorrow...shouldn't screw my sleep up too much, a week tomorrow I'll be getting kicked off a sleeper train at 8:30am...
o/
samcv jnthn, i guess that's a good thing? maybe?
since lots of things are going on?
jnthn samcv: Oh yes. 23:50
samcv: I mean, the ecosystem being small enough that I knew all the stuff we had a module for wasn't so preferable ;)
samcv heh
yeah… that's not a great thing
jnthn Was quite some years ago. :) 23:52
Anyways, really sleep o/ 23:53
samcv night o/

Powered by Cro and the Raku® Programming Language.

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

Thank you!