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.
lizmat an optimization thought that just occurred to be: a serialized hash in bytecode is read into memory completely at first access, right? 11:50
If so, I was wondering if there could be a way to keep the values in the bytecode, but only read the keys, so that only the keys/values actually accessed would live in memory, rather than the whole hash ? 11:51
does that make sense ? 11:52
nine Just now I had a core dump in t/spec/S02-types/bag.t 12:35
non-reproducible of course
#0 0x00007f4e47f865ac in __strlen_evex () from /lib64/libc.so.6
#1 0x00007f4e47eb05d2 in strdup () from /lib64/libc.so.6
#2 0x00007f4e4856afe2 in dcCall_x64_sysv () from //home/nine/rakudo/install/lib/libmoar.so
timo but you do have the core available? 12:49
what does S02-types/bag.t even do with NativeCall 12:50
can you make triple-sure that that core corresponds to that test? did some kind of confusion from parallel testing happen there perhaps? 12:53
i think it shouldn't be terribly hard to run every test wrapped in "rr record" and then just rm the recording for every test file that succeeded 12:55
nine Oh, disregard!
Since when do we have spec tests using NativeCall? 12:56
timo i have no idea
S29-os/system.t
210:‘use NativeCall; sub strdup(int64) is native(Str) {*}; strdup(0)’;
this?
oh is this literally a "easiest way to segfault" bit of code? 12:57
nine seems like 12:58
timo 'Exit with a segfault makes the Proc throw in sink context';
lizmat t/spec/S17-procasync/windows-print-raw-args.raku also appears to be using NativeCall
timo ... surely this is not the thing we sometimes see in CI logs?
how about we make a nqp::syscall named "segfault" that segfaults and also puts a big fat symbol on the stack that is called "the_user_code_explicitly_asked_for_this_process_to_segfault_ok" 12:59
lizmat such a test would not belong in roast fwiw, but yes, feels like an idea? 13:06
nine We could just ship a binary that will always segfault 13:08
timo or use another program, like "perl" which we already require anyway 13:19
if we required posix shell or so, we could literally shell out to like, "kill -11 $PID" 13:20
unfortunately, the "signal" and "kill" stuff is not A Thing on windows
we could instead of segfaulting with strdup(0) just call abort(), that should kill the process with SIGABRT on linux, and i'm not sure what exactly it will do on windows 13:21
nine: btw do you know why there's no arguments visible on your stack trace? no debug symbols for your libc? 13:26
and where did you get the core dump from? did it land in your PWD and you picked it up from there, or "coredumpctl list" or some other thing? 13:29
nine coredumpctl 13:34
We're in 2025 after all :)
timo right. well, we could in theory set the "maximum size of core dump file" ulimit before turning that particular test. not sure how that would translate to windows though 13:39
lizmat on the interesting issues front: github.com/lizmat/Text-Emoji/issues/2 19:03
apparently it needs 4.5GB to install
timo whew. 20:07
timo MVM_spesh_args allocates a boatload of memory when trying to optimize the slurpy arguments instruction for presumably one absolutely ginormous callsite 20:19
presumably the benefit to turning the "make array from slurpy args" into "create the array and bindpos every argument individually" will drop off after a thousand 20:30
the guard tree also looks ridiculous 20:37
> 1.23user 0.10system 0:00.97elapsed 137%CPU (0avgtext+0avgdata 196852maxresident)k 20:44
> 1.10user 1.00system 0:01.92elapsed 109%CPU (0avgtext+0avgdata 3332068maxresident)k 20:47
first is after, second is before
Geth MoarVM/spesh_arg_refuse_for_enormous_slurpies: 62a5398105 | (Timo Paulssen)++ | src/spesh/args.c
Don't turn slurpies into huge amounts of code

For example, a file with a huge hash literal created with the `infix:<,>` operator may end up with a callsite with thousands of entries, and peak memory usage from register facts and other stuff can balloon quite massively.		 20:56
MoarVM: timo++ created pull request #1921:
Don't turn slurpies into huge amounts of code		 21:00
timo lizmat: here's a fix, though i think it might still be better to have a begin block with a string constant that gets combed or something like that 21:01
lizmat you mean, generate it all into a single string with \0 between entries, and then my constant %h = largestring.split("\0") ? 21:03
timo for example, yeah 21:31
MasterDuke timo: where aren't we creating the MVMP6int correctly? 22:48
because we only get iirc three of those ubsan errors, so not everything is wrong 22:49
oh, and for flappers, there is one long-standing one 22:53
can't remember the name now... 22:55
./S32-str/gb18030-encode-decode.t or ./S32-str/gb2312-encode-decode.t maybe? 23:01
ah, i think it's t/02-rakudo/15-gh_1202.t ! 23:09
that's been flapping since at least 15 Sep 2019 23:11

Powered by Cro and the Raku® Programming Language.

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

Thank you!