|
01:48
ilbot3 joined
03:46
hoelzro joined
07:10
geekosaur joined
07:30
zakharyas joined
|
|||
| brrt | good * #moarvm | 07:32 | |
|
07:33
domidumont joined
07:38
domidumont joined
08:12
FROGGS joined
|
|||
| FROGGS | o/ | 08:13 | |
|
09:04
domidumont joined
|
|||
| jnthn | o/ | 09:26 | |
| yoleaux2 | 20 Oct 2016 22:16Z <FROGGS> jnthn: I got it to work now: gist.github.com/FROGGS/bd727a2408e...c4b8765a8c | ||
| jnthn | FROGGS: I'm a tad surprised there ain't a c => ... on the first line of output :) | 09:28 | |
| But...nice work! \o/ | |||
|
10:24
JimmyZ joined
|
|||
| timotimo | jnthn: i figure instead of immediately freeing the last frame's env and locals, i could store up to one of each and when either freeing the next two or allocating new ones hit the allocator four times in a row and locking and unlocking only once in the process | 10:52 | |
| and on top of that, if the sizes match up, just not hit the allocator at all | |||
|
10:53
domidumont joined
|
|||
| timotimo | if there's also a way to store what the original size of a slot was, we can re-use one or both of those cached ones if the size of the next needed one is smaller than or equal to the current one, and also not hit the allocator in these cases | 10:58 | |
| maybe actually freeing the slot if we require less than half or a quarter so that we don't hang on to a 4 megabytes big frame for an hour | 10:59 | ||
| oh, hmm, we want zeroes, eh? | 11:10 | ||
| i suppose when i free a frame and return it to the cache i can zero it out with memset and that'll be fine | 11:11 | ||
| i'm not entirely sure why the logic for setting up the VMNull pointers differs between allocate_heap_frame and allocate_frame. maybe an oversight when the VMNull-via-spesh mechanism was invented? | 11:16 | ||
| well, i managed to make things error out | 11:58 | ||
| that's ... progress? | |||
| ah, of course. i didn't grab the size out of the cache. that way later frees would give the wrong size | 12:05 | ||
| not quite nailing this ... at all :) | 12:11 | ||
| at least i can play my newly obtained vidya game to try and get a fresh look at things | 12:22 | ||
| brrt | vidya game? | 12:24 | |
| timotimo | yup. Rhythm Heaven Megamix | ||
| brrt is so so so so so excited about the nintendo switch :-o | |||
| otoh, haven't touched the wii u in ages, and not for lack of games | 12:27 | ||
| but utterly no energy for it | |||
| timotimo | hm. even when i turn off putting stuff into the cache, i get segfaults | 12:28 | |
| er, i mean: even when i turn off getting things out of the cache | 12:29 | ||
| brrt | and git diff doesn't tell you why? | 12:30 | |
| timotimo | gist.github.com/timo/b8f32c09684ef...30b1844e85 - do you see an obvious mistake? | 12:32 | |
| brrt | not yet | 12:36 | |
| timotimo | all i can imagine is i'm destroying the FSA by giving things the wrong size when freeing | ||
| i thought i was being sufficiently careful about that | |||
| oh, i get it | 12:37 | ||
| the memset is wrong | |||
| it's still asploding now, though | 12:40 | ||
| ah | 12:42 | ||
| allocd_* attributes in MVMFrame are MVMuint16, but the local vars (and therefor my parameters) are size_t | |||
| no, they are MVMint32 * instead of MVMuint32 * | 12:43 | ||
| hm. things are still explodey | 12:45 | ||
| MVMuint16, i should have said. | 12:46 | ||
| energy levels seem to be used up now :o ... but it's still so early in the day =_= | 13:00 | ||
| it's a bit suspicious that sometimes fprint is losing its \n | 13:01 | ||
| brrt | hmm, that it is | 13:03 | |
| jnthn | What does the line doing the fprintf look like? | 13:05 | |
| timotimo | looks like redirecting to a file makes it less bad | 13:08 | |
| gist.github.com/timo/1154ffecdb190...e44af62bcb - the log with cache hits and misses | |||
| though the use of parens is b0rky here; for the cache misses i output the sizes that are in the cache, for getting something out of the cache i put the size from the cache first, then the size actually requested into the parens | 13:09 | ||
| whoops, using 152 byte sized regions to satisfy a request for 16 bytes | 13:10 | ||
| refresh for better output and more details | 13:13 | ||
| nap & | 13:14 | ||
| oh, i really gotta do laundry today | |||
| so nap has to wait | 13:15 | ||
|
13:15
harrow joined
|
|||
| nine | Turning native_callback_cache into a weak hash doesn't seem to be a winner strategy. At times the cache will be the only thing referencing those MVMNativeCallbacks. That's why we need the cache in the first place. | 13:16 | |
|
13:16
japhb joined
|
|||
| nine | So I propose a different solution: add a usage counter to MVMNativeCallback. Increase the counter every time we take the callback info out of the cache. On GC go through the cache and evict all items with a usage counter of 0 and then reset all counters to 0. | 13:18 | |
| Does this sound sane? | |||
| Could be that it needs a s/MVMNativeCallback/MVMNativeCallbackCacheHead/g | 13:19 | ||
| lizmat | nine: feels like a refcounting scheme, and that hasn't worked too well in the past | 13:25 | |
| and what we had in refcounting, jnthn removed from Moar recently, didn't he ? | |||
| (thinking about frames) | |||
| jnthn | Unfortunately, I suspect this is one of those problems that we can't have a 100% automatic solution | 13:26 | |
| a-c-function-that-uses-the-callback(-> { 42 }) // here we could evict it right away after the call | 13:27 | ||
| a-c-function-that-registers-the-callback-somewhere(-> { 42 }) // but here we cannot | |||
| And there's no way to tell between the two | |||
| Evict all itmes with usage count of 0 - what if the GC run happens before the callback's first use? | 13:28 | ||
| Or in the second example, what happens if there happens to be no use of the callback between two GC runs? | |||
| nine | Good news is that we don't need 100 %. It's just a cache after all. | ||
| jnthn | I fear cache is also a tad misleading name wise | 13:29 | |
| nine | ouch | ||
| jnthn | It also is serving as what keeps closures alive. | ||
| Note that "closure" is also significant here | |||
| I can't remember if the cache keys on ->outer also | 13:30 | ||
| But at the end of the day, this is a memory management issue | |||
| Essentially, for how long does the native code we're calling need the callback to stay alive | 13:31 | ||
| I can't remember the full history of callback impl. I do remember having to fix it at some point, I think because the cache didn't distinguish between closures of the same code | 13:32 | ||
| So it would end up with outers messed up when you were doing, so, GUI event handler registration | 13:33 | ||
| timotimo | a) it'd be better if that cache was bigger, b) a bigger cache will at some point resemble hoard without the added intelligence that makes hoard actually good | 17:05 | |
| jnthn: any reason in particular we'll not just use hoard for everything? | 17:07 | ||
|
18:06
FROGGS joined
|
|||
| FROGGS | o/ | 18:07 | |
|
23:06
dalek joined,
synopsebot6 joined,
geekosaur joined,
_longines joined,
nine joined,
mtj_ joined,
btyler joined,
konobi joined,
cxreg joined,
timotimo joined,
sivoais joined,
avar joined,
yoleaux2 joined,
jnthn joined,
camelia joined,
nwc10 joined,
[Coke] joined,
harrow joined
23:07
moritz joined,
ggoebel joined,
nebuchadnezzar joined,
pyrimidi_ joined,
diakopter joined,
brrt[idle] joined,
japhb joined,
mst joined,
hoelzro joined,
stmuk_ joined,
zostay joined,
ilmari joined,
arnsholt joined
23:08
Util joined,
BinGOs joined,
Dunearhp joined,
geekosaur joined
23:11
ChanServ joined
23:12
TimToady joined
23:13
sivoais joined
|
|||