github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
02:00 timotimo left 02:08 timotimo joined, p6bannerbot sets mode: +v timotimo, lizmat left
AlexDaniel dogbert11: maybe you should try reproducing this: github.com/rakudo/rakudo/issues/2576 02:50
my gut feeling tells me it's not just on mips
03:04 lizmat joined, p6bannerbot sets mode: +v lizmat 03:44 squashable6 left 03:48 squashable6 joined 03:49 p6bannerbot sets mode: +v squashable6 06:01 robertle left 07:03 domidumont joined, p6bannerbot sets mode: +v domidumont
Geth MoarVM: 2bc5ce7b84 | (Stefan Seifert)++ | src/6model/reprs/CStruct.c
Fix segfaults related to corrupted CStruct STables

The fix is basically a port of commit 6733e927ceb1aeff0daf23a58c43730cb2c38d77 from CUnion to CStruct. It fixes composed CStruct STables showing up with a NULL REPR_data pointer and garbage in sc_forward_u caused by an unfortunately timed GC run. Fixes GH #2564 (segfault in t/04-nativecall/06-struct.t)		 07:43
08:02 robertle joined 08:03 p6bannerbot sets mode: +v robertle
Geth MoarVM: c001ce23ca | (Timo Paulssen)++ | src/math/bigintops.c
fix declaration after code (thanks @dod38fr)
 09:34
