00:21 MasterDuke joined
MasterDuke timo: not quite sure what's meant by "size parameters moved into the allocated blob"? 00:23
body->slots and body->ssize would be combined? 00:25
something like `MVMuint64 ssize = (MVMuint64)body->ssize_and_slots` and `*slots = &(body->ssize_and_slots) + sizeof(MVMuint64)`? 00:28
btw, timo++, fixing my silly realloc error
should i PR what i have now? or do it all together? 00:30
01:54 ilbot3 joined 04:56 geekosaur joined 05:05 geekosaur joined 05:07 yoleaux joined 05:51 Skarsnik joined 06:02 Skarsnik_ joined 06:11 brrt joined 06:12 domidumont joined 06:23 domidumont joined 06:26 domidumont joined
brrt good * #moarvm 06:49
nwc10 good *, brrt 06:50
brrt i'm still… puzzling about doing register allocation using dynamic programming
that should be a best-of-both-worlds kind of solution
but, the difficulty is, the dimensional space for spill/no-spill decisions is kind of large 06:51
so what i'd need is a way to 'build' one dimension on top of the other, as it were
also, good * nwc10 06:52
07:34 brrt joined 08:31 robertle_ joined 08:44 brrt joined
jnthn morning o/ 09:02
brrt good hi jnthn 09:05
samcv morning jnthn 09:31
jnthn is continuing with this scheduler adventures 09:32
samcv fun :) 09:42
MasterDuke jnthn: since i believe you are the one who originally suggested it: what's meant by "size parameters moved into the allocated blob"? 10:31
jnthn Today we have start/elems/ssize and then the element data 10:34
The suggest is to store ssize in the same piece of memory as the element data
*suggestion
So that you could then read that pointer *once*
And have a piece of memory and its size 10:35
MasterDuke something like `MVMuint64 ssize = (MVMuint64)body->ssize_and_slots` and `*slots = &(body->ssize_and_slots) + sizeof(MVMuint64)`?
jnthn Yeah, something like that
Though that will throw power-of-2 allocation sizes off some 10:36
MasterDuke what about body->elems? include it also?
jnthn The key thing is that we want to be able to do a single pointer deref
And then never read outside of it
Thus how we can get safety if multiple threads try to mess with the safe VMArray 10:37
*the same
Just freeing the memory at a safepoint ain't quite enough
Because we could still read outside the bounds of that memory in a race 10:38
MasterDuke right, the related question is, when should the *_at_safepoint functions be used?
jnthn We could move elems/start too, but we can't really trust them
We'd probably have to always use them at the moment
ssize is the actual thing that tells us if we're going to read in-bounds or not 10:39
MasterDuke ah, so i should change the code i have now in gc_free to use MVM_fixed_size_free_at_safepoint? 10:40
jnthn Oh
That's the one exception
In gc_free we are at a afepoint 10:41
*at a safepoint
grr, lag
MasterDuke ah. the only other free in VMArray.c is for the repr_data, which i didn't modify at all 10:42
Geth MoarVM: 3c3a52f961 | (Jonathan Worthington)++ | 8 files
Implement getrusage op
jnthn Oh right
But you'll need to safepoint version of realloc
MasterDuke yeah, i added that 10:43
jnthn So that's why there's no other frees needing it; 'cus it's the reallocs that need it :) 10:44
MasterDuke i modified set_size_internal to use my new MVM_fixed_size_realloc, should it be the *_at_safepoint version instead? 10:45
jnthn Yes 10:46
I guess you already took care of this, but the safepoint version of realloc can't delegate to MVM_realloc for overflows 10:47
It really must do the defensive copy
MasterDuke nope, i'll make both those changes
jnthn Cool 10:48
MasterDuke++
10:49 Ven`` joined
MasterDuke should i PR what i have now? or do the ssize+slots thing also? 10:50
jnthn I think separate PR for the FSA changes would be good 10:51
Since it's additive that should be an easy/quick review 10:52
MasterDuke k, will do that once the spectest finishes
jnthn Then maybe one for the switch to use FSA at all for VMArray, and we can merge that after the weekend release
And then another for the step afterwards to make it fully safe 10:53
Geth MoarVM: MasterDuke17++ created pull request #688:
Add MVM_fixed_size_realloc		 11:34
MasterDuke ^^^ is a cherry-pick and squash of the commits from my branch i linked earlier that just deal with adding MVM_fixed_size_realloc(_at_safepoint), but don't use them anywhere 11:37
next i'll cherry-pick and squash the commits that use those for the FSA support in VMArray and PR that 11:38
11:50 vendethiel- joined
Geth MoarVM: MasterDuke17++ created pull request #689:
Use FSA in VMArray		 12:02
MoarVM: 1e6f4afae5 | (Samantha McVey)++ | src/6model/reprs/MVMHash.c
Init. points as NULL in MVMHash.c & remove a few unneeded vars
 12:43
MoarVM: 6971e14524 | (Samantha McVey)++ | 2 files
Add documentation on UCA collation implementation

This is an overview on some aspects of the Unicode Collation Algorithm, as well as details for my implementation of it in MoarVM.
samcv night all o/
lizmat night samcv! 12:48
jnthn o/ samcv++ 12:50
13:03 Ven`` joined 13:43 timo1 joined 14:08 AlexDaniel joined
Geth MoarVM: a5c9c963fc | (Jonathan Worthington)++ | 2 files
Include debug names in some wrong REPR errors
 14:51
