github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo lwn.net/Articles/775971/ - whoa. 01:46
Geth MoarVM/expr-jit-devirtualize: 5b63fa723c | (Bart Wiegmans)++ | src/spesh/plugin.c
[Spesh] Update deopt idx if we clone the deopt annotation

Otherwise the deopt index check in codegen.c breaks (even though it refers to the same output address).		 07:46
brrt that was one of the bugs, at least 07:49
there's a tiny bit of weirdness going on with annotations, in, that there can be multiple deopt annotations and they don't necessarily refer to the same target address
nwc10 brrt: this is a brtt but he/she/it satirises "Well volunteered" brilliatly: old.reddit.com/r/Python/comments/d...2/ezpqfl9/ 07:53
and much better than my typing
brrt lol 08:00
well, if/once I understand why it does the weird thing, I'll certainly be happy to change it
timotimo oof, profiling a program and `perf top` shows profile_log_enter and profile_log_allocated very high up the list 13:54
MasterDuke any way to make those cheaper? 14:01
timotimo i have an idea or two, nothing concrete yet 14:04
MasterDuke `if (IS_CONCRETE(timo->idea)) { profit++ } else { ??? }` 14:05
timotimo MVM_profit(tc) 14:06
Geth MoarVM: b7151da7d7 | (Stefan Seifert)++ | 2 files
Fix possible memory corruption in CStruct's and CPPStruct's get_attribute

An untimely GC run may move *root before we get to assign the newly created object into the child_objs slot. This could cause us to over write unrelated memory. Fix by MVMROOTing root. Same fix as commit d76ebbe49ada2d4649b9237db86fd36e004d6612 did for CUnion		 14:35
nine Yay code duplication
MasterDuke yay fixing possible memory corruption 14:40
timotimo the solution to code duplication in C is macros; i hope you love backslashes! 14:41
timotimo (or a generator script that builds the files for us) 15:00
www.di.ens.fr/~zappa/projects/frdwarf/ - oooooooh 15:07
MasterDuke how would that help us? just by making `perf report` faster? 15:11
timotimo i thought it'd be able to make "perf record" faster, too 15:11
i.e. be able to gather either more samples per second, or more stack data per sample
MasterDuke huh, cool 15:12
timotimo though actually thinking about it, i think "perf record" literally just takes the top parts of the stack by copying it
brrt good * #moarvm 15:14
timotimo ohai brrt 15:14
MasterDuke brrt: hey hey. if you've got some free time eventually (hopefully not a lot required) i replied to some of your additional comments on github.com/MoarVM/MoarVM/pull/1139 15:16
Guest15407 timotimo: around? 15:24
timotimo asquare 15:25
Guest15407 I suspect that jnthn is busy so I just wanted to ask if there might be a missing 'break;' here
github.com/MoarVM/MoarVM/blob/mast...rite.c#L21
timotimo looks very much like 15:26
nine very much
timotimo much very
Guest15407 hello nine, thx for the quick fix yesterday
nine Guest15407: did you see? It's even a 3 for the price of 1 :) 15:27
Guest15407 indeed 15:27
I'm having problems finding new ones now :)
timotimo damn
Guest15407 will one of you fix the missing break or should I PR it when I get home? 15:28
Guest15407 relocates & 15:34
timotimo now ... how do i display the "high score lists" properly in the heapanalyzer shell ... 15:40
for each of the snapshots it has a list of 40 for each of "frames by size", "frames by count", "objects by size", and "objects by count"
it's obviously not always the same 40 in each of the snapshots 15:41
theoretically it could have "1st", "2nd", "3rd", "4th", "5th" as the column titles
especially frame names can be very long 15:42
maybe i'll skip implementing it in the shell and go for the moarperf impl first, since that can render charts
nine Guest15407: will do. There's another one, I'll commit as well 16:02
dogbert17 nine: thx 16:25
Geth MoarVM: 3f97d73d4c | (Stefan Seifert)++ | 2 files
Add obviously missing break; to switch statement in instrument_graph

  Thanks to dogbert17++ for noticing!		 16:39
Kaiepi can someone review github.com/MoarVM/MoarVM/pull/1166 ? 17:12
timotimo Kaiepi: i wonder if the AsyncTask actually causes the ri->handle and ri->buf_type pointers to be updated in case GC happens 17:23
timotimo Kaiepi: i can't do a full review of the PR :( 17:53
you can more easily find out if your roots are correct if you set GC_DEBUG to 3 in src/gc/debug.h (or gcdebug.h?) or to 2 and reducing the nursery size drastically in src/gc/collect.h (or something) 17:58
Kaiepi ok 18:04

Powered by Cro and the Raku® Programming Language.

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

Thank you!