Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-05-31

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:13 timotimo i wonder why the sp_bind_* ops are NYI? do they require something more than just setting the value at an offset?
00:13 timotimo like, do they have to ASSIGN_REFERENCE?
00:13 timotimo ASSIGN_REF, that is
00:14 timotimo on the other hand, having ASSIGN_REF doesn't stop us from having just the "target object, offset, value" op layout
00:17 timotimo huh? sp_get_o is NYI? but all the other sp_get_* ops aren't?
00:17 timotimo this must be purely on-demand implementation that i'm seeing nad not some deeper underlying difficulty that i may be missing
01:16 timotimo brrt, why does the emit*.dasc file grab the offset for a sp_p6obind_* via the .callsite_idx union member?
01:33 dalek MoarVM/jit_throw_ops: a861e6f | timotimo++ | src/core/interp.c:
01:33 dalek MoarVM/jit_throw_ops: implement the remaining sp_get_* and sp_bind_* ops in interp
01:33 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/a861e6f8a0
01:33 dalek MoarVM/jit_throw_ops: b96924d | timotimo++ | src/jit/ (2 files):
01:33 dalek MoarVM/jit_throw_ops: jit sp_bind_* ops
01:33 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/b96924d523
01:33 dalek MoarVM/jit_throw_ops: b1228a7 | timotimo++ | src/spesh/facts.c:
01:33 dalek MoarVM/jit_throw_ops: learn about newexception's type facts
01:33 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/b1228a7d44
01:33 dalek MoarVM/jit_throw_ops: 5f10592 | timotimo++ | src/spesh/optimize.c:
01:33 dalek MoarVM/jit_throw_ops: spesh newexception and bindex* into sp_fastcreate and sp_bind_*
01:33 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/5f105924a5
02:09 vendethiel joined #moarvm
03:49 vendethiel joined #moarvm
07:15 vendethiel joined #moarvm
09:00 brrt joined #moarvm
09:02 brrt timotimo: very simple answer to that. arg 2 to sp_(p6o_)?bind_[inso] is u16
09:02 brrt lit_i16 is signed
09:02 brrt hence, wrong
09:03 brrt on the other hand, if you assign them as lit_i16 values....
09:03 brrt anyway
09:03 brrt i'm going to check your patches out
09:14 brrt on the other hand
09:15 brrt it seems that i've been totally inconsistent with the u16/i16 distinciton
09:15 brrt and i have a hard time finding a real case where it matters; for situations that are somewhat likely to overflow we typically use i32 anyway
09:29 dalek MoarVM/jit_throw_ops: 3f9c337 | brrt++ | src/ (3 files):
09:29 dalek MoarVM/jit_throw_ops: Remove logging
09:29 dalek MoarVM/jit_throw_ops:
09:29 dalek MoarVM/jit_throw_ops: Also remove superfluous stores and made use of i16 as an offset
09:29 dalek MoarVM/jit_throw_ops: consistent. Wrong, but consistent.
09:29 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/3f9c337729
09:50 cygx joined #moarvm
09:50 cygx o/
09:50 cygx typo: https://github.com/MoarVM/MoarVM/search?utf8=%E2%9C%93&q=destory&type=Code
09:53 brrt wow
09:53 vendethiel joined #moarvm
09:53 brrt that is a persistent typo
09:54 cygx I suspect there was some code completion involved
09:57 timotimo what's the story behind that typo?
09:57 timotimo um
09:57 timotimo wat's de story behind dat typo?
09:58 * brrt doesn't know
09:59 cygx just something I noticed while looking at open pull requests, in particular https://github.com/MoarVM/MoarVM/pull/212/files
10:02 brrt hmm
10:02 brrt that looks sane to me
10:02 brrt (the patch, i mean
10:02 timotimo oh, wow, we've had pretty many pull requests so far
10:02 cygx timotimo: you've got an open one for rakudo from 2013
10:03 timotimo uh oh :)
10:04 timotimo the raw blocks thing
10:06 brrt ehm, many of these pull requests look good
10:06 brrt i'll see if i can merge them after lunch
10:06 timotimo cool
10:06 brrt afk &
10:06 timotimo i'm glad my patches look good to you :)
10:06 timotimo well, the jit throw ops ones
10:07 timotimo i'd really like to find out why &THROW-NIL doesn't get inlined into &next
10:07 timotimo maybe :throwish ops cause the inliner to immediately bail out?
10:08 timotimo but then, why isn't &next inlined into the frames of send-more-money-loops?
10:15 FROGGS joined #moarvm
10:19 cygx btw, should MVM_exception_throw_adhoc() take a char** argument of strings to free?
10:19 cygx right now, MoarVM leaks C strings...
10:20 cygx (as far as I can tell)
10:20 FROGGS hmmmm, that's perhaps sane
10:20 FROGGS it does, yes
10:31 cygx so, who wants to go through the 886 occorrences of the term 'throw_adhoc' in MoarVM ;)
10:31 timotimo ideally, we'd have a second function that does the freeing thing
10:32 timotimo ooooh, inlining at the spesh level is prevented by having lexical access to any frame that refers to outers
10:32 timotimo so not having lexicals-to-locals working any more makes spesh inlining much weaker, too
10:36 timotimo hum. the specialization of THROW-NIL is finished before next's is
10:36 timotimo THROW-NIL contains no ops that'd prevent inlining
10:37 cygx so instead of freeing the strings in MVM_exception_throw_adhoc_va(), do it after the longjmp() in MVM_interp_run()
10:40 timotimo the callsite for THROW-NIL's specialization matches the one prepared in next for the call ...
10:41 timotimo hm. the spesh dump doesn't contain any information about guards the specialization relies upon; i could put that in
10:50 cygx any ideas for a good name for the function that does an adhoc_throw and cleans p
10:51 cygx *clean up after intself?
10:51 cygx *cleana
10:51 cygx *cleans
10:51 timotimo https://php.net/manual/de/function.mysql-real-escape-string.php ← take inspiration from winners? :)
10:55 cygx MVM_exception_throw_adhoc_tidy? MVM_exception_throw_adhoc_collect with a waste parameter?
10:55 cygx os just MVM_exception_throw_adhoc_free?
10:56 timotimo MVM_exception_throw_adhoc_free and MVM_exception_throw_adhoc_premium :)
10:56 timotimo do we have a clue how much we actually leak?
10:57 timotimo in a regular program run? or maybe "collected over the spec tests"?
11:08 timotimo my last resort seems to be littering the spesh code with stderr output to figure out what's going wrong ;(
11:11 cygx preparing lunch &
11:22 timotimo https://gist.github.com/timo/104e64dc729f69987350  ... seriously? %)
11:30 timotimo i don't understand why these getlexstatic_o aren't turned into spesh slot reads; these ops had logs put in for them, according to the spesh log
11:31 timotimo and i really don't expect the value they pointed to to have changed, except if they were in the young generation - for some strange reason - and got moved around since the last log ?!
11:36 dalek MoarVM/jit_throw_ops: d51fd47 | timotimo++ | / (3 files):
11:36 dalek MoarVM/jit_throw_ops: sp_log doesn't take a sslot, it's a "log slot", which is int16
11:36 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/d51fd47577
11:37 dalek MoarVM/jit_throw_ops: 1059847 | timotimo++ | src/spesh/dump.c:
11:37 dalek MoarVM/jit_throw_ops: [speshdump] show argument guards directly below callsite
11:37 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/1059847a58
11:47 timotimo '' (0x2e0a550): looking for inline candidates to 'next'
11:47 timotimo '' (0x2e0a550):     candidate number 0 is a good choice.
11:47 timotimo survived the simplest checks
11:47 timotimo found instruction getlex_no, which is no_inline.
11:47 timotimo '' (0x2e0a550):     can't inline, boo :(
11:47 timotimo well ... :\
11:48 timotimo getlex_no r0(5), lits(&EXHAUST)
11:48 timotimo bindlex lex(idx=5,outers=0,RETURN), r0(5)
11:48 timotimo god damn it
11:48 timotimo i don't think i really understand the whole exhaust, return, dispatcher, ... stuff thoroughly
11:49 timotimo all i know is that multi methods get it
11:50 timotimo since we're trying to inline that anyway, shouldn't we be able to throw (most of?) that stuff out?
12:01 * timotimo considers putting in a dump of logged values
12:50 cygx joined #moarvm
13:01 cygx sent https://github.com/MoarVM/MoarVM/pull/219
13:03 timotimo ah, so a null-terminated list of pointers
13:10 timotimo https://gist.github.com/timo/cec6c14aac3f8484eb12 ← yay or nay?
13:11 timotimo i'll probably also output some random info about the values in the explanation bellow
13:11 timotimo hm, the (-) looks a bit too "big"for a non-filled slot
13:14 timotimo i obviously don't understand printf formatting
13:15 timotimo why would "% 2d" have different lengths for 0-9 and 10-99?
13:16 timotimo apparently i need to use 3 if i want same-length outputs for those ranges
13:17 timotimo maybe it's meant to always put a space up front?
13:19 cygx timotimo: the idea behind the space prefix is to make negative and non-negative nmbers the same length without adding a +
13:20 timotimo ah
13:20 timotimo i hadn't realized that
13:21 timotimo so it leaves space for a -, but in my case i only have positive numbers and it never occurs that a - ends up there
13:21 cygx that's it
13:21 timotimo i did something terrible and built a tell_ds + rewind_ds function pair for the DumpStr object
13:22 timotimo and if the table contains only empty slots (like if the logging stuff has just been put in, but never run) i rewind the DumpStr
13:22 timotimo rather than checking the values up front
13:22 timotimo but dumping spesh isn't a performance-critical thing anyway
13:23 dalek MoarVM/jit_throw_ops: 846cd07 | timotimo++ | src/spesh/dump.c:
13:23 dalek MoarVM/jit_throw_ops: output number of spesh & log slots and a log table in spesh dump
13:23 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/846cd07065
13:23 dalek MoarVM/jit_throw_ops: 2ff5011 | timotimo++ | src/spesh/optimize.c:
13:23 dalek MoarVM/jit_throw_ops: since spesh slots are immutable pointers, we can re-use them
13:23 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/2ff50115c7
13:25 timotimo oh, i committed log output again
13:25 dalek MoarVM/jit_throw_ops: d17f3a5 | timotimo++ | src/spesh/optimize.c:
13:25 dalek MoarVM/jit_throw_ops: remove debug output
13:25 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/d17f3a5980
14:34 Peter_R joined #moarvm
15:11 timotimo huh ... on my laptop builds and the benchmark i'm using are both broken ... ?!
15:14 timotimo re-using spesh slots seems to cause that problem
15:19 timotimo there's places where we grab a spesh slot with the value set to NULL so that we can put values into them later, in that case re-use is definitely taboo
15:24 dalek MoarVM/jit_throw_ops: 23f25e0 | timotimo++ | src/spesh/optimize.c:
15:24 dalek MoarVM/jit_throw_ops: spesh slot reuse must be opted in, otherwise we crash
15:24 dalek MoarVM/jit_throw_ops: review: https://github.com/MoarVM/MoarVM/commit/23f25e0e9a
15:25 FROGGS joined #moarvm
15:53 timotimo https://gist.github.com/timo/1883a8c4287650f38925 - i wonder why these P6ints with the same value end up with different locations in memory
16:03 zakharyas joined #moarvm
16:24 timotimo where do we box an integer without hitting the cache?!
16:46 cygx joined #moarvm
17:28 FROGGS joined #moarvm
18:53 cygx left #moarvm
19:05 timotimo the next thing i'd love to have is to show the exact instruction that wrote the value that got logged next to the table
20:22 zakharyas joined #moarvm
21:20 Peter_R joined #moarvm
21:30 lizmat joined #moarvm
21:37 timotimo i think i know what's going on
21:37 timotimo the int cache doesn't get marked
21:37 timotimo so it's quite possible that the int type it gets made for moves after the first GC?
21:37 timotimo i would have expected that type to land in gen2, though
21:40 timotimo making an intcache for 0x1c62338
21:40 timotimo nursery's at 0x7fcfc57e0010 and 0x7fcfc53df010 right now
21:40 timotimo i suppose that answers it
21:41 timotimo but why, then, doesn't it register? :\
22:18 vendethiel joined #moarvm
23:20 vendethiel joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary