github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:00 lizmat joined 01:02 lizmat left 05:08 scovit left 06:43 domidumont joined 07:26 scovit joined 08:28 lizmat joined 08:55 lizmat left, lizmat_ joined 09:40 domidumont left 10:05 lizmat_ is now known as lizmat 10:41 domidumont joined
MasterDuke timotimo: what i just tried and some output gist.github.com/MasterDuke17/4bd90...b2e6172262 11:30
dogbert17 MasterDuke: I just made an update to github.com/MoarVM/MoarVM/issues/1093 11:56
MasterDuke huh 11:57
dogbert17: same with jit disabled? 11:58
dogbert17 let me check
valgrind still complains but the output is a bit different 12:01
MasterDuke and if spesh is disabled? 12:02
dogbert17 then it looks exactly like the gist
MasterDuke interesting 12:03
dogbert17 it has something to do with this line: whenever signal(SIGTERM).merge: signal(SIGINT) {
MasterDuke good catch, i hadn't realized there was any problem with that part 12:04
dogbert17 perhaps a few errors like that will lead to the SEGV you reported 12:07
I get the impression that the signal handling block is never executed 12:11
MasterDuke i think i have seen those "signal received" prints, but am not 100% sure 12:13
dogbert17 "signal received" is mysteriously absent in the gist I posted 12:14
MasterDuke maybe it occasionally works 12:15
dogbert17 yes, guess I have to run it several times. I am a bit confused even though I have watched jnthn's talk from the GPW 12:17
I mean, when we come to the 'whenever Promise.in(20) {' line and kill the process, which whenever will be run next? It's not obvious to me. 12:18
looking at the gist it seem to be the block surrounded by 'whenever $proc.start' 12:21
MasterDuke i don't perfectly understand it either, i just cribbed the code from the example in the docs 12:22
dogbert17 perhaps we need jnthn's wisdom 12:23
15:33 zakharyas joined 15:47 sena_kun joined, patrickb joined
timotimo MasterDuke: oh, interesting, it's probably necessary to also tell valgrind how our nursery allocations work 16:24
i.e. how individual objects get to exist, rather than just the whole nursery space
because "Address 0x597e378 is 1,307,448 bytes inside a block of size 4,194,304 alloc'd" is barely helpful 16:25
16:31 patrickb left 16:49 lizmat left 17:25 zakharyas left 17:50 sena_kun left 17:53 Voldenet left
MasterDuke timotimo: yeah, but is the other one useful? and, how do we tell valgrind about the nursery allocations? 17:58
17:59 Voldenet joined, Voldenet left, Voldenet joined
timotimo i think the second one is just the register that has the pointer in it because it's on the call stack 18:01
MasterDuke ah. so we need to teach valgrind about the nursery to get anything useful? 18:02
how does one do that? 18:05
timotimo one example would be VALGRIND_CREATE_BLOCK (and also VALGRIND_DISCARD when we have cleared the nursery) 18:07
otherwise, deal with it via VALGRIND_*_MEMPOOL client requests 18:08
valgrind.org/docs/manual/mc-manual....clientreqs - it's slightly explained here 18:11
MasterDuke hmm, looks not entirely trivial, i will probably have to punt 18:14
timotimo i think CREATE_BLOCK is a lot simpler and might be the right one for our purpose 18:15
if we want to be extra much, we can even annotate individual parts inside of structs
it'll make allocating stuff a bit slower, of course, which isn't fun 18:16
also, it'll surely be "fun" to try to get the client request stuff into the jit 18:19
MasterDuke i presume it's not as simple as sticking a CREATE_BLOCK in MVM_malloc? 18:21
timotimo MVM_malloc is already understood by valgrind
the thing is that the nursery allocation works by grabbing one gigantic chunk of memory, and just giving pieces of memory whenever someone asks
or do you mean the jit part? 18:23
MasterDuke nursery part, i'm fine with ignoring the jit for now
timotimo ah
nursery allocation is equivalent to "result = nursery_alloc; nursery_alloc += size; return result" 18:24
though the STable pointer and the owning thread ID has to be set
and many reprs do some initial setup
MasterDuke looks like tc->nursery_alloc is mentioned in a couple places. all of them will need a CREATE_BLOCK? 18:27
timotimo the ones that flip old and new nursery around in the GC will want to remove the previously created blocks in there, hopefully we can do it with just one big call 18:28
MasterDuke so a CREATE_BLOCK somewhere in here github.com/MoarVM/MoarVM/blob/mast...#L316-L329 ? 18:41
timotimo that's one place, yeah
MasterDuke and here github.com/MoarVM/MoarVM/blob/mast...gen2.c#L60 ? 18:43
timotimo yeah 18:52
did you already put it in MVM_gc_nursery_allocate or whatever it's called?
MasterDuke MVM_gc_allocate_nursery? 18:54
timotimo ah, yes
that must be the one
MasterDuke i haven't actually added anything anywhere yet. still trying to figure out exactly what goes where 18:55
timotimo ah 18:57
right
we'll also want to come up with something cool to put as the blocks names
MasterDuke timotimo: gist.github.com/MasterDuke17/76864...3ad1be78c4 19:03
"Address 0x597ced8 is 40 bytes inside a MVM_gc_allocate_nursery of size 56 client-defined" looks like something worked(ish) 19:06
timotimo that looks like a good first step, yeah
if we put #ifdef for valgrind support around the allocate nursery thing, we can afford to put a bit more work into the names that show up 19:07
(then we can allow ourselves to sprintf some details)
MasterDuke what would make sense to put in the names? 19:08
timotimo oh, dang, MVM_gc_allocate_nursery only has the size
so maybe MVM_gc_allocate_object has to do that
since it should have the STable, which has, for example, the debug name
MasterDuke instead of in *_nursery? or in addition to? 19:10
timotimo i'd say instead of 19:11
i have no idea if valgrind copies away the character string you give it, i.e. if we can/should put it on the stack or free it after building it 19:13
i think it should be fine to construct it on the stack
MasterDuke i just gave it st->debug_name
timotimo just like we did with the monitor command for "who points at"
oh
that could even be enough, yeah
MasterDuke man, i should check if i'm currently running with --optimize=0 or if adding that CREATE_BLOCK is what's making this run even slower than usual 19:15
timotimo well, valgrind makes it super super slow already 19:19
MasterDuke yeah, but it's even slower than it usually is under valgrind 19:20
it's been sitting for a couple min now and hasn't even ok'ed the first test
timotimo damn
the only create block part you've currently got was the one for gc_nursery_alloc? 19:21
gc_allocate_nursery*
MasterDuke now only in MVM_gc_allocate_object
timotimo right
well, i imagine that'd be called a whole, whole lot
MasterDuke ok, test 4! 19:23
"Address 0x59810f8 is 8 bytes inside a BOOTCode of size 72 client-defined" 19:26
gist updated 19:28
timotimo isn't that hella sweet? 19:39
MasterDuke useful?
timotimo no idea
do you think we should split it into header and body of the object in question?
we definitely get a "proper" traceback now 19:40
however
when an object gets moved, for example from nursery to nursery or from nursery to gen2, i think it will lose the backtrace :o
now that i read a bit more, i see that you get an integer back from VALGRIND_CREATE_BLOCK that it expects you to call VALGRIND_DISCARD with at some point 19:41
so maybe we're leaking loads of these blocks all over the place
perhaps this makes things slower?
maybe i'll go ask in #valgrind-dev 19:45
MasterDuke would it go in MVM_6model_stable_gc_free?
i'm gonna be afk for a while, but i'll backlog later
timotimo that'll only be called in the case of an stable getting freed, because that is handled a bit more specially 19:46
MasterDuke doh, i knew that, dumb question 20:18
one of the MVM_gc_collect_free_* ? 20:20
or the gc_free for MVMCode? 20:21
timotimo "uncopied" something something 20:22
i'm pretty tired :\ 20:28
20:46 domidumont left 22:54 lucasb joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!