Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2016-03-24

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:27 vendethiel joined #moarvm
02:02 dalek MoarVM: ee2e258 | timotimo++ | src/6model/reprs/MVMMultiCache.c:
02:02 dalek MoarVM: MVMMultiCache gets an unmanaged_size
02:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ee2e2582d0
02:02 dalek MoarVM: e2b01a9 | timotimo++ | src/6model/reprs/MVMStaticFrame.c:
02:02 dalek MoarVM: the first ~half of MVMStaticFrame's unmanaged_size
02:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/e2b01a90be
02:02 dalek MoarVM: 6b90ccb | timotimo++ | src/6model/reprs/MVMCompUnit.c:
02:02 dalek MoarVM: measure unmanaged size for MVMCompUnit
02:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6b90ccba7f
02:02 dalek MoarVM: 9136a3e | timotimo++ | src/6model/reprs/SCRef.c:
02:02 dalek MoarVM: measure SCRef's unmanaged size (potentially incomplete)
02:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/9136a3ed3b
02:02 timotimo still missing: MVMHash and MultiDimArray
02:02 timotimo and there's a few XXX's here and there
02:05 timotimo but at least it's only ever underestimating, and it definitely gets us closer to the truth
02:06 timotimo oh, whoops, what a silly mistake i made in there
02:06 dalek MoarVM: ad01448 | timotimo++ | src/6model/reprs/MVMCompUnit.c:
02:06 dalek MoarVM: fix drastic copy-pasto in MVMCompUnit.c
02:06 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ad01448cb0
02:11 colomon joined #moarvm
02:15 dalek MoarVM: 9872121 | timotimo++ | src/6model/reprs/MVMCompUnit.c:
02:15 dalek MoarVM: some of these callsites are null, so skip those.
02:15 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/987212147a
02:21 timotimo "considering the snapshot ..." %)
02:21 timotimo i wsan't quick enough to close the window when it was taking the snapshots in the terminal
02:22 timotimo 5941561 142M -rw-r--r--. 1 timo timo 142M Mar 24 03:12 heap-snapshot-1458785563.50406
02:26 timotimo Total heap size:              4,179,359,695,703,278,305 bytes
02:26 timotimo m: say "4,179,359,695,703,278,305".split(",").join("").Int / 1024
02:26 camelia rakudo-moar 6732d2: OUTPUT«4081405952835232.719727␤»
02:26 timotimo m: say "4,179,359,695,703,278,305".split(",").join("").Int / (1024 * 1024)
02:26 camelia rakudo-moar 6732d2: OUTPUT«3985748000815.65695286␤»
02:26 timotimo ... ?!?
02:27 timotimo SCRef                                  4,179,359,695,653,307,760 bytes
02:27 timotimo that's probably where that error comes from %)
02:29 timotimo m: say "4,179,359,695,703,278,305".split(",").join("").Int / (1024 * 1024 * 1024)
02:29 camelia rakudo-moar 6732d2: OUTPUT«3892332032.04653999303␤»
02:29 timotimo m: say "4,179,359,695,703,278,305".split(",").join("").Int / (1024 * 1024 * 1024 * 1024)
02:29 camelia rakudo-moar 6732d2: OUTPUT«3801105.50004544921194␤»
02:30 timotimo so, like, a couple thousand terabytes?
02:30 timotimo m: say "4,179,359,695,703,278,305".split(",").join("").Int / (1024 * 1024 * 1024 * 1024 * 1024)
02:30 camelia rakudo-moar 6732d2: OUTPUT«3712.01708988813399603␤»
02:30 timotimo is that 3 exabytes?
02:33 geekosaur sounds more like total allocations, not active heap
02:33 synopsebot6 joined #moarvm
02:34 timotimo https://github.com/MoarVM/MoarVM/commit/9136a3ed3b9e1279bde7be65a18d22f504f879da  -  i wonder how i overestimate the size so drastically with this simple code?
02:38 timotimo SCRef size: 1 objects, 1 stables, size is -1358922752
02:38 timotimo ... errr .... ?!?!
02:38 timotimo am i casting the object wrongly?
02:39 timotimo that still doesn't make any sense
02:39 timotimo oops, wrong number of arguments to fprint :)
02:47 ilbot3 joined #moarvm
02:47 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
02:49 timotimo how does this go wrong? :o
03:01 timotimo somehow 144115737831669776 and 144116837343297552 seem to have ended up in the dump
03:07 timotimo those values actually are in the data
03:11 diakopter interesting
03:11 timotimo i don't quite get it
03:11 timotimo SCRef size: 1 objects, 1 stables, size is 16
03:11 diakopter 4,179,359,695,653,307,760 bytes 4,179,359,695,653,307,760 bytes
03:11 timotimo this object gave a humongous result: 144115737831669776; SCRef
03:12 diakopter that's a lot of bytes
03:12 timotimo that's inside the "unmanaged_size" function and then right outside it
03:12 timotimo so on the way out it gets misinterpreted
03:12 diakopter well there must be some uninitialized memory
03:12 mojca joined #moarvm
03:13 diakopter so one of the unmanaged_size routines is returning garbage sometimes
03:13 timotimo let me show you the code i'm looking at
03:13 timotimo https://github.com/MoarVM/MoarVM/blob/master/src/profiler/heapsnapshot.c#L304
03:14 timotimo here i dump the REPR of the thing that we call unmanaged_size on, and the result if it's above a certain threshold
03:15 timotimo https://github.com/MoarVM/MoarVM/blob/master/src/6model/reprs/SCRef.c#L137  -  here i fprintf the size before it gets returned
03:17 timotimo oh, well, i print it with %d
03:17 timotimo that's not the right one to use here
03:18 timotimo oh
03:18 timotimo PRId64 is actually for signed int, it seems like?
03:19 diakopter (don't know)
03:19 timotimo and PRIu64 seems to be for unsigned
03:19 timotimo which is what we have here
03:21 diakopter well in SCRef's initialize it needs to zero out the num_objects and num_stables
03:22 timotimo no, those values are fine
03:23 timotimo something's still off
03:24 timotimo anyway, PRIu64 is for unsigned values. we have those here, so putting that into the format strings is more correct.
03:24 timotimo SCRef size: 1 objects, 1 stables, size is 144115737831669776
03:24 timotimo this object gave a humongous result: 144115737831669776; SCRef
03:25 timotimo this is with the right format specifier, and it reads the exact same values that get multiplied with the sizeof those pointers
03:26 * timotimo needs to print those numbers with PRIu64, too
03:26 timotimo OK, you were right, those numbers are actually bogus
03:26 timotimo even though they looked harmless (but only because i printed them with %d)
03:26 timotimo so ... good catch! :)
03:27 timotimo i'm a bit surprised we don't allocate the SCRef object in a zeroed-out area
03:28 timotimo i put = 0 into the initialize function, but i still get those "interesting" results
03:29 timotimo heap me diakopter senpai; what's going on here? :\
03:30 geekosaur "a heap of trouble"
03:31 timotimo we have many places where SC indexes are MVMint64
03:32 timotimo like MVM_sc_get_object, which is, AFAIK, an API function
03:32 timotimo so ... ugh
03:34 timotimo i guess i'll open an issue about these numbers being not so right all over the place?
03:34 timotimo i mean, mixed signed and unsigned
03:36 timotimo https://github.com/MoarVM/MoarVM/issues/348
03:42 dalek MoarVM: ef856ae | timotimo++ | src/6model/reprs/SCRef.c:
03:42 dalek MoarVM: disable unmanaged size for SCRef untix #348 gets some attention
03:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ef856aeade
03:42 dalek MoarVM: ae196c6 | timotimo++ | src/profiler/heapsnapshot.c:
03:42 dalek MoarVM: use proper unsigned formatting codes in collectables_str
03:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ae196c65b4
03:42 dalek MoarVM: 543c727 | timotimo++ | src/profiler/heapsnapshot.c:
03:42 dalek MoarVM: use unsigned formatting codes in types_str, too
03:42 dalek MoarVM:
03:42 dalek MoarVM: though we are very unlikely to hit the point where that
03:42 dalek MoarVM: makes a difference
03:42 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/543c727270
03:57 vendethiel joined #moarvm
04:01 timotimo diakopter: do you think you can make moarop_mapper and add_core_moarop_mapping keep around less memory?
04:01 timotimo like, do you have time to do that this week or something?
04:21 dalek MoarVM/annotate_refs_reprapi: 43f5701 | timotimo++ | src/6model/ (44 files):
04:21 dalek MoarVM/annotate_refs_reprapi: give all REPRs a "describe_refs" function
04:21 dalek MoarVM/annotate_refs_reprapi: review: https://github.com/MoarVM/MoarVM/commit/43f570161e
05:14 vendethiel joined #moarvm
05:39 diakopter timotimo: dunno
05:39 diakopter also dunno if it's worth it
05:43 diakopter timotimo: ohh (looking at #348)
05:58 vendethiel joined #moarvm
06:21 vendethiel joined #moarvm
07:03 vendethiel joined #moarvm
07:09 mojca joined #moarvm
07:16 domidumont joined #moarvm
07:21 domidumont joined #moarvm
08:01 timotimo i'm having difficulty falling asleep :|
08:01 timotimo so i'm banging my head against the describe_ref functions
08:02 timotimo MVMArray seems okay, but i couldn't actually see it put any indices anywhere so far
08:02 timotimo P6opaque gives me segfaults
08:02 timotimo and SCRef is just totally b0rked
08:04 vendethiel joined #moarvm
08:07 dalek MoarVM/annotate_refs_reprapi: 9d355e7 | timotimo++ | src/6model/6model.h:
08:07 dalek MoarVM/annotate_refs_reprapi: describe_refs ought to be void.
08:07 dalek MoarVM/annotate_refs_reprapi: review: https://github.com/MoarVM/MoarVM/commit/9d355e777c
08:07 dalek MoarVM/annotate_refs_reprapi: 842eb4e | timotimo++ | src/6model/reprs/MVMCompUnit.c:
08:07 dalek MoarVM/annotate_refs_reprapi: describe refs of MVMCompUnit
08:07 dalek MoarVM/annotate_refs_reprapi: review: https://github.com/MoarVM/MoarVM/commit/842eb4ea8d
08:07 dalek MoarVM/annotate_refs_reprapi: 138f13e | timotimo++ | src/profiler/heapsnapshot.c:
08:07 dalek MoarVM/annotate_refs_reprapi: actually call describe_refs for things
08:07 dalek MoarVM/annotate_refs_reprapi: review: https://github.com/MoarVM/MoarVM/commit/138f13e587
08:07 dalek MoarVM/annotate_refs_reprapi: e91e879 | timotimo++ | src/6model/reprs/MVMArray.c:
08:07 dalek MoarVM/annotate_refs_reprapi: describe_refs in MVMArray
08:07 dalek MoarVM/annotate_refs_reprapi:
08:07 timotimo the b0rken parts are commented out, so compiling with this branch doesn't give you crashes.
08:10 timotimo well, one thing that's wrong is having alloc_objects and alloc_stables in SCRef
08:10 timotimo it should be num_*
08:12 timotimo $5 = {handle = pointer to '', description = <error reading variable: Cannot access memory at address 0x20>,
08:12 timotimo num_objects = 15762615875665921, alloc_objects = 6316048, root_objects = 0x38, root_stables = 0x0,
08:12 timotimo num_stables = 56, alloc_stables = 7601200, root_codes = 0x0, rep_indexes = 0x20000400000001, rep_scs = 0x606550,
08:13 timotimo owned_objects = 0xa6d540, sc = 0x0, hash_handle = {tbl = 0x38000400000001, hh_prev = 0x606010, hh_next = 0xa9,
08:13 timotimo key = 0x0, keylen = 169, hashv = 0}, sc_idx = 13310112, sr = 0x0, mutex = 0x20000400000001}
08:13 timotimo which of these fields is supposed to tell me "do not try to look into this object's things"?
08:14 FROGGS joined #moarvm
08:14 dalek MoarVM/annotate_refs_reprapi: 0953d68 | timotimo++ | src/6model/reprs/SCRef.c:
08:14 dalek MoarVM/annotate_refs_reprapi: improvement to SCRef's describe_refs
08:14 dalek MoarVM/annotate_refs_reprapi: review: https://github.com/MoarVM/MoarVM/commit/0953d685fb
08:15 timotimo oooooh
08:15 timotimo there's a level of indirection there that i hadn't noticed!
08:15 domidumont joined #moarvm
08:16 zakharyas joined #moarvm
08:17 dalek MoarVM/annotate_refs_reprapi: 2a873b0 | timotimo++ | src/6model/reprs/SCRef.c:
08:17 dalek MoarVM/annotate_refs_reprapi: finally noticed SCRef's body is one more pointer away!
08:17 dalek MoarVM/annotate_refs_reprapi:
08:17 dalek MoarVM/annotate_refs_reprapi: fixes SCRef's unmanaged_size as well as describe_refs
08:17 dalek MoarVM/annotate_refs_reprapi: review: https://github.com/MoarVM/MoarVM/commit/2a873b09ce
08:23 timotimo > find 100 objects type="SCRef"
08:23 timotimo fish: Job 2, “perl6 -Ilib bin/moar-ha ~/perl6…” terminated by signal SIGSEGV (Address boundary error)
08:23 timotimo *cough cough* :)
08:23 timotimo but probably because moar re-compiled in the background?
08:45 mojca joined #moarvm
08:48 timotimo https://gist.github.com/timo/1d9d45ae647a870799eb - not quite sure how exactly this is going wrong, but it's kinda neat to see at least
08:49 timotimo i'd like it to also output the index of the other objects if that's not too much
08:51 timotimo https://github.com/timo/p6-app-moarvm-heapanalyzer - fork'd
08:57 timotimo jnthn: even though having a collectable already in the seen hash isn't a problem for describe_refs, the refs that get described end up getting added another time on top of the already existing one, because add_reference doesn't check that yet
08:57 * timotimo tries to sleep again
09:51 timotimo why did i even try *sigh*
09:55 harrow joined #moarvm
10:03 * timotimo is implementing deduplication of references
10:03 jnthn timotimo: Why do we get duplicate references?
10:04 timotimo because first it gets added in gc_mark, then it gets added again in describe_refs
10:04 jnthn ...
10:04 jnthn Yes, you're mean tto call gc_mark *or* describe_refs!
10:04 jnthn Not both!
10:04 jnthn describe_refs if available, gc_mark as a fallback
10:04 timotimo oh, then describe_refs has to implement all of what gc_mark does
10:04 jnthn Yes.
10:05 timotimo then every one of them has to be perfect :|
10:05 jnthn Right :)
10:05 jnthn So add them where they're useful
10:05 jnthn And not where they ain't :)
10:05 timotimo the one for p6opaque is useful, but also b0rked
10:10 timotimo if you could look into my p6opaque describe_refs, that'd be nice :)
10:16 timotimo jnthn: is there anything bad about having "index" for multiple different things in the same object?
10:16 timotimo like, objects and stables in the SCRef
10:18 jnthn timotimo: Well, it won't complain if you do, it'll just be a bit confusing in the output, but tbh SCs reference so much it's going to be a lot of output if you try and ls one :)
10:19 timotimo fair enough
10:19 timotimo i put a "show" (basically ls) into the analyzer in my fork on github
10:19 jnthn Yeah, I saw
10:19 jnthn show is a nice name
10:20 timotimo it ought to show some more stuff, too
10:20 timotimo size, unmanaged size, stuff like that
10:21 jnthn yeah
10:22 jnthn And also only show some refs if there are a gazzilion
10:22 jnthn (And a number or refs up top)
10:22 jnthn We can show the refs on a single line in show too, I think
10:22 jnthn as in --[ ... ]--> foo
10:23 jnthn And yeah, include the collectable ID
10:23 jnthn as in --[ ... ]--> 1234 moarop_mapper (QAST.nqp:666) (Frame)
10:23 jnthn So then you can navigate :)
10:24 timotimo right
10:24 timotimo also, we may want a "next page" command for "find" and friends
10:24 jnthn Maybe show without an arg should default to show 0 - that is, the root :)
10:24 dalek MoarVM/annotate_refs_reprapi: 5765e61 | timotimo++ | src/ (4 files):
10:24 dalek MoarVM/annotate_refs_reprapi: describe_refs is supposed to be an alternative to gc_mark
10:24 dalek MoarVM/annotate_refs_reprapi:
10:24 dalek MoarVM/annotate_refs_reprapi: not an addition to it.
10:24 dalek MoarVM/annotate_refs_reprapi: review: https://github.com/MoarVM/MoarVM/commit/5765e616a0
10:26 timotimo what's the thing that makes startup so slow, btw?
10:26 timotimo we just don't read lines fast?
10:27 jnthn Yeah, and I think it's in MoarVM
10:27 jnthn Maybe something pathological about really long lines
10:27 timotimo OK, sounds good
10:27 timotimo maybe we only grow our line buffer linearly
10:27 timotimo instead of 2* it every time?
10:27 jnthn It's actually managed as a linked list, iirc
10:27 jnthn Until we assemble the string and then we know how many things we have
10:28 jnthn I suspect the code that looks for the separator
10:28 jnthn Need to do a C profile though
10:28 jnthn But got other job to work on today :)
10:30 timotimo it's going to be interesting to support describe_refs for p6opaque
10:30 timotimo as it has flattened STables in it
10:30 timotimo well, *can have*
10:31 jnthn :)
10:31 timotimo i can think of a few different ways to hack around that potential problem
10:31 timotimo we could remember what reference ID we were at when we started, then we can pass a "success" flag upwards from describe_refs
10:32 timotimo we could have an extra repr api function to do a check up-front, recursively, if we'd succeed or not
10:32 timotimo or the describe_refs function could also take a worklist and do gc_mark when it can't do describe_refs for children
10:33 timotimo that last one seems the least painful
10:33 jnthn OK, leave it for now, I'll have to think about it a bit :)
10:33 jnthn But I'm doing other things now.
10:33 timotimo on top of that, my implementation of p6opaque caused segfaults and i have no clue why :)
10:33 jnthn Note that unmanaged_size will also need to factor in flattened in stuff
10:34 jnthn (for P6opaque)
10:34 timotimo aye
10:35 harrow joined #moarvm
10:36 dalek MoarVM/annotate_refs_reprapi: d5de54b | timotimo++ | src/6model/reprs/P6opaque.c:
10:36 dalek MoarVM/annotate_refs_reprapi: restore a NULL that went missing
10:36 dalek MoarVM/annotate_refs_reprapi: review: https://github.com/MoarVM/MoarVM/commit/d5de54b229
10:37 timotimo yes, 66% in find_separator
10:37 jnthn aha :)
10:38 jnthn I have a vague memory I cheated in there somewhere
10:39 timotimo the hottest instruction in there is the jne from the if (sep_spec->sep_lengths[j] == 1) { ... }
10:40 jnthn :)
10:40 jnthn OK. I'll look into it
10:54 timotimo how do we feel about finding all incoming references to a given object?
10:56 jnthn Do we have a use case?
10:56 timotimo just navigation in general, nothing very important
10:57 jnthn I don't think it's worth it unless we need it
10:57 jnthn I think if we did it then a paths 1234 would do it
10:57 jnthn That is, list all paths
10:58 jnthn But usually shortest path is the easiest way to understand a leak
10:59 timotimo hm, all paths could be *really* much :)
11:00 timotimo i think i want VMString to show up with its contents, does that make sense?
11:00 jnthn No
11:00 timotimo right, if it's huge, that'd be bad
11:00 jnthn I didn't do that on purpose
11:02 jnthn The point of this isn't to see the exact data on the heap
11:02 jnthn It's to understand the objects and their relationshps
11:02 jnthn And magnitudes
11:02 jnthn Once you start including data too it'll get incredibly large
11:03 jnthn Plus imagine somebody taking heap snapshots of code that has, for example, passwords or keys in memory
11:03 timotimo that's very true
11:03 timotimo oh
11:03 timotimo well, that's true
11:03 jnthn Today you don't have to worry you'll leak them if you share the snapshot with somebody for debugging.
11:05 timotimo that also means i don't want to give MVMHash's keys into the string heap
11:06 jnthn Yeah, maybe we should add key, value, key, value, etc.
11:06 timotimo i can definitely do that
11:07 timotimo or give both the key and the value the same index
11:10 timotimo though won't the key always be a string anyway? even with object hashes?
11:14 jnthn Yeah, for now
11:15 dalek MoarVM/annotate_refs_reprapi: 7c369e5 | timotimo++ | src/6model/reprs/MVMHash.c:
11:15 dalek MoarVM/annotate_refs_reprapi: give MVMHash an unmanaged_size
11:15 dalek MoarVM/annotate_refs_reprapi: review: https://github.com/MoarVM/MoarVM/commit/7c369e583a
11:28 timotimo pushed some more commits up to my fork of your heap analyzer. feel free to pull those in :)
11:28 timotimo i'll try to get a bit of shut-eye
11:28 jnthn Good luck! :)
11:29 jnthn .oO( The timotimo is a nocturnal species... )
12:31 vendethiel joined #moarvm
12:36 nine /win 37
12:37 jnthn /fail 43
12:40 ilmari /lose 42
12:46 nwc10 /lunch
12:46 nwc10 not sure what number goes with that
12:46 moritz at least 30 (minutes) :-)
17:10 geekosaur joined #moarvm
17:18 domidumont joined #moarvm
17:45 dalek joined #moarvm
18:15 dalek joined #moarvm
18:55 Ven joined #moarvm
19:13 geekosaur joined #moarvm
19:23 vendethiel joined #moarvm
19:29 FROGGS joined #moarvm
19:37 Ven joined #moarvm
20:12 dalek joined #moarvm
20:18 dalek joined #moarvm
20:42 timotimo .o( and now i slept far too much )
20:50 mojca joined #moarvm
21:12 jnthn Turns out there's more than one reason that EVAL leaks...
21:13 jnthn But at least I know I fixed the first one ('cus the heap snapshot analysis tells me so) and where to start looking for the second :)
21:14 timotimo did the amount of leakage get reduced at all, or is something else holding on to the same sub-tree?
21:15 jnthn The latter
21:15 timotimo feared as much :(
21:16 timotimo would the imagined "paths" command start from every single root (i.e. those things that are referenced by the Root collectable) and see if the object can be reached from there exclusively? or what?
21:17 jnthn You can probably do it with a modified bfs...
21:17 jnthn That keeps arrays of preds instead of just the best pred
21:19 timotimo mhm
21:20 timotimo then we'll have to be careful about circularity, though
21:21 timotimo perhaps it's enough to just not accept links that have a difference in "distance" that goes the wrong way?
21:21 jnthn It's a bfs, the color prevents you going in circles
21:21 timotimo oh
21:22 timotimo that makes sense
21:26 jnthn wtf, these paths are bizzare
21:27 timotimo show one? :)
21:28 jnthn https://gist.github.com/jnthn/5e6c8f84a9e44fd9966b
21:28 jnthn How on earth does ABC end up in the same SC has Int?
21:28 timotimo argh!
21:28 jnthn It's not reposeesion.
21:29 timotimo well, the boxed integer cache doesn't know about SCs at all
21:29 timotimo so whoever calls box_i at the right time gets it
21:29 jnthn oh...
21:30 timotimo that's something i didn't even think about when i wrote that code
21:30 jnthn Yes. Damn.
21:30 timotimo we could just empty out the BIC when we pop an SC, fwiw
21:30 timotimo or unset the sc in the cached boxed integers, if that makes any sense at all?
21:31 jnthn Well, an SC needs to "own" the thing really
21:31 timotimo a fake SC could do that, if need be
21:32 timotimo how does scdisclaim do it?
21:33 jnthn We really do need separate constants per SC, I think
21:33 timotimo OK, so the cache gets an extra "layer"/key and we'll have to throw out SC entries when we pop SCs?
21:36 ilmari joined #moarvm
21:36 dalek joined #moarvm
21:37 jnthn Maybe...or just clear it on push/pop of SCs
21:37 timotimo it could also get a hit/miss counter for SCs and an entry for what SC is currently being accepted and when the misses go much above the hits, it just gets dumped out completely
21:37 timotimo multiple threads would increment those counters, though
21:37 timotimo but i think it already has a lock that prevents competitive additions?
21:38 jnthn yeah
21:38 timotimo i'd go with the "dump when SC changes", fwiw
21:38 timotimo i mean, when push or pop get executed
21:38 jnthn Think I'll sleep on it. Currently checking if disabling it totally makes a difference.
21:38 timotimo OK. if not, we'll just have another place to look at ;)
21:38 jnthn It makes the heap snapshot a lot bigger for one.
21:39 timotimo yeah, many more Int objects
21:39 timotimo maybe an #ifdef for the int cache might be a good idea in general? i could put that in if you'd like
21:40 jnthn Seems I didn't disable it well enough...
21:41 jnthn Anyway, the short answer is that lexotic_cache is also guilty
21:41 timotimo if you'd like you can just gist the whole test setup including the ABC script
21:42 timotimo also, i think the int cache can only contribute to a limited amount of old SCs being kept around, no?
21:43 jnthn It's the same test as yesterday :)
21:43 jnthn I'd think so
21:43 timotimo isn't in my irc backlog any more :S
21:44 timotimo or was it not a gist?
21:44 jnthn https://gist.github.com/jnthn/f67379ff234861729f34
21:44 timotimo lovely, thanks
21:44 jnthn Make sure you have the NQP patch I did too
21:44 jnthn To fix the immediate leak
21:44 timotimo oh, it *was*!
21:44 timotimo aye, i built that on at least one of my two machines
21:45 timotimo oh, that one
21:45 timotimo yeah, will surely get that. i thought you meant the stage0 update and such
21:46 jnthn Oh, those are in a branch :)
21:46 jnthn 'cus I didn't do the JVM updates for them
21:46 jnthn And don't want to bust JVM
21:46 timotimo understandably
21:46 jnthn If you fancy doing that we can merge it
21:46 timotimo otoh, #?if moar :)
21:51 jnthn Would prefer to at least stub the op on JVM, even if it does nothing :)
21:52 timotimo understood
21:52 timotimo i'll have to run emergency-grocery-shopping
21:52 timotimo feel free to outline some more tasks
21:53 jnthn Well, removign the int cache helps but...then we just get other odd traces :)
21:53 timotimo i know nothing about the lexotic cache fwiw :)
21:53 jnthn That don't make sense, but I'm tired, so I'll leave it there for now. But feel free to see if you can figure them out
21:53 jnthn Yeah, that one I need to ponder
21:54 jnthn But there are *others* :)
21:54 timotimo but it can probably just be dumped at the same time the int cache gets dumped?
21:54 timotimo OK
21:54 timotimo i'll at least take a few looks
21:54 timotimo rest well!
21:54 jnthn I think I may come up with a better design for the lexotic cache :)
21:54 timotimo is it easy-ish to just chop the cache out of moar and see what happens?
21:55 timotimo or will that slow execution down 1000x?
21:55 jnthn No, I did exactly that
21:55 jnthn It makes bigger heap snapshots is all
21:56 jnthn timotimo: https://gist.github.com/jnthn/0e9274240cb928c31cfd was my patch
21:56 timotimo oh, i meant the lexotic cache
21:56 jnthn 'night
22:16 mojca joined #moarvm
22:20 geekosaur joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary