github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:19 Altai-man_ joined 01:21 sena_kun left 01:28 lucasb left 02:05 Kaiepi left 02:06 Kaiepi joined 03:20 sena_kun joined 03:21 Altai-man_ left 04:01 pamplemousse joined 04:48 pamplemousse left 04:49 pamplemousse joined 04:51 pamplemo_ joined 04:53 pamplemousse left 04:55 pamplemo_ left 05:19 Altai-man_ joined 05:22 sena_kun left 05:23 pamplemousse joined 05:27 pamplemousse left 05:59 pamplemousse joined 06:04 pamplemousse left 07:20 sena_kun joined 07:22 Altai-man_ left 09:19 Altai-man_ joined 09:22 sena_kun left 10:10 farcas1982regreg joined
Geth MoarVM/gcc_root_checker_plugin: 7 commits pushed by (Stefan Seifert)++ 10:21
MoarVM/gcc_root_checker_plugin: 7c7867c678 | (Stefan Seifert)++ | src/spesh/inline.c
Fix possible access to fromspace in MVM_spesh_inline_try_get_graph_from_unspecialized

MVM_spesh_facts_discover may trigger deserialization of a WVal and MVM_spesh_optimize may trigger deserialization of a method cache. Since static frames can be allocated in the nursery by freshcoderef, a GC run started by ackquiring a deserialization lock can move target_sf.
While it seems incredibly unlikely that such a static frame would stay in the nursery long enough to be affected while being hot enough to trigger inlining but it's not quite impossible if the code doesn't cause any allocations. It will also become a bit more likely the better we become at avoiding allocations.		 10:40
MoarVM/gcc_root_checker_plugin: dae0220b0c | (Stefan Seifert)++ | src/spesh/optimize.c
Fix possible access to fromspace in optimize_method_lookup

MVM_spesh_try_find_method may trigger deserialization of a method cache which in turn may trigger a GC run when acquiring the deserialization lock. This can cause the name pointer to become outdated while it may still get used for writing the spesh log. Simply fetch the name in question again from the spesh graph to avoid unnecessary work when the spesh log isn't being used.
MoarVM/master: 33 commits pushed by (Stefan Seifert)++
review: github.com/MoarVM/MoarVM/compare/a...e0220b0c8b		 10:59
lizmat nine: time for a bump ? 11:00
nine And that's 30 new fixes for GC issues in this round :)
lizmat nine++
nine lizmat: definitely!
lizmat oki, will do!
.oO( Spring GC Cleanup )
 11:01
Altai-man_ nine++ # this is outstanding 11:13
lizmat nine: bumped! 11:15
11:20 sena_kun joined 11:22 Altai-man_ left
jnthn nine++ # excellent work 12:03
Geth MoarVM: 24e9082dc9 | (Stefan Seifert)++ | tools/check-roots.py
Fix off-by-one error in the GCC plugin's temp root simulation

