|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
02:05
lucasb left
02:26
Kaiepi joined
05:33
evalable6 left,
linkable6 left
05:34
linkable6 joined
05:35
evalable6 joined
06:38
Altai-man joined
07:57
sena_kun joined
07:59
Altai-man left
08:19
domidumont joined
08:43
domidumont left
09:09
domidumont joined
09:24
domidumont left
|
|||
| Geth | MoarVM: f9d33d2d0a | (Nicholas Clark)++ | src/core/str_hash_table.h Fix a typo in a comment. |
10:03 | |
| nwc10 | good *, #moarvm | ||
| MasterDuke | happy boxing day (new holiday for me, but when in England...) | 10:18 | |
| nwc10 | yes, England. :-) | 10:21 | |
| Scotland does Jan 2nd instead, IIRC. | |||
| MasterDuke | over the past couple days i've been trying to disablea spesh optimization using essentially pre-existing mechanisms, but haven't succeeded | 10:22 | |
| Geth | MoarVM/hash-delete-corner-case: 15e7fc2fab | (Nicholas Clark)++ | 2 files Fix a potential bug when all elements are individually deleted from a hash. Two optimisations were coming together in an unforeseen way, which could cause an assertion failure on a debugging build. There's a space optimisation for empty hashes which only allocates the control structure, and flags this with both `cur_items` and `max_items` ... (26 more lines) |
||
| MasterDuke | so maybe i can't use these mechanisms to just test the heuristics of when an optimization should be removed (the eventual reason for making MVMSpeshCandidate a REPR, i.e., GC-able) | ||
| Geth | MoarVM: nwc10++ created pull request #1410: Fix a potential bug when all elements are individually deleted from a hash |
10:23 | |
| MasterDuke | huh, i've never heard that about scotland | ||
| nwc10 | Northern Ireland, England & Wales and Scotland have slightly different holidays. | 10:24 | |
| and strictly I've been told that different parts of Scotland can end up with different holidays, but I've not double checked this (or lived there to know this) | 10:25 | ||
| MasterDuke | heh. of course they do | ||
| nwc10 | anyway, next bug to fix - "ENOCOFFEE" | 10:26 | |
| MasterDuke | so instead i need to jump straight to actually removing an optimization. but currently i don't think a mechanism exists for that, they're just an array of MVMSpeshCandidates that's realloced when a new one is added, but i don't see anything about it shrinking | ||
| so am i going to have to alloc a new array of size - 1 and memcpy the two parts of the original into it? | 10:30 | ||
| gist.github.com/MasterDuke17/4b754...3fa1f94b19 has a current diff, plus my test case and the output it gives | 10:46 | ||
| nine | MasterDuke: sounds sensible, yes | 11:13 | |
| MasterDuke: I wonder: after you discard that spesh cand, how will you prevent the exact same one from getting created again? Or do we just hope that the new stats will be different anyway? | 11:14 | ||
| MasterDuke | nine: thanks, will have to work on that then | 11:15 | |
| and hadn't gotten that far, but yeah, i assume that a new/different optimization may happen | 11:18 | ||
| i guess there could be some pathological case where we bounce between creating an optimization, it not being valid anymore, deleting it, creating a new one, it not being valid because we're back to the code that triggered the first optimization, etc | 11:20 | ||
| should probably teach the profiler or spesh log to record when an optimization is removed | |||
|
11:56
Altai-man joined
11:59
sena_kun left
|
|||
| timotimo | we're hoping in general that when a specialization runs out its usefulness it won't come up again very soon | 14:30 | |
| like when you compiled your script or program, a bunch of stuff in the compiler will have been specialized, but won't be used again | |||
|
14:36
domidumont joined
|
|||
| MasterDuke | hm. my example goes from 690398 deoptimizations to 928 deoptimizations, but runtime doesn't seem to be improved | 15:34 | |
| gist.github.com/MasterDuke17/3cb47...68b5343269 current status of the patch if anyone is curious | 15:39 | ||
|
15:53
dogbert17 left
15:57
sena_kun joined
15:58
Altai-man left
16:23
dogbert17 joined
|
|||
| MasterDuke | nqp build dies though | 16:29 | |
| timotimo | the positioning of a deopt relative to the end of a frame is quite important | 17:58 | |
| MasterDuke | the backtrace of the segv usually includes MVM_spesh_candidate_add -> MVM_spesh_arg_guard_regenerate | 18:02 | |
| timotimo: not sure what i'm missing (code-wise), any suggestions? | 18:05 | ||
| timotimo | huh | ||
| can you give a full stacktrace? | 18:06 | ||
| MasterDuke | gist updated | 18:07 | |
|
18:07
Kaiepi left
|
|||
| timotimo | i wonder, do we set cand->discarded when we throw it out? | 18:21 | |
| does the guard tree keep candidates alive through marking? | 18:22 | ||
| will valgrind or asan tell us what the memory used to be that it's trying to access, and why it was tossed out? probably just in gc_free, though | 18:32 | ||
| MasterDuke | setting the dropped cand to discarded doesn't change anything... | 19:01 | |
| afk for a bit, but gist updated with valgrind output | 19:17 | ||
|
19:56
Altai-man joined
19:59
sena_kun left
22:11
Altai-man left
|
|||