00:13 klaas-janstol joined
jnthn sleep & 00:19
00:25 klaas-janstol joined
TimToady $ perl6-m -e 'my $i = 0; while $i < 262145 { ++$i }' 00:34
Segmentation fault
that might be easier to trace
replaceing ++$i with $i = $i + 1 gets back to the Invalid SC index in bytecode stream 00:36
klooer: low numbers don't segfault, but binary search for a sharp boundary fails at about: perl6-m -e 'our $i = 1; while $i < 154745 { ++$i }' 00:42
at that number, it fails approximately 50% of the times I run it on my machine, so perhaps GC pressure 00:46
never fails at 153000, always fails at 155000
00:48 dalek joined
TimToady 154700 seems to fail about ¼ the time 00:54
154900 fails about ¾ the time 00:56
japhb Interesting that it is not a sharp transition 00:58
TimToady so some kind of normal curve with mean at about 154800, with a sigma on the order of magnitude of 100
yeah, I thought so 00:59
I was expecting it to fail at the short to long int transition, but no
how does that number compare to nursery size? 01:00
but you'd think this would be more predictable if it were related to some fixed allocation size 01:01
japhb Dunno for sure. I'd probably go look at the last time jnthn calculated savings in terms of GC runs ... but of course, there's probably a constant somewhere. :-)
TimToady it's almost like it's related to something that's allocated based on how much memory we think we have available instantaneously 01:02
but I dunno if we do that
what other possible sources of noise are there?
does Mersenne Twistor take a variable number of startup resources? 01:03
japhb Race/missing write barrier/etc. in GC code itself?
Wait, does the process seem to leak at all? Or is it too fast to notice? 01:04
TimToady fails very quicly
I suppose if we'd just run gdb on it, we'd've found the problem by now :)
but it's more fun to guess 01:05
not very interesting without debugging info: gist.github.com/anonymous/fb0951ec83f86812783f 01:10
but somewhere inside of MVM_fixed_size_alloc_zeroed, 10 levels up 01:11
well, I'll let someone else pursue it from here 01:12
01:28 FROGGS__ joined
diakopter if it's beneath MVM_fixed_size_alloc_zeroed, that's the GC, for sure 03:06
or above, if you're declined that direction 03:07
03:13 colomon joined, lue joined, daxim joined, ingy joined, retupmoca joined, FROGGS__ joined, sergot joined, ashleydev joined, avuserow joined, TimToady joined
diakopter if it's beneath MVM_fixed_size_alloc_zeroed, that's the GC, for sure 03:15
or above, if you're declined that direction
08:44 danaj joined 08:53 brrt joined
brrt diakopter: (in response to your question from last night): set the environment variable MVM_JIT_BYTECODE_DIR 08:53
timotimo brrt: good to see you're here!
brrt i'm backlogging :-)
timotimo i'm just now trying to implement ~assertparamcheck in the jit 08:54
brrt assertparamcheck?
timotimo would you like to tell me if i did it rong?
brrt let me see that
i saw there was a bugyesterday
timotimo because it gives an "inconsistent bind result" now in the restricted setting
gist.github.com/timo/ccf81437e03e276d8a88 08:55
brrt no, that's not quite right yet 08:56
you're missing the argument to MVM_args_bind_failed
i.e. | mov ARG1, TC; 08:57
timotimo oh! tc! 08:58
of course
brrt also.. you want to call MVM_args_bind_failed if ok is zero, right?
timotimo one thing i was especially wondering about: how do i make sure it all works properly with exception throwing
if (!ok) { args_bind_failed }
brrt which means that you want to jump over it if TMP1 tests /nonzero/
so you'll want to use jnz rather than jz 08:59
lastly, for adhoc exceptions, you don't need to do anything
timotimo oooh
brrt adhoc exceptions don't return to the JIT, they return directly to the interpreter
via longjmp
timotimo i see! 09:00
but
brrt the :throwish is for regular exceptions that assume they return to the interpreter
timotimo how does that handle stuff like the instruction pointer?
OK, so i'll remove :throwish
brrt basically 'handle the instruction pointer' is a much longer answer than the question :-) 09:01
but the gist of it is this
when you throw an exception, it is handled by a handler
that handler is either a JIT code handler or a interpreted code handler
depending on the frame
timotimo the thing is that the interpretation version increases the IP before it calls the error raising function 09:02
brrt that is of no significance to us
timotimo OK, great!
brrt basically, it does this to deal with handlers correctly 09:03
timotimo i'm going to learn a tiny bit about x86_64 assembly!
a friend told me about x86_64 long mode
where everything is beautiful
brrt but the jit_entry_label is updated every 'handler border'
x86_64 isn't so bad :-)
timotimo now building rakudo works again :) 09:04
timotimo makes a spectest run
brrt is only a little bit stuck on the param_* stuff because he'd like to remove a few switches 09:06
as in, this is a very common path
making it faster = better
timotimo well, making it implemented at all would make stuff faster, too, but it's entirely up to you :) 09:08
the spectests look quite good 09:10
dalek arVM: c053c8d | (Timo Paulssen)++ | src/jit/ (2 files):
assertparamcheck implemented in the jit, yay
 09:12