This let us believe that stuff was rooted after an MVM_gc_root_temp_popn when it really wasn't anymore.		 12:06
MoarVM: 899fff969a | (Stefan Seifert)++ | tools/check-roots.py
Have the GCC plugin warn about control flows leaving stuff on the temp root stack
MasterDuke nine++ (this ++ operator doesn't seem to work very well, he never reaches ten) 12:07
Geth MoarVM: 142257b16a | (Stefan Seifert)++ | src/strings/ops.c
Fix possible access to fromspace in MVM_string_join

If we need to MVMROOT result, we need to treat separator the same as it's used throughout the covered code.		 12:27
MoarVM: c93aa0098e | (Stefan Seifert)++ | src/core/frame.c
Fix possible access to fromspace in prepare_and_verify_static_frame

MVM_validate_static_frame can cause deserialization which can trigger a GC run when acquiring the deserialization lock. Thus we need to make sure our static_frame pointer stays up to date.
nine These two appeared after fixing the off-by-one error
13:08 pamplemousse joined 13:10 pamplemousse left 13:11 pamplemousse joined 13:19 Altai-man_ joined 13:22 sena_kun left 13:46 pamplemousse left, pamplemousse joined 15:00 krunen left, avarab left, eater left, krunen joined, avar joined, avar left, avar joined 15:02 eater joined, vesper11 left 15:03 vesper11 joined 15:06 leedo left, leedo joined
MasterDuke cool, i now think all VMArrays (that have slots allocated) are using the FSA. NQP and Rakudo both build ok and pass tests 15:10
15:17 zakharyas joined 15:20 sena_kun joined 15:22 Altai-man_ left 15:34 MasterDuke left
Geth MoarVM: 8edc0b506a | (Stefan Seifert)++ | 2 files
Don't warn about GC issues in serialization code

Serialization and deserialization code always runs with allocation in gen2 active, so there's no need to warn about potential GC issues. Secure this fact with a couple of debug assertions.		 15:48
MoarVM: 6fd2939ae4 | (Stefan Seifert)++ | 2 files
Try to fix issues by marking takenextdispatcher :noinline

We know that takenextdispatcher as implemented is not correct and that it doesn't play well with inlining. Try to mark it :noinline so we can find out whether the allegations that it also breaks rakudo on Windows are true.
15:53 MasterDuke joined
MasterDuke github.com/MoarVM/MoarVM/pull/689 now converts all uses of VMArray to use the FSA (so the final commit removes the header flag setting and checking) and NQP and Rakudo build ok and pass tests 15:57
jnthn MasterDuke: Cool; any benchmark results? 15:58
MasterDuke however, github.com/MoarVM/MoarVM/pull/689/...059afb841e is a little less than ideal. in it i copy some memory because it wasn't created with the FSA, and it looked like it would be a bit annoying to fix the place where the memory is first allocated
so if anybody has any suggestions for that, much appreciated 15:59
jnthn: not yet, other than building rakudo wasn't noticeable faster
anything you think would be particularly illustrative, either in a positive or negative sense? 16:00
ugh, the commit i mentioned is now at github.com/MoarVM/MoarVM/pull/689/...f276618571 16:04
nine So it doesn't look like the GC issues on Windows are caused by inlined takenextdispatcher 16:06
tellable6 2020-04-25T13:23:19Z #raku <tbrowder> nine when using Inline::Perl5 and a perl class object is there any way to dump its structure? i've tried
2020-04-25T13:24:17Z #raku <tbrowder> nine perl Data::Dump dump as well as Raku Data::Dump.
Geth MoarVM: f636d2cde3 | (Stefan Seifert)++ | 2 files
Revert "JIT nextdispatcherfor"

This reverts commit 162b68b6b676318901c7baf6fd4c4955710b6f7d.
This commit is suspected for breaking the Windows build		 16:10
MasterDuke m: my @a; race for ^100_000_000 { @a.push($_) }; say @a.elems; say now - INIT now 16:16
camelia (signal XCPU) 16:17
MasterDuke that ^^^ segfaults on my machine on master. however, it also does so on my branch. my understanding was that using MVM_fixed_size_realloc_at_safepoint should have made it safe from segfault 16:18
jnthn MasterDuke: Not enough on its own; you need the array size be be along with the safepointed thing 16:27
MasterDuke you mean updating `body.elems` and `body.ssize`? 16:28
jnthn Yes; at least ssize has to live in the same memory as the allocated slots, and you must only ever deference it once in a given operation and bounds check any access into the memory against the ssize 16:38
tbh I'd do this as a separate follow-up change
MasterDuke yeah, sounds like 16:47
nine Could we ever find ourselves with an STable in the nursery that has a not yet deserialized HOW? 16:54
And could we ever find ourselves with an STable in the nursery that has a not-yet-deserialized method_cache? That seems more unlikely. But if not, why do we MVMROOT st in MVM_serialization_finish_deserialize_method_cache?
17:19 Altai-man_ joined 17:22 sena_kun left
jnthn nine: I guess any in-process newtype won't have one, and any deserialized one will deserialize into gen2 17:34
So probably the MVMROOT is an abundance of caution rather than needed 17:35
Altai-man_ Yay, appveyor is green after the revert. 17:47
nine So now we know for sure that it's indeed takenextdispatcher 19:06
19:20 sena_kun joined 19:22 Altai-man_ left
MasterDuke nine: any idea if it's the implementation of takenextdispatcher, or my jitting of it? 19:33
oh, my jitting was of nextdispatcherfor
19:43 lucasb joined
nine MasterDuke: oh...actually, the commit enabled JIT of both, takenextdispatcher and nextdispatcherfor. So I'm re-enabling takenextdispatcher now to see which one is causing the issue 20:19
MasterDuke right, cool
Geth MoarVM: 19a7154cf6 | (Stefan Seifert)++ | src/jit/graph.c
Enable JIT compilation of takenextdispatcher

The JIT implementation was there, but it was missing from consume_ins		 20:20
nine If only there was a way to trigger a build on Appveyor without bumping
MasterDuke i think timotimo knows how? RDPing in and doing it manually or something like that? 20:21
nine Actually I could just open a PR with the bump
But I'd need to bump NQP anyway
timotimo rdping into appveyor only works once a build is running 20:22
but yo can actually trigger a build on appveyor without bumping
there's a button
like "redo build" or something
nine can't find that 20:23
timotimo where on appveyor are you looking? 20:24
MasterDuke changing topics, the FSA sets up each bin with a single page. however, even `raku -e ''` adds a bunch of pages (see gist.github.com/MasterDuke17/bf4bd...d8e892e481 stats). would it make sense to start with more pages for the smaller bins?
nine What difference would it make whether we allocate them now or later? 20:25
timotimo it'd be possible to allocate 10x the size of one page, then taking pointers inside for each page 20:26
that'd possibly mean fewer sys calls to grow memory, or could even be mmapped
MasterDuke fewer calls to fixed_size_alloc that actually go through the slow path and add them 20:27
20:32 farcas1982regreg left 20:33 Kaiepi left, Kaiepi joined
timotimo perhaps have it in the rakudo launcher program so that it doesn't do that for nqp 20:36
nine Is there a way to see the actual code generated by the expr jit? 20:39
MasterDuke gist updated with stats for `nqp -e ''` 20:40
bins 2 and 5 are also the most common 20:41
21:07 Kaiepi left 21:08 Kaiepi joined
timotimo nine: do you mean the assembly code? 21:08
for that you'll want MVM_JIT_DUMP_BYTECODE as well as objdump -D -b binary -m i386:x86-64 -M intel /tmp/moar-jit.1234/moar-1234.bin 21:09
nine got it :) 21:14
21:19 Altai-man_ joined 21:22 sena_kun left
nine So takenextdispatcher is actually ok. It's definitely nextdispatcherfor 21:23
21:25 farcas1982regreg joined
nine And now I know why 21:26
21:28 zakharyas left
MasterDuke my asm was incorrect? 21:31
21:31 farcas1982regreg left
Altai-man_ .oO ( does it mean we can have a release this month ) 21:31
nine A very subtle mistake 21:32
Fully correct on Linux and broken indeed on Windows
timotimo argument passing with overlapping registers? 21:33
MasterDuke guess i don't feel too bad then
i'll just blame microsoft 21:34
Geth MoarVM: b77aa16223 | (Stefan Seifert)++ | 2 files
Bring back a fixed JIT building block for nextdispatcherfor

