01:24 FROGGS_ joined 02:06 [Coke] joined 02:10 dalek joined, sergot joined, synopsebot joined 02:21 sergot joined 02:39 dalek joined, synopsebot joined 02:47 dalek joined 03:07 d4l3k_ joined 03:09 sergot joined 03:14 sergot joined 03:17 [Coke]_ joined, synopsebot joined 03:23 synopsebot joined 03:30 dalek joined 03:54 synopsebot joined 04:01 dalek joined 04:07 d4l3k_ joined 04:27 dalek joined 04:46 dalek joined 04:51 dalek joined 04:58 sergot joined 05:08 dalek joined 05:46 lizmat_ joined 05:54 lizmat joined 05:58 woolfy joined 06:02 lizmat joined
sergot o/ 06:48
07:09 zakharyas joined
ren1us should moar be regularly running at ~99% CPU? 08:43
nwc10 I guess "that depends" - what are you doing with it? 10:14
10:28 brrt joined
jnthn Was gonna say...depends how many cores you have and what workload you put on it. 10:38
nwc10 jnthn: fresh SAN barf paste.scsys.co.uk/408725 10:41
master/master/nom
need to go for lunch 10:42
can't do more
brrt \o
jnthn timotimo: ^^ may relate to your recent spesh work; probably a missing NULL check
o/ brrt
brrt how's things :-) 10:43
jnthn Not bad. Got a friend visiting for the weekend, so will be playing tour guide a bit :) 10:44
brrt nice
(why off all frames that had to fail, did it have to be one of 49 basic blocks?)
24 basic blocks
jnthn has had to debug stuff in a frame with 200 before 10:45
It's..."fun"...
brrt 'challenging'
anyway, i see two things that i've been finding difficult to test 10:51
decont on one hand, getlex with viv on the other
jnthn Both will only show up a lot in Rakudo 11:06
You may want to try disabling JIT for the build, getting a Rakudo, then running stuff with it
11:08 brrt joined
jnthn afk for a while 11:40
FROGGS have fun
nwc10 timotimo: ^^ 1869baf6cd92f1149ed5838ecfa3e566a09ab66c is the first bad commit 11:45
timotimo thank you, i'll have a look in a few 11:46
11:51 btyler joined 11:54 brrt joined
timotimo can the boolification spec ever be null? 11:59
12:09 jnap joined
brrt yes 12:14
afaik
timotimo oh, that'd explain the problem :) 12:15
how do we boolify something that doesn't have a boolification spec set?
just use the default, which is check if the object is concrete? 12:17
brrt let me see
see MVM_coerce_istrue, src/core/coerce.c, l32
basically, no boolifciation spec means MVM_BOOL_MODE_NOT_TYPE_OBJECT, which is indeed IS_CONCRETE 12:18
timotimo ah, right
brrt so no boolification spec and known type can be converted to sp_guardconc and set
(it would seem)
timotimo well, i turn it into an isconcrete and defer to the isconcrete optimization 12:19
i suppose the isconcrete optimization does the guardconc piece?
dalek arVM: 9a0099d | (Timo Paulssen)++ | src/spesh/optimize.c:
boolification spec may be null, which means "not type object"
 12:27
