github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:00 huggable joined
Geth MoarVM/ctx-lazy: 3da1e5fb63 | (Jonathan Worthington)++ | 5 files
Preserve enough data for accurate traversal

In the absence of inlining, the ->caller chain is immutable, so we can simply hold the frame the `ctx` op ran on and it's enough. When there's inlining, however, we didn't have sufficient information in order to be able to reconstruct the caller chain, since the current address of the caller is mutable. Thus, snapshot those at the point of a use of the `ctx` op in the *callee*. A callee can only ever have been called from a particular program point, and so this lets us better traverse the chain.		 00:23
jnthn Got it to work
[Coke] \o/ 00:24
jnthn So that branch fixes both github.com/rakudo/rakudo/issues/2058 and github.com/rakudo/rakudo/issues/2046 00:25
The issue ctx-lazy solves has been around for a while, but we managed to get away with it for the most part by doing less inlining :)
Now we do a bit more, and couldn't :) 00:26
MasterDuke jnthn: think github.com/MoarVM/MoarVM/issues/908 and github.com/MoarVM/MoarVM/issues/907 might have been fixed with your recent work? 00:30
jnthn MasterDuke: I think 907 was hash related and samcv++ fixed that 00:31
908 - no idea, I didn't touch anything in that area 00:32
MasterDuke ok, i'll re-test it
jnthn Spectest looks OK and ctx-lazy fixes at least two modules that were regressed 00:33
So I figure I'll merge it
MasterDuke 907 is looking good so far...
Geth MoarVM/master: 24 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/f...08d3c180e0		 00:35
00:38 lizmat left
jnthn Comments left on tickets that this work is known to fix 00:41
Sleep; 'night 00:42
01:08 lizmat joined 01:13 lizmat left 01:31 MasterDuke left 02:10 leedo joined 04:17 Kaiepi left 05:02 Kaiepi joined 05:28 chansen__ joined 05:29 SmokeMachine_ joined 05:30 chansen_ left, chansen__ is now known as chansen_ 05:31 SmokeMachine left, SmokeMachine_ is now known as SmokeMachine 05:33 statisfiable6 left, bisectable6 left, nativecallable6 left, statisfiable6 joined, bisectable6 joined 06:28 brrt joined 06:31 nativecallable6 joined, squashable6 joined 06:47 robertle joined 06:48 brrt left 06:50 domidumont joined 06:56 domidumont left 06:57 domidumont joined 07:22 brrt joined
brrt \o 07:24
i now know why my trees are getting corrupted 07:25
masak .oO( Saruman ) 07:44
07:46 zakharyas joined 07:48 brrt left 07:49 lizmat joined 07:53 zakharyas left 07:55 zakharyas joined 08:17 undersightable6 joined 08:45 brrt joined
brrt :-) almost 08:49
no
when generating templates, we compute fixed offsets from the start of the template, then during the application of them, we add the start of the tree (where the template is applied) to 'link' it in to a fixed address 08:50
now, in the original version, variadic operators would have an additional size argument just after the operator 08:52
and the in-memory tree would copy that 08:53
but in my refactored version, the in-memory tree stores the number of operands in the same node (a struct) as the operator, given that we don't have nearly enough operators to justify spending 32 bits on them 08:54
anyway, that means that the computed offset in the template generation phase is now wrong, since the size argument is no longer there
(in the tree representation) 08:58
I think... this indicates that I'm going in the wrong direction with this 09:07
jnthn morning o/ 09:37
tadzik 5 09:38
brrt morning jnthn 09:40
dogbert2 morning jnthn & brrt
tadzik morning :) 09:45
jnthn tadzik: Wow, didn't see you on this channel in a whle. :-) 09:46
dogbert2 spectest looks pretty good, had to set MVM_GC_DEBUG and decrease the nursery size in order to get some failures 09:55
on the other hand I'm not certain that these errors are entirely new 09:56
tadzik jnthn: I'm always here, just passive :) 09:59
jnthn :) 10:01
Geth MoarVM/jit-expr-refactor: 10 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/c...2a143136a4		 11:13
11:13 MasterDuke joined
brrt Maybe just merge the above, and move to template compaction some other day 11:14
so, just for curiosity's sake: why do I want to compact the nodes 11:15
currently, we store a bunch of essential information for the tree in a (rather wasteful) secondary array called the 'info' array
information like: the operand type, the size of the result 11:16
some other information essential for interpreting the tree is stored elsewhere
e.g. the number of child nodes and the number of parameters are encoded in an 'expr op info' array 11:17
except for variadic operators, in which case the number of child nodes (operands) are enocded as a parameter directly after the operator node 11:18
this means that wherever we use the tree, we have to look in three different places in order to make sense of it properly; 11:19
i.e. I need to look at the operator, then at the expr op array, then maybe again at the tree, to find the correct number (and offset) of the child node links 11:23
MasterDuke brrt: and all that has to happen frequently? 11:26
brrt all throught the expr JIT 11:28
now, this isn't actually a problem per se.
everywhere this is done, it's done correctly
but
It does mean that there's at least two dynamic arrays that have to be kept in sync when modifying the tree
so far the tree modifications are very simple, i.e. only during template application, so it's an append-only operation 11:29
but if this is supposed to become more fancy, I don't want to be bogged down by the inadequacy of the representation
11:31 zakharyas left 11:39 squashable6 left 12:09 lizmat left 12:16 lizmat joined 12:21 lizmat left 12:35 brrt left
dogbert2 jnthn: are you still looking for regressions? 12:36
jnthn Have had some other things to take care of so far today, though about to resume looking at what's left of those 12:44
dogbert2 there seems to be a nasty bug hiding in t/spec/S02-names/pseudo.t - if run with MVM_GC_DEBUG=1 it panics every run and if run normally it sometimes crashes with 'MoarVM panic: Internal error: zeroed target thread ID in work pass'
ok, just curious :)
jnthn Hm, that passed fine for me last night
Will see if I can repo 12:45
dogbert2 perhaps because I'm running on 32 bit then (without JIT)
jnthn *repro
dogbert2: No luck reproing it without GC debugging turned on, at least 13:08
dogbert2 grrr
for I can make it fail every time with MVM_GC_DEBUG set 13:09
dogbert2 can't type properly, sigh
jnthn Will give it a try with that shortly 13:10
dogbert2 hopes jnthn will be able to repro 13:12
13:18 zakharyas joined
dogbert2 here's what it looks like on my end: gist.github.com/dogbert17/26f45c42...d8ed902c9c 13:20
Geth MoarVM: 1166f6632f | (Jonathan Worthington)++ | src/jit/unsafe.expr
Remove unsafe template invalidated by recent work
 13:29
