timotimo not too far apart, eh. not really a big surprise there 00:00
samcv trying to figure out why moarvm segfaults on alpine 00:59
it seems to be happening when realloc is called
and maybe in build_cfg 01:02
gdb is giving me all kinds of "can't read this variable from this address" warnings on #0 in the backtrace 01:03
MasterDuke didn't someone figure that out a little while ago? something about the max stack size is too small 01:12
samcv that's not the issue 01:13
maybe it's a different issue idk. i just installed it and stack size is 8192
and valgrind shows the badness as well 01:14
MasterDuke well, there are a bunch of people who've mentioned it in #perl6, but no obvious solutions (at least from a 15s skim of the chat logs) 01:16
samcv i'm not seeing any problem with the stack. no stack overflow
MasterDuke "exec stack protection"? 01:17
samcv well it's happening in free and maloc 01:18
sec 01:19
MasterDuke, cry.nu/p/p72n/
MasterDuke "Address 0x4e9b180 is in a rw- mapped file /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so segment" maybe? 01:20
"Bad permissions for mapped region at address 0x408AFA8"
samcv here's a backtrace one place cry.nu/p/gr2w/
MasterDuke have you tried with MVM_SPESH_DISABLE=1? 01:21
samcv nice it fixes it 01:22
that stack is pretty big though 01:24
did you see the stacktrace? at least 212+ recursive calls to optimize_bb 01:25
MasterDuke yep, fun to dig through
01:54 ilbot3 joined
samcv MasterDuke, i think i solved compiling nqp on musl with spesh 03:34
MasterDuke cool, how'd you do that? 03:35
samcv i moved as much code as possible to another function. so we don't trash the stack completely 03:36
so keep as small a function as possible being recursed into 03:37
MasterDuke moved from what function? 03:40
optimize_bb?
Geth MoarVM: 5528083df7 | (Samantha McVey)++ | src/spesh/optimize.c
Fix segfault when compiling nqp with musl as libc

Because optimize_bb() can be deeply recursive, separate as much code as possible into a separate function optimize_bb_switch(), so we don't trash the stack. This fixes a segfault that occured when compiling nqp on Alpine Linux which uses musl as its libc.		 03:42
samcv MasterDuke, there we go :)
MasterDuke nice 03:43
samcv it recurses at least 99 depth when compiling nqp 03:52
yeah looks like 99, or a total of 100 calls to the funccion including the outer optimize_bb 03:53
Geth MoarVM: 6d844e0085 | (Samantha McVey)++ | src/spesh/optimize.c
Avoid recursion in optimize_bb() when only 1 child node

Optimize the case where we only have one child. This avoids having to do a recursive call to optimize_bb(). Keep following the nodes and running optimize_bb_switch() on them until we hit one with more than 1 child. Reduces the depth of recursion when compiling nqp from 99 to 29.		 04:36
07:39 domidumont joined 07:44 domidumont joined 08:21 zakharyas joined
nine Ooook, bytecode validator is happy, too :) Now on to the runtime 09:48
JimmyZ timotimo: github.com/cyrus-and/gdb-dashboard # you may like it 10:04
jnthn: ^^ too 10:05
samcv JimmyZ, you find it helpful? 10:17
timotimo JimmyZ: yup! i already got it in use :) 10:23
samcv: the problem really is the stack size
musl libc gives all threads launched with pthread_create a tiny default stack size 10:24
that's different from the main thread's size as well as whatever ulimit you might have set
samcv fun
timotimo that's also the reason why it only started failing now
samcv anyway the problem is mostly fixed
timotimo because spesh is now on a thread instead of on the main thread
samcv fixed it by splitting up the function so it recursises in only a small amount of code 10:25
and reduced recursion needed by 3x
so we should be pretty safe for now
timotimo not bad
samcv yeah. i felt smart for thinking about not recursing when there's only one subnode. and just running the separated code to keep tracing the nodes until it finds more than 1 child 10:26
only then doing recursion
that function doesn't seem to use up too much cpu time so may not affect our performance though? always good not having 100 levels of recursion just in the nqp compilation. not sure how much it would have been for the rakudo core setting
going to measure actually. 10:30
though just the 1st optimization of moving all the code into a separate function allowed rakudo to build and spectest to pass 10:31
nine Well reducing memory traffic can only help. It may e.g. free some CPU cache for other usage and thus improve performance more than the CPU stats alone would suggest. 10:34
samcv ok building rakudo it goes up to 59 *now*. before it went up to 313
wow timotimo
that's a *huge* improvement
timotimo that sounds good 10:35
samcv 5.3x less recursion. vs nqp saw 3x less
10:46 Skarsnik joined 10:48 samcv left, samcv joined 11:44 Skarsnik_ joined
jnthn . 12:00
yoleaux 04:06Z <AlexDaniel> jnthn: ? green light from me. SNAFU with Windows and JVM spectests, but it builds fine. No more blockers besides minor RT #132108 (it's a rakudo issue so doesn't prevent you from cutting a moar release). Besides that, everything looks fine from here. Good luck with moar release! ā™„
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132108
jnthn Alright, will get to it shortly :)
Geth MoarVM: 44dfdf7982 | (Jonathan Worthington)++ | docs/ChangeLog
ChangeLog for 2017.09
 12:35
