github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:04 murman left, murman joined 00:05 murman left 00:09 murman joined 00:22 leont left 00:29 squashable6 left 00:31 squashable6 joined, murman left 00:37 murman joined 00:43 mst left 00:44 mst joined, ChanServ sets mode: +o mst 00:51 murman left 00:55 sena_kun joined 00:56 bisectable6 left, bisectable6 joined 00:57 Altai-man_ left 01:02 unicodable6 left, bloatable6 left, quotable6 left, squashable6 left, committable6 left, sourceable6 left, bisectable6 left, reportable6 left, shareable6 left, benchable6 left, releasable6 left, coverable6 left, nativecallable6 left, linkable6 left, greppable6 left, statisfiable6 left, notable6 left, tellable6 left, evalable6 left 01:03 greppable6 joined, releasable6 joined, notable6 joined, coverable6 joined, committable6 joined 01:04 linkable6 joined, squashable6 joined, quotable6 joined, unicodable6 joined, reportable6 joined, bloatable6 joined, nativecallable6 joined, tellable6 joined 01:05 evalable6 joined, bisectable6 joined, shareable6 joined, statisfiable6 joined 01:06 sourceable6 joined 02:54 Altai-man_ joined 02:57 sena_kun left 04:48 MasterDuke left 04:55 sena_kun joined 04:56 Altai-man_ left 06:54 Altai-man_ joined 06:57 sena_kun left 07:41 zakharyas joined 08:34 leont joined 08:55 sena_kun joined 08:57 Altai-man_ left
jnthn morning o/ 09:36
nwc10 \o 09:37
jnthn So, how did ASAN feel about you last commit yesterday? :) 09:38
nwc10 my last commit? 09:39
jnthn oops
*my last
:)
The office coffee apparently works better... 09:40
(At home today)
nwc10 IIRC there's been no ASAN excitement for at least a day. It doesn't find SEGVs very exciting 09:43
and yesterday seems like a very long time away
fighting with NOTwok^Hrk lumpy 09:44
and $ork thing that hates me
even osh has given up
jnthn What fun... 09:45
Guess I should try and take on flattening dispatches, given I've managed to put them off so far...
nwc10 well, given up on the predict-your-typing 09:49
jnthn Ouch, that failing test in the nqp repo is a real bug, not just a wrong test... 10:04
nwc10 jnthn: if I hack some stuff locally and it gets past all the tests, but when I try to make install I see: 10:07
MoarVM panic: Internal error: zeroed target thread ID in work pass
where might I even start to look?
it's not like ASAN has anything to offer... 10:09
jnthn Try to make install what? 10:10
nwc10 well, rakudo was one 10:11
jnthn NQP or Rakudo?
nwc10 IIRC yes
I should go back and retrace all my steps
given that I've just got a SEGV on a previous commit 10:12
what I *wanted* to do was MoarVM, nqp, rakudo, zef, App::MoarVM::HeapAnalyzer
this of course works when I don't mess with things locally :-) 10:13
I should go back to $work and fighting images and Pg dump formats
and missing shared objects on a production host
and all the other little things that hate me today
oh, ansible. I'm sure it loves me 10:14
Geth MoarVM/new-disp: 2cb845fd5c | (Jonathan Worthington)++ | src/disp/program.c
Fix mis-compile of dispatch program

We used the program value index instead of the argument index when emitting a load from the initial capture; often they did match up, especially when guarding, and situations where they did not were only likely to come about when we were constructing a new argument list.		 10:27
jnthn That's test 20 10:32
Very silly
Though I'm glad it was silly mistake than flawed algorithm design :) 10:33
10:54 Altai-man_ joined 10:57 sena_kun left
nwc10 All tests successful. 10:58
jnthn yay 11:07
Geth MoarVM/new-disp: e6c469e04a | (Jonathan Worthington)++ | 2 files
Stub out flattening callstack frame

When we flatten today, we have to malloc and possibly realloc two regions of memory: one for the callsite flags, and another for the args themselves. In principle, if we want to do arg names in the new way, we'd need a third such buffer too.
... (7 more lines)		 11:29
12:02 zakharyas left
nwc10 still All tests successful. 12:16
12:31 MasterDuke joined 12:55 sena_kun joined 12:57 Altai-man_ left 12:59 zakharyas joined
Geth MoarVM/new-disp: 09d1149ff4 | (Jonathan Worthington)++ | src/disp/program.c
Prepare dispatch program running for flattening
 14:37