timotimo isconcrete may want to flag any given guardconc as "used" when it turns that into a const_i 12:30
brrt well then, you can swap an const_i and an if_i into a goto :-)
timotimo well, the isconcrete opt already turns an isconcrete and a "known to be concrete" into a const, and the if would remove the usages of that const and turn into a goto (or rather: should) 12:31
12:49 btyler_ joined
nwc10 timotimo: pass 12:50
timotimo thank you!
nwc10 thank you for the quick fix
timotimo you made it easy :) 12:51
brrt getlex with autoviv isn't hit on rakudo build 12:53
... hit_wb is hit 12:55
yes
(it is in fact hit in a relevant code path, it seems) 12:58
timotimo is that the code you spiked with a little abort()? 12:59
brrt other code that i spiked 13:00
timotimo ah 13:01
brrt the good thing is that it blows up in approximately the right frame 13:04
timotimo AFK for a bit ...
brrt see you :-0 13:05
:-)
if i have an MVMObject in the debugger, how can i figure out what type it is? 13:17
oh, it's VMArray
13:25 woolfy joined 13:26 lizmat joined
brrt it seems a GC bug 13:30
13:30 jnap joined
brrt (that's not quite right. it seems a bug in jit related to gc) 13:30
brrt afk 13:33
timotimo that sounds like a nasty kind of problem 13:50
14:07 woolfy1 joined
jnthn Need to be rather careful in the JIT not to have something sat in a register then do a call that may allocate. 14:35
nwc10 is it possible to add optional assertion code that spots if that is happening?
14:56 jnap joined
jnthn nwc10: Hmm...could try emitting a sanity check of the current frame between instructions... 15:05
Not srue that's enough though
Best bet is the usual "make the nursery tiny" trick
FROGGS jnthn: I know you have no time, but this is on topic: github.com/MoarVM/MoarVM/issues/114 15:10
do you have any pointers?
jnthn *foo, **bar 15:11
On "Is it related to spesh/inlining?" - set MVM_SPESH_DISABLE=1 for no spesh 15:12
And MVM_SPESH_INLINE_DISABLE=1 just for disabling inlining.
FROGGS &baz 15:17
if I disable one of them then it infiniloops, probably again in libuv waiting for data 15:23
jnthn Which one? 15:27
FROGGS that example here: gist.github.com/FROGGS/be23c4bcdca366a0ddab
jnthn no, which flag... 15:29
Anyway, heading out &
FROGGS both MVM_SPESH_DISABLE=1 and MVM_SPESH_INLINE_DISABLE=1 15:30
jnthn The first subsumes the second
FROGGS yes, sure 15:31
jnthn OK, so could be inlining related
16:04 cognominal joined 16:08 cognominal joined 16:55 vendethiel joined 18:26 cognominal joined 18:47 lizmat joined 18:48 woolfy joined 19:07 brrt joined, brrt left, brrt joined
brrt \o 19:08
ok, i have no good evidence of jit-relatedness, but i have this 19:09
ehm, gc-related-jit-bugs, i mean
and fwiw, our main interface with the GC is hitting write barriers
which i suspected of not being tested very well, but nevertheless 19:10
hmm 19:11
maybe that's wrong
19:11 woolfy joined 19:17 woolfy joined
brrt can i influence when GC is run? 19:26
[Coke] ISTR jnthn & nwc10 have a way to make it run more frequently. I don't know if you can kick off a run from a particular line of code. 19:30
brrt hmm i might need that way 19:31
FROGGS brrt: you can adjust these values: 19:33
/home/froggs/dev/MoarVM/src/gc/collect.h:4:#define MVM_NURSERY_SIZE 4194304
/home/froggs/dev/MoarVM/src/gc/collect.h:9:#define MVM_GC_GEN2_RATIO 25
brrt ah, ok
awesome 19:34
that should help
FROGGS make the first smaller (like 5000 or so)
but the gc is only triggered when an allocation happens, so you cannot trigger it at another moment
brrt that's ok, i already know that the gc is triggered just twice before the 'funky' stuff happens 19:35
i.e. a REPR that can't be invoked because it is (probably) VMNull
hmmmm 19:37
ok, very interesting, i get troubles invoking but the invoked code is VMNull 19:38
it is exactly the same object
shame i can't get at the actual object since it's been optimized out 19:45
it's a P6Opaque 19:48
but P6Opaque should be able to look stuff up, shouldn't it? 19:49
FROGGS 'look stuff up'? 19:50
brrt support atkey_o 19:54
19:55 btyler joined, carlin joined
brrt off 20:06
20:06 brrt left
itz__ what version of nqp should I use with moar-jit? 22:24
FROGGS latest I guess
itz__ master seems to depend on a newer moar version 22:25
FROGGS yes, moar master might need to be merged into moar-jit
so, take a look when moar master was merged into moar-jit the last time, and pick an nqp from the same time 22:28
itz__ I'll try that 22:31
timotimo merging moar-jit into master should be mostly clean, though 23:35
carlin is jit being merged before the next release? 23:40

Powered by Cro and the Raku® Programming Language.

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

Thank you!