MoarVM: 1e005d2f4b | (Jonathan Worthington)++ | VERSION
Bump VERSION
jnthn Changelog review welcome
Will do the release after lunch 12:36
samcv hey jnthn 12:46
my commits fixing the issue of recursion in optimize_bb, if you coul dcheck out those commits and make sure it seems fine. almost certain it is 12:48
jnthn samcv: Well, I'm not keen on the assignment inside of the call to optimize_switch_bb, could be clearer as a separate statement. 12:50
But in terms of correctness, looks fine
really lunch :) & 12:51
samcv jnthn, the assignment? 12:55
timotimo i've stumbled upon a very strange case where gi_get_grapheme infiniloops 12:58
i'll need to recompile without opts 12:59
gi->blob_type is 8864, that seems Very Wrong 13:00
timotimo rebases on latest master 13:01
did the ci_init go wrong somehow? 13:02
darn, it seems to only break with heap snapshots enabled
must be my fault, then :)
Geth MoarVM/jit_nativecall: 16 commits pushed by (Stefan Seifert)++
review: github.com/MoarVM/MoarVM/compare/1...0197e92370		 13:03
MoarVM/jit_nativecall: 6cc32bd9dc | (Stefan Seifert)++ | 13 files
Use proper args buffer for arguments of JIT compiled native subs

Replace the undocumented convention of expecting the args in the first locals of the block containing the nativecallinvokejit op by using the existing mechanism for passing args to invoking ops. The VM now has ncinvoke_* ops mirroring invoke_*. The special case in spesh is not needed anymore.		 13:07
jnthn samcv: optimize_bb_switch(tc, g, (bb = bb->children[0]), p); 13:11
samcv ah 13:12
jnthn At first I was like "huh, how is this not an infinite loop", and only then spotted that bb was updated inside the argument list
nine Ok, now let's see if I can revive the JITing of JITed native calls
samcv haha
my bad :)
i can separate that out jnthn
jnthn samcv: Yeah, if you don't mind, I think it'd help readability
timotimo i'm doing something wrong with the "major only" heap snapshot filter. but that's post-release anyway 13:13
jnthn Nice idea to just solve that problem instead of the harder problem of making it fully iterative ;)
samcv yeah. probably best not to do that unless it is in the if statement itself
heh
jnthn, even just taking the switch/while loop and putting it in its own function at least solved the nqp compilation issue
i was especially happy i thought of making it so it doesn't recurse for when there's only 1 child. so we do 3-5 less times the recursive calls 13:14
if we count the highest number encountered in nqp/rakudo compilation. so we should probably be okay for a while. since even the 1st change fixed compiling nqp and rakudo and passed nqp and rakudo roast
jnthn Yeah, hopefully that'll be enough
samcv yeah :) 13:15
dogbert2 FWIW, quite often when running spectest one of the tests (no 22) in t/spec/S17-promise/nonblocking-await.t fails with 'connection refused' 13:17
timotimo i think we're already refusing to spesh things that have too many BBs
we can surely up that number now, too
jnthn The nubmer is really high
I don't think we want to waste time speshing anything bigger than that
It pretty much never happens in real code anyway; it shows up mostly in the mainlines of huge .t files under MVM_SPESH_NODELAY 13:18
timotimo ah
fair enough
dogbert2 sometimes the same test hangs 13:19
jnthn It's probably the test 13:33
Release tagged. www.moarvm.org/releases/MoarVM-2017.09.tar.gz 13:39
nine Turns out, JITing an invoke is much harder than JITing a plain op... 13:41
MasterDuke hm, i'm getting rather varying results from `perf record -g --call-graph dwarf /home/dan/Source/perl6/install/bin/moar --libpath="blib" --libpath="/home/dan/Source/perl6/install/share/nqp/lib" --libpath="/home/dan/Source/perl6/install/share/nqp/lib" perl6.moarvm --nqp-lib=blib --setting=NULL --ll-exception --optimize=3 --target=parse --stagestats --output=CORE.setting.moarvm gen/moar/CORE.setting && perf report --call-graph=none 13:45
i.e., running it repeatedly shows different functions in the top 20 13:47
nine: just curious, do you expect a noticeable performance difference once you get all the JITing done? 13:51
nine Actually...not that much :/
timotimo not? :( 13:52
nine A couple percent. But... performing native calls will at least no longer be this opaque piece of C code. Instead it's speshable and JITable ops, thus we can profit from inlining and JITing larger parts. 13:53
Also even-moar-jit will be able to help with the generated code.
Though i have to admit, that I'm suprised that it doesn't help more by itself, considering that dyncall needs memory allocations on every call. 13:54
13:55 Zoffix joined
dogbert2 jnthn, ok, running MoarVM 2017.09 through ASAN atm 13:59
13:59 robertle joined
dogbert2 ASAN is happy with 'make spectest' on my 32 bit Linux VM 14:15
Skarsnik dang 14:16
it's a good and sad ^^ 14:17
14:19 AelxDnaiel joined
Geth MoarVM: f76ae338f8 | (Samantha McVey)++ | src/spesh/optimize.c
optimize_bb: assign on its own line for clarity

As @jnthn pointed out, it is confusing to easily see we are assigning
  `bb` unless we do it on its own line.		 14:32
14:35 Skarsnik_ joined 14:54 leont joined
AlexDaniel github.com/MoarVM/MoarVM/issues/693 15:18
^ please :) 15:19
oh 15:21
it's already there now?
wow that was quick 15:22
jnthn: please don't hate me :S
jnthn AlexDaniel: What have you done? :) 15:23
Set up Appveyor? :)
AlexDaniel jnthn: I said everything is fine, but there was no moar/nqp bump and I didn't notice that appveyor is failing with the latest moar 15:24
jnthn Failing how?
Some tests? To build?
AlexDaniel ci.appveyor.com/project/timo/moarv...ild/1.0.26
nmake syntax error
timotimo yeah, there's an ifneq in there that would have to become an !IF in nmake 15:25
jnthn :-(
AlexDaniel jnthn: :-( told ya 15:26
jnthn Please everyone stop trying to write clever make files. Do them tedious and boring.
And if you can't then write a darn Perl script and call it from the Makefile
timotimo something for the Makefile.in or for Configure.pl then
we need an nmakeable bot %)
jnthn I'll never, ever complain if you copy-paste in a Makefile.
Because it's worse than dealing with cleverness not being widely supported. 15:27
:/
samcv i added an ifneq i thought it was a makefile feature :\
AlexDaniel timotimo: frequent appveyor reports should do the trick, it's just that all these CI things are failing too often and nobody seems to care 15:28
samcv timotimo, so if ifneq is replaced verbatim with !IF then it works?
jnthn, any way to get appveyor autobuilding for moarvm as well? that would be nice
timotimo it also needs an != in the middle
and !ENDIF
samcv ok
will figure something out or remove
jnthn samcv: I dunno how to set that up, but yeah, we really should have it, and preferably have it report here like Travis does 15:29
samcv well you're an admin, i'm not
so i can't do it :(
jnthn Is there some instructions I can follow somewhere to set it up?
samcv i'll do it if i can temporarily get admin powers
hmm. no clue
jnthn OK, let's do that ;) 15:30
AlexDaniel somehow we have appveyor reporth already: github.com/MoarVM/MoarVM/commits/master
samcv ok :)
AlexDaniel but it's pointing at timo's fork
samcv AlexDaniel, someone must have run it manulaly
timotimo ah
it me
oh there's a "build schedule, crontab syntax"
if i remembered crontab syntax :)
AlexDaniel folks, I'm really sorry :-/ 15:31
jnthn samcv: You should now have owner privs; let me know if not 15:32
We should really scale out MoarVM releases beyond me also.
samcv sounds like a good idea :) 15:34
jnthn tbh the only step that needs some kind of solution is the upload one, and that really just means me asking somebody to give me a public key and doing some admin work :) 15:35
Or somebodies who want to help with release cutting :) 15:37
samcv i volunteer
jnthn Cool; I'll do what's needed to get it worked out in time for the next relesae. ;) 15:38
*:)
AlexDaniel \o/ 15:39
jnthn Anyway, if somebody gets a Makefile fix together, then I'll cut a point release afterwards 15:41
Will be away for a bit now; the dinner won't make itself. :) 15:42
15:51 domidumont joined 15:57 geekosaur joined
samcv ok i think i have basically solved it 15:59
@ifneq_start@"$(wildcard 3rdparty/libatomic_ops/src/Makefile)"@ifneq_middle@""@ifneq_end@ 16:22
did this so we can have it work on all platforms
we can also replace having @mknoisy@ being different for each platform 16:23
oh looks like some things don't support that. oh well. like solaris 16:38
geekosaur or msvc
samcv no msvc does have conditionals 16:39
just different syntax
geekosaur I bmeant $(wildcard) 16:48
samcv ah ok 16:51
geekosaur if you have $(...) and there is a space inside the parens, it's a gnu make extension. if there's a colon, it'd a bsd make extension.
I don't know if there's a quick rule for the (few) ms make extensions 16:52
Geth MoarVM: 0f59f0cff1 | (Samantha McVey)++ | build/Makefile.in
Revert "Fix errors when running `make realclean"

