github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:27 Altai-man_ joined 00:28 sena_kun left 00:49 konvertex left 02:27 sena_kun joined 02:29 Altai-man_ left 04:26 Altai-man_ joined 04:29 sena_kun left 06:27 sena_kun joined 06:28 Altai-man_ left
nine MasterDuke: no 07:27
The only reason to do that would be to detect some use-after-free error. Which valgrind is already pretty good at. 07:28
Though I've used 0xefefefefefefefef instead of NULL when working on the GC, as that stands out much more 07:29
08:12 zakharyas joined
MasterDuke nine: thanks. that's what i thought, but wasn't 100% sure 08:21
btw, any thoughts on github.com/MoarVM/MoarVM/pull/1291 ?
nine MasterDuke: I'm pretty sure there's a way to get results without the patch. Looks like the issue is just that you collect all control flows ending in a BB that returns. You can also just collect control flows that end in a call to one of the throwing functions. Indeed, those seem to be the only ones you're interested in. 08:26
08:26 Altai-man_ joined 08:28 sena_kun left
nine That would actually be useful for the GC checker plugin, too, as we could detect errors where stuff gets put on the temp root but in the case of an exception not taken off again 08:32
MasterDuke hm, that does make sense 08:44
MasterDuke wonders if/why i didn't try that
Geth MoarVM: MasterDuke17++ created pull request #1292:
Convert MVM_free+setting to NULL to MVM_free_null		 08:58
MasterDuke something which is `REPR(foo)->allocate()`ed doesn't need to be manually freed in the case of an exception, correct? it will get cleaned up by the GC 10:09
10:11 konvertex joined
jnthn Correct 10:11
MasterDuke thanks 10:12
10:27 sena_kun joined 10:29 Altai-man_ left 11:14 MasterDuke left 11:18 zakharyas left 11:43 MasterDuke joined 12:16 Prince213 joined
jnthn Ok, back to dispatch hackery, I guess... :) 12:21
12:21 Prince213 left 12:22 Prince213 joined
sena_kun jnthn, Friday fun. <3 12:22
jnthn Yes, though the Friday lunch was a big steaming bowl of halušky, which are certainly a good way to induce a carb coma... 12:24
12:26 Altai-man_ joined 12:28 sena_kun left 12:36 Prince213 left 12:37 Prince213 joined, Prince213 left
Geth MoarVM/new-disp: 7b9327c63d | (Jonathan Worthington)++ | 5 files
Wire up basic invocation via boot-syscall

This currently does not do checks or stack up guards to make sure the call is safe.		 12:40
12:54 Prince213 joined 12:55 Prince213 left
Geth MoarVM/new-disp: 547987f7ce | (Jonathan Worthington)++ | 2 files
Implement registering userspace dispatchers
 12:55
13:06 sivoais left
MasterDuke i'm not entirely sure what to do about github.com/MoarVM/MoarVM/blob/mast....c#L25-L37 13:19
should `repr_data` be freed before the exception?
could/should github.com/MoarVM/MoarVM/blob/mast....c#L30-L31 be moved to after the if/else if/else blocks? 13:21
13:32 zakharyas joined, sivoais joined
MasterDuke MVM_HASH_(GET|BIND) and maybe some of the other hash-related macros can throw, but they only take one element of a malloced array as an argument 14:05
14:05 zakharyas left
MasterDuke any reason not to change them to (also?) take the base array so it can be freed before the throw? 14:05
14:06 zakharyas joined
MasterDuke github.com/MoarVM/MoarVM/blob/mast...#L194-L204 14:06
timotimo can it really throw there? we grab the keys by iterating first 14:11
hopefully no other thread is messing with the hash at thatt ime
MasterDuke github.com/MoarVM/MoarVM/blob/mast...Hash.h#L41 14:18
14:27 sena_kun joined 14:28 Altai-man_ left
timotimo pea is using MVM_VECTOR, which of course is fine, but we may get a benefit from switching any MVM_VECTOR usage inside of spesh functions to the spesh allocator 15:08
Geth MoarVM/new-disp: 7b829a943c | (Jonathan Worthington)++ | 2 files
Invoke userspace dispatchers

However, they cannot yet delegate to another dispatcher, so aren't able to do anything useful.		 15:13
MoarVM/new-disp: 4e44e64bbb | (Jonathan Worthington)++ | 7 files
Implement dispatcher delegation

