github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
00:23
MasterDuke joined
00:24
MasterDuke left,
MasterDuke joined
01:18
MasterDuke left
01:23
MasterDuke joined
01:24
MasterDuke left,
MasterDuke joined
02:57
Kaiepi left
|
|||
timotimo | japhb: there is already limited telemetry that'll give you timings of minor and major collections, both their offsets and their durations, without giving you the normal profiler's overhead | 03:46 | |
there is nothing in the way of visualization yet, which is why i'd like to get tracy into moarvm | 03:52 | ||
05:33
brrt joined
06:08
domidumont joined
06:12
domidumont1 joined
06:14
domidumont left
06:56
brrt left
07:18
brrt joined
|
|||
brrt | \o | 08:22 | |
11:55
p6lert left
11:56
masak left,
Util left,
synopsebot left,
dalek left
11:57
Geth left
13:15
lucasb joined
13:43
MasterDuke left
|
|||
japhb | timotimo: How do I get that info? I want to add that to my animation frame rate visualization | 15:04 | |
timotimo | japhb: compile moarvm with --enable-telemetry (or is it --enable-telemeh?) flag, then set MVM_TELEMETRY_LOG=/tmp/foobar.txt | 15:05 | |
15:07
brrt left
|
|||
japhb | timotimo: Oh, that's not helpful then for the case I'm thinking of. I need to be able to introspect from the running program, so that I can say "How many nursery and full GCs since the last time I asked?" in the code that does the live frame data visualization. | 15:13 | |
(But good to know at least the infrastructure exists.) | |||
timotimo | ah | 15:22 | |
that'll be in rakudo in the next few days i hope | |||
japhb | Awesome! :-) | 15:49 | |
timotimo | can you think of other stats you'd like to have available? | ||
16:03
domidumont1 left
|
|||
japhb | Hmmmm ... objects and bytes promoted/kept/freed would probably be useful. | 16:16 | |
Also some of the other limited resources, like file descriptors in use | |||
Oh, time spent GC paused | 16:17 | ||
timotimo | i can make that part of it; how would you like to get the data for the common cases of "the nursery had its size reduced" | 16:31 | |
japhb | Current nursery size perhaps? I can do the math to figure out if it grew or shrank pretty easily. | 16:32 | |
timotimo | how about past nursery sizes, if you poll "too far apart"? | 16:33 | |
also, when lying in bed and not sleeping i thought perhaps a "wait for GC to happen" op could actually be interesting | 16:34 | ||
also, threads being added; do you want a total over all live threads or entries for every thread | 16:35 | ||
i wanted to ask something else, but i forgotted | 16:46 | ||
japhb | timotimo: If you were going to track past nursery sizes, when would you checkpoint that data? Each time you change it? Each GC? | 16:50 | |
Re: "threads being added; do you want a total over all live threads" -- what are you talking about totalling here? | 16:51 | ||
Did you intend "wait for GC to happen" to force GC immediately, or pause the thread until GC happens sometime in the future? | 16:52 | ||
timotimo | block until GC happens, or maybe register a callback that gets called when GC happened | 16:53 | |
the latter would be async-friendly | |||
so that'd be nice | |||
japhb | Yeah, that would be nice. | 16:56 | |
16:57
zakharyas joined
|
|||
ugexe | isnt forcing the GC immediately already a thing with nqp::force_gc? | 17:08 | |
japhb | ugexe: Yes, I believe so. I was asking timotimo what he meant, since memory is a strange thing while attempting to fall asleep. | 17:18 | |
It happens that he meant the *other* possibility, which was to block the thread until a "naturally occuring" GC. | |||
timotimo | it's for getting notified when the GC was triggered | 17:43 | |
17:50
zakharyas left
18:55
lucasb left
20:30
fake_space_whale joined
22:49
kiwi_31 joined
22:52
kiwi_31 left
|