[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 [10:21] ¦ MoarVM/gcc_root_checker_plugin: 7 commits pushed by (Stefan Seifert)++ [10:21] ¦ MoarVM/gcc_root_checker_plugin: 1fd9efae48 | Don't check MVMCompUnit and MVMStaticFrameSpesh - always allocated in gen2 [10:21] ¦ MoarVM/gcc_root_checker_plugin: 00def9fd9a | Detect simple cases of allocations in gen2 [10:21] ¦ MoarVM/gcc_root_checker_plugin: 3ecce8be88 | Don't treat variables initialized with NULL as being initialized with a GC managed object [10:21] ¦ MoarVM/gcc_root_checker_plugin: 20c4a4a249 | Warn about unncessessary MVMROOTs for MVMCompUnit and MVMStaticFrameSpesh [10:21] ¦ MoarVM/gcc_root_checker_plugin: 070d0e66a7 | No longer MVMROOT MVMCompUnits as they are always allocated in gen2 [10:21] ¦ MoarVM/gcc_root_checker_plugin: c2cf2f25b3 | Fix possible access to fromspace in MVMContext's at_key [10:21] ¦ MoarVM/gcc_root_checker_plugin: 60a1a287ea | Document cases where we know that no GC issues can appear [10:21] ¦ MoarVM/gcc_root_checker_plugin: review: https://github.com/MoarVM/MoarVM/compare/863e4104f2c1...60a1a287ea7d [10:40] ¦ MoarVM/gcc_root_checker_plugin: 7c7867c678 | (Stefan Seifert)++ | src/spesh/inline.c [10:40] ¦ MoarVM/gcc_root_checker_plugin: Fix possible access to fromspace in MVM_spesh_inline_try_get_graph_from_unspecialized [10:40] ¦ MoarVM/gcc_root_checker_plugin: [10:40] ¦ MoarVM/gcc_root_checker_plugin: MVM_spesh_facts_discover may trigger deserialization of a WVal and [10:40] ¦ MoarVM/gcc_root_checker_plugin: MVM_spesh_optimize may trigger deserialization of a method cache. Since static [10:40] ¦ MoarVM/gcc_root_checker_plugin: frames can be allocated in the nursery by freshcoderef, a GC run started by [10:40] ¦ MoarVM/gcc_root_checker_plugin: ackquiring a deserialization lock can move target_sf. [10:40] ¦ MoarVM/gcc_root_checker_plugin: [10:40] ¦ MoarVM/gcc_root_checker_plugin: While it seems incredibly unlikely that such a static frame would stay in the [10:40] ¦ MoarVM/gcc_root_checker_plugin: nursery long enough to be affected while being hot enough to trigger inlining [10:40] ¦ MoarVM/gcc_root_checker_plugin: but it's not quite impossible if the code doesn't cause any allocations. It [10:41] ¦ MoarVM/gcc_root_checker_plugin: will also become a bit more likely the better we become at avoiding allocations. [10:41] ¦ MoarVM/gcc_root_checker_plugin: review: https://github.com/MoarVM/MoarVM/commit/7c7867c678 [10:41] ¦ MoarVM/gcc_root_checker_plugin: dae0220b0c | (Stefan Seifert)++ | src/spesh/optimize.c [10:41] ¦ MoarVM/gcc_root_checker_plugin: Fix possible access to fromspace in optimize_method_lookup [10:41] ¦ MoarVM/gcc_root_checker_plugin: [10:41] ¦ MoarVM/gcc_root_checker_plugin: MVM_spesh_try_find_method may trigger deserialization of a method cache which [10:41] ¦ MoarVM/gcc_root_checker_plugin: in turn may trigger a GC run when acquiring the deserialization lock. This can [10:41] ¦ MoarVM/gcc_root_checker_plugin: cause the name pointer to become outdated while it may still get used for [10:41] ¦ MoarVM/gcc_root_checker_plugin: writing the spesh log. Simply fetch the name in question again from the spesh [10:41] ¦ MoarVM/gcc_root_checker_plugin: graph to avoid unnecessary work when the spesh log isn't being used. [10:41] ¦ MoarVM/gcc_root_checker_plugin: review: https://github.com/MoarVM/MoarVM/commit/dae0220b0c [10:59] ¦ MoarVM/master: 33 commits pushed by (Stefan Seifert)++ [10:59] ¦ MoarVM/master: review: https://github.com/MoarVM/MoarVM/compare/ab089e947f45...dae0220b0c8b [11:00] nine: time for a bump ? [11:00] And that's 30 new fixes for GC issues in this round :) [11:00] nine++ [11:00] lizmat: definitely! [11:00] oki, will do! [11:01] .oO( Spring GC Cleanup ) [11:13] nine++ # this is outstanding [11:15] nine: bumped! [11:20] *** sena_kun joined [11:22] *** Altai-man_ left [12:03] nine++ # excellent work [12:06] ¦ MoarVM: 24e9082dc9 | (Stefan Seifert)++ | tools/check-roots.py [12:06] ¦ MoarVM: Fix off-by-one error in the GCC plugin's temp root simulation [12:06] ¦ MoarVM: [12:06] ¦ MoarVM: This let us believe that stuff was rooted after an MVM_gc_root_temp_popn when [12:06] ¦ MoarVM: it really wasn't anymore. [12:06] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/24e9082dc9 [12:06] ¦ MoarVM: 899fff969a | (Stefan Seifert)++ | tools/check-roots.py [12:06] ¦ MoarVM: Have the GCC plugin warn about control flows leaving stuff on the temp root stack [12:06] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/899fff969a [12:07] nine++ (this ++ operator doesn't seem to work very well, he never reaches ten) [12:27] ¦ MoarVM: 142257b16a | (Stefan Seifert)++ | src/strings/ops.c [12:27] ¦ MoarVM: Fix possible access to fromspace in MVM_string_join [12:27] ¦ MoarVM: [12:27] ¦ MoarVM: If we need to MVMROOT result, we need to treat separator the same as it's used [12:27] ¦ MoarVM: throughout the covered code. [12:27] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/142257b16a [12:27] ¦ MoarVM: c93aa0098e | (Stefan Seifert)++ | src/core/frame.c [12:27] ¦ MoarVM: Fix possible access to fromspace in prepare_and_verify_static_frame [12:27] ¦ MoarVM: [12:27] ¦ MoarVM: MVM_validate_static_frame can cause deserialization which can trigger a GC run [12:27] ¦ MoarVM: when acquiring the deserialization lock. Thus we need to make sure our [12:27] ¦ MoarVM: static_frame pointer stays up to date. [12:27] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c93aa0098e [12:27] 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 [13:46] *** pamplemousse joined [15:00] *** krunen left [15:00] *** avarab left [15:00] *** eater left [15:00] *** krunen joined [15:00] *** avar joined [15:00] *** avar left [15:00] *** avar joined [15:02] *** eater joined [15:02] *** vesper11 left [15:03] *** vesper11 joined [15:06] *** leedo left [15:06] *** leedo joined [15:10] cool, i now think all VMArrays (that have slots allocated) are using the FSA. NQP and Rakudo both build ok and pass tests [15:17] *** zakharyas joined [15:20] *** sena_kun joined [15:22] *** Altai-man_ left [15:34] *** MasterDuke left [15:48] ¦ MoarVM: 8edc0b506a | (Stefan Seifert)++ | 2 files [15:48] ¦ MoarVM: Don't warn about GC issues in serialization code [15:48] ¦ MoarVM: [15:48] ¦ MoarVM: Serialization and deserialization code always runs with allocation in gen2 [15:48] ¦ MoarVM: active, so there's no need to warn about potential GC issues. Secure this fact [15:48] ¦ MoarVM: with a couple of debug assertions. [15:48] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8edc0b506a [15:48] ¦ MoarVM: 6fd2939ae4 | (Stefan Seifert)++ | 2 files [15:48] ¦ MoarVM: Try to fix issues by marking takenextdispatcher :noinline [15:48] ¦ MoarVM: [15:48] ¦ MoarVM: We know that takenextdispatcher as implemented is not correct and that it [15:48] ¦ MoarVM: doesn't play well with inlining. Try to mark it :noinline so we can find out [15:48] ¦ MoarVM: whether the allegations that it also breaks rakudo on Windows are true. [15:48] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6fd2939ae4 [15:53] *** MasterDuke joined [15:57] https://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:58] MasterDuke: Cool; any benchmark results? [15:58] however, https://github.com/MoarVM/MoarVM/pull/689/commits/673feec4d852e1ee875a42cfe166ab059afb841e 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 [15:59] so if anybody has any suggestions for that, much appreciated [15:59] jnthn: not yet, other than building rakudo wasn't noticeable faster [16:00] anything you think would be particularly illustrative, either in a positive or negative sense? [16:04] ugh, the commit i mentioned is now at https://github.com/MoarVM/MoarVM/pull/689/commits/f338a76ef7871def9b5a25bbaa6e60f276618571 [16:06] So it doesn't look like the GC issues on Windows are caused by inlined takenextdispatcher [16:06] 2020-04-25T13:23:19Z #raku nine when using Inline::Perl5 and a perl class object is there any way to dump its structure? i've tried [16:06] 2020-04-25T13:24:17Z #raku nine perl Data::Dump dump as well as Raku Data::Dump. [16:10] ¦ MoarVM: f636d2cde3 | (Stefan Seifert)++ | 2 files [16:10] ¦ MoarVM: Revert "JIT nextdispatcherfor" [16:11] ¦ MoarVM: [16:11] ¦ MoarVM: This reverts commit 162b68b6b676318901c7baf6fd4c4955710b6f7d. [16:11] ¦ MoarVM: [16:11] ¦ MoarVM: This commit is suspected for breaking the Windows build [16:11] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/f636d2cde3 [16:16] m: my @a; race for ^100_000_000 { @a.push($_) }; say @a.elems; say now - INIT now [16:17] rakudo-moar 18d083ead: OUTPUT: «(signal XCPU)» [16:18] 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:27] MasterDuke: Not enough on its own; you need the array size be be along with the safepointed thing [16:28] you mean updating `body.elems` and `body.ssize`? [16:38] 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 [16:47] yeah, sounds like [16:54] 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 [17:34] nine: I guess any in-process newtype won't have one, and any deserialized one will deserialize into gen2 [17:35] So probably the MVMROOT is an abundance of caution rather than needed [17:47] Yay, appveyor is green after the revert. [19:06] So now we know for sure that it's indeed takenextdispatcher [19:20] *** sena_kun joined [19:22] *** Altai-man_ left [19:33] 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 [20:19] 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] right, cool [20:20] ¦ MoarVM: 19a7154cf6 | (Stefan Seifert)++ | src/jit/graph.c [20:20] ¦ MoarVM: Enable JIT compilation of takenextdispatcher [20:20] ¦ MoarVM: [20:20] ¦ MoarVM: The JIT implementation was there, but it was missing from consume_ins [20:20] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/19a7154cf6 [20:20] If only there was a way to trigger a build on Appveyor without bumping [20:21] i think timotimo knows how? RDPing in and doing it manually or something like that? [20:21] Actually I could just open a PR with the bump [20:21] But I'd need to bump NQP anyway [20:22] rdping into appveyor only works once a build is running [20:22] but yo can actually trigger a build on appveyor without bumping [20:22] there's a button [20:22] like "redo build" or something [20:23] can't find that [20:24] where on appveyor are you looking? [20:24] changing topics, the FSA sets up each bin with a single page. however, even `raku -e ''` adds a bunch of pages (see https://gist.github.com/MasterDuke17/bf4bddee8e928526817ef2d8e892e481 stats). would it make sense to start with more pages for the smaller bins? [20:25] What difference would it make whether we allocate them now or later? [20:26] 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 [20:27] fewer calls to fixed_size_alloc that actually go through the slow path and add them [20:32] *** farcas1982regreg left [20:33] *** Kaiepi left [20:33] *** Kaiepi joined [20:36] perhaps have it in the rakudo launcher program so that it doesn't do that for nqp [20:39] Is there a way to see the actual code generated by the expr jit? [20:40] gist updated with stats for `nqp -e ''` [20:41] bins 2 and 5 are also the most common [21:07] *** Kaiepi left [21:08] *** Kaiepi joined [21:08] nine: do you mean the assembly code? [21:09] 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:14] got it :) [21:19] *** Altai-man_ joined [21:22] *** sena_kun left [21:23] So takenextdispatcher is actually ok. It's definitely nextdispatcherfor [21:25] *** farcas1982regreg joined [21:26] And now I know why [21:28] *** zakharyas left [21:31] my asm was incorrect? [21:31] *** farcas1982regreg left [21:31] .oO ( does it mean we can have a release this month ) [21:32] A very subtle mistake [21:32] Fully correct on Linux and broken indeed on Windows [21:33] argument passing with overlapping registers? [21:33] guess i don't feel too bad then [21:34] i'll just blame microsoft [21:34] ¦ MoarVM: b77aa16223 | (Stefan Seifert)++ | 2 files [21:34] ¦ MoarVM: Bring back a fixed JIT building block for nextdispatcherfor [21:34] ¦ MoarVM: [21:34] ¦ MoarVM: The original version overwrote one of the temp registers when setting up the [21:34] ¦ MoarVM: function arguments as on Windows TMP and ARG are using exactly the same [21:34] ¦ MoarVM: registers. Use an instruction order that works for Windows and Linux instead. [21:34] ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/b77aa16223 [21:34] I really just swapped lines 993 and 994 [21:36] huh, i never would have diagnosed that [21:36] nine++ [21:36] nine, what about performance penalty, is it a thing (or was it)? Any known blockers from moar side of things? [21:43] 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 [21:44] * Altai-man_ sets up release checks [21:45] 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:46] MasterDuke: I actually don't know Windows. I just read the define lists in our source :) https://github.com/MoarVM/MoarVM/blob/master/src/jit/x64/emit.dasc#L153 [21:47] *** Kaiepi left [21:47] read the source...reason about it...who does that? turns out someone who wants software to work correctly does... [21:48] Appveyor looks happy. That means......that actually I wouldn't have had to do those GC fixes :/ [21:49] Too bad :D [21:50] 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:51] But I don't know how long it'll take to get right. [21:51] I think it's better not to rush such things anyway :) [21:51] Indeed [21:51] *** Kaiepi joined [21:52] Off to bed now...good night! [21:53] 'night o/ [22:37] oops, seems we suddenly got a big perf regression [22:38] one of my test programs suddenly went from ~3 secs to ~8secs [22:41] sigh [22:42] let me see if I can find the offending commit [22:44] here's the culprit https://github.com/MoarVM/MoarVM/commit/6fd2939ae4ddfff973a647e15ddf2cbccabe614c [22:45] yeah, ouch [22:46] question is, did nine just forget to revert it, it seems to have been an experiment after all [22:46] would be nice if it could get reverted [22:48] any takers or should we wait until nine++ wakes up? [22:48] dogbert17, why rush? [22:49] Altai-man_: got the impression that you're planning a release :) [22:50] 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:51] 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] ok, we'll wait for nine then. I'm quite certain that he'll backlog [22:51] I assume that you're no referring to a test with 'kill' in the name [22:51] *not [22:51] * Altai-man_ started blin, now sleep time [22:52] dogbert17, alas, not. :( [22:53] 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:54] 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 [23:16] 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