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.
Geth MoarVM/fix_sleep_jit_for_windows: 10edfeeceb | (Timo Paulssen)++ | src/jit/graph.c
MVM_platform_sleep takes no tc argument

This was causing the amount of seconds to land in the xmm1 register on windows, where the function wasn't looking, and therefore any loop that was attempting to run "slowly" by calling sleep to accidentally sleep by whatever happened to still be in that register, which turned out to be 0.0, which is roughly equivalent ... (7 more lines)		 11:27
MoarVM: timo++ created pull request #1918:
MVM_platform_sleep takes no tc argument
timo now i wonder if it'd be easy to check statically that the arguments we pass when jitting function calls are correct for the function in question ... 11:29
Geth MoarVM/main: 0416a0974d | timo++ (committed using GitHub Web editor) | src/jit/graph.c
MVM_platform_sleep takes no tc argument (#1918)

This was causing the amount of seconds to land in the xmm1 register on windows, where the function wasn't looking, and therefore any loop that was attempting to run "slowly" by calling sleep to accidentally sleep by whatever happened to still be in that register, which turned out to be 0.0, which is roughly equivalent ... (7 more lines)		 12:36
MasterDuke timo: here's an interesting problem you might be good at tracking down. in t/04-nativecall/00-misc.t, at line 119, we end up in MVM_string_substrings_equal_nocheck, with `a->body.num_graphs == 0` and `a->body.cached_hash_code == 0`, but `b->body.num_graphs == 0` and `b->body.cached_hash_code != 0`. then ubsan complains that memcmp's first argument 14:26
is NULL when it's not allowed to be
timo interesting. i think cached_hash_code == 0 means we just haven't calculated the hash? and there's apparently a valid hash code for a null grapheme long string 14:27
MasterDuke yeah, the cached_hash_code might be a red herring 14:29
but `a->body.storage.blob_32 + starta` being NULL seems like it should never happen 14:30
src/strings/ops.c:542:29: runtime error: null pointer passed as argument 1, which is declared to never be null 14:32
    #0 0xffffb25b81b4 in MVM_string_substrings_equal_nocheck src/strings/ops.c:542
    #1 0xffffb21389cc in MVM_interp_run src/core/interp.c:1393
    #2 0xffffb223edfc in start_thread src/core/threads.c:101
    #3 0xffffb1934b2c in start_thread nptl/pthread_create.c:447
    #4 0xffffb199d888 in thread_start ../sysdeps/unix/sysv/linux/aarch64/clone3.S:76
timo it seems a little odd that we're calling substrings_equals_nocheck with starta and startb both set to 0, it feels like we might be able to do a little better than the substrings equals nocheck function when we know that. though maybe the only stuff we can actually do better is the stuff we already do in front of that function 14:33
MasterDuke interp.c is calling MVM_string_equal 14:34
timo how come we have a blob_32 with num_graphs == 0, it would be much easier to just have it be an in-situ-8 instead 14:35
i know. MVM_string_equal is the thing that calls substrings_equal with starta and startb as 0
MasterDuke github.com/MoarVM/MoarVM/blob/main...1561-L1572 maybe should add a special case for both 0?
but yeah, the real problem/fix might be elsewhere 14:36
afk for a bit, have to push a kid on a swing 14:37
timo have fun :) 14:38
static MVMString * get_all_in_buffer(MVMThreadContext *tc, MVMDecodeStream *ds) always builds grapheme_32 14:39
478 /* If there's no codepoint buffer, then return the empty string. */ 14:40
there's already a special case here, we can just make that set in_situ_8
timo actually, it could return the empty string constant instead 14:41
Geth MoarVM/decode_stream_take_all_in_buffer_return_empty_string_constant: 3edbf6db79 | (Timo Paulssen)++ | src/strings/decode_stream.c
Save allocating a string in decodestream for empty string

Instead, reuse the global empty string constant		 14:49
timo regarding a->body.storage.blob_32 + starta being NULL, the only way this can happen is if blob_32 and starta are both 0; starta is always 0 when called via MVM_string_equal of course. it could also happen that the sum of the pointer blob_32 and starta just happen to exactly hit the overflow point and wrap back around to 0 14:54
with our case of num_graphs also being 0, it is only dangerous to call memcmp if it's defined by the standard to be dangerous, which i don't actually know. but if ubsan complains, it does sound like that's undefined behaviour what happens in that case 14:57
Geth MoarVM: timo++ created pull request #1919:
Save allocating a string in decodestream for empty string		 14:59
MoarVM/main: 3edbf6db79 | (Timo Paulssen)++ | src/strings/decode_stream.c
Save allocating a string in decodestream for empty string

Instead, reuse the global empty string constant		 16:46
MoarVM/main: e480f2db72 | MasterDuke17++ (committed using GitHub Web editor) | src/strings/decode_stream.c
Merge pull request #1919 from MoarVM/decode_stream_take_all_in_buffer_return_empty_string_constant

Save allocating a string in decodestream for empty string

Powered by Cro and the Raku® Programming Language.

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

Thank you!