github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
02:41 notable6 left, greppable6 left, quotable6 left, linkable6 left, committable6 left, tellable6 left, benchable6 left, evalable6 left, coverable6 left, shareable6 left, nativecallable6 left, bloatable6 left, releasable6 left, statisfiable6 left, bisectable6 left, squashable6 left, sourceable6 left, unicodable6 left 02:42 linkable6 joined, statisfiable6 joined, greppable6 joined, sourceable6 joined, evalable6 joined, nativecallable6 joined, unicodable6 joined 02:43 squashable6 joined, notable6 joined, shareable6 joined, bisectable6 joined, benchable6 joined 02:44 bloatable6 joined, quotable6 joined, tellable6 joined, committable6 joined, coverable6 joined 02:45 releasable6 joined 07:20 linkable6 left 07:21 linkable6 joined
nwc10 good *, #moarvm 07:39
07:49 squashable6 left 07:50 squashable6 joined 07:57 Kaiepi left 07:59 domidumont joined 08:01 squashable6 left 08:02 squashable6 joined 08:06 Kaiepi joined
nwc10 nine: you'll like this. cherry-picking just 298298aaac65e71 (Fix spesh removing not-really-dead code) onto MoarVM master fixes the SEGV, but if one is running with MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 MVM_SPESH_CHECK_DU=1 it *instead* causes (or exposes) a test failure in t/spec/S09-multidim/assign.t -- not ok 37 - Cannot assign to many items at first dimension (native) 08:20
and t/spec/S22-package-format/local.t -- Type check failed in binding to parameter '$bytes'; expected Blob but got Supplier::Preserving (Supplier::Preserving...) 08:32
In the middle of adding a comment to github.com/MoarVM/MoarVM/pull/1451 08:44
the failure exposed in t/spec/S22-package-format/local.t is actually a JIT bug
comment done. I'm not (currently) investigating futher 08:51
oh, for reference, the SEGV that I found that the MoarVM branch fixes was exposed by rakudo commit a7c57a01e82f09d0bb3a8270e91abca0deafa520 -- Make subtest output a header
08:52 linkable6 left
nwc10 there is zero obvious connection between the two 08:52
08:54 linkable6 joined
nine nwc10: this is hilarious. I tried to golf S09-multidim/assign.t and found that the test starts to pass once I remove tests that come _after_ it 09:00
nwc10 also, ./rakudo-m -Ilib t/spec/S22-package-format/local.t 09:01
now reliably passes for me. It had reliably failed.
nine Oh, assign.t doesn't actually fail reliably 09:03
nwc10 hash randomistation hates everyone. 09:05
nine disabling that right now 09:06
Ah, it's hash randomisation's fault! Disabling that makes the failure go away ;)
Using a salt of 2 makes it fail reliably 09:11
But it still needs those trailing tests which makes me think memory layout
09:21 sena_kun joined
nine nwc10: ooh...with salt 2 it fails even without my commit 09:22
And Spesh of 'process' (cuid: 7125, file: SETTING::src/core.c/native_array.pm6:2132) which is the frame that makes it failing is identical with and without my commit 09:26
nwc10 oh. strange. so it was a random failure I saw several times? 09:39
nine Apparently, yes 09:44
Turn off hash randomization and set the salt to 2 and it fails 09:45
09:58 frost-lab joined
nine nwc10: oh, this is lovely. The expected exception is "Index 2 for dimension 2 out of range (must be 0..1)" which is thrown by the nqp::atposnd_i implementation. 10:04
The line containing that op is "nqp::atposnd_i($!list,$!indices) # boom!" at github.com/rakudo/rakudo/blob/mast....pm6#L2166
So the op is called specifically for the side effect of throwing that exception.
However, the op is marked :pure in MoarVM's oplist. Since we don't actually use the returned value, spesh concludes that it's free to remove the pure op completely. And indeed in the speshed version the op is gone. 10:05
So no exception gets thrown and the test correctly fails.
The only thing about this I don't understand is why it depends on hash randomization to occur. 10:06
nwc10 does randomisation change *what* gets speshed 10:16
that was always the thing that I remember jnthn saying - randomisation can change the recorded paths sufficiently that sometimes different optimisations win first 10:17
nine No. And as I said, in both cases I get the exact same result in the spesh log
nwc10 oops. sorry for the confusion. But I also don't see what you wrote that meant "I get the exact same result in the spesh log" 10:18
what you wrote the first time. (hence my misunderstanding)
nine This sentence was supposed to express that :) "And Spesh of 'process' (cuid: 7125, file: SETTING::src/core.c/native_array.pm6:2132) which is the frame that makes it failing is identical with and without my commit" 10:20
nwc10 oh, I thought you meant "With and without the salt being 2" 10:21
nine Actually....yes :D 10:22
but let me check to be sure
10:27 linkable6 left 10:28 linkable6 joined
nine And of course there are quite a few differences in the spesh result most notably inlining of the .throw call 10:30
But neither versions contain the atposnd_i call 10:32
Since the exception gets thrown I can only conclude that the speshed version is not actually run, despite getting created 10:34
nwc10 but one version passes the test (by throwing and catching the exception)?
and the other version fails the test (no exception)?
other possibility (and I remember being somewhere near some of this code) is that the same exception can be thrown by a second op 10:35
is there atpos and then bindpos?
nine Only this one op can throw this exact exception. And in gdb I clearly see that tc->cur_frame does not have a spesh_cand 10:36
And that the exception does get thrown in the atposnd_i op
10:37 linkable6 left, linkable6 joined
nwc10 I'm not sure what I can add that's useful 10:44
10:46 linkable6 left
lizmat if it is a problem that atposnd_i is called fits exception, I can probably work around that in Raudo 10:47
10:47 linkable6 joined
lizmat *Rakudo 10:47
nwc10 I thought that we were keen to figure out what the bug was and hence fix it 10:49
nine The :pure marker is clearly wrong as the op does have a side effect (throwing an exception if appropriate) 10:50
As it is spesh must only remove the op if it can prove that the indexes passed to it are safe. 10:51
The whole quest to find out why it depends on hash randomization is more for gaining a better understanding of what exactly happens. My hypothesis is that hash randomization affects the order some things are run and thus the availability of spesh candidates when we're looking for inlining possibilities. 10:54
lizmat fwiw, I have a long standing feeling that some setting builds are intrinisically faster / slower than others, even with minimal changes 10:55
and I wonder whether that has to do with hash randomization 11:10
11:11 linkable6 left 11:13 linkable6 joined 11:24 linkable6 left 11:26 linkable6 joined
nwc10 lizmat: yes, likely faster/slower could be chance due to hash randomsiation, affecting spesh 11:26
11:31 linkable6 left
nwc10 I can also get t/spec/S22-package-format/local.t to fail on master on a different machine, so it's not the change on your branch 11:33
11:33 linkable6 joined 11:34 linkable6 left 11:35 linkable6 joined 11:36 linkable6 left 11:37 linkable6 joined 11:42 linkable6 left 11:43 linkable6 joined 11:54 linkable6 left 11:57 linkable6 joined 12:06 linkable6 left 12:07 linkable6 joined 12:09 Kaiepi left 12:10 Kaiepi joined 12:45 domidumont left 12:47 linkable6 left 12:49 linkable6 joined 12:55 ggoebel left
nine nwc10: FWIW I'm pretty sure I've seen the "Type check failed in binding to parameter '$bytes'; expected Blob but got Supplier::Preserving" before 13:35
13:36 frost-lab left 13:56 squashable6 left 13:57 squashable6 joined
Geth MoarVM/master: 6 commits pushed by (Stefan Seifert)++, niner++ 13:58
14:15 domidumont joined 14:19 domidumont left
dogbert17 and suddenly all remaining MoarVM bugs were fixed :) nine++ 16:27
16:52 evalable6 left, linkable6 left 16:54 evalable6 joined 16:55 linkable6 joined 17:09 domidumont joined
lizmat so, time for a bump ? 17:30
17:43 domidumont left 18:21 zakharyas joined
dogbert17 +1 for bump 18:46
19:19 zakharyas left
nine That's included in the rakudo PR for backtraces 19:52
20:01 zakharyas joined 21:23 zakharyas left
leont started a branch on moarvm years ago that now seems lost (not that it really matters, I sincerely doubt it was rebasable at this point) 21:30
MasterDuke there has been the occasional pruning of branches, but i don't remember any particularly recently 21:40
Geth MoarVM: MasterDuke17++ created pull request #1456:
Save malloc+free per frame when creating backtrace		 21:41
leont MasterDuke: I don't think it was pushed to the official repo, I don't even think I have permissions to do so 21:49
It only existed on my hard-drive, on an older computer 21:50
I tried adding asynchronous pipe support, which I had needed for a project then and seem to be needing again for something different 21:52
MasterDuke ah 21:58
leont It's a rakudo feature that's 90% a moarvm feature 22:08
In this case, it involves a refactor of the socket support because a bunch of stuff is the same (e.g. reading), but another bunch isn't (e.g. connecting) 23:22

Powered by Cro and the Raku® Programming Language.

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

Thank you!