The original version overwrote one of the temp registers when setting up the function arguments as on Windows TMP and ARG are using exactly the same registers. Use an instruction order that works for Windows and Linux instead.
nine I really just swapped lines 993 and 994
MasterDuke huh, i never would have diagnosed that 21:36
nine++
Altai-man_ nine, what about performance penalty, is it a thing (or was it)? Any known blockers from moar side of things?
nine MasterDuke: it became somewhat obvious after I on a hunch replaced the symbolic register names with the actual ones used on Windows 21:43
Altai-man_: no idea about performance. But we're arguably correcter now than on the previous release and that has always been more important
Altai-man_ sets up release checks 21:44
MasterDuke nine: it's good someone knows windows. i've written very little asm in my life, and none of it was ever done on windows (or done to be run primarily on windows ) 21:45
nine MasterDuke: I actually don't know Windows. I just read the define lists in our source :) github.com/MoarVM/MoarVM/blob/mast....dasc#L153 21:46
21:47 Kaiepi left
MasterDuke read the source...reason about it...who does that? turns out someone who wants software to work correctly does... 21:47
nine Appveyor looks happy. That means......that actually I wouldn't have had to do those GC fixes :/ 21:48
Too bad :D 21:49
jnthn Ah phew, this means I don't need to overly hurry myself on the new dispatcher stuff, then, it seems. (Though still, much of my next week remains allocated to it. :-)) 21:50
But I don't know how long it'll take to get right. 21:51
nine I think it's better not to rush such things anyway :)
jnthn Indeed
21:51 Kaiepi joined
nine Off to bed now...good night! 21:52
jnthn 'night o/ 21:53
dogbert17 oops, seems we suddenly got a big perf regression 22:37
one of my test programs suddenly went from ~3 secs to ~8secs 22:38
Altai-man_ sigh 22:41
dogbert17 let me see if I can find the offending commit 22:42
here's the culprit github.com/MoarVM/MoarVM/commit/6f...bccabe614c 22:44
timotimo yeah, ouch 22:45
dogbert17 question is, did nine just forget to revert it, it seems to have been an experiment after all 22:46
timotimo would be nice if it could get reverted
dogbert17 any takers or should we wait until nine++ wakes up? 22:48
Altai-man_ dogbert17, why rush?
dogbert17 Altai-man_: got the impression that you're planning a release :) 22:49
Altai-man_ Alas, I am seeing some quite reliable spectest failures, as well as have to prepare a blin, so no real need to rush until all of this will be investigated properly. 22:50
What I hate the most is when you run stresstest and one test fails reliably regardless of number of workers, but when you fudgeandrun it directly it passes fine. 22:51
dogbert17 ok, we'll wait for nine then. I'm quite certain that he'll backlog
I assume that you're no referring to a test with 'kill' in the name
*not
Altai-man_ started blin, now sleep time
dogbert17, alas, not. :( 22:52
dogbert17 I believe that two stresstests are broken, i.e. t/spec/MISC/bug-coverage-stress.rakudo.moar and t/spec/S17-procasync/kill.t 22:53
Altai-man_ e.g. on 6.c-errata branch S32-str/encode.t has failed for me like 3 times in a row, others are fine. What is a mystery is that on master there were no commits there, so they are mostly identical and should work. 22:54
Yes, those two are not at fault this time. Anyway, Blin is working, can't provide more info yet. Good night. o/
23:06 Altai-man_ left
dogbert17 dogbert@dogbert-VirtualBox ~/repos/rakudo $ ./perl6-m -Ilib t/spec/S32-str/encode.t 23:16
===SORRY!=== chr codepoint 16777215 (0xFFFFFF) is out of bounds

Powered by Cro and the Raku® Programming Language.

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

Thank you!