02:34 vendethiel joined 03:16 kjs_ joined 05:46 TimToady_ joined 08:44 domidumont joined 08:49 domidumont joined 10:51 vendethiel joined 11:16 leont joined 11:27 18WABBFX8 joined 12:32 nebuchadnezzar joined 12:44 kjs_ joined
timotimo jnthn: frame.c has the instrumentation level barrier check if the levels are unequal. if they are, it sets to the instances current instrumentation level and then only does a single instrumentation; is that correct? perhaps we want to make profiling, cross-thread-writing, and coverage reporting to be mutually exclusive 12:55
13:41 moritz_ joined, arnsholt_ joined, ashleydev joined 13:42 Util joined 13:45 vendethiel joined
timotimo there seems to not be a precedent yet for allocating objects during a spesh or instrumentation phase. but i expect it'll be all right 13:45
13:55 kjs_ joined 13:57 ilmari joined
jnthn timotimo: We assume during spesh that we won't allocate, fwiw 14:21
(That's relied on in various places) 14:22
timotimo oh, good to know 14:24
14:24 vendethiel joined
timotimo how do i allocate a spesh slot that a later op can then allocate an object into? 14:24
can i just set it to 0 and later change the effective_spesh_slots array? 14:25
jnthn I...guess 14:27
timotimo i'm trying to give each spesh graph a little BOOTIntArray where it stores if a given line has already been reported
it feels icky; it looks like you agree :)
jnthn On the instrumentation: yeah, we don't have a story on composing those yet. It's a hard problem, so I decided to just leave it :)
For when there's time :) 14:28
timotimo right. i wasn't expecting it to be easy to just instrument one after the other
i could just go full insanity mode and use malloc to allocate that BOOTIntArray
jnthn You usually only use one or the other anyway
timotimo yeah, who would profile *and* coverage-analyze
jnthn You're not actually doing anything with spesh, just writing an instrumentation? 14:29
timotimo and if you expect things to blow up because of threadedness trouble, you wouldn't run a coverage log either
that's right
jnthn ah
Then at least if it busts it's low-impact :)
timotimo it puts a reporting op after each bb's batch of PHI ops
hehe.
then i'll keep the current way until i find it breaks
14:30 virtualsue joined
timotimo it'll be running against the spec test suite, so it'll have plenty of work and opportunity to asplode 14:30
if i pre-size that array at instrumentation time to hold all possible reportable numbers, it'll not be trouble to access the BOOTIntArray concurrently either!
i'm starting to think this isn't going to suck terribly :) 14:32
jnthn :)
timotimo cool. tc is null. that's new. 14:43
timotimo builds with 0 optimization
huh. effective_spesh_slots is 0 14:44
well, that's not so nice 14:45
dalek arVM/line_based_coverage: 5795ee0 | timotimo++ | / (11 files):
first prototype of a per-line coverage reporter
 14:46
timotimo maybe it's something obvious that makes that happen. it occurs when the interpreter hits the coverage_log instruction 14:47
or perhaps it's impossible to use spesh slots from instrumentation because it neglects to set up ... something? 14:50
perhaps because it kicks out all spesh candidates after instrumenting? and perhaps that makes the spesh slots disappear, too? :\ 14:57
jnthn: maybe you can figure something out, i'll be AFK for a bit 14:59
15:20 ilmari joined 15:28 camelia joined 15:39 flussenc1 joined 15:55 flussence joined 16:07 kjs_ joined
JimmyZ so jvm has less than 300 opcode and we have more than 750 opcode? ;) 16:09
16:36 dalek joined
jnthn JimmyZ: Did you count all of their VM-implemented methods too? 16:57
JimmyZ jnthn: I didn't , but I know they have special VM-implemented methods 17:02
jnthn Right, so you need to count those too to get a fair comparison.
timotimo jnthn: got a clue about the disappearing spesh slots? 17:07
jnthn Oh... I guess it's that instrumenation does not actually go through the full spesh pipeline. 17:11
timotimo right
jnthn Otherwise we'd think instrumented frames were already specialized.
timotimo but i can do it for this one?
jnthn Um...not...easily... 17:12
timotimo OK, so i'll use malloc instead of the gc to alloc those arrays? :P
jnthn Or I can't see an asy way :(
Yeah, that'd do it
17:13 flussence joined, vendethiel joined
timotimo grmbl. we don't have a GET_I64 17:21
oh, we do 17:23
it's just named differently
hm. my MVMArray isn't being set up right, it seems 17:38
body->slots ends up being a null pointer 17:40
but body->elems is set to 1 17:41
.o( if we only have 1 element, we could totally store that in the body pointer! what a fantastic space saving idea!!)
oh, i have to use zeroed alloc 17:45
malloc*
i forgot malloc doesn't do that for you :)
that's a silly mistake to make :) 17:46
ho-hum. a segfault in "goto NEXT" 17:49
17:51 domidumont joined
timotimo my instruction is defined to be str int32 int32 int64 and i do cur_op += 20; that should be right, right? 17:52
haha. in my last commit i forgot to add the new files 17:55
dalek arVM/line_based_coverage: 6a7c350 | timotimo++ | / (6 files):
add missing files, adjust op to not use spesh slot

since instrumented frames are actually not fully speshed, and can't easily be, we have to rely on a literal int64 as a pointer to the line report store and allocate it without involving the GC, so it won't move.		 17:57
timotimo oh! it's because i'm corrupting jumplists! 18:01
hum. 18:08
my jumplist detection code doesn't work here 18:09
there isn't actually a jumplist, so the bytecode itself must have been corrupted or something? 18:10
oh. my conclusion about jumplist not being there might well be wrong 18:13
as i used the spesh log, but that only triggers when frames get considered hot
whoa, ouch. num_preds is 0 for all those BBs? 18:17
jnthn timotimo: I think we may compute those as part of SSA
And if you just copied the profiler code, it knows it doesn't need that analysis doing 18:18
timotimo right, that'd make sense
:)
i did copy that! :)
jnthn So simply asks for a CFG without SSA applying.
timotimo if i can rely on all blocks following the jumplist to be chained in linear_next properly, i can just skip them that way
ho-hum. 18:20
now i just don't instrument bbs that have exactly one instruction which is a goto
and that gets me to ===SORRY!===
No lexical found with name 'decints'
damn. const_iX NYI; so i'm creating bogus bytecode here 18:22
neato! i have something that survives a simple "say 'hi!!'" 18:25
next step is to throw out the BOOTIntArray and use a little chunk of memory instead, to make the impact a bit less severe 18:31
dalek arVM/line_based_coverage: 479e645 | timotimo++ | src/instrument/line_coverage.c:
properly skip over jumplists
 18:34
arVM/line_based_coverage: 0d94be2 | timotimo++ | src/ (3 files):
use a blob of memory instead of BOOTIntArray

this ought to make things a bit less expensive.		 18:56
Heuristic branch merge: pushed 35 commits to MoarVM/even-moar-jit by bdw 19:29
timotimo ohai brrt
19:39 brrt joined
brrt ohai timotiom 19:40
i was actually just pushing something i'd merged earlier :-)
timotimo oh, ok 19:41
you know how happy i am every time i see you commit stuff ;)
i'll be afk for half an hour now, after that i'll teach spesh to kick out coverage reports that have already fired before we hit the spesh and that'll allow a few frames to be jitted again 19:42
but i'm running a full spec test run at the moment, collecting all coverage reports with tail -f on the one file and putting the result into another file
it's already 300 megabytes big :)
brrt wow :-o 19:45
anyway, i maybe get some work down on the tiler linearisation tomorrow 19:47
i hope :-)
see you!
jnthn o/ brrt
timotimo \o/ 20:12
20:37 JimmyZ joined 21:49 leont 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!