github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 08:30
MasterDuke aloha 09:30
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
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
MasterDuke nine: can i just repeat the cur_op logic in emit.dasc with get_cur_op? 12:06
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
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
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
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
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
Geth MoarVM/gc_measurement_debughelper: c22047356e | (Timo Paulssen)++ | 3 files
add a layer of indirection between call graph and types/sf
 19:06
[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
Geth MoarVM/gc_measurement_debughelper: 0d8fae3a00 | (Timo Paulssen)++ | 2 files
use FSA for alloc and dealloc counts
 22:12

Powered by Cro and the Raku® Programming Language.

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

Thank you!