00:41 tgt joined 00:54 tgt joined 01:05 colomon joined 01:28 benabik joined 01:55 tgt joined 02:05 FROGGS_ joined 02:56 tgt joined 04:59 tgt joined 05:44 ingy joined 06:00 tgt joined 07:01 tgt joined 08:01 tgt joined 08:48 odc joined 09:30 tgt joined 09:42 tgt joined 10:56 donaldh joined
dalek arVM: 3ef533d | (Timo Paulssen)++ | src/strings/ops.c:
a more general fastpath for flattening ropes.
 12:12
timotimo jnthn: does it seem like a bad idea to put the string allocation counter next to nursery_fromspace and nursery_tospace? 12:13
struct memory layout wise?
and cache lines and stuff?
jnthn timotimo: I doubt they'll be accessed that close in time 12:14
timotimo: So I think it doesn't overly matter here.
timotimo should i put it at the end of the struct?
jnthn Well, maybe put it near other memory management related bits, for the sake of humans :) 12:15
timotimo mhhh sake 12:16
i should try that some time
what's a good place to put the constant i should compare to? allocate.h has the function to add pressure 12:17
jnthn I tried it once and can't wine against the experience...
timotimo: Near the function that adds pressure :)
timotimo: uh, in the .h though :)
So, that same one
timotimo aye. 12:18
jnthn kingjamesprogramming.tumblr.com/pos...end-of-the :) 12:20
timotimo %)
it seems like i should store MVMGCStatus_INTERRUPT to tc->gc_status 12:21
is that what i use MVM_STORE for? 12:22
or do i CAS that?
jnthn Well, you know it's your own, which simplifies things since you don't race with yourself. 12:23
So MVM_store will do it
timotimo ah 12:24
good
jnthn: are we certain that enter_from_interrupt actually works? 12:37
jnthn timotimo: Umm 12:38
timotimo: It may make an assumption...
(That another thread set the flag.) 12:39
timotimo oh
jnthn It certainly works as in we wouldn't be able to pass the concurrency tests we do if it didn't.
timotimo hold on. 12:40
i may have done something dumb .. .again :)
jnthn: so, MVMGCStatus_SHOULD, or something like that? 12:48
or _INTERRUPTED_SELF?
jnthn Maybe the latter... 12:51
timotimo done 12:52
jnthn Do make sure you didn't regress threads.t and locks.t in moar-conc with these changes.
timotimo ah. i check that only in GC_SYNC_POINT, which might be wrong. 12:53
jnthn Yeah, this may cause issues...hm.
timotimo yeah 12:54
does rerouting enter_from_interrupt directly to enter_from_allocator seem like a bad idea to you, too? :)
jnthn We may be better off allowing self-interupting. But not sure. And can't be now.
timotimo allocate_nursery checks for !=0, so at a normal allocation, it'll enter_from_interrupt 12:57
... do we even reset the gc status? o_O 12:59
i may have just reproduced nwc10++'s torture tester by accident %) 13:00
ah, we CAS it from INTERRUPT to NONE 13:03
13:03 Ven joined
timotimo but if it's INTERRUPTED_SELF, the cas will infiniloop instead 13:03
jnthn Right 13:04
I think adding an extra status will mess things up 13:05
timotimo it doesn't infiniloop, it just doesn't swap and returns immediately
while the code doing it doesn't expect that
should i if(cas(try to change INTERRUPT to NONE) == INTERRUPTED_SELF) { cas(try to change INTERRUPTED_SELF to NONE) }; ? 13:06
that's ... not really atomic %)
it does, however, now gc a bunch of times
jnthn Nok don't screw with csa stuff unless yo're good enough.
*as 13:07
*cas, even
If you're asking, you're going to get it wrong.
timotimo aye :)
i put a second cas below the INTERRUPT to NONE change that changes INTERRUPTED_SELF to NONE, but it really does seem terribly fragile
jnthn (I'm doing too many other things at the moemnt to work it out...this stuff is too hard to multi-task on...)
timotimo what i could do is set the state to INTERRUPT as soon as we've seen it's INTERRUPTED_SELF and *then* enter_from_allocator 13:08
jnthn It may be we can fuse enter_from_allocator and enter_from_interupt into a single enter that does the right thing.
timotimo i've changed the manual check + invocation in gc_allocate_nursery to a SYNC_POINT instead
whoops, integer overflow %) 13:09
moritz
.oO( us an Int )
 13:10
timotimo now it gets up to 3 gigabytes of ram used and then collects pretty often 13:11
dinner time :) 13:12
270.30user 11.18system 4:42.56elapsed 99%CPU (0avgtext+0avgdata 3378420maxresident)k 13:51
perl6-m -e 'my $s = ""; for (1 .. 1000000) { $s ~= "x" }; 1'
as soon as it hits the set value for the threshold, it'll start collecting very often for this very test. 13:52
in this case 3 gb is the threshold for string allocations
(for string allocations to trigger a gc run) 13:53
but since it would try to allocate 3gb of string directly after the collection anyway, it's the choice between getting killed by memory pressure or becoming very slow :P
if there was a way to signal "do a minor collection only" so it would skip major collections, that might be nice. 13:54
16:25 rurban_ joined 17:45 rurban joined 18:41 tgt joined 19:38 lizmat_ joined 19:44 __rnddim__ joined 19:48 synopsebot joined 19:58 _sri joined 20:00 lue joined 20:01 japhb joined 20:05 _sri joined 20:13 japhb__ joined, colomon_ joined 20:26 tgt joined 20:54 benabik joined 21:23 lizmat joined 21:24 ggoebel1118 joined 21:32 colomon_ joined 23:29 tgt 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!