github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:24 sena_kun left 00:34 leont left 00:47 leont joined 00:56 squashable6 left 00:57 squashable6 joined 02:59 leont left 08:38 zakharyas joined 09:19 zakharyas left 09:20 zakharyas joined 10:27 sena_kun joined 10:49 Guest1277 joined 11:34 Altai-man_ joined 11:36 sena_kun left 11:45 leont joined
Geth MoarVM/derived-specializations: 19 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/d...a856b9aba8		 11:48
jnthn Just a rebase 11:49
12:10 zakharyas left 12:21 hankache joined 12:51 squashable6 left 12:52 squashable6 joined
Guest1277 jnthn: are you gonna try and squish the remaining bug(s)? 12:56
jnthn Yeah, will try at least. 12:57
Just running the spectest with nodelay/blocking now
To see the current state
13:03 MasterDuke left 13:35 sena_kun joined 13:37 Altai-man_ left 13:39 hankache_ joined 13:43 hankache left
jnthn Been investigating the hang of the S17-procasync test. Almost certainly an existing bug uncovered. Don't know the details yet, but the problem is inlining into rethrow of...whatever could be inlined into rethrow. It's not a very big method, so... 13:50
13:55 zakharyas joined 13:58 tadzik left 14:06 hankache joined 14:09 hankache_ left 14:26 hankache left
jnthn This is really odd. It's the inlining of maybe-set-control that does it, apparently, but that all looks really simple...e.g. it's a no-op for this case 14:50
Guest1277 the plot thickens 15:05
15:34 Altai-man_ joined 15:36 sena_kun left
jnthn Yeah, at some point it just finds completely the wrong exception handler 15:38
lizmat
.oO( perhaps its clutching at straws )
 15:39
*it's
nwc10 jnthn: what do valgrind/ASAN/coffee/beer/step-away-and-cook-curry think of this? 15:40
(sorry, can't offer much more help than moral support here. And beer next week (hopefully)) 15:41
jnthn With further dumping of the exception handler search, it does all fit: it wrongly finds a handler in rethrow. Question now is: what on earth? 15:49
16:42 leont left 16:43 rypervenche left 16:47 rypervenche joined
jnthn In one case we had a specialized frame on the stack and in the other not...which led me to look again more closely at what deopts happen...and indeed there is a failure to deopt the rethrow frame with that inlining done :S 16:49
lizmat so the plot thickened ? 16:50
jnthn It's now about as thick as I feel :P 16:51
17:06 hankache joined 17:09 Guest1277 left
jnthn As always with these things, there's a chance one line of code will fix this :P 17:09
japhb
.oO( Bug fix bill: 1000 credits. Itemization: one line of code -- 1 credit; knowing which line of code -- 999 credits.)
 17:18
jnthn When we throw an exception, we didn't set anything in the return address of the handler. When we do inlines, we update that address less regularly. The inline led to a more lagged address showing up when the exception handler search took place. 17:22
And that led to a bogus handler being found
The most immediate fix is just the null out that address, though that doesn't truly fix deopt 17:23
But it fixes the test in question :)
japhb Heh 17:24
jnthn It prevents bogus handler finds, at least
I guess an even better fix is to set it to the throw address 17:25
I guess we kinda missed this one 'cus throwing exceptions while handling exceptions isn't quite so common... 17:26
17:28 MasterDuke joined
japhb jnthn: Actually, I'm surprised it doesn't come up in supply handling code more often, what with people making mistakes in QUIT handlers and such. 17:29
jnthn Well, that code also had to be hot... 17:30
japhb (I'm presuming that an error exception thrown during a control exception would count)
Ah, true -- but then in Cro websocket code, every body stream is a supply, so that code would probably get hot after ~100 frames 17:31
jnthn While looking through the bytecode dumps today while debugging I spotted no less than 3 small/easy optimizations to do... 17:33
17:35 sena_kun joined 17:37 Altai-man_ left
timotimo that sounds super interesting :) 17:41
jnthn Well, if you want to nab the in theory LHF, then: 17:43
* Supplier uses shift on an empty array which makes a Failure which is costly
* Assignment into $! from a `try` is not doing good code-gen (should be able to assume it's a Scalar and use optimized assign, it's doing the whole iscont dance)
* The facts/opt for `null` does not set the TYPEOBJ fact, so an isconcrete on a known null doesn't get constant folded in spesh 17:44
Hm, so NULLing that thing breaks stuff. 17:45
(And fixes stuff)
japhb
.oO( Waterbed theory of bugs )
 17:51
jnthn Well, I suspected just NULLing it was not going to really do 17:53
I was surprised how little it broke
Setting it to an up to date address is far more sensible, and seems to both keep the bugs fixed *and* fix the stuff I regressed by NULLing it 17:54
If anything, I've improved the state of spectest with spesh stressing...
18:02 zakharyas left 18:08 MasterDuke left
japhb Seems like a win by itself ... 18:14
jnthn Well, it should also mean merging the derived-specializations branch is unblocked. 18:19
Geth MoarVM/derived-specializations: f89ffd54cd | (Jonathan Worthington)++ | src/core/exceptions.c
Ensure return address is up to date when throwing