MoarVM/new-disp: 1b0841c8f2 | (Jonathan Worthington)++ | 7 files
Minimal integration of flattening with dispatch

This fills out most of the flattening algorithm, however it currently misses de-dupe of named arguments (that is, making sure the final one wins). It also only works on the first use of the callsite, since the monomorphic flattening handler is not yet implemented, let alone the polymorphic one. However, it's enough to successfully do a dispatch that starts out with flattening arguments.
nwc10 jnthn: so yes, local changes, and after a lot of loops I see:
MoarVM panic: Internal error: invalid thread ID 803208664 in GC work pass
nothing from ASAN or valgrind 14:38
could this happen if I push a garbage pointer as a GC permanent root?
jnthn Yes, or add a garbage pointer to a worklist
nwc10 mmm, both are possible :-(
jnthn Where garbage includes "into a GC managed area but the object was already eaten"
Well, but... 14:39
#if MVM_GC_DEBUG
#define MVM_gc_worklist_add(tc, worklist, item) \
Worklist addition is defined differently in debug mode, and:
if ((*item_to_add)->owner > tc->instance->next_user_thread_id) \
MVM_panic(1, "Invalid owner in item added to GC worklist"); \
I think that would trigger it
nwc10 ooho, I wasn't aware that I could also turn that on 14:40
jnthn So assuming you turned on GC debugging, I'd expect it to be caught a bit earlier
nwc10 more pain!
jnthn There's actaully 3 levels of pain, I suggest starting from the lowest
You could in theory make a debugging version of adding a perm root that also does such checks 14:42
Though I think you'll probably be able to make it panic on worklist add, look at the stack trace, and see if it's in the place we add perm roots
language class, bbiab 14:52
14:54 Altai-man_ joined 14:57 sena_kun left
nwc10 jnthn: All tests successful. 15:08
MasterDuke i ran ugexe's example from github.com/rakudo/rakudo/issues/3740 under perf, killing it after 20s or so. 49% of the time is in MVM_gc_root_add_frame_registers_to_worklist, 32% of the time is in MVM_gc_root_add_frame_roots_to_worklist
so it's creating tons and tons of objects for the gc to manage, but never cleaning them up? 15:09
nwc10 OK, and now: 15:10
MoarVM panic: Must not GC when in the specializer/JIT
timotimo what are we talking about right now? 15:52
nwc10 timotimo: strange failures in my local branch 16:06
which likely are caused by something I didn't get right
jnthn MasterDuke: More significantly, lots of closures 16:09
Oh, though registers is odd
We shouldn't really have those in a closure
Hm
nwc10 timotimo: at least, that's what I'm prattling on about
timotimo there was a recent commit that fixed a problem where spesh could accidentally go into jit 16:11
er
gc
is your branch rebased on master recently?
nwc10 oooh, thanks, yes, no
but it will conflict with master (or at least, "this week's" master) 16:12
so it might be easier for me to start a new branch and cherry-pick one by one to deal with that conflict
timotimo ah 16:14
it was just the removal of two lines that was necessary
there were mark_thread_blocked / unblocked in spesh's optimize.c i think 16:15
nwc10 I need to do the reworkng to get things clean atop master
so it seems better to bite the bullet and do that now
although actually, first I should eat
timotimo this is the branch that uses the array instead of the hash for lexical names? 16:24
MasterDuke timotimo, nwc10: and removing the write of the facts.value 16:39
for the curious and easily nerd-sniped, the code i ran is: `my $proc = Proc::Async.new: "perl", "-E", q|while(1) { say "y" x 100 }|; react { whenever $proc.stdout.lines { say "stdout: $_"; }; whenever $proc.stderr.lines { say "stderr: $_"; }; whenever $proc.start { say "Exit code: {.exitcode}"; done; } }` 16:42
nwc10 timotimo: no, jnthn merged that 16:45
timotimo oh, ok cool
that's the code that sometimes stands still? 16:46
all i see when i run it is that it grows in memory very fast, and then i have the choice of letting my system go unresponsive or i ctrl-c it 16:47
MasterDuke yep
timotimo i did a "perf trace" of it and that shows mostly writes from perl and reads and mprotect from perl6 %) 16:48
16:55 sena_kun joined 16:56 Altai-man_ left
MasterDuke something easy to optimize? 17:18
timotimo i don't think it was very enlightening on itself; i think we're currently just allowing perl to output as fast as it wants, and we allocate buffers to store all the results while working on the items at the front of the queue a little slower 17:22
i didn't get to reproduce the "it just stands still twiddling its thumbs intensely" situation yet 17:23
17:35 zakharyas left 18:01 leont left 18:08 leont joined
MasterDuke hm. re what jnthn mentioned, how can i tell if closures are in fact being created? or if not, what are? 18:50
18:54 Altai-man_ joined 18:57 sena_kun left 19:29 zakharyas joined
MasterDuke gist.github.com/MasterDuke17/df204...218ece6c72 is a segv i've never seen before 20:26
why would there be ~100k calls to Proc::Async's TWEAK, but only ~720 calls to it's new? 20:35
20:50 zakharyas left
MasterDuke another weird segv added to the gist 20:50
with some more debug info 20:55
20:55 sena_kun joined 20:57 Altai-man_ left 21:52 Altai-man_ joined 21:54 sena_kun left 22:03 notable6 left, notable6_ joined, statisfiable6 left 22:04 statisfiable6 joined, AlexDaniel` left 22:06 committable6 left, committable6 joined 22:12 AlexDaniel` joined 22:30 AlexDaniel` left 22:33 nativecallable6 left, coverable6 left, jjatria left, committable6 left, nebuchadnezzar left, colomon_ left, nine left, [Coke] left, MasterDuke left, Altai-man_ left, sivoais left, Geth left, krunen left, gugod left, japhb left, nwc10 left, SmokeMachine left, Util left, elcaro left, klapperl_ left, moritz left, shareable6 left, bisectable6 left, evalable6 left, releasable6 left, greppable6 left, BinGOs left, mtj_ left, vrurg left, dogbert17 left, Kaiepi left, AlexDaniel left, vesper11 left, statisfiable6 left, notable6_ left, eater left, mst left, tbrowder left, lizmat left, raku-bridge left, ChanServ left, Altreus left, moon-child left, synthmeat left, jnthn left, leont left, sourceable6 left, tellable6 left, bloatable6 left, reportable6 left, unicodable6 left, quotable6 left, squashable6 left, linkable6 left, leedo left, TimToady left, Voldenet left, kawaii left, robertle left, xiaomiao left, rypervenche left, chansen_ left, hoelzro left, rba left, jpf1 left, camelia left, harrow left, avar left 22:36 [Coke] joined, ChanServ joined, nebuchadnezzar joined, colomon_ joined, nine joined, cherryh.freenode.net sets mode: +o ChanServ 22:37 Altai-man_ joined, sivoais joined, Geth joined, krunen joined, gugod joined, japhb joined, statisfiable6 joined, notable6_ joined, eater joined, AlexDaniel joined, vesper11 joined, mst joined, cherryh.freenode.net sets mode: +o mst, rypervenche joined, chansen_ joined, hoelzro joined, rba joined, jpf1 joined 22:38 nwc10 joined, elcaro joined, SmokeMachine joined, Util joined, klapperl_ joined, moritz joined, nativecallable6 joined, coverable6 joined, jjatria joined, leont joined, sourceable6 joined, tellable6 joined, bloatable6 joined, reportable6 joined, unicodable6 joined, quotable6 joined, squashable6 joined, linkable6 joined, leedo joined, TimToady joined, Voldenet joined, robertle joined, xiaomiao joined, committable6 joined, vrurg joined, dogbert17 joined, Kaiepi joined, Altreus joined, moon-child joined, synthmeat joined, jnthn joined, MasterDuke joined, tbrowder joined, lizmat joined, raku-bridge joined 22:39 shareable6 joined, bisectable6 joined, evalable6 joined, releasable6 joined, greppable6 joined, BinGOs joined, mtj_ joined 22:40 kawaii joined 22:42 camelia joined, harrow joined, avar joined 22:46 sivoais left, sivoais joined 22:51 AlexDaniel` joined 22:55 sena_kun joined 22:57 Altai-man_ left 23:58 leont 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!