Did not work on all of our platforms, so reverting. This reverts commit 238896a50a595879a1e1d66b5bd39943678d73ac.		 16:56
17:09 robertle_ joined 17:16 robertle joined
AlexDaniel samcv: so that's it? 17:17
17:28 dogbert2 joined 17:29 robertle joined
jnthn So, ready for point release? 18:30
timotimo appveyor is testing still 18:39
one hour in and it's not yet finished the x64 build 18:40
maybe having verbose set on the spec tests in appveyor strains the browser to its limits ... 18:42
which is, of course, unrelated to appveyor taking a long-ass time 18:43
it's only doing one job at a time, too ;( 18:44
but since it reached far into the spec tests, i'm sure it'll be fine
especially since we're fixing a build problem here
AlexDaniel jnthn: ready 21:06
timotimo oh, point release? i didn't actually notice we got the first release 21:09
AlexDaniel timotimo: whoops, yeahā€¦ 21:14
timotimo: looking at moarvm release history you can kinda see when I started doing rakudo releasesā€¦ :S 21:15
timotimo no i mean jnthn said it's a point release now
AlexDaniel yeah
well, moar point release 21:16
.tell jnthn ready! 22:11
yoleaux AlexDaniel: I'll pass your message to jnthn.
AlexDaniel buggable: tags 22:12
buggable AlexDaniel, Total: 1685; BUG: 1080; UNTAGGED: 398; LTA: 180; NYI: 96; REGEX: 69; RFC: 61; TESTNEEDED: 55; JVM: 53; CONC: 50; REGRESSION: 38; UNI: 29; PERF: 28; SEGV: 26; @LARRY: 23; IO: 23; NATIVECALL: 23; POD: 21; TODO: 18; PRECOMP: 14; OO: 13; BUILD: 11; TESTCOMMITTED: 10; OPTIMIZER: 9; STAR: 7; PARSER: 6; BOOTSTRAP: 5; REPL: 5; GLR: 4; MATH: 4; OSX: 4; WINDOWS: 3; RT: 2; WEIRD: 2; BELL: 1; CONFIGURE: 1; DOCS: 1;
AlexDaniel buggable: tag MATH
buggable AlexDaniel, There are 4 tickets tagged with MATH; See fail.rakudo.party/t/MATH for details
AlexDaniel buggable: tag BELL
buggable AlexDaniel, There is 1 ticket tagged with BELL; See fail.rakudo.party/t/BELL for details
jnthn o/ 22:24
yoleaux 22:11Z <AlexDaniel> jnthn: ready!
jnthn OK, let me do this
Sorry it's later than expected
Geth MoarVM: d0e9e6d8a7 | (Jonathan Worthington)++ | VERSION
Bump VERSION
 22:26
MoarVM: ea35e146cd | (Jonathan Worthington)++ | docs/ChangeLog
ChangeLog entries for 2017.09.1
jnthn AlexDaniel: Tagged, tar.gz at www.moarvm.org/releases/MoarVM-2017.09.1.tar.gz 22:30
AlexDaniel yay
jnthn Goodness, where does the weekend go... 22:31
AlexDaniel jnthn: thanks 22:34
jnthn++
jnthn I finally managed to knock a little bit off my blog posts backlog also: 6guts.wordpress.com/2017/09/17/moa...2-planning 22:40
cognominal jnthn++ 22:47
jnthn goes to rest up so he might be able to do something useful tomorrow :) 22:49
o/
timotimo gnite jnthn :) 22:57
good blog, jnthn++ 23:12

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!