brrt shall i tell you the funny secret about that
timotimo sure :)
09:13 klaas-janstol joined
brrt posix x64 says 'hey, the MVMArgInfo struct is less than 16 bytes wide. we can stuff that into rax/rdx and be done' 09:13
windows says: 'tis a struct. ye shall allocate a pointer and read from there' 09:14
timotimo %)
excellent
is there something that'd make implementing getlex_no hard for me? 09:16
brrt let me see 09:17
it's not implementable as a c call per se 09:18
timotimo 358 bails across the setting compilation nowadays
48 of which are getlex_no
brrt oh that's not a lot anymore
timotimo 407 across tadziks test run of steroids on moar-jit
nwc10 the current fun is setting bail out whack-a-mole?
timotimo :)
the setting is too big to fail!
timotimo throws bailouts 09:19
brrt basically, you'll want to implement the found ? found->o : NULL as: test RV, RV; cmovnz RV, [RV]; mov WORK[dst], RV; 09:21
why? if RV is NULL, cmovnz will be skipped, whcih means you'll assign NULL] 09:22
if RV isn't NULL, RV will be dereferenced, and you'll assign the object
timotimo the oooh, conditional move not ero
brrt yes, they're very handy for precisely this situation :-) 09:23
also take a look at the get_string macro
timotimo oke :3
er ... dumb question probably, but how do i set a register's value to the value of an integer i know at dynasm-compile-time? 09:34
... a literal, so to speak
brrt is this a 64 bit literal? 09:40
normally it's just mov register, literal
but a 64 bit literal would be mov64 register, literal
literal /must/ be an integer, by the way, cast that way if necessary 09:41
also
what compiles
ehm
what allocates a fixed frame from the JIT
timotimo uint16 actually 09:46
brrt oh, in that case, you can pass it as is 09:48
timotimo oke 09:50
it builds and spectests fine so far
brrt i'm wondering what caused the jit bug from yesterday 09:51
timotimo you mean theempty while loop that asplode? 09:52
the s17 tests seem a bit too sad ... 09:53
dalek arVM: 28738a6 | (Timo Paulssen)++ | src/jit/ (2 files):
implement getlex_no in the jit
 09:54
brrt yes that 09:57
much timotimo++
timotimo oh that was nothing! :P 10:01
10:01 FROGGS[mobile] joined
timotimo er, also wrong 10:01
dalek arVM: 857f244 | (Timo Paulssen)++ | src/jit/emit_x64.dasc:
fix a copy-pasto.
 10:02
brrt lunch &
timotimo you almost did all of the work
S17 seems very unhappy indeed ... not sure if it's the changes i made :\ 10:07
nwc10 NQP build from clean fails 10:12
963 MVMFrame *cur_frame = tc->cur_frame; 10:13
(gdb) p tc
$1 = (MVMThreadContext *) 0xfc80
10:13 zakharyas joined
nwc10 #0 0x00007ffff65be972 in MVM_frame_find_lexical_by_name (tc=0xfc80, name=0x627000017e90, type=8) at src/core/frame.c:963 10:14
#1 0x00007ffff1d5f454 in ?? ()
#18 0x00007fffffffc810 in ?? ()
#19 0x00007ffff674bf76 in MVM_jit_enter_code (tc=0x7fffffffe000, cu=0x7fffffffe040, code=0xffffffffc12) at src/jit/compile.c:123
...
jnthn Hm, that's called by getlex_no 10:25
That tc pointer looks hosed
11:09 timotimo joined 11:15 brrt joined
brrt yes 11:18
hmm
but the code looks pretty good
haha i see what it is 11:19
much subtle, such bug 11:20
| mov ARG1, tc
jnthn get_string uses ARG1? :)
brrt see it? 11:21
no
jnthn oh
That's the local tc
brrt uhuh
passed as a 32 bit number
while it is a 64 bit pointer
jnthn Should be TC, I guess? 11:22
brrt yeah
brrt is testing the fix
dalek arVM: e6c5f48 | (Bart Wiegmans)++ | src/jit/emit_x64.dasc:
Use TC from register rather than from variable :-)
 11:23
