Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
MasterDuke timo: i haven't looked at your commits closely yet, think they conflict with github.com/MoarVM/MoarVM/pull/1746 or complement it? 01:45
lizmat and yet another Rakudo Weekly News hits the Net: rakudoweekly.blog/2023/05/29/2023-...t-rolling/ 13:23
timo just a tiny bit of conflict i thin, mostly complement 14:46
Geth MoarVM/callercode_in_inline_is_just_curcode: d42ed3e275 | (Timo Paulssen)++ | src/spesh/optimize.c
Also note rewrite_callercode relies on no nested inlines
15:59
MoarVM/main: 3b4d55a081 | (Timo Paulssen)++ (committed by timo) | 3 files
callercode no longer prevents inlining

assuming that an inliner's curcode is what an inlinee's callercode is supposed to return, we can just turn callercode into curcode when inlining. There is already a guard that prevents an inlining block from immediately inlining another so we can't for example by accident skip over one level of ... (48 more lines)
MoarVM/main: b9df871d1f | (Timo Paulssen)++ (committed by timo) | src/spesh/optimize.c
Also note rewrite_callercode relies on no nested inlines
lizmat ok, shall I bump NQP/Rakudo ? 16:03
timo ^^ ?
timo you can if you like, it's not urgent i think, but of course it always helps to have the code in the hands of everyone who build the bleeding edge 16:10
lizmat my feelings exactly :-) 16:11
timo are we able to run the regular profiler on core setting compilation at the moment? :D 16:13
lizmat I don't think so
generally anything running more than a few seconds, creates too much data 16:14
timo i tried --profile-compile=coresettingprofile.sql and it didn't crash but there's also no file 16:23
it could be at some point we changed whether Raku's HLL Symbol @END_PHASERS is defined or not at the position where run_profiled is used for profile-compile, and maybe the end phasers don't actually run in this case? 16:37
i'm digging into it in any case
lizmat ++timo 16:38
timo yeah, the dump_profile_data never runs after it got pushed into the end phasers 16:40
timo we could get a flag that makes mvm not track allocations, which would reduce the size of profiling data 16:45
lizmat fwiw, I'm usually less interested in allocation info 16:47
not seeing much difference in speed in core setting building or spectests 16:52
timo sad 16:59
i still get a crash, let's see if i can figure it out 17:16
oh it's a stack overflow from the dump call graph node loop 17:18
i could only get the frame size for the dump call graph node loop function from 144 or so to 112 bytes 17:48
74k stack frames, whew ... 17:51
timo something Very broke when we added return_u but forgot to tell the profiler to instrument that with "returned from frame" instruction 18:14
with spesh's inlining disabled, the output can actually be written 18:58
i think i will really need to go through the code again and find that nasty situation where IIRC optimizing a throw to a goto would cause trouble 18:59
MasterDuke timo: i think my PR fixes a segfault in the profiler 19:04
timo maybe it does the exact thing i just menitoned 19:06
i mean adding return_u to instrument.c 19:08
MasterDuke github.com/MoarVM/MoarVM/pull/1746...7c4f8fde2d yep, i thought that sounded familiar 19:26
i need to address nine++'s comments and finish that one up