[01:09] *** konvertex left [05:44] good *, #moarvm [06:42] *** domidumont joined [07:42] *** zakharyas joined [08:06] *** sena_kun joined [08:21] https://news.ycombinator.com/item?id=23212620 the actual article, comments, and other papers/articles referenced are all very interesting [08:21] but i don't know how much time moarvm spends sorting things [08:26] *** Altai-man_ joined [08:28] *** sena_kun left [08:51] *** konvertex joined [09:18] *** Prince213 joined [09:19] *** Prince213 left [09:30] morning o/ [09:38] jnthn o/ [09:39] \o [09:40] jnthn: I had a question. MVM_6model_add_container_config does MVM_gc_root_add_permanent_desc (twice) whereas the seemingly analogus MVM_load_bytecode() does nothing. [09:40] so is the former doing unneeded work, or the latter missing one? [09:41] ("twice" seems to be a separate thing - I don't think that entry->name is ever read again [09:41] but I've not checked that carefully) [10:18] nwc10: I guess you're referring to the loaded_compunits hash; this is walked in src/gc/roots.c. By contrast, container_registry is not. [10:21] Monday morning admin done...time to hack. [10:21] jnthn: and that is what I missed [10:22] (thanks) [10:26] *** sena_kun joined [10:28] *** Altai-man_ left [10:33] OK, good, so make test in Rakudo is clear with JIT/OSR/inline disabled (and spesh blocking enabled), and then has assorted explosions with inline enabled, giving me a good set of candidates to figure out what is going on. [10:35] Good hunting! [10:35] 2020-05-17T01:43:49Z #raku-dev nine Was close, but recent changes in PrecompilationStore necessitated another solution. [10:43] *** Kaeipi joined [10:43] *** Kaiepi left [10:45] heh, it's seemingly putting us in a totally bogus place after deopt... [11:10] D'oh, that was silly... [11:10] ¦ MoarVM/new-disp: 4b3f914c21 | (Jonathan Worthington)++ | src/spesh/deopt.c [11:10] ¦ MoarVM/new-disp: Remove a now-unused argument to uninline [11:10] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/4b3f914c21 [11:10] ¦ MoarVM/new-disp: 5495b1b6d9 | (Jonathan Worthington)++ | src/core/frame.c [11:10] ¦ MoarVM/new-disp: Null out spesh_cand when making a deopt frame [11:10] ¦ MoarVM/new-disp: [11:10] ¦ MoarVM/new-disp: There are some things we can get away with leaving as junk in a frame. [11:10] ¦ MoarVM/new-disp: This is not one of them. [11:10] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/5495b1b6d9 [11:17] Oh boy.... when looking at https://github.com/MoarVM/MoarVM/commit/af1f04aaf9d06b2a3daf27ab54a38b201736840a I was wondering whether initializing only a few select fields was a bit fragile and if it wasn't better to memset it at first and narrow it down once you have a stable base [11:18] But of course I didn't say any of this loud [11:20] Was mostly going on "what do we normally get away with", but missed that bit. [11:21] "This is not one of them" :-) [11:27] *** zakharyas left [11:30] *** Prince213 joined [11:53] *** Prince213 left [11:53] *** Prince213 joined [11:53] *** Prince213 left [11:57] Some lunch later... [11:58] Spectest seems to look about the same with inlining or without [11:58] Still got some kind of deopt-related trouble, I think 'cus I removed a terrible workaround... [11:59] Next question is what state the JIT is in. [12:00] denial? Massachusetts? solid? [12:00] *** Prince213 joined [12:00] In theory it should be fine. :) [12:00] It's made it to CORE.setting build so far [12:00] So through all of NQP and NQP tests [12:01] In theory OSR doesn't need updating, but I need to check that also [12:03] Didn't spectest, but JIT does the rakudo build and make test. [12:03] Will spectest with OSR thrown into the mix too [12:06] *** Prince213 left [12:11] OK, seems we're no worse with JIT and OSR. [12:16] Yup, so...bug hunting wise, "just" that deopt thing to hunt, though I may defer that and get back to the dispatcher stuff that caused me to go and do all of this callstack refactoring for a bit... :) [12:17] *** konvertex left [12:26] *** Altai-man_ joined [12:26] *** Prince213 joined [12:26] *** Prince213 left [12:28] *** sena_kun left [13:14] *** konvertex joined [13:20] *** zakharyas joined [14:09] *** jjatria left [14:09] *** jjatria joined [14:11] *** jjatria left [14:27] *** sena_kun joined [14:28] *** Altai-man_ left [16:26] *** Altai-man_ joined [16:28] *** sena_kun left [16:43] ¦ MoarVM/new-disp: b924234023 | (Jonathan Worthington)++ | src/core/interp.c [16:43] ¦ MoarVM/new-disp: Make sure to set return address on dispatch [16:43] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/b924234023 [16:43] ¦ MoarVM/new-disp: 1ac55d4de6 | (Jonathan Worthington)++ | src/gc/debug.h [16:43] ¦ MoarVM/new-disp: Make GC debug macro more robust [16:43] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/1ac55d4de6 [16:43] ¦ MoarVM/new-disp: ac9b65ea7a | (Jonathan Worthington)++ | 15 files [16:43] ¦ MoarVM/new-disp: First steps towards dispatch programs [16:43] ¦ MoarVM/new-disp: [16:43] ¦ MoarVM/new-disp: With this, the built-in `boot-value` and `boot-constant` dispatchers can [16:43] ¦ MoarVM/new-disp: now be invoked, and will produce a result. This does not yet result in [16:44] ¦ MoarVM/new-disp: the construction of a dispatch program to optimize the dispatch, so the [16:44] ¦ MoarVM/new-disp: slow-path `dispatch` is called every time. However, the various hooks to [16:44] ¦ MoarVM/new-disp: do that are now in place. [16:44] ¦ MoarVM/new-disp: [16:44] ¦ MoarVM/new-disp: For the moment, however, only very boring dispatch programs can be [16:44] ¦ MoarVM/new-disp: recorded, so it's probably rather more interesting to make some more [16:44] ¦ MoarVM/new-disp: possibilities there first. [16:44] ¦ MoarVM/new-disp: review: https://github.com/MoarVM/MoarVM/commit/ac9b65ea7a [17:16] To be continued, most probably on Wednesday :) [17:17] yay [17:32] *** jjatria joined [17:40] *** domidumont left [17:55] .but what can someone do in the mean time to make it easier for you when you come back to it? :3 [17:55] i see some // XXX TODO comments [17:57] *** lucasb joined [17:58] i assume in disp_program_record_result_constant the "record the result action" that currently just finds the topmost recording and stashes the value, it'd want to put more info in there? it currently only stores "outcome", and the only other thing it could be writing into that struct is the args capture thingie [18:01] disp_program_record_end currently only has DISP_OUTCOME_VALUE, maybe that's a good spot to add a little bit? like a "set up invocation and continue" piece for OUTCOME_BYTECODE [18:02] "compile program" in record_end is literally about writing a bit of mvm bytecode and a corresponding frame to hold it? [18:03] not sure if we can add frames to a compunit that's already loaded or if we have to have a compilation unit for each frame we compile [18:03] *** brrt joined [18:04] \o [18:04] brrt o/ [18:04] do we have a quick way to find out if MoarVM is running on a big-endian or a little-endian system ? [18:05] we've got a #define i think? [18:05] ohai lizmat [18:06] yeah, I'm sure we have a define [18:06] but how is that exposed in Raku ? [18:06] hm. nqp::backendconfig? [18:06] '#define MVM_BIGENDIAN 0' [18:09] I don't think we export the endianness (endianity?) using the backendconfig [18:10] judging from the implementation in config.c [18:10] m: dd $*VM.config [18:10] rakudo-moar 44b270196: OUTPUT: «"0"␤» [18:10] could that be it ? [18:10] .o( it could "be" ) [18:14] *** Kaeipi left [18:17] *** Kaiepi joined [18:26] *** sena_kun joined [18:28] *** Altai-man_ left [18:31] hmm [18:34] yes, it is [18:34] but I'm not sure how it's set [18:34] m: dd Kernel.endian # apparently I've asked this question before :-) [18:34] rakudo-moar 95f7d34e8: OUTPUT: «Endian::LittleEndian␤» [18:36] lizmat: it comes from perl's $Config{byteorder} during configuration [19:07] brrt: o/ [19:15] ohai nwc10 [19:37] *** brrt left [19:55] *** zakharyas left [20:09] timotimo: (what can people do) one that may not be so bad is to fix up continuation profiling, 'cus for now it just has a "fix me" panic [20:22] that's a fun area in general [20:26] *** Altai-man_ joined [20:28] *** sena_kun left [21:56] *** raku-bridge2 joined [21:56] *** raku-bridge2 left [21:56] *** raku-bridge2 joined [21:56] *** raku-bridge left [21:57] *** raku-bridge2 is now known as raku-bridge [22:06] *** Kaiepi left [22:06] *** Kaiepi joined [22:25] *** Altai-man_ left