|
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
|
|||