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'm excited to see nfas being looked at 02:49
but if you're around, can i distract you with `runtime error: member access within misaligned address 0x058f6d766614 for type 'struct MVMP6intBody', which requires 8 byte alignment`?
timo can you give more details for that? does it come from a P6Opaque that embeds a P6intbody, or is it a stand-alone MVMP6int? what's the address of the root object? with `ptype/o MVMP6opaque` in gdb i see that the `MVMObject common` bit of it is 24 bytes big, so that should also be the alignment of the MVMP6intBody inside an MVMP6int 08:34
github.com/MoarVM/MoarVM/blob/e480...6int.c#L17 we get the alignment that's meant to be used for an integer of the given size here, but it could be that some sizes of integer may have different alignment requirements based on other factors, like if we ask for an atomic integer? 08:36
and it's also possible that the object wasn't allocated 8-byte-aligned? then we'd want to know if it lives in the nursery or the old generation, and if so, in what size bin 08:37
i'm not sure if i understand the mechanism of fate edges correctly yet, but we may be able to generate smaller NFAs by putting a fate edge later in the graph, then the stuff before it can more easily re-use stuff? i have no evidence that that would actually ever help, though 08:43
if the fate edge actually has to live at the exact point where it is now, because it also stores the amount of characters matched if i see it correctly, then we probably can't do anything though 08:45
jdv i second the enthusiasm on nfa opti progress 15:42

Powered by Cro and the Raku® Programming Language.

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

Thank you!