So that userspace dispatchers can delegate to each other and, ultimately, to the boot dispatchers that cause actions.
The whole "thunked" flag part of this is kind of ugly, and will go away in a follow-up cleanup of return handling (some logic that currently is in frame.c wants to at least be triggerred from callstack.c). However, that yak can be shaved a bit later - perhaps when the special return mechanism is also refactored.
jnthn eww :) 15:17
But it works, and chains of delegations work now
And finally it feels approximately like I'm making progress without having to shave a yak every step :)
MasterDuke nice 15:19
jnthn Well, in part 'cus I did the horrible thunked thing and deferred that yak, but still.. :) 15:21
timotimo for a freshly fastcreated object we should be able to figure out what "getobjsc" would do pretty much universally, right? 15:25
i'm looking at a pea log and getobjsc is preventing one, but it's also going to be running into a setobjsc if there's no sc yet 15:26
i imagine a fastcreated object wil not have an sc set on it
timotimo looks closer
jnthn Yeah, you'd know it doesn't have one 15:27
timotimo right. so spesh could turn the check into a constant set, but pea won't have much use for it
would you like me to change the pea log mechanism to use spesh comments or add spesh comments to it, perhaps even when pea log is turned off? 15:28
also: cool on the disp work :) 15:30
15:35 Kaiepi left 15:39 Kaiepi joined
jnthn Hm, where's the latest commit... :) 16:15
timotimo the nqp one?
:)
nope, i see it on github 16:16
jnthn No, the MoarVM one I pushed a moment ago :)
timotimo " Provide dispatcher-drop-arg syscall " - "And fix up passing along derived captures as we delegate between dispatchers." - github.com/MoarVM/MoarVM/commit/d3...a26a1b0539
jnthn OK, think I'll do dispatcher-insert-constant-arg and then call it a day 16:17
timotimo i wonder if i can cargocult something together for, like, dispatcher-insert-variable-arg, like when you duplicate an argument or something 16:25
that may need an implementation of "get a positional argument" first? 16:26
16:26 Altai-man_ joined
jnthn I'm currently doing "insert a constant arg" one 16:26
timotimo yeah
jnthn I'm still pondering a bit the "insert something we got from somewhere else" part
Because the somewhere else could be an incoming capture
timotimo i thought "add a variable one" would be a logical next step, but it may be further away
jnthn But it could also be from an attribute read from an object that we have access to also 16:27
spesh plugins kinda track those by object identity, and I was going to copy the design, but then realized it's very fragile
'cus the same value could be passed in as two args in the example we work from, but not be like that always 16:28
So I think we need explicit tracked value references
16:29 sena_kun left
jnthn That we can then pass along the guards also 16:29
timotimo mhm
jnthn And capture insertions, etc.
timotimo some representation that says "this was taken from capture / object X with positional / attribute Y"
not unlike bytecode at all
jnthn Really a dispatch/resume callback is writing a "dispatch program", and we need to know about the data 16:30
Yeah, something like that
tbh the repr doesn't need to know where the thing came from at all 16:31
It just needs to be a unique object identity that holds the value
timotimo i thought the guard list/tree needs to know how to extract it the next time around
jnthn No, these are only for the record phase 16:32
For understanding which capture arg or attribute or whatever we're guarding against
timotimo oh, so if we're getting the '$!do' attribute of a thing, the guards will check if the object that had the $!do in it is identical?
jnthn One could do that 16:33
(as in, write a dispatch callback that does that)
timotimo i'm probably missing something, so i'll just leave you to it :) 16:35
turns out changing the strcpy to memcpy in the heap snaphot profiler to silence a compiler warning breaks the heap snapshot profiler because there's now a trash byte in there after shorter names like "sffile" ends up as "sffile\0c" in one instance 16:36
jnthn To give a clear example: we get a capture coming in. We read an object arg 0 from it. We want to guard against the type of that object. How does the instruction that declares a guard know that it was capture arg 0?
timotimo i'm not sure if i want to allow bytes after a null in the 8-bytes-wide fixed field should be allowed to be whatever they want 16:37
jnthn And the proposed solution is that the instruction for taking a reference to capture arg 0 creates the wrapper object, and notes down that's where it came from. Then we pass the wrapper to the guard adding instruction, and it says "oh, that's arg 0 from this capture" (and potentialy "which was arg 1 when we started out, because we dropped the first arg") 16:38
Ultimately, when we run the dispatch program, it will not normally create any intermediate captures. 16:39
(at least, if we write our dispatchers carefully)
timotimo right, it'll just do the whole thing in one step?
like, it could have a mapping from beginning capture slots to final capture slots
jnthn It'll just see that the twiddling around at the start is just some temporary values, and that we eventually get a code object to invoke on the tail of the arg buffer
So it will do the bytecode invoke with ->work, arg_map + offset, updated_callsite 16:40
timotimo so no reason to support something like "reverse the order of arguments"
jnthn Where updated_callsite was interned
Well, technically you can write "reverse the order of the arguments", but we ain't going to bust a gut to make it fast :P
timotimo :) :)
that's fine
jnthn Though it might end up alright anyway :) 16:41
But yeah, my observation is that most of the time we'll be able to have <dispatcher-targetted args> <final invokee targetted args>
Of course, the second chunk of them might be guarded
But that doesn't break us being able to do the simple "shuffle the pointer along to ignore the first args" trick 16:42
The only case where it gets trickier is FALLBACK, which wants to insert the method name into the args we actually send along 16:43
But I think that'll not work out too bad either 16:44
timotimo right
jnthn In principle we'll even be able to inline a short FALLBACK, CALL-ME, etc.
timotimo somehow be clever and have the initial arguments start at 1 instead of 0 so there's already a free spot to put an early thing 16:45
jnthn Probably not that; probably just allocate some working space inside of the dispatch program frame and stick them into the correct order there
In most cases there's very few args
timotimo fair enough
jnthn Flattening will be handled along similar lines, btw 16:46
We'll flatten *before* we dispatch
Thus removing the spesh + flattening limitations of today
But also the flattening result will live on the callstack
timotimo i haven't found a satisfactory solution to "this construct works fine for up to 100 elements in a list, but at some point you'll just get a 'too many arguments in flattening' error" thing, but that's not quite related i think?
jnthn So we won't have to malloc or whatever memory for it
No, I've not worried about that one for now 16:47
Generally anything producing that wants to be written differently anyway
nine I just realized that those dispatchers will probably allow me to have cached dispatch per callsite to candidates with and without named arguments. That will speed up calls yet some more 17:09
timotimo i think hllize could also use this to dispatch to the array-ify, hash-ify, and code-ify functions that are registered in the hll 17:15
Geth MoarVM/new-disp: 2ed2e638d0 | (Jonathan Worthington)++ | 8 files
Implement capture insert constant dispatcher func

