timo ideally something that can do it systematically so we can have some kind of measurement to ensure we've definitely covered some kind of area, which-ever metric we would use for that i am not sure 00:00
but as a start it'd be good to just do it randomly 00:01
there's already a commit from nine that was meant to address exactly this situation i think 02:53
github.com/moarvm/moarvm//commit/a...ab8c08ec26
haven't stumbled upon what exactly went wrong to give us a null in the spot we're looking at when trying to osr 02:54
Geth MoarVM/main: d2c12b9776 | (Timo Paulssen)++ | Configure.pl
Output a very visible notice when building with asan

Since not setting this env var prevents nqp/rakudo from building, it might be helpful to have it not only in the --help text for the asan flag.		 04:14
MoarVM/main: 6f925f2560 | (Timo Paulssen)++ | src/spesh/dump.c
Add debug helper to dump locals vars

includes details about inlines that are active in the frame you pass, and for good measure also the source and callsite of the frame's params and its arg context.
timo github.com/MoarVM/MoarVM/commit/6f...-147871624 here's what that looks like 04:17
whomst-ever wants to further track down the issue, it happens when we uninline in the situation shown in that comment. the call to elems was used to get the list fully reified. we deopt because we expect to see an Iterator but instead get a Scalar. that's what invalidates the optimized code we're inside of. then we go into deoptimized via uninlining, we return from the elems call, and when we hit 04:22
the loop where we're supposed to insert a bunch of stuff, we finally explode because the registers we thought contained the Int argument to this function actually has that low-level null in it
gist.github.com/timo/22f18ecdf3783...1139b5f1bb bunch of output from my debug session 04:39
04:59 kjp left 05:00 kjp joined 05:01 kjp left, kjp joined
timo i also put the rr recording there now 05:04
# Failed test at t/04-nativecall/25-embedded.t line 32 05:42
# Cannot locate native library 'lib25-embedded.so': lib25-embedded.so: cannot open shared object file: No such file or directory
do we know what this is about?
might be just having to change the "is native" to "./25-embedded" instead of "25-embedded" for it to work? 05:54
pushed a fix 05:55
lizmat timo++ 10:14
fwiw, I tried to reproduce the issue without Data::Generators, and failed 10:15
re t/04-nativecall/25-embedded.t worked ok for me without that fix, still works ok with it as well 10:43
10:58 sena_kun joined 16:16 lizmat_ joined 16:19 lizmat left
Geth MoarVM/main: b284498939 | (Timo Paulssen)++ | src/spesh/dump.c
fix compile error introduced by previous commit
 17:13
MoarVM/main: 824436eba3 | (Timo Paulssen)++ | src/spesh/dump.c
missed a change in the previous commit
 17:39
timo dev.azure.com/MoarVM/MoarVM/_build...&l=788 oof 18:09
dev.azure.com/MoarVM/MoarVM/_build...amp;l=4584 what actually was the process that segfaulted here? 18:16
i like just having to push a single object into a queue for vmeventsubscribe to work properly, since not having to run any code means it's easy-peasy to send something from even inside of something "fun" like the spesh thread, or close to where GC happens, or inside any operation that isn't marked invokish 20:15
but then in order to react to it, there has to be a dedicated thread that's blocking on reading on that queue 20:16
ThreadPoolScheduler wants the queues that get stuff put into it to be either a List with a callable in its first $!reified slot, or a callable that takes no arguments 20:17
maybe it's fine to force the user of vmeventsubscribe to provide a pool of List objects with the right callable in the first slot, and the bit that puts information in will then just push stuff in the right slots after it 20:19
ideally, there would be no allocation at the location where the vm wants to emit the event
maybe this is what i'll make an attempt to build
the current design asks for the subscriber to provide as a type object an int64 native array, because in order to put data into it, no GC allocation has to be made. it's just an array that grows the more you put into it 20:21
but of course that means you can only put integers in it
annoying amount of stuff to implement :| 20:26
hrmpf. with a List to hold the callable and its arguments, i still need to box everything, unless i want to force the user (which will be rakudo's own core, of course, not the end user) to provide a set of native arrays for different types of stuff to go into? 20:34
or alternatively boxes that i just overwrite the values of whenever i emit an event 20:35
a lot to think about :| 20:36
oh, i could totally just add a slot for a callable and corresponding queue that is sent every time an event gets emitted, so that it can just check the ConcBlockingQueue with the regular objects in it 20:39
that's much easier to set up, neat. 21:06
now where would the code for that go ... 21:12
Perl6::Compiler is where you get a heapsnapshot (Telemetry offers this for example) 21:13
Telemetry is where a bunch of stuff vaguely like what I'm talking about already happens
and it'd be cool to have the stuff from vmeventsubscribe to be available in the snapper too 21:14
also, the vmeventsubscribe API only offers one queue it should push stuff to, so that's kind of annoying to work around. the snapper causing a thread pool scheduler to be created immediately is not optimal, but if it steals the vmevent queue for itself that's also not great? 21:18
having to pull in Telemetry in order to just use the event queue also doesn't seem optimal? 21:20
lizmat_ vmeventsubscribe is news to me 22:13
22:13 lizmat_ left, lizmat joined
timo haha 22:16
yeah i didn't exactly make a huge announcement or anything 22:17
lizmat perhaps document it at github.com/Raku/nqp/blob/main/docs/ops.markdown ? 22:25
sleep&
timo still not sure if i want to give it a major rework first 22:28
22:54 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!