MoarVM: 4a7248e9ec | (Jonathan Worthington)++ | src/io/asyncsocket.c
MVMROOT the object intended, not an integer

Fixes occasional crashes in async socket servers since the port/host information was added
15:01 Ven`` joined 15:04 Skarsnik joined 15:24 brrt joined 15:35 Skarsnik_ joined
timo ouch, that was my mistake 15:47
16:26 leont joined 16:57 domidumont joined
Geth MoarVM: zoffixznet++ created pull request #690:
Use safer macro formatting		 17:33
18:19 zakharyas joined
Geth MoarVM/heapsnapshot_onlymajor_filter: 9154dcce6a | (Timo Paulssen)++ | 2 files
allow heapsnapshot to only record major collections
 18:44
MoarVM/heapsnapshot_onlymajor_filter: 48470d57ca | (Timo Paulssen)++ | 2 files
proper is_null check, allow forcing last snapshot
18:47 zakharyas joined
Geth MoarVM/heapsnapshot_onlymajor_filter: f147cf96ff | (Timo Paulssen)++ | src/profiler/heapsnapshot.c
fix compiler warning
 18:54
MoarVM/heapsnapshot_onlymajor_filter: e499fcbbbe | (Timo Paulssen)++ | src/profiler/heapsnapshot.c
root some vars while decoding strings into VMStrings
 19:08
timo starts a "make a table of all snapshot's summaries" feature and notices that ram isn't quite cheap 19:56
oopsie, exhausting the whole thread pool with awaiting threads when trying to parse multiple snapshots in parallel for this 20:04
completely without guidance this will probably cause catastrophical memory use, too, before the "forget snapshot" function is called even once 20:05
oh, huh 20:06
m: my @foo = do { await start { do for ^10 { my uint64 @ = 1, 2, 3; }.Slip }, start { do for ^10 { my uint64 @ = 1, 2, 3; }.Slip }; }; for @foo -> @pieces { say @pieces.^name }; 20:07
camelia array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]
array[uint64]…
timo m: use v6.d.PREVIEW; my @foo = do { await start { do for ^10 { my uint64 @ = 1, 2, 3; }.Slip }, start { do for ^10 { my uint64 @ = 1, 2, 3; }.Slip }; }; for @foo -> @pieces { say @pieces.^name };
camelia Slip
Slip
timo jnthn: ^- i have a feeling this isn't supposed to be like that? 20:08
m: use v6.d.PREVIEW; my @foo = do { await start { do for ^10 { my uint64 @ = 1, 2, 3; }.Slip }, start { do for ^10 { my uint64 @ = 1, 2, 3; }.Slip }; }; for flat @foo -> @pieces { say @pieces.^name };
camelia Slip
Slip
timo m: use v6.d.PREVIEW; my @foo = do { await start { do for ^2 { my uint64 @ = 9, 9; }.Slip }, start { do for ^2 { my uint64 @ = 1, 2; }.Slip }; }; say @foo.perl 20:09
camelia [slip(array[uint64].new(9, 9), array[uint64].new(9, 9)), slip(array[uint64].new(1, 2), array[uint64].new(1, 2))]
timo m: my @foo = do { await start { do for ^2 { my uint64 @ = 9, 9; }.Slip }, start { do for ^2 { my uint64 @ = 1, 2; }.Slip }; }; say @foo.perl
camelia [array[uint64].new(9, 9), array[uint64].new(9, 9), array[uint64].new(1, 2), array[uint64].new(1, 2)]
20:09 eater joined
jnthn timo: Looks interestingish; worth an RT 20:11
timo filed a bug 20:22
Geth MoarVM: 0925bb8f26 | (Samantha McVey)++ | 3 files
Make a few documentation updates for collation/strings
timo perl #132091 20:31
synopsebot6 Link: rt.perl.org/rt3/Public/Bug/Display...?id=132091
timo i ... i think i need to take a heap snapshot of the heap snapshot analyzer ...
cool, it segfaults 20:32
i suppose it's high time i made some soup
MVM_gc_worklist_add(tc, worklist, &(tc->instance->all_scs[sc_idx]->sc)); 20:36
sc_idx is 3020696576 here :D
[Coke] timo: I assume the implicit request on 132091 is that you don't want that change, yes? 21:33
.... ww.
22:11 travis-ci joined
travis-ci MoarVM build failed. Samantha McVey 'Add documentation on UCA collation implementation 22:11
travis-ci.org/MoarVM/MoarVM/builds/275451859 github.com/MoarVM/MoarVM/compare/3...71e1452453
22:11 travis-ci left
samcv travis race 22:12
timo hm, so ... if we properly have an "MVMCollectable common" at the beginning of every single collectable object ... we can totally put a big entry in there that gets declared a red zone when run under valgrind 22:24
Geth MoarVM: 73e4351caf | (Zoffix Znet)++ (committed using GitHub Web editor) | src/6model/reprs/P6bigint.h
Use safer macro formatting

To ensure it works right, regardless of what arg is used		 22:28
MoarVM: f042d9eb61 | (Jonathan Worthington)++ (committed using GitHub Web editor) | src/6model/reprs/P6bigint.h
Merge pull request #690 from zoffixznet/patch-1

Use safer macro formatting
timo it explodes no earlier when run under valgrind :\ 22:38
even with gc debug being cranked up to 2

Powered by Cro and the Raku® Programming Language.

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

Thank you!