MoarVM: 82054a8567 | (Jonathan Worthington)++ | src/jit/x64/emit.dasc
Update JIT of ctxcallerskipthunks
MoarVM: fdd571963f | (Jonathan Worthington)++ | src/spesh/frame_walker.c
Tidy up and correct MVMROOT in get_lexicals_hash

We can root them all at once, and we need to root `sf` because we access it during the loop.		 13:35
jnthn dogbert2: See if that last commit helps any :)
dogbert2 jnthn: will do ... 13:39
no dice unfortunately :( 13:41
gdb output is the same 13:43
jnthn What if you `frame 4` and `p type`? 13:45
dogbert2 let's see 13:47
... 13:49
(gdb) p type
$1 = 8
(gdb) info locals, obj = 0xb382b740, idx = 239, type = 8, lexreg = 0x8e14220, i = 239, frame = 0xa680de8, sf = 0x85526b0, base_index = 0, hll = 0x8111488, ctx_hash = 0xb7422060 13:56
Geth MoarVM: 8d96c86c78 | (Jonathan Worthington)++ | 4 files
Always preserve return value for exit handler

When the caller had void return type, we lost the return value of the callee and so would not pass it to its exit handlers. This stores it in the case that we have a void caller.		 14:00
jnthn 239...that's a big frame :) 14:05
14:05 zakharyas left
dogbert2 :), ran it again and it's 239 again 14:05
jnthn 8 is an object register
Hmm
Managed to reproduce it 14:09
dogbert2 yesssss
14:16 zakharyas joined
jnthn Though not much idea what it could be. The lexical in the frame comes out as an old version 14:16
Well, fromspace
But the frame itself is fine
and oddly, making the nursery smaller makes it vanish 14:17
Ah, the frame itself is gen2, so it's a missing write barrier 14:19
It's not in the inter-gen root set
timotimo so having a smaller nursery just makes it enter the gen2 early enough before it gets a problem? 14:32
jnthn Yeah, presume so
dogbert2 is it an old or new problem 14:33
timotimo could be either, really
maybe the code where it's wrong was made reachable by more inlining than before
but in theory, every little piece of change can have ripple effects like that 14:34
jnthn New.
It's too coincidental :)
timotimo listen to the one who knows! :D
jnthn Also I think I found it :)
ctx-lazy was fixing an old and uncovered issue 14:35
The regression seems to have been in bind_key in MVMContext
Yeah, test seems happy now 14:36
dogbert2 cool 14:38
perhaps the upcoming fix will solve another issue I've seen as well 14:39
Geth MoarVM: 1c8c2702c8 | (Jonathan Worthington)++ | src/core/frame.c
Missing GC rooting during contextual resolution
 14:45
