02:57 ilbot3 joined 08:53 dogbert11 joined
Geth MoarVM: 7abf248f3e | cygx++ (committed using GitHub Web editor) | src/spesh/manipulate.h
Make MVM_spesh_manipulate_remove_handler_successors() public

Rakudo commit baa1393 uses it in src/vm/moar/ops/container.c		 09:00
MoarVM: e15db944bc | niner++ (committed using GitHub Web editor) | src/spesh/manipulate.h
Merge pull request #789 from cygx/patch-2

Make MVM_spesh_manipulate_remove_handler_successors() public
09:07 statisfiable6 joined 09:23 greppable6 joined 09:28 reportable6 joined, bisectable6 joined, unicodable6 joined 11:35 quotable6 joined 11:42 quotable6 joined 12:14 quotable6 joined 13:19 p6lert joined 14:55 Ven`` joined 16:32 domidumont joined 16:38 evalable6 joined, domidumont joined 16:40 zakharyas joined 17:19 wictory[m] joined
wictory[m] How is memory alignment of gc allocated objects handled in moarvm? 17:23
timotimo objects are created in a push-the-pointer area and move at most once into a size-segregated memory pool 17:28
no, sorry, at most twice
once from nursery to nursery (semi-space copying garbage collector for the nursery) and another time to the "old generation"
wictory[m] ok, when I read the code I got the impression that the nursery basically does not guarantee any alignment. If we start by assuming that nursery memory area is "well aligned" from the beginning. Then the sizes of the objects pushed before an object of interest decides on whether the object will be aligned. Have I understood this correctly? 17:32
17:33 zakharyas joined
wictory[m] this is a place where is happens: github.com/MoarVM/MoarVM/blob/e15d...tion.c#L37 17:38
so if `tc->nursery_alloc` unaligned, the allocated object will be unaligned. `tc->nursery_alloc` becomes unaligned when an object with an "unaligned" size is allocated. 17:41
This is another place where it happens: github.com/MoarVM/MoarVM/blob/e15d...ect.c#L313 17:42
timotimo how about putting a printf in there that triggers if an unaligned address gets in there and see if it actually does happen?
wictory[m] And for reference, here is a piece of code that relies on the fact that the objects are tight together github.com/MoarVM/MoarVM/blob/e15d...ect.c#L618 17:44
when I install rakudo from openbsd ports, I get an unaligned access assertion from libatomic_ops when I `use` the openssl module. 17:47
I managed to minimize the test that triggered this to something like: load a module A with a NativeCall Sub in, then load module B. Unfortunately I don't have the code here right now. 17:48
The native sub is a `Sub+Something` which has an unaligned size. After that a Lock is created, and when someone tries to access the Lock, I get the assertion 17:49
timotimo ah, access to atomic variables is likely a bunch more picky
if you're in gdb, you can "call MVM_dump_backtrace(tc)" (just go up a few frames to get a tc) 17:50
wictory[m] yeah, so I also hacked toghether a fix which tries to keep `tc->nursery_alloc` aligned. I'm able to run the test suites of nqp and rakudo with it. however, I'm not sure if that is the right way to solve it. 17:51
`MVM_dump_backtrace(tc)` sounds like a useful routine :) I will try that later. 17:52
I could open up an issue or PR on github about this later, maybe that the best thing to do here. 17:53
timotimo cool 18:01
18:09 domidumont joined 18:16 zakharyas joined, domidumont1 joined 19:35 greppable6 joined 20:36 Kaiepi joined 21:14 colomon joined, MasterDuke joined
MasterDuke Has anybody had a chance to look at github.com/MoarVM/MoarVM/pull/788 ? Any comments? 21:15
timotimo i don't see a reason to keep it unmerged 21:28
Geth MoarVM/master: 8 commits pushed by MasterDuke17++ 21:29
timotimo so there we go
mst the S-expr format for the templates makes me irrationally happy 21:31
timotimo you surely saw damian conway's talk that has quicksort written in basically-lisp-but-actually-perl6? :) 21:32
mst I think that one was first thing in the morning, ergo "no" 21:37
timotimo i'm not sure if it's the "shoulders of giants" talk or another 21:38
but i do believe there's recordings available
21:41 Zoffix joined
Zoffix I tried to do the bumps to bring those commits in, but the build died with "failed to load library 'dynext/libperl6_ops_moar.so'" 21:41
yoleaux 15:51Z <TimToady> Zoffix: removing that hack is probably fine, since my lack of nqp understanding at that point was primarily syntactic
timotimo Zoffix: you may need a "make clean"?
lizmat timotimo: make clean where ? 21:42
timotimo rakudo
lizmat done that, doesn't fetch the new Moar :-(
timotimo "fetch"?
Zoffix k, lemme try that 21:43
lizmat perl Configure.pl --gen-moar --gen-nqp --backends=moar --make-install
with a locally bumped NQP_VERSION
timotimo huh
lizmat aaah... 21:44
oops
my bad
I had only added the new version, not removed the previous one :-( 21:45
timotimo oh, you mean the file had two lines?
Zoffix Ah, lizmat++ already bumped nqp. Never mind me then.
21:45 MasterDuke joined
lizmat timotimo: yeah 21:46
and it took the first I guess
timotimo that could be made to explode
lizmat yeah... well, perhaps...
MasterDuke timotimo: cool, thanks 21:47
timotimo no, thank *you*
MasterDuke There are still a couple missing that had a lot of hits when building rakudo 21:48
timotimo cool, which are those?
MasterDuke But they were a bit more complicated 21:49
Zoffix Yeah, make realclean in all repos made the thing compile
MasterDuke I’m on my phone, don’t remember exactly
timotimo it'd be interesting to compare counts of how big the lines "making tree out of [blah, blah, blah"]" get
MasterDuke Maybe I can find them…
timotimo don't worry, i'll be afk soon, but i could check myself
MasterDuke Getattr and bindattr were two I remember 21:51
_i variant I think 21:53
21:58 MasterDuke joined
Zoffix Oh, the place where it worked (I think) was my local box. Still fails with the same error on my VM :/ 22:03
nm, wrong commands 22:04
22:13 Zoffix left 23:09 Ven`` joined, dalek joined, synopsebot joined, Geth joined, p6lert joined 23:11 Ven`` joined 23:30 Util joined 23:54 colomon joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!