brrt interesting slides (the pitfualls of object oriented programming thingy) 11:28
brrt wonders if we can't make a compiler 'sufficiently smart' (tm) to make such transformations by itself 11:29
OT: vodafone computes that with 35 MB, you can check facebook a whopping 70 times 11:33
(facebook uses .5MB per update reqeust? WOW) 11:34
lizmat yes, FB uses inordinate amounts of data
we burned ~600 MB in the US in 10 days 11:35
I expect 550MB of that to be from FB
brrt as a way of comparison, you can send (again according to vodafone) 3500 whatsapps with the same amount of data 11:36
brrt resists making a perl/php joke out of this
tadzik whatsapp is perl? 11:37
brrt whatsapp is partially perl 11:38
perl, erlang, c++ iirc
on freebsd
tadzik nice
brrt bbi2h 11:39
sergot o/ 11:51
tadzik \o 12:04
timotimo is back, too 12:42
tadzik: would you like to generate a new jit log with an up-to-date moarvm/master? :) 12:43
33 + 28 bails havehad their op implemented and a few others by not using master when you made the log you missed at least all the bigint ops 12:44
12:47 cognome joined
timotimo about 24 bails would be gone or pushed back due to the bigint ops 12:48
tadzik timotimo: sure :) 12:49
timotimo also 5 bails from existspos
tadzik oh, so now I need to have some rakudobrew trickyness
to actually fetch moarvm head 12:50
timotimo --gen-moar=master
tadzik that'd be --gen-moar=...right
timotimo would be all you'll need
also, nan and inf are bailing somewhere in your code, these are just calls to MVM_num_{nan,inf}, so i can implement them soon, too 12:51
but first: benchmark analysis time!
12:55 ggoebel1111119 joined
tadzik timotimo: yay, didn't segfault :)| 13:05
feather.perl6.nl/~tjs/foo2.txt
tadzik off to fetch some food 13:06
timotimo about 30 bails less, so many of those bails have just moved further into the frame 13:15
16 more param_ns for example 13:17
tadzik so, certain frames are still not jat because some of the ops are missing, right? 13:46
13:48 brrt joined
timotimo yes 13:48
seems like i'm not built for writing assembly code ... 13:59
brrt: gist.github.com/timo/4dc3eb65b316b9adfc3c - can you have a look?
i think this should be correct
but it breaks spectests 14:01
it could be that iscont just makes some frames suddenly get jitted that didn't get jitted before and iscont is correct, but some other op isn't ... 14:02
that would be great
brrt that doesn't mean it's broken
yeah, i think this is correct
not optimal, but correct
timotimo i know there's some kind of "setz" and "setnz" opcodes 14:03
jnthn brrt: Been looking at the SEGV in the benchmarks
timotimo that i could have used, but i think i would have had to branch anyway
brrt jnthn: yes?
TimToady++ found a pretty quick way to replicate it iirc
jnthn Yeah
I'm looking at the disassembly
I'm fairly sure I'm looking at
|.macro get_string, reg, idx
| mov reg, CU->body.strings;
| mov reg, STRING:reg[idx];
|.endmacro
The output of this
reg ends up NULL after the first thing 14:04
CU is a GC-able object
brrt o rly
jnthn Yes.
brrt ehm
oops
how is that
timotimo hehe
brrt why is that
i don't even
timotimo we're not rooting the CU from a jitted frame?
brrt hmmm 14:05
this is annoying
jnthn Well, because we'd rather like eval to not leak memory for one :)
timotimo yes, pretty please
brrt ok 14:06
hmmm
so if you'd call eval a bunch of times, this should break
timotimo brrt: in what way should i improve my assembly code for iscont? 14:07
brrt timotimo: basically, you can use setnz and cmovnz to not jump
not jumping is awesome
timotimo oh! 14:08
of course, conditional mov!
brrt yes, it does make things more compilcated though
timotimo i think i can handle that, it'll be fun!
brrt :-) 14:09
timotimo i have a solution, not sure if it's correct, though 14:10
dalek arVM: de91a91 | jnthn++ | src/core/compunit.c:
Force compunits to be gen-2 allocated.