MoarVM: f356e5ac60 | (Jonathan Worthington)++ | 4 files
Fix bind_key to use correct frame in write barrier

Since we traverse lazily, the frame available in the context is no longer always the one that owns the lexical being bound to.
jnthn The second of those commits fixed the pseudo.t problem for me 14:51
dogbert2 the test no longer fails on my system, jnthn++ 14:52
jnthn hurrah :)
dogbert2 could there be more missing write barriers? 14:53
jnthn There could be, but I don't see any other places in ctx-lazy that could have them 14:54
We only touched one codepath where lexicals are bound
Hmmm..
dogbert2 I can still trigger a panic when running t/spec/S15-nfg/concat-stable.t, the gdb output looks different though 14:55
it looks like this - gist.github.com/dogbert17/796acab7...dff8a2ce93 14:56
Geth MoarVM: 43c716c0fb | (Jonathan Worthington)++ | src/core/frame.c
Ensure we never leak a real NULL to exit handler
 14:59
MoarVM: 92a7c91c65 | (Jonathan Worthington)++ | src/spesh/plugin.c
Missing rooting of test object in evaluate_guards
 15:03
jnthn dogbert2: Try ^
dogbert2 I'm on it :)
jnthn (Didn't repro it, just looked at the code and spotted that :))
15:04 zakharyas left
dogbert2 you're on a roll :) 15:05
MasterDuke i wonder how difficult it would be to write a plugin for some static analyzer to find missing MVMROOTs?
dogbert2 seems to work ... 15:06
jnthn dogbert2: hurrah
15:07 zakharyas joined
dogbert2 nooo, we're running out of bugs :-) 15:07
jnthn MasterDuke: Not sure, it may be possible to catch some cases
15:10 domidumont left
jnthn Unfortunately we still have github.com/rakudo/rakudo/issues/2072 which I can't find any way to make happen other than with CORE.setting compilation 15:10
dogbert2 ah, the 32 bit build bug 15:11
jnthn You can produce it on 64-bit with MVM_JIT_DISABLE=1 too
dogbert2 that sounds like a tricky bug to find 15:16
jnthn Yes, terribly 15:18
It's a deopt bug of some sort
And happens on deopt all
dogbert2 perhaps we should ask Alexdaniel to do a toaster run with the JIT disabled, that might give us something 15:23
15:24 benchable6 joined, robertle left
jnthn Perhaps we'd find something that way 15:26
The deopt log is 21562441 lines long 15:28
MasterDuke wonders if jnthn will use perl6 to parse it 15:30
Geth MoarVM: 39642e249d | (Jonathan Worthington)++ | src/spesh/deopt.c
Improve deopt logging

  * Log which frames are touched in a deopt all
  * Use indentation to make the log clearer
jnthn Doesn't really need parsing, just searching
dogbert2 is this something which needs to be turned on? 15:31
jnthn Yes, by the define at the top of the file 15:32
15:41 zakharyas left 15:51 zakharyas joined 15:58 zakharyas left
jnthn Wowser, it seems deopt somehow puts the frame back at the wrong address 16:00
So the registers then contain the wrong thing 16:01
Since it's running completely different code than it should be 16:04
The contents of the register at the deopt index matches what it would wrongly be when we deopt
MasterDuke that seems like it would break very loudly
jnthn Well yes, the question is why it gets it right in hundreds of thousands of cases, but not this one 16:05
MasterDuke
.oO(the less common off by one-in-hundreds-of-thousands)
 16:07
16:07 zakharyas joined
ilmari postgres fixed an off-by-one-in-four-billion bug recently 16:12
www.postgresql.org/message-id/CAKJ....gmail.com
jnthn It looks like it's going to be an off-by-blah issue 16:22
Uninlining is missing that it's in an inline
16:46 lizmat joined
jnthn Might well have a fix 16:51
16:52 domidumont joined 16:53 lizmat_ joined 16:55 lizmat left, lizmat_ left
jnthn Yup, builds with and without JIT now :) 17:02
dogbert11 impressive 17:05
jnthn The patch is tiny for something that took so long to find... 17:06
17:11 lizmat joined, lizmat left
Geth MoarVM: 23ea67b847 | (Jonathan Worthington)++ | src/spesh/manipulate.c
Fix delete motion of INLINE_END annotations

