github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:09 konvertex left
nwc10 good *, #moarvm 05:44
06:42 domidumont joined 07:42 zakharyas joined 08:06 sena_kun joined
MasterDuke 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
jnthn morning o/ 09:30
lizmat jnthn o/ 09:38
nwc10 \o 09:39
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?
("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)
jnthn 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:18
Monday morning admin done...time to hack. 10:21
nwc10 jnthn: and that is what I missed
(thanks) 10:22
10:26 sena_kun joined 10:28 Altai-man_ left
jnthn 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:33
nine Good hunting! 10:35
tellable6 2020-05-17T01:43:49Z #raku-dev <Xliff> nine Was close, but recent changes in PrecompilationStore necessitated another solution.
10:43 Kaeipi joined, Kaiepi left
jnthn heh, it's seemingly putting us in a totally bogus place after deopt... 10:45
D'oh, that was silly... 11:10
Geth MoarVM/new-disp: 4b3f914c21 | (Jonathan Worthington)++ | src/spesh/deopt.c
Remove a now-unused argument to uninline
MoarVM/new-disp: 5495b1b6d9 | (Jonathan Worthington)++ | src/core/frame.c
Null out spesh_cand when making a deopt frame

There are some things we can get away with leaving as junk in a frame. This is not one of them.
nine Oh boy.... when looking at github.com/MoarVM/MoarVM/commit/af...201736840a 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:17
But of course I didn't say any of this loud 11:18
jnthn Was mostly going on "what do we normally get away with", but missed that bit. 11:20
nwc10 "This is not one of them" :-) 11:21
11:27 zakharyas left 11:30 Prince213 joined 11:53 Prince213 left, Prince213 joined, Prince213 left
jnthn Some lunch later... 11:57
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...
Next question is what state the JIT is in. 11:59
MasterDuke denial? Massachusetts? solid? 12:00
12:00 Prince213 joined
jnthn In theory it should be fine. :) 12:00
It's made it to CORE.setting build so far
So through all of NQP and NQP tests
In theory OSR doesn't need updating, but I need to check that also 12:01
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
jnthn OK, seems we're no worse with JIT and OSR. 12:11
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:16
12:17 konvertex left 12:26 Altai-man_ joined, Prince213 joined, Prince213 left 12:28 sena_kun left 13:14 konvertex joined 13:20 zakharyas joined 14:09 jjatria left, 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
Geth MoarVM/new-disp: b924234023 | (Jonathan Worthington)++ | src/core/interp.c
Make sure to set return address on dispatch
 16:43
MoarVM/new-disp: 1ac55d4de6 | (Jonathan Worthington)++ | src/gc/debug.h
Make GC debug macro more robust
MoarVM/new-disp: ac9b65ea7a | (Jonathan Worthington)++ | 15 files
First steps towards dispatch programs

With this, the built-in `boot-value` and `boot-constant` dispatchers can now be invoked, and will produce a result. This does not yet result in the construction of a dispatch program to optimize the dispatch, so the slow-path `dispatch` is called every time. However, the various hooks to do that are now in place.
For the moment, however, only very boring dispatch programs can be recorded, so it's probably rather more interesting to make some more possibilities there first.
jnthn To be continued, most probably on Wednesday :) 17:16
Altai-man_ yay 17:17
17:32 jjatria joined 17:40 domidumont left
timotimo .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
timotimo 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 17:58
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:01
"compile program" in record_end is literally about writing a bit of mvm bytecode and a corresponding frame to hold it? 18:02
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
18:03 brrt joined
brrt \o 18:04
lizmat brrt o/
do we have a quick way to find out if MoarVM is running on a big-endian or a little-endian system ?
timotimo we've got a #define i think? 18:05
brrt ohai lizmat
yeah, I'm sure we have a define 18:06
lizmat but how is that exposed in Raku ?
timotimo hm. nqp::backendconfig?
brrt '#define MVM_BIGENDIAN 0'
I don't think we export the endianness (endianity?) using the backendconfig 18:09
judging from the implementation in config.c 18:10
lizmat m: dd $*VM.config<be>
camelia "0"
lizmat could that be it ?
timotimo .o( it could "be" )
18:14 Kaeipi left 18:17 Kaiepi joined 18:26 sena_kun joined 18:28 Altai-man_ left
brrt hmm 18:31
yes, it is 18:34
but I'm not sure how it's set
lizmat m: dd Kernel.endian # apparently I've asked this question before :-)
camelia Endian::LittleEndian
brrt lizmat: it comes from perl's $Config{byteorder} during configuration 18:36
nwc10 brrt: o/ 19:07
brrt ohai nwc10 19:15
19:37 brrt left 19:55 zakharyas left
jnthn 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:09
timotimo that's a fun area in general 20:22
20:26 Altai-man_ joined 20:28 sena_kun left 21:56 raku-bridge2 joined, raku-bridge2 left, raku-bridge2 joined, raku-bridge left 21:57 raku-bridge2 is now known as raku-bridge 22:06 Kaiepi left, Kaiepi joined 22:25 Altai-man_ 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!