Note completely tested yet, because an issue where we have a sandwich of bytecode dispatcher, C dispatcher, bytecode result currently explodes.		 17:25
jnthn boom SIGSEGV...but time to go home for dinner 17:26
Altai-man_ jnthn, have a nice evening. o/ 17:27
timotimo mhhh sandwich 17:35
MasterDuke why is github.com/MoarVM/MoarVM/blob/mast...1116-L1117 here? couldn't it be moved much earlier to not do all that extra work? 17:59
timotimo i sure hope we don't hit that exception at all 18:18
18:27 sena_kun joined 18:29 Altai-man_ left 18:46 zakharyas left
MasterDuke well yeah, github.com/MoarVM/MoarVM/blob/mast...ons.c#L448 is the only call that doesn't explicitly pass NULL for the return_address parameter 18:53
but still, any reason not to bail out immediately? do we have to go through the body of the loop if it's not NULL? 18:54
19:17 konvertex left 19:34 zakharyas joined
nwc10 jnthn: paste.scsys.co.uk/589021 -- ASAN excited by t/moar/53-dispatch.t on origin/new-disp 19:47
20:06 MasterDuke left
jnthn nwc10: ooh, interesting... 20:20
Ran out of time to throw ASAN or valgrind at it before I had to go home.
nwc10 "my 20:22
"my" machine was decommissioned.
So I figured a new "my" machine to use
debian buster, so a reasonably new gcc
and ASAN there (also) grumbles about leaks. But I've not chased those down yet
it will certainly wait until Monday. Enjoy your weekend. 20:23
(or whichever day you have time to return to non-work hacking)
20:25 MasterDuke joined 20:26 Altai-man_ joined 20:28 sena_kun left
jnthn Thanks to $grant, it is work hacking :) 20:29
nwc10 this is TPF++ ? 20:32
21:54 zakharyas left
jnthn Yes :) 21:55
timotimo TPG
[Coke] Glad it got voted on and approved before I retired. :) 22:26
22:27 sena_kun joined 22:29 Altai-man_ left
lizmat [Coke]: I think jnthn is currently working on the core grant 22:30
[Coke] Then I retract my joy. 22:33
jnthn You can be joyful about that next week :) 22:34
sena_kun thinks a couple of items in the design doc can be marked as done before going to sleep 22:39

Powered by Cro and the Raku® Programming Language.

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

Thank you!