10:07 zakharyas joined 10:08 p6bannerbot sets mode: +v zakharyas 10:38 brrt joined 10:39 p6bannerbot sets mode: +v brrt 11:06 domidumont left 11:34 brrt left, brrt joined 11:35 p6bannerbot sets mode: +v brrt 11:59 brrt left 12:02 robertle left 12:04 robertle joined 12:05 p6bannerbot sets mode: +v robertle 12:38 robertle left 12:45 dogbert2_ joined, p6bannerbot sets mode: +v dogbert2_ 12:46 domidumont joined 12:47 p6bannerbot sets mode: +v domidumont 13:12 robertle joined, p6bannerbot sets mode: +v robertle 13:34 brrt joined 13:35 p6bannerbot sets mode: +v brrt 13:41 brrt left 14:05 zakharyas left 15:11 brrt joined, p6bannerbot sets mode: +v brrt 15:38 brrt` joined 15:39 p6bannerbot sets mode: +v brrt`, brrt left 15:40 lizmat left 16:29 domidumont left 16:30 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 16:31 brrt` left, robertle left
MasterDuke timotimo: huh, looks like you can't use %p in profile filenames to get the pid in there, only in the MVM_*_LOGs 17:00
timotimo i should probably implement that! 17:03
MasterDuke that would be nice 17:04
timotimo if you could somehow target a very specific invocation to have profiling enabled ... 17:07
also, ATM you can't have "give me sql, but randomly generated filename", which the %p thing would fix
MasterDuke yep 17:08
nine I don't get this. I have a branch for Inline::Perl5 that removes some no longer used arguments which gets some functions below speshs arguments limit. The profiler shows much better numbers for this branch but the actual run time is some 15 % higher. 17:12
MasterDuke nine: does MVM_SPESH_BLOCKING make a difference? 17:17
nine MasterDuke: none that I can see 17:20
MasterDuke how are you measuring? with something like 'now - INIT now' or with /usr/bin/time? maybe compilation is taking longer? 17:27
nine /usr/bin/time
MasterDuke --stagestats show anything interesting? 17:28
nine Startup overhead is virtually identical (measured by using only 1 CSV row as data)
MasterDuke weird indeed 17:29
nine Btw. what's the reason why a speshresolve can remain in speshed code?
MasterDuke perf record? 17:30
heh...i've been trying to track down the answer to that exact question for at least a week now
nine gotten any closer? Is that an intended situation or is something wrong? 17:31
MasterDuke nine: i the case i've been looking at, github.com/MoarVM/MoarVM/blob/mast...ze.c#L2126 is relevant
*in the
but that's where my understanding ends. i was chatting with timotimo about it some, you and him taking would probably make more progress than i have/would 17:32
17:34 domidumont joined
MasterDuke fwiw, it's from this Str.index multi github.com/rakudo/rakudo/blob/mast...r.pm6#L272 17:35
17:35 p6bannerbot sets mode: +v domidumont 17:36 lizmat joined, p6bannerbot sets mode: +v lizmat
nine MasterDuke: same line is hit in my case 17:39
MasterDuke: your case also on a decontrv? 17:40
MasterDuke nine: don't remember 17:44
this is the code i'm testing with: 'my $a; $a = $_.Str.index("0", 0) for 1 .. 2_000_000; say $a' 17:45
18:19 robertle joined, p6bannerbot sets mode: +v robertle 18:48 [Coke] left, [Coke] joined, [Coke] left, [Coke] joined, p6bannerbot sets mode: +v [Coke] 18:49 p6bannerbot sets mode: +v [Coke]
nine MasterDuke: I firmly believe that that return there is just wrong. I've replaced it and everything seems to still work and I see performance improvements in csv-ip5xs.pl 20:11
dogbert11 this can't be good: MoarVM panic: Tried to garbage-collect a locked mutex 20:13
nine jnthn: does this patch make sense? gist.github.com/niner/7f146f55c52d...bf16867711 20:17
20:24 domidumont left
nine Another real conundrum: in my supposedly faster branch enabling the profiler speeds things up from ~24 to ~21s! 20:24
lizmat how is that a conundrum ? :-) 20:25
timotimo the profiler is supposed to not make things go faster %)
lizmat aaaahhh... ok
20:25 AlexDaniel left
lizmat well, the solution is easy then: always run with the profiler :-) 20:26
20:26 AlexDaniel joined, p6bannerbot sets mode: +v AlexDaniel
nine Btw. the profiles do show sensible numbers. 28s for the unoptimized version vs. 20s for the optimized one. It's just the real wall clock times that make no sense. 20:26
lizmat how about CPU usage ? 20:27
nine Pretty much the same. It's just ~200-300ms of spesh time
timotimo could be slower to compile i guess? 20:28
nine All numbers are better in the optimized branch. Less runtime according to the profiler, millions of frames saved, much less GC, 2/3 of deopts (~2 million!) gone, 99.97 % JIT instead of 97.54 %, > 10 million fewer allocates. 20:30
But wall clock time is slower
timotimo: I checked. Their compile time is virtually identical
timotimo millions of lines saved sounds like perhaps a lot less profiler overhead 20:32
20:36 zakharyas joined, p6bannerbot sets mode: +v zakharyas
nine timotimo: btw. what do you think about this? gist.github.com/niner/7f146f55c52d...bf16867711 20:36
timotimo i'm not entirely sure what that entails 20:37
dogbert11 here's a gist of what gdb could uncover wrt the failure in t/spec/integration/eval-and-threads.t, gist.github.com/dogbert17/8d0ed184...7b8949c545 20:41
20:42 MasterDuke left
timotimo shall i hack a totally bad patch that records when a mutex was last successfully locked? 20:44
nine timotimo: go for it! 20:45
dogbert11 if it could help us pinpoint the problem why not :) 20:46
20:46 zakharyas left
timotimo .o( pingpoint ) 20:51
AlexDaniel dogbert11: I think there was an issue that you had to file? :) 20:57
dogbert11: we're running out of blockers :)
dogbert11 AlexDaniel: if we disregard the problem above we have the t/spec/S04-exceptions/fail.t problem 21:07
releasable: next 21:08
releasable6 dogbert11, Next release in ā‰ˆ21 hours. 3 blockers. 112 out of 238 commits logged (āš  41 warnings)
dogbert11, Details: gist.github.com/cd1a6f4147484b45ad...2f934101fc
timotimo my silly patch is ... pretty explosive 21:09
if you're okay with a moarvm that leaks memory like a ripped sieve, you can have it, though 21:11
huh. it seems to work now? 21:13
maybe recompiling rakudo was the magic ingredient ...
OH COME ON :( 21:14
Failed to open file /home/timo/perl6/install/share/perl6/vendor/version: No space left on device
oh, silly me 21:15
of course now it doesn't reproduce any more :| 21:17
dogbert11 AlexDaniel: R#2623 21:18
hmm, an explosive patch 21:20
Geth MoarVM/pinpoint_garbage-collected_locked_mutex: 409fef09bd | (Timo Paulssen)++ | 4 files
dump a trace when mutex gets GC'd while locked

more precisely, the backtrace is taken when the lock gets acquired (and cleared when it gets unlocked)		 21:23
timotimo i couldn't get it to reproduce any more with this applied
but if it does crash it could maybe give an interesting piece of info
dogbert11 so I switch to this branch and rerun ? 21:24
timotimo switch or cherry-pick or whatever 21:25
dogbert11 let's see if it happens again ... 21:26
baaam 21:28
timotimo oh?
dogbert11 should I run MVM_dump_backtrace now?
timotimo that's sheepish
no, it's supposed to output the backtrace by itself
dogbert11 aha, the I should continue in gdb I guess
*then 21:29
timotimo depends on where your breakpoint lives?
you can just as well "print rm->body.backtrace"
dogbert11 in MVM_panic
timotimo then it should already have outputted it
dogbert11 no, the backtrace is here in fron of my blind eyes, sec
timotimo haha
well, anyway, that backtrace tells you where the lock was last locked successfully 21:30
sadly, the backtrace from where the panic happens doesn't correspond to anything
dogbert11 gist.github.com/dogbert17/8d0ed184...7b8949c545 21:31
check the comment
timotimo i see it
hm, is that the buffertocu that locks the lock? 21:32
dogbert11 buffertocu? 21:33
timotimo nqp::buffertocu
dogbert11 ah
timotimo is the only line in assemble_and_load 21:34
well, i suppose we might also need a gdb-level backtrace?! 21:35
dogbert11 wasn't nine working on this recently?
timotimo yeah, but not sure if he touched that C part of the code specifically 21:36
dogbert11 perhaps I'm jumping to incorrect conclusions
timotimo i can't find the actual corresponding lock call :) 21:37
could perhaps be MVM_bytecode_finish_frame 21:40
dogbert11 there's mutex stuff happening there 21:41
timotimo so yeah anyway some mutex is locked and then whatever's being done ends in not unlocking the mutex and the reference disappears 22:00
that's probably what happens
dogbert11 trying to repro again but so far nothing 22:01
timotimo damn it :|
dogbert11 I just wanted to see if I get the same stacktrace 22:02
timotimo OK
dogbert11 I'm running it in the background so perhaps it will trigger again 22:03
timotimo best of luck! 22:04
dogbert11 in the meantime, libuv 1.25.0 is out. github.com/libuv/libuv/blob/v1.x/ChangeLog 22:07
22:09 synopsebot joined
dogbert11 and the bug triggered again, the first line is still 'gen/moar/stage2/QAST.nqp:7325 (/home/dogbert/repos/rakudo/install/share/nqp/lib/QAST.moarvm:assemble_and_load)' 22:10
22:10 p6bannerbot sets mode: +v synopsebot
AlexDaniel R#2623 22:10
synopsebot R#2623 [open]: github.com/rakudo/rakudo/issues/2623 Intermittent failure when running t/spec/S04-exceptions/fail.t
timotimo it's not completely unlikely that reducing the nursery size will trigger it more often 22:11
22:11 Kaiepi left
dogbert11 and suddenly the number of blockers have risen to 4 22:11
AlexDaniel hahaha
dogbert11: no strong opinion on that one, but this kind of issues causes all sorts of troubles in the end 22:12
22:12 Kaiepi joined
AlexDaniel e.g. failures in buildd 22:12
I think robertle++ changed the way the package is built
so that it doesn't use spesh on mips, I think? I'm not sure
22:12 p6bannerbot sets mode: +v Kaiepi
AlexDaniel but sweeping under the rug is not a great strategy for the long run 22:13
dogbert11 how true
I might have to report this mutex problem as well 22:14
AlexDaniel I've been running t/06-telemetry/01-basic.t in a loop for like half a day
and no failure so far
dogbert11 I couldn't reproduce that one either 22:15
AlexDaniel btw nine++ jnthn++ lizmat++ # working on blockers 22:17
our heroes :)
dogbert11 indeed
jnthn nine: Yes, I believe it does; nice find 22:56
23:40 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke
MasterDuke nine++ that makes my test case much better. i tried some random changes, but had no idea what i was doing and none of mine made anything better 23:44

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!