github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:39 Kaiepi left 00:42 Kaiepi joined 03:56 evalable6 left, linkable6 left, linkable6 joined 03:57 evalable6 joined 06:13 coverable6 left, releasable6 left, reportable6 left, committable6 left, statisfiable6 left, notable6 left, squashable6 left, quotable6 left 06:15 coverable6 joined, releasable6 joined, reportable6 joined, committable6 joined, statisfiable6 joined, notable6 joined, squashable6 joined, quotable6 joined
nwc10 good *, #moarvm 08:30
MasterDuke aloha 09:30
09:32 Altai-man_ joined
MasterDuke C question. i have a function that returns MVMint64. but i want a way to indicate it doesn't have a valid value to return. if i return `(MVMint64)NULL`, can i safely `if (some_func() == NULL)` ? 09:33
hm, i think that was not a smart question 09:42
nine Usually 0 is a very valid integer :) 10:03
MasterDuke: what are you working on?
MasterDuke nine: trying to do github.com/MoarVM/MoarVM/pull/660 correctly 10:22
though timotimo pointed out it may be moot anyway if all optional parameter jitting is going to be reworked 10:23
but i'm not sure if it's possible to change the return value of MVM_args_get_optional_pos_int to MVMint64 since checking the .exists will have to happen there 10:24
10:26 Altai-man_ left, sena_kun joined
nine MasterDuke: looks like I already suggested a proper fix? 10:29
MasterDuke oh. ha. 10:30
hm, i guess then MVM_args_get_optional_pos_int needs to return some boolean value to make the cur_op decision 10:33
or will it be a constant value? i've never really learned how cur_op works 10:38
nine Yes and that will complicate doing it in the JIT 10:39
Yes for needing to return a bool because of that cur_op decision
Basically param_op_* are conditionals causing jumps 10:40
10:47 hankache joined 10:59 hankache left 11:14 Altai-man_ joined 11:17 sena_kun left
MasterDuke nine: can i just repeat the cur_op logic in emit.dasc with get_cur_op? 12:06
12:26 Kaiepi left 12:27 Kaiepi joined 12:28 Kaiepi left
nine MasterDuke: no, it will be closer to if_i 12:56
Handling of optional arguments is a branching operation, i.e. it changes control flow. Now control flow is handled via cur_op in the interpreter, while the JIT uses jumps and labels. 12:58
This also means that we have to take deoptimization into account. For this there may be existing infrastructure that can just be used. Or it may be something that needs handling on a case-by-case basis. I don't know. 13:00
13:15 sena_kun joined 13:16 Altai-man_ left
jnthn I'm still unconvinced by trying to JIT the param_* ops. 14:15
They mostly get specialized away, and I'd rather we fix the causes of them not being.
MasterDuke it's turning out to be a little more complicated than i'd anticipated. and yes, the original code that was bailing doesn't have any bails anymore (from param_op_* ops) because of spesh 14:17
i'm just going to close github.com/MoarVM/MoarVM/pull/660
jnthn: but while you're here. should i try to re-invogorate github.com/MoarVM/MoarVM/pull/689 and github.com/MoarVM/MoarVM/pull/773 ? or just close them also 14:18
jnthn github.com/MoarVM/MoarVM/pull/689 is potentially a step towards making them not segfault on multi-threaded bause... 14:19
*abuse
14:20 Kaiepi joined
MasterDuke yeah, that's also the simpler one to update and/or expand 14:20
jnthn Does the string one show a decent speedup in benchmarks? 14:21
MasterDuke it's been to long, i don't remember
*too
i can try to update it enough to get some benchmarks 14:22
sounds like there's enough of an interest in them to at least get their branches rebased to master 14:24
nine Btw. the commits don't mention why the change is a good idea. As a reviewer I wouldn't know why using the FSA is better 14:26
timotimo i was wondering how we can have a repr-defined flag if we also have inlined object bodies in p6opaque 14:48
since for that we'll only have one header withh flags for multiple things
or is that not applicable to VMArray anyway?
jnthn I'd think they're only usable on things that are exclusively reference types 15:00
15:14 Altai-man_ joined 15:16 sena_kun left
timotimo OK, if we keep that limitation in mind, that should be fine 15:17
MasterDuke is it safe to memmove stuff that's been allocated by the fsa? 16:02
jnthn MasterDuke: Should be, it's just a safer memcpy 16:07
timotimo it's memcpy but allows for from and to to overlap, right? 16:08
jnthn Yeah, iirc 16:09
MasterDuke ok, good 16:10
hm. if the vmarray uses the FSA, what would/should unmanaged_size return? 16:19
timotimo the same as before, IMO 16:23
it'll just be more accurate because the FSA has less per-item overhead and we don'- count the overhead of whatever malloc impl we have 16:24
MasterDuke good, i'm liking these answers (expect that i still don't know why i now get a `free(): invalid pointer` in slice, when i didn't before) 16:25
i've rebased my use_fsa_for_vmarray branch 16:30
16:48 zakharyas joined
nine So, I've worked some more on my gcc plugin for detecting GC issues and when run on this file: gist.github.com/niner/2d6391d7413a...b5cb7e80f6 it prints: 16:49
Missing root for `param` in test-checker.c:47
Missing root for `bar` in test-checker.c:57
Missing root for `param` in test-checker.c:57
Missing root for `bar` in test-checker.c:54
16:50 zakharyas1 joined 16:53 zakharyas left 17:15 sena_kun joined 17:17 Altai-man_ left 17:27 MasterDuke left 17:44 MasterDuke joined
Geth MoarVM/gc_measurement_debughelper: c22047356e | (Timo Paulssen)++ | 3 files
add a layer of indirection between call graph and types/sf
19:06
19:14 Altai-man_ joined 19:17 sena_kun left
[Coke] pmurias; can you throw a bit of documentation for the opcode into docs/op*? that will make it vanish from my sight. :) 19:22
20:02 zakharyas1 left 20:47 zakharyas joined 21:12 zakharyas left 21:15 sena_kun joined 21:17 Altai-man_ left
Geth MoarVM/gc_measurement_debughelper: 0d8fae3a00 | (Timo Paulssen)++ | 2 files
use FSA for alloc and dealloc counts
22:12
23:14 Altai-man_ joined 23:17 sena_kun left