Previously we relied on this being reasonably up to date thanks to the last call having been made recently enough. We mostly got away with it, but inlining actually broke this (already bad) assumption. Apparently the derived specialization work has given some further opportunities for inlining (perhaps thanks to some guard tree fix along the way), and the ... (5 more lines)		 18:22
MoarVM/master: 21 commits pushed by (Jonathan Worthington)++
review: github.com/MoarVM/MoarVM/compare/f...951892a022		 18:28
jnthn There we go, derived specializations are merged 18:29
nwc10 and now beer?
jnthn Along with assorted fixes for things they showed up
Walk home, make dinner, then beer, yes :)
timotimo i'm doing the supplier one right now
18:30 MasterDuke joined
timotimo huh, neither S17-supply/syntax.t nor the /supplier-preserving.t cause that method to go into the spesh log; the static optimizer doesn't inline private methods, does it? but not even "replay" as a string shows up, even though the lexical should be accessed 18:35
jnthn Dunno, I noticed it when looking at bytecode output from spesh stressing :) 18:36
timotimo right 18:38
though i already have a change in there that might even have broken it in some very specific way so who knows
c: my $sp = Supplier::Preserving.new; $sp.emit($_ + 1) for ^1000; supply whenever $sp.Supply { print "." }; say "done";
committable6 timotimo, ¦my: «Cannot find this revision (did you mean “all”?)»
timotimo c: HEAD my $sp = Supplier::Preserving.new; $sp.emit($_ + 1) for ^1000; supply whenever $sp.Supply { print "." }; say "done";
committable6 timotimo, ¦HEAD(8b70bfb): «done␤»
timotimo need to grab the .Supply first maybe 18:39
c: HEAD my $sp = Supplier::Preserving.new; my $p = $sp.Supply; $sp.emit($_ + 1) for ^1000; supply whenever $p { print "." }; say "done";
committable6 timotimo, ¦HEAD(8b70bfb): «done␤»
timotimo is my brain rotting?
quotable6: Supplier::Preserving 18:42
quotable6 timotimo, OK, working on it! This may take up to three minutes (4582161 messages to process)
timotimo, ===SORRY!=== Error while compiling /tmp/xO9Eehnqxj␤:: not yet implemented␤at /tmp/xO9Eehnqxj:2␤------> m⦑ Supplier::⏏Preserving ⦒;␤ «exit code = 1»
timotimo haha oops
quotable6: "Supplier::Preserving"
quotable6 timotimo, OK, working on it! This may take up to three minutes (4582161 messages to process)
timotimo, 55 messages (2015-11-26⌁2018-03-30): gist.github.com/51c9cfb34de008f559...3129eae558
timotimo m: my $s := Supplier::Preserving.new; $s.emit: 42; my $ss = $s.Supply; react whenever $ss {say "here"; done}; $s.emit: 70; react whenever $ss { say "init" } 18:43
evalable6 (signal SIGHUP) here
«timed out after 10 seconds»		 18:44
jnthn Home time, bbl o/ 18:46
19:34 Altai-man_ joined 19:37 sena_kun left 20:19 lucasb joined 20:23 zakharyas joined
MasterDuke jnthn: i get two new warnings in src/spesh/arg_guard.c. `In function ‘add_nodes_for_typed_argument’`, `217:20: warning: ‘first_added’ may be used uninitialized in this function` and `271:21: warning: ‘update_node’ may be used uninitialized in this function` 20:26
20:26 hankache left
jnthn Yeah. I get less warnings now than when I started out with it, though. :) 20:30
nwc10 fewer! 20:32
(I'm going to get into trouble for that)
Altai-man_ (ooc) do derived specializations result in generated code simplification or rather set a foundation for working on that? 20:35
20:57 zakharyas left 21:09 squashable6 left 21:11 squashable6 joined 21:35 sena_kun joined 21:36 Altai-man_ left
timotimo mostly causes needing fewer candidates to handle more cases, so potentially more "interesting" candidates for any given routine? 21:58
jnthn They let us do a better job of things like Array.push, where the type of the first argument is pretty consistently the same, but the second tends to vary a lot in more realistic program 22:04
*programs
Before now, you'd make lots of specializations and then hit the limit, and beyond the limit was just the certain specialization, which knew nothing much
Now we can identify the situation and make a specialization that specializes on some arguments, but not all 22:05
timotimo so a "partially-certain specialization" essentially 22:06
22:08 leont joined 23:34 Altai-man_ joined 23:36 sena_kun left

Powered by Cro and the Raku® Programming Language.

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

Thank you!