|
github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today Set by moderator on 9 May 2018. |
|||
|
01:55
zakharyas joined
01:57
ilbot3 joined
|
|||
| moderator | github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today | ||
| nine | .tell brrt scanning the stack might be just a heuristic, but at least you should be able to determine if the result is correct with very high probability. After all if you found the right addresses your chain must end at a known address (the JIT entry point) within a finite (and usually rather low) number of steps. | 06:57 | |
| yoleaux | nine: I'll pass your message to brrt. | ||
|
07:39
robertle joined
08:39
unicodable6 joined,
nativecallable6 joined,
undersightable6 joined,
greppable6 joined,
statisfiable6 joined,
quotable6 joined,
squashable6 joined
|
|||
| samcv | timotimo: i would store the strlen in a variable and then call strncpy with the value | 08:41 | |
| since you are mallocing data. you don't want to copy longer than you allocate. so strncpy is still a good idea since you know how long your malloc's data is | 08:42 | ||
| Geth | MoarVM: a93f62a430 | (Samantha McVey)++ | src/profiler/telemeh.c Store the size we malloc and use it with strncpy Since we already know how much we have allocated, use that instead of calling strlen again. |
08:46 | |
| samcv | anyway i've made those changes | ||
|
09:02
travis-ci joined
|
|||
| travis-ci | MoarVM build failed. Samantha McVey 'Store the size we malloc and use it with strncpy | 09:02 | |
| travis-ci.org/MoarVM/MoarVM/builds/377186539 github.com/MoarVM/MoarVM/compare/c...3f62a43049 | |||
|
09:02
travis-ci left
|
|||
| samcv | not sure why that test failed. everything passed | 09:06 | |
| ah i see it got a segfault? | |||
|
09:08
FROGGS joined
09:09
brrt joined
|
|||
| brrt | \\o | 09:12 | |
| yoleaux | 06:57Z <nine> brrt: scanning the stack might be just a heuristic, but at least you should be able to determine if the result is correct with very high probability. After all if you found the right addresses your chain must end at a known address (the JIT entry point) within a finite (and usually rather low) number of steps. | ||
| brrt | nine: noted, and I agree, but | ||
| i figured out a better solution | |||
| one that doesn't need stack or walking at all | |||
| see | |||
| all that we are after is the location of the return address into the JIT frame | 09:13 | ||
| by processor semantics, we know exactly where that is going to be placed; 8 bytes down from the position of %rsp, at the point where we do the call instructoin | 09:14 | ||
| provided we never do a push or pop, which is easy to ensure, we know exactly what that is, because it is completely under our control | 09:15 | ||
| jnthn | :) | 09:19 | |
| brrt | we also don't need to walk the stack, and we also don't need to keep the frame pointer arround. this solution has literally no drawbacks at all | 09:20 | |
| so the idea is to take a pointer to where I know the return address will be, and assign that to a field in the threadcontext. this field will then also function as a reliable way to answer 'are we currently executing in the JIT' | 09:23 | ||
| so. thanks for bearing with me :-) | 09:25 | ||
| huh, did you know the terminal interprets C-m as a newline? | |||
| Geth | MoarVM/jit-moar-ops: 4 commits pushed by (Elizabeth Mattijsen)++, (Samantha McVey)++, (Bart Wiegmans)++ | 09:26 | |
| brrt | .tell lizmat i'll review the ctxlexpad later today | ||
| yoleaux | brrt: I'll pass your message to lizmat. | ||
|
09:31
ilmari[m] joined
09:36
committable6 joined
|
|||
| samcv | though we should figure out what is segfaulting. i think it was introduced a few days ago when lizmat merged some of the JIT ops? unless it's unrelated | 09:37 | |
| Geth | MoarVM: a87a8791c5 | (Samantha McVey)++ | src/platform/memmem32.c Implement memmem_two_uint32, up to 45% faster index of short 32bitstr In cases where the first grapheme is found throughout the haystack this can speed things up by indexing by two graphemes at the same time. To do this we index two graphemes at a time which prevents us from finding needles of short strings in the wrong location. Worst case it is about the same speed on 64 bit systems. May be slower on 32-bit systems which ... (5 more lines) |
09:40 | |
| MoarVM: 48cdf3d66e | (Samantha McVey)++ (committed using GitHub Web editor) | src/platform/memmem32.c Merge pull request #856 from samcv/memmem_two_uint32 Implement memmem_two_uint32, up to 45% faster index of short 32bitstr |
|||
|
09:57
travis-ci joined
|
|||
| travis-ci | MoarVM build passed. Samantha McVey 'Merge pull request #856 from samcv/memmem_two_uint32 | 09:57 | |
| travis-ci.org/MoarVM/MoarVM/builds/377201967 github.com/MoarVM/MoarVM/compare/a...cdf3d66e73 | |||
|
09:57
travis-ci left
10:06
brrt joined
10:11
AlexDaniel` joined,
wictory[m] joined
|
|||
| brrt | samcv: agreed.... if you know *what* is segfaulting, i can help you point jit-bisect to it | 10:36 | |
| i can also do it, but i kind of want to share that knowledge :-) | 10:49 | ||
| Geth | MoarVM/jit-stack-walker: 12 commits pushed by (Bart Wiegmans)++ review: github.com/MoarVM/MoarVM/compare/a...20dab94da5 |
10:50 | |
|
11:27
brrt joined
|
|||
| samcv | brrt: well lizmat said she was getting occasional segfault on t/spec/S01-perl-5-integration/basic.t but i cannot reproduce | 12:00 | |
|
13:11
zakharyas joined
13:17
AlexDaniel joined
|
|||
| brrt | on linux, maybe? hmm | 13:44 | |
|
14:12
samcv left,
samcv joined
16:13
brrt joined
|
|||
| Geth | MoarVM/jit-stack-walker: 16f0372a88 | (Bart Wiegmans)++ | 8 files [JIT] Add pointer to return address, remove stack walker It turns out not to be necessary to search the stack for the return address, because as we compile the JIT code frame, we know exactly where the future return address will end up (namely, just beyond our current stack frame). Provided we never use 'pop' and 'push', we can just store the pointer to this address in the thread context, and read our current ... (6 more lines) |
16:14 | |
| brrt | i'll have to see if this works on windows later | ||
| but i suspect that it will :-) | |||
| and. i may be wrong :-( | 16:51 | ||
| TimToady | doesn't matter, since Microsoft says it's no longer about Windows, it's now all about The Cloud... :) | 16:53 | |
| brrt | and the cloud is linux anyway | 17:04 | |
| jit bisect blames the expr jit :-o | 17:06 | ||
| that was unexpected | 17:23 | ||
| ok, i think it's because we can emit a push. | 17:58 | ||
| but why would we do that? | |||
| no, that's unlikely. the push/pop instructions are in the data section | 18:00 | ||
| Geth | MoarVM: 1aa02fe45e | (Bart Wiegmans)++ | tools/jit-bisect.pl [Tools] Unbreak jit-bisect.pl Wrong variable names were left over, oops |
18:13 | |
|
18:21
undersightable6 joined,
quotable6 joined,
squashable6 joined,
statisfiable6 joined,
greppable6 joined,
nativecallable6 joined,
unicodable6 joined,
committable6 joined
19:25
MasterDuke joined
20:15
Ven`` joined
|
|||
| MasterDuke | samcv, timotimo: the warning in telemeh.c is still there (see gist.github.com/MasterDuke17/b4f5b...8ad46bc138 ) | 21:00 | |
| yoleaux | 10:57Z <[Tux]> MasterDuke: --20 versions do not store their timings | ||
| 11:12Z <timotimo> MasterDuke: hack.p6c.org/~timo/test-t-20-timings.txt | |||
| MasterDuke | i don't think samcv's change really changed anything. i assume the warning/problem is because if `description` wasn't null-terminated, the `strlen(description)` call is problematic, regardless if the result is stored in a variable or not | 21:04 | |
| timotimo | that makes sense | 22:00 | |
| Geth | MoarVM/pluggable-spesh: 449e96c3ee | (Jonathan Worthington)++ | src/spesh/plugin.c Correct instruction size in deopt target calc |
22:10 | |
| MoarVM/pluggable-spesh: 5fa3908b92 | (Jonathan Worthington)++ | src/spesh/plugin.c Implement spesh plugin type guard deopt |
|||
| MoarVM/pluggable-spesh: 31462230ec | (Jonathan Worthington)++ | src/spesh/plugin.c Clear up plugin state on resolver exception |
22:30 | ||
| MoarVM/pluggable-spesh: 33ace0dc5c | (Jonathan Worthington)++ | src/spesh/plugin.c Implement spesh plugin concrete/type object deopt |
|||
|
22:42
lizmat_ joined,
nebuchadnezzar joined
22:43
Kaiepi joined
22:48
Kaypie joined
22:49
nebuchadnezzar joined
22:51
jpf1 joined
23:10
yoleaux joined
23:40
quotable6 joined,
nativecallable6 joined,
squashable6 joined
23:41
undersightable6 joined
|
|||