github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
vrurg .tell nine I have solved it. github.com/rakudo/rakudo/pull/4218 01:37
tellable6 vrurg, I'll pass your message to nine
Geth MoarVM: e316dc34e2 | (Jonathan Worthington)++ | src/profiler/instrument.c
Fix confused profiler output in multi-threaded app

At some point we started to assign indexes to static frames and then look them up, so as to cheapen GC of the profiler data. Unfortunately, this introduced a bug when we recorded profiles in multi-threaded programs: the wrong thread context was used to resolve those indices when dumping the profile results, which in turn led to the indices resolving to the wrong static frame. Thus the output of profiles involving multiple threads would often end up garbled.		 08:21
MoarVM: 4ae157c33d | niner++ (committed using GitHub Web editor) | src/profiler/instrument.c
Merge pull request #1441 from MoarVM/fix-profiler-thread-bug

Fix confused profiler output in multi-threaded app
nine jnthn: the sad thing about this ^^^ is that the compiler could have warned us about the unused argument, but we don't let it
tellable6 2021-02-24T01:37:32Z #moarvm <vrurg> nine I have solved it. github.com/rakudo/rakudo/pull/4218
MasterDuke because of all the false warnings we'd get from unused `tc`s? 08:36
nine yes 08:37
Those and other args, mostly in 6model functions
nine That's some 8791 warnings :D 08:40
MasterDuke ha 08:44
nwc10 I was going to say "don't scare leont with things like that" but I on reflection think he's big/battle scarred enough to take it 08:46
leont Heheh
MasterDuke only 177 unique if you exclude src/6model/*  and any warnings for 'tc' 08:54
a couple of those i checked are false positives (i.e., used in an #ifdef or #define), but some seem legit (e.g., 'unwind' here github.com/MoarVM/MoarVM/blob/mast...og.c#L236) 09:16
Raeiyhan hello 09:28
would like to register for rvm
nine rvm? 09:31
Raeiyhan ruby virtual machine 09:37
MasterDuke this channel is about the moar virtual machine (which is for running raku code, not ruby) 09:39
Raeiyhan ok 09:40
MasterDuke well, it looks like the reason my remove_spesh_candidate branch is slower is that it's doing massively more temporary allocations (according to heaptrack), caused by allocating more frames 13:53
it's calling allocate_frame 470440 more times. 677015 times fewer for non heap-allocated, but 1147455 times more for heap-allocated 14:11
MasterDuke i don't understand why these heaptrack profiles are so very different. sure there are more frames allocated on my branch, but the difference doesn't seem enough to explain these profiles (and perf shows something similar) 15:06
lizmat is it ok to bump MOarVM to get the profiler fixes ? 15:07
nine yes
lizmat ah,,.. I guess not, until sena_kun has done a point release
sena_kun lizmat, yes
well...
lizmat ...
sena_kun: if you say yes again, I will bump :-) 15:09
sena_kun I am doing one out of branch today, so can be bumped.
lizmat okidoki

Powered by Cro and the Raku® Programming Language.

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

Thank you!