We should always move them forwards. We never had a problem with this in the past, since the last instruction of an inline was always a
  `set` that was replacing the `return`. That was never deleted, so we
never had a problem. Now we support inlining of `invoke_v`, which means the return instruction is simply deleted. When we moved the inline end ... (6 more lines)		 17:12
MasterDuke jnthn: fwiw, i've been running github.com/MoarVM/MoarVM/issues/908 in a loop on two different computers for probably about 2h now and no problems so far 17:15
jnthn MasterDuke: ah, good :) 17:16
I think the sometimes-failing async lock spectests can be tomorrow's debugging task 17:43
jnthn wanders home 17:45
17:59 MasterDuke left 18:02 domidumont left
Geth MoarVM/jit-expr-refactor: b335cdde7e | (Bart Wiegmans)++ | 6 files
[JIT] General cleanups in expression trees

  - Store type without 3-bit shift (is redundant and removed by its sole
   user)
  - Remove (redundant) spesh_ins pointer from 'info' (making info very
   tiny)
  - Make template nodes into plain MVMint32 (MVMJitExprNode is going away)
  - Make value_bitmap unsigned (shifting isn't entirely safe otherwise)		 18:09
18:12 buggable left 18:13 buggable joined, lizmat joined 18:20 zakharyas left 18:37 MasterDuke joined 18:52 lizmat left 18:58 lizmat joined 19:07 lizmat left 19:14 Kaiepi left 19:19 hoelzro joined
Geth MoarVM: 30dd47c1d8 | (Jonathan Worthington)++ | src/6model/reprs/MVMContext.h
Expose a symbol for Windows sake
 19:22
jnthn "For goodne^WWindows sake!"
geekosaur isn't that what you drink to recover? 19:24
jnthn :-) 19:25
19:32 Kaiepi joined 19:41 brrt joined
brrt \o 19:41
i saw there was a branch on reading-things-from-a-concatenated-binary 19:42
so that was linux-specific since it relied on opening the /proc/self/exe file
geekosaur there's no reliable way to find the current executable otherwise 19:43
(on POSIXlikes; iirc there's a Windows API to get the current executable's handle) 19:44
brrt i was thinking, maybe we can link the moar binary with a dll (.so); in which case, we can use dlsym to get the concatenated contents 19:45
and it's windows' equivalent
geekosaur perl 5 style? (which is forced on some platforms) 19:46
brrt i don't know how perl5 does that 19:47
geekosaur -Duseshrplib means perl was built as a stub executable which dlopen()s the actual perl so/dll 19:49
brrt aha 19:50
yeah, something like that
but for bytecode rather than for the dll
dogbert11 one of today's commits was this - github.com/MoarVM/MoarVM/commit/92...de6b8d9dd0 - I'm wondering if there's something else which should be rooted here except for what was indeed fixed? 20:03
jnthn brrt: About github.com/rakudo/rakudo/issues/2070 I just did a Windows build and all make test passes with MVM_JIT_DISABLE=1, so it looks like something is off with Windows JIT still. 20:05
20:06 brrt left 20:07 brrt joined
Geth MoarVM/jit-expr-refactor: 11 commits pushed by (Bart Wiegmans)++
review: github.com/MoarVM/MoarVM/compare/b...cca73bf7a7		 20:16
20:18 AlexDaniel joined 20:26 zakharyas joined 20:29 timo2timo joined
timo2timo i'm somehow not able to reach my irc client 20:31
mhh, the listen method on IO::Socket::Async creates a new Supply from the SocketListenerTappable 20:33
so in order to have the port there it'd have to mix into the supply that results 20:35
or something entirely different
20:41 brrt left
jnthn timo2timo: See Proc::Async and how it lets you get the file descriptor from stdout/stderr 20:42
timo2timo GTG 20:47
20:47 timo2timo left 20:55 brrt joined 21:05 zakharyas left 21:25 brrt left 21:51 lizmat 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!