This means they won't move - something the JIT chose to rely on.
brrt hmm jnthn, there is of course another solution :-) 14:11
(not that i mind this solution)
timotimo gist.github.com/timo/414f465df7efa622148b
jnthn brrt: Yeah, but I doubt it's less lines of code than mine ;)
brrt hmm yeah, that's true 14:12
also having CU in the register is /really/ handy for all sorts of things
jnthn Right
It wasn't a bad choice in the JIT; just wasn't a safe one until the above patch :) 14:13
brrt fair enough. i had assumed the CU to be an immutable thing, but that's obviously not true in eval()
timotimo oh, it seems like setnz needs an extend register value roperation or something 14:18
movzx 14:19
brrt yes
timotimo the failure mode is the same a sbefore 14:20
jnthn Grrrr
Allocating the cu in gen2 seems to cause some other fails 14:21
brrt o? how is that? earlier fails?
dalek arVM: 0bb7430 | (Timo Paulssen)++ | src/jit/ (2 files):
implement iscont with clever non-branching strats
 14:23
timotimo this looks good?
brrt reading :-)
yes 14:24
nice :-)
jnthn: i think you said deopt_all spesh annotations would be transformed to deopt_inline in inlines? 14:26
jnthn brrt: I think so 14:36
brrt ok, hmm
dalek arVM: d6365b0 | jnthn++ | src/core/compunit.c:
Fix inter-generational issue with CU/HLLConfig.
jnthn brrt: Well, it's more that it doens't have much info left about what kind of deopt index it was 14:37
brrt that may be an issue for my current setup
i.e. i may have to move the 'is this a deopt all idx' thingy back to the invocation node creation function
14:42 zakharyas joined
brrt that, or not care that we sometimes add deopt idx labels without a good reason 14:43
timotimo do we do jit-only version bumps? 14:44
jnthn brrt: Maybe not caring is good enough for now? :) 14:45
My 2 patches seem to have dealt with the perl6-bench SEGVs
timotimo nice. 14:46
but now spectests fail pretty hard, like t/spec/S02-types/sethash.rakudo.moar
and i don't quite know what to look at to figure it out
brrt yeah, i agree with the not caring
nwc10 PASS at de91a91 (apart from sin) 14:47
jnthn nwc10: Oddness; it bust things like Panda builds...
brrt const_iX NYI whut 14:48
timotimo we don't have smaller int registers at all
jnthn That tends to mean "jumped to a bogus spot of bytecode"
nwc10 I don't think that I did anything stsupid
jnthn nwc10: Was it with --enable-jit?
nwc10 exactly. I need to check. 14:49
jnthn nwc10: It's quite possible the spectests didn't trigger it. It got a good way into the Panda build before exploding here
nwc10: HEAD seems good to me, though.
nwc10 ah sigh. It's getting like Perl 5
there's regression tests.
and then there's stuff that breaks for a clean build, even though the regression tests all pass
jnthn nwc10: Note I didn't try the spectests locally before patching the issue; some may have failed here for me too 14:50
nwc10 and then there's also stuff out in the ecosystem that neither the regression tests nor a clean build spot
timotimo trouble is that the jit only kicks in on hot code and our spectests are mostly do things only a few times 14:51
times*
jnthn Yeah. I think one thing we may want is a JIT_ALL_THE_SHIT envvar that sets the thresholds to zero. 14:52
Or close to zero
nwc10 or the sort of politer version - the tellytubbie flag 14:53
("again again")
jnthn MVM_TELLYTUBBIE 14:55
That'd really force us to document the envvars :P 14:56
brrt true 14:57
hmm
adding an extra label makes for ugly crashes
timotimo well, you need to ++ the index, too 14:58
brrt hmm? 15:00
brrt no comprendre
timotimo i was trying to give you a sufficiently vague tip so that you wuld be forced to think about a different possible cause for the issue and maybe help you find the problem faster that way 15:01
brrt :-)
thank you
brrt afk for a bit 15:03
TimToady finds that being vague works frequently that way, but maybe it's just because other people are so smart around here... :) 15:04
timotimo has an implementation for guardconttype 15:35
luckily it was almost a complete copy-paste from guardcontconc
nwc10 JIST spectest now somewhat unhappy
t/spec/S03-operators/bag.t t/spec/S02-types/mix.rakudo.moar t/spec/S03-operators/set.rakudo.moar t/spec/S02-types/mixhash.rakudo.moar spin the CPU, but steady on RAM 15:36
had to kill them
other fails
eg t/spec/S32-temporal/DateTime-Instant-Duration.rakudo.moar
MVMArray: Can't shift from an empty array in method STORE at src/gen/m-CORE.setting:7380
...
jnthn um...which commit did that? 15:39
nwc10 will try to work out, but might be abducted by mealtime
no actual ASAN fail that I can spot 15:40
15:41 klaas-janstol joined
timotimo yes, many fails sadly :( 15:57
jnthn: the commit i did for iscont brought those fails to light
jnthn Yes, that's my conclusion too 15:58
Should probably spectest JIT additions before adding them.
timotimo i thought the conclusion was that iscont is correct, but something else is now enabled to fail 15:59
jnthn That still doesn't make it Ok to commit something that knowingly breaks spectest. 16:00
That's what branches are for.
timotimo oh
do you suggest i push the anticommit for iscont and continue that line of thought on a branch by cherry-picking the original commit again? 16:01
jnthn Yeah 16:03
dalek arVM: b6b37b2 | (Timo Paulssen)++ | src/jit/ (2 files):
add guardconttype, almost a 1:1 copy of guardcontconc.
arVM: 08c56b5 | (Timo Paulssen)++ | src/jit/ (2 files):
Revert "implement iscont with clever non-branching strats"

This reverts commit 0bb7430c030017d4ddb86bd210cf320b57cfde61.
It looks correct, but it leads to spectest fails, so i'm continuing the investigation on a branch.
jnthn Even reverting that only gets rid of the hang, not the Can't shift... 16:05
timotimo so i made even more boo-boo ...
jnthn Trouble is, going back further doesn't help either 16:06
maybe I need to re-build Rakudo
timotimo that would be bad :\
jnthn wtf, even going back to a commit 2 days ago has that broken... 16:08
timotimo er ... 16:09
there were changes to spectests recently
your rakudo is up to date i assume?
jnthn Yeah, and bag.t wasn't touched in a while 16:10
timotimo well... damn :\
jnthn 4th Aug, to be specific
timotimo augh.
t/spec/S04-phasers/init.t, t/spec/S17-lowlevel/lock.rakudo.moar, t/spec/S32-io/IO-Socket-Async.rakudo.moar and t/spec/S32-str/sprintf.rakudo.moar fail on moarvm/master for me 16:15
the fail in sprintf is "todos unexpectedly passed", though
jnthn well, wtf...
jnthn just realcleans everything 16:16
timotimo my apartment could use a good spring cleaning, too ...
jnthn OK, it was some local artefact, I think 16:23
master/master/nom now is just the usual handful of fails
timotimo good to know 16:26
jnthn Which means I can think about by next task for today, which is to unbust init.t 16:28
timotimo OK 16:29
jnthn Hm, I should chop some veg first...
timotimo i'm not really feeling like i'm helping anything by implementing those low-hanging ops
jnthn One suggestion: MATCH is not currently JITted. It may not be many ops off being, but it is very hot-path in parsing. 16:30
timotimo on the other hand, the bail summary for the setting now fits on a single screen
diakopter timotimo: nopaste it?
timotimo the summary? 16:34
can do
gist.github.com/timo/5adae0b84092d9055a3a 16:35
diakopter will the JIT be able to package its JITted routines into an SC on disk? (with the obligatory tables of offsets to pointers [and their relocatable identifying target addresses] that will need updating when it's loaded again?] 16:40
)
timotimo i suppose it could if you implement that :)
diakopter I'm asking if it's conceptually plausible.. next question is whether it'd be effective.. next question is feasibility.. next question is worth it.. 16:41
timotimo unfortunately, i can only guess :( 16:42
the pypy people always said "we'd rather make jit warm-up faster than do any kind of persistent jit" 16:44
diakopter jnthn: ^ your thoughts? 16:45
dalek arVM: 0be1b0f | (Timo Paulssen)++ | src/jit/graph.c:
isbig_I and join based on function calls.
 16:46
timotimo ^- spectests still in the known state
jnthn diakopter: Problem will always be trusting such a cache 16:48
diakopter: It'll be a nuisance to implement fixing up stuff too
japhb So I was trying to understand why I haven't seen cmovnz used all the time for segfault avoidance, so I went searching. And the answer is: it doesn't help avoid segfaults. Due to pipelining, the src is loaded *before* the test happens.
jnthn diakopter: May well be possible, just tricky
japhb Or rather, referenced before the test. 16:49
diakopter jnthn: why would it be less trustworthy than a normal SC, if you saved room for "jitted version hashsum" in the SC reference identifiers
timotimo japhb: wait what.
github.com/MoarVM/MoarVM/commit/0b...0b57cfde61 - does that mean this is wrong?
japhb timotimo: Yes, I believe so. 16:50
I found multiple places this problem was referenced. :-(
diakopter japhb++ # research
Chrome thinks that BAIL op list gist is in Danish 16:51
16:51 brrt joined
timotimo %) 16:51
brrt diakopter: currently that's hard 16:56
the hard bit is the 'relocatable identifying taget addresses'
cuz you don't exactly know where these are in the bytecode 16:57
jnthn diakopter: SC is the wrong place for it anyway, I think. That's static at compile time, whereas this really would want generating and caching.
diakopter hm that's true, per machine
jnthn But yeah, what brrt++ said. We'd have to know where all the interesting things that need relocating are.
timotimo what we could perhaps do is cache the flags we observe after the logging stage
16:57 klaas-janstol joined
jnthn Which probably means custom dynasm patches. 16:57
timotimo so that we can immediately spesh stuff
brrt nods
diakopter yeah, need some kind of mapping with canonicalized identifiers to unique thingies 16:58
brrt that isn't even all that hard :-) the hard bit is knowing where exactly those addresses are 16:59
diakopter I meant all the places that initially place the things in those addresses need to store such a mapping 17:00
brrt you can't label within an operand in dynasm (obviously) so you'd have to guess
i.e. if i store somewhere a pointer to a function (which i do really often) then i have to know which part of the mov instruction references the address, and which is the instruction proper 17:01
diakopter I wouldn't want to guess :p
brrt no, neither would i
jnthn
.oO( Conservative GC^Wmachine code modification! )
brrt yeah, exactly that 17:02
you'd have to implement a linker
diakopter oh, is that what that's called..
TimToady well, we already have a LINK phaser, so we're all set, apart from a smop 17:03
17:05 jnap joined
diakopter just need a few more doublings vertically on all those log-log graphs... ;) 17:05
(I'm teasing of course, even 1 doubling (ever) is tremendous) 17:06
timotimo did you see the long-term benchmarks i posted on #perl6 a minute ago and a few hours ago? 17:07
diakopter maybe not
er yes those are the ones I meant
didn't see the one a few hours ago
brrt dinner & 17:09
17:09 brrt left
timotimo it was the exact same 17:10
17:36 zakharyas joined
nwc10 master/master/nom PASS, apart from the usual sin :-( 17:42
yes, "implement iscont with clever non-branching strats" was the problem 17:43
timotimo sorry :( 17:46
it could be the cmovnz thing mentioned above
jnthn hoped prepping chili would help him figure out what on earth is going on with init.t...alas, no... 17:49
FROGGS :/ 17:52
jnthn I think I busted autoclose. 18:25
And think I see how to fix it
But right now, the chili has become ready to nom, so I'll do it in a bit :)
nwc10 enjoy
timotimo i don't know what autoclose is .. 18:50
oh that's when a nexception flies and we close a file descriptor for that automatically 19:07
OSLT 19:08
19:18 brrt joined
brrt \o 19:18
hmm we can always implement iscont the dumb way
nwc10 o/
timotimo oh, yeah 19:19
the way i had it before you told me not to branch
i still have the patch here
the 'ternet connection here is really weaksauce >_< 19:20
gist.github.com/timo/414f465df7efa622148b#
actually ...
brrt hmm 19:21
must be other gist
timotimo gist.github.com/timo/4dc3eb65b316b9adfc3c
it takes me minutes to load stuff
maybe *one* of the branches can be turned into a cmovnz instead 19:22
brrt hmm
i don't necessarily thnk your version was wrong 19:23
timotimo the cmovnz?
brrt yeah, the gist is wrong 'cuz lacking extension
jnthn mmm...such hot :) 19:24
timotimo oh
brrt much curry
jnthn Chili tonight :)
brrt but the committed version looks really much right
timotimo i have the extension locally
and in the jit-iscont branch, too
brrt did you push that? 19:25
timotimo yeah, except you mustn't use cmovnz if the condition would prevent a null dereference
because the pipeline will go ahead and try to dereference and explode before it even checks the flag
japhb said so 19:27
brrt hmmm 19:32
and that'd still cause a null pointer exception
?
timotimo he says he sfound multiple references to that exploding 19:33
brrt weird 19:35
hmm, i see 19:36
you're quite correct
www.cs.cmu.edu/~fp/courses/15213-s...andout.pdf says the same, page 16
timotimo not me, him.
brrt japhb++ is quite correct :-)
i did not know that
i use that pattern quite often 19:40
timotimo seems like you really shouldn't do that :)
jnthn seems to have an init.t fix 19:42
dalek arVM: 530fada | (Bart Wiegmans)++ | src/jit/emit_x64.dasc:
Remove cmovnz NULL pointer deref

Apparantly these are executed by the pipeline before considering the flag, thus causing a null pointer exception. japhb++ for pointing this out.
brrt \o/
timotimo getlex_no was mine! 19:43
thanks for fixing
jnthn (init.t passes, just doing a spectest run to make sure I didn't knock off anything else) 19:45
brrt thanks for pointing it out (both of you :-)) 19:47
that could've been quite a nasty bughunt session
by the way, what actuall broke because of it? 19:50
ugh netsplit
19:50 FROGGS joined, sergot joined, ashleydev joined, avuserow joined, TimToady joined
brrt as in, whcih tests broke 19:51
timotimo a bunch
brrt hmmm
:-(
19:53 lue joined, klaas-janstol joined, colomon joined, daxim joined, ingy joined, retupmoca joined
brrt seems they still do 19:54
timotimo oh no! :(
brrt well... 19:55
wei'll manage
dalek arVM: 669a171 | jnthn++ | src/core/frame.c:
Fix under-sharing of containers regression.

The lazy lexical deserialization caused an overly-incomplete static environment to be copied into place, meaning things that should have been shared over BEGIN/INIT blocks failed to be.
timotimo oh my 20:00
FROGGS jnthn: that fixed init.t? 20:10
brrt ugh, iscont is /really/ common in baghash.t 20:11
jnthn FROGGS: yes
brrt hmmm
p6box_n
is an extop?
jnthn Yes
FROGGS jnthn++
now I can unfudge v5's grammar :o)
all p6* are extops, no? 20:12
jnthn Right
Well, actually
Some are just code-gen'd
But many map to a function in perl6_ops.c 20:13
brrt which tests are expected to fail? 20:17
none?
hmmmpf 20:19
well, that sure doesn't work out as planned 20:20
timotimo brrt, jnthn, posted my benchmarks on reddit: www.reddit.com/r/perl6/comments/2co...at/cjs4rpv
brrt impressive 20:21
jnthn timotimo++
brrt timotiom++ indeed
timotimo++ that is 20:22
timotimo what is impressive about that? 20:24
jnthn: if the init.t fix (and maybe something else, too?) warrant a version bump, could we get iscont in there, too? 20:26
brrt, with the branching version of iscont, do things still asplode?
brrt aye
they do
timotimo damn. 20:27
brrt yah 20:28
what's more
iscont is in /many/ frames
timotimo gist.github.com/timo/40214498dae386ee0bdd
jnthn iscont is extremely common because it shows up in many assignments 20:30
timotimo mhm
so not frequent in the setting compilation, as that's basically nqp code
jnthn yup
brrt ok, that's good to know
jnthn Except the bits of Perl 6 code that we might run 20:31
Butthat's mostly BEGIN blocks
= not hot
timotimo yup
should i collect bails for the nqp portion of the benchmark suite as well?
i think i will. 20:32
brrt: do you have an idea when you'll pfinish and push the param* support? 20:33
brrt uh... 'yesterday' was my original guess :-( 20:34
timotimo hehe
brrt basically i'm stuck thinking 'this can be more efficient'
timotimo no need to feel bad
brrt :-)
basically, we know ahead of time which of (obj/str/int/num) we want 20:35
timotimo sounds like you'd best implement it less efficient first and we'll see from there
brrt no need to dispatch
dalek arVM: cb9e151 | jnthn++ | src/6model/6model.c:
Complain properly about missing late-bound methods.
brrt no, first i need to fix the bug that causes iscont to fail
timotimo OK
brrt although i have some bits of an idea
FROGGS Program received signal SIGSEGV, Segmentation fault. 20:39
0x00007ffff79d2467 in MVM_sc_get_object (tc=tc@entry=0x603650, sc=0x7ffff63db300, idx=idx@entry=1258) at src/6model/sc.c:151
151 MVMObject **roots = sc->body->root_objects;
:o(
brrt what 20:41
FROGGS jit is not enabled fwiw 20:42
brrt oh
pfew
:-) these tend to be more fixable 20:43
brrt has no idea why adding a few labels makes nqp crash 20:51
adding a few deopt idxs makes nqp crash, apparantly 20:59
dalek Heuristic branch merge: pushed 51 commits to MoarVM/moar-jit by bdw 21:18
brrt last commit of these contains new iscont timotimo
also the line that adds some extra labels for inline deopts... that causes a crash in nqp building
no idea why
or, not yet a good idea :-) 21:19
brrt afk for tonight
21:19 brrt left
jnthn 'night, brrt++ 21:19
timotimo gnite brrt 21:20
FROGGS jnthn: that causes trouble in v5: d6365b0989965fa3577eb6e87b838a4a6011834c 21:23
jnthn FROGGS: huh...that should either fix a GC bug or have no effect... 21:24
FROGGS well, all v5 spectests fail...
with the segfault pasted 50 minutes ago 21:25
jnthn And if you revert exactly that commit?
FROGGS let's see
timotimo oh, we're not even optimizing iscont into a const in spesh yet 21:31
that could be a low-hanging fruit even
especially since it shares a whole bunch of logic with the decont opt
FROGGS jnthn: reverting exactly this commit helps for most of the spectests 21:32
ewww 21:34
Internal error: invalid thread ID in GC work pass
ERROR: Cannot build English, failing command was:
/home/froggs/dev/nqp/install/bin/perl6-m -I/home/froggs/dev/v5/lib --target=mbc --output=lib/Perl5/English.pm.moarvm src/Perl5/English.pm
that's new
jnthn Yes, that's exactly what the patch fixed.
FROGGS ahhh, I did not have the problem before the patch :o) 21:35
dunno at what revision I was before though :/
jnthn Well, that commit was to fix an issue introduced by the patch to allocate the compunit in gen2, in order to fix the JIT SEGV 21:36
FROGGS I see
jnthn So reverting the pair of them should get you something that works again 21:37
timotimo don't really know why dalek thought brrt did a branch merge? 21:42
oh!
to moarvm/moar-jit!
that's new
callercode seems to be quite common 21:43
jnthn Used in !cursor_start iirc
timotimo but i'm quite tired right now
i think i want to go to bed
maybe i'll implement cal
callercode tomorrow or something 21:44
jnthn :)
'night
FROGGS jnthn: I moved back to HEAD and the object is just garbage:
p *sc
$1 = {common = {header = {owner = 3, flags = 0, size = 0, sc_forward_u = {forwarder = 0x4b64210, sc = {sc_idx = 79053328, idx = 0}, st = 0x4b64210}},
st = 0x20000400000001}, body = 0x0}
timotimo indeed, !cursor_start has it almost immediately
FROGGS gnight timo :o) 21:45
jnthn Urgh
timotimo gnite froggs, and good luck with your v5 woes!
jnthn OK, then it appears a bit more is going on...
FROGGS it also fails here when I rerun:
Program received signal SIGSEGV, Segmentation fault.
MVM_sc_get_object (tc=tc@entry=0x603650, sc=0x7ffff63c7d18, idx=idx@entry=565) at src/6model/sc.c:154
154 return roots[idx] ? roots[idx] : MVM_serialization_demand_object(tc, sc, idx);
jnthn I'm guessing something went unmarked 21:46
It's not too clear to me how, though :( 21:47
FROGGS I'll go to bed now too... but I guess that this will also show up in star-daily
timotimo poor jit, MATCH chomps through four screen-pages full of ops to bail on bindattrs_i~
jnthn ugh, why're we using the indirect form...
oh...I know 21:48
And it's not hot path
(It's <( and )> handling)
timotimo since it's always either "from" or "to", maybe it'd be better code if we had an if there for those two possibilities :) 21:49
jnthn Mebbe 21:50
timotimo gist.github.com/timo/40214498dae386ee0bdd - anyway, this has the bails for perl6 and nqp benchmarks now 21:51
but i don't think the rakudo benchmarks actually got to the point where the actual benchmark part got "hot"

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!