|
01:50
FROGGS_ joined
02:56
woolfy1 joined
02:57
tadzik1 joined,
FROGGS__ joined
03:57
colomon joined
06:47
FROGGS joined
07:21
zakharyas joined
07:45
colomon joined
07:47
donaldh_ joined
08:00
woolfy1 left
08:07
zakharyas joined
10:28
donaldh_ joined
11:47
vendethiel joined
13:20
zakharyas joined
13:26
FROGGS[mobile] joined
13:46
btyler joined
14:24
FROGGS joined
14:32
zakharyas joined
14:50
FROGGS[mobile] joined
15:34
btyler joined
16:25
btyler joined
17:05
brrt joined
18:35
zakharyas joined
|
|||
| dalek | arVM: 998e30e | jnthn++ | docs/ChangeLog: Mention loop labels in change log. |
18:48 | |
| arVM: c38c389 | jnthn++ | VERSION: Bump VERSION to 2014.05. |
18:49 | ||
| arVM: 0f939db | jnthn++ | docs/release_guide.md: Correct release guide to mention tagging. |
18:52 | ||
|
19:57
Vendethiel- joined
20:22
btyler joined
|
|||
| timotimo | refresh my head again, how do i teach the gc about internal pointers again? | 22:01 | |
| is adding to the worklist when i get mark'd enough? | |||
| jnthn | See MVM_gc_root_add_tc_roots_to_worklist | 22:02 | |
| Near the bottom | |||
| Currently it iterates the native_callback_cache entries | |||
| You'll just need to change it to walk the linked list hanging off each of them instead | |||
| That'll be enough. | |||
| timotimo | ah, sounds easy enough | 22:03 | |
| jnthn | Yeah, I don't see any traps in this | ||
| timotimo | the MVMNativeCallbackCacheHead doesn't actually need to store its cuid inside it, aye? | ||
| like, it'll really only need the ut_hash handle thing and the link to the MVMNativeCallback? | |||
| jnthn | Correct. | 22:04 | |
| MVMNativeCallback doesn't have a cuid slot | |||
| timotimo | someone i know told me linked lists are never superior to dynamic arrays | 22:07 | |
| what does our interpreter loop look like when we go back and forth between callbacks, btw? | 22:08 | ||
| jnthn | I guess they didn't consider deletion-in-the-middle, let alone how the two compare if you're considering lock-free design... | 22:09 | |
| timotimo | do we build a "return to C" special frame into our VM stack and just drop back into the interpreter loop we've always been using? | ||
| jnthn | Yeah, somethin glike | ||
| But it's not very robust yet | |||
| timotimo | mhm | ||
| jnthn | It gets very, very upset about exceptions | ||
| And don't even think about gather/take-ing over it. | |||
| timotimo | it's to get away from the "inferior runloop" thing parrot got which was very unhappy, right? | ||
| jnthn | Well, it is an inferior runloop | ||
| It's the *one* place MoarVM actually lets it happen. | 22:10 | ||
| Because we don't actually have a choice. | |||
| timotimo | an "inferior runloop" is whenever you have an interp_run somewhere in the C stack that's below another interp_run belonging to the same TC? | ||
| jnthn | Right. | ||
| If we've C code on the stack, though, it can't not be something like this. | 22:11 | ||
| And it has to be a continuation barrier anyway | |||
| 'cus we can't really co-opt arbitrary C code into that. | |||
| timotimo | mhm | ||
| jnthn | At least, not without unspeakable evil. | 22:12 | |
| timotimo | is there stuff that has to be done in order for the exceptions/gather-take across callbacks thing to be started working on? | ||
| jnthn | You will never be able to gather/take across callback boundaries, I don't think. That's the consequence of it being a continuation barrier. | 22:13 | |
| Exceptions we can do something about. | |||
| timotimo | oh | ||
| continuation barrier means exactly that | |||
| jnthn | Right. | ||
| Well, the issue is | |||
| timotimo | well, fair enough. as long as we can get a better error than a kernel panic/BSOD out of it :) | ||
| jnthn | <moar VM stack frames> <C stack frames unknown to us> <MoarVM stack frames> | 22:14 | |
| The nature of the bit in the middle is the problem. | |||
| timotimo | right; and we can't just go around inspecting x86, arm, mips, ppc machine code :) | 22:15 | |
| jnthn | right | 22:16 | |
| FROGGS | I could write a slang for it :o) | ||
| timotimo | haha, ouch | ||
| jnthn | Well, C lets code hold pointers into the stack, which is what makes it a lot more than "just know where the stack boundaries are and memcpy". | ||
| timotimo | jnthn: given infinite person-hours we could do it :) | ||
|
22:16
lizmat joined
|
|||
| timotimo | or is it halting-problem-hard? | 22:16 | |
| jnthn | The only way I think you can do it is actually allocate a blob of memory on the heap to serve as the stack | 22:17 | |
| And then somehow re-instate it. | |||
| timotimo | the pypy people actually have their frames on the heap nowadays | ||
| so their "continulet" stuff works out | |||
| jnthn | You could longjmp out of there but...getting back in there is gonna be fun. | ||
| I'm not sure you can't do it without dropping to assembly | |||
| uh, can do it | |||
| Even if you do that lot, it's still questionable how robust it will be. | 22:18 | ||
| Wouldn't surprise me if somebody has tried this before. | |||
| timotimo | mhm | 22:19 | |
| MVMObject *target in MVMNativeCallback is the thing i'll be comparing addresses against, aye? | 22:23 | ||
| jnthn | Yeah | 22:25 | |
| timotimo | not really sure if i want to patch the same thing on parrot, too :P | 22:26 | |
| but we should probably have a ticket ready for this | |||
| FROGGS | timotimo: when you are done, put the links tour commits into a ticket, so somebody who wants to tackle it does not need to do research | 22:27 | |
| timotimo | sounds good | ||
|
22:28
donaldh_ joined
|
|||
| timotimo | jnthn: any hot fix we could add for the upsetness about exception in case callbacks are in play? | 22:34 | |
| jnthn | timotimo: No, it's just tricky. I'll try and get to it soonish | ||
| timotimo | fair enough | 22:35 | |
| i think i've done most of the linked-list-translation for creation and marking, now to add lookup for finding the right callback to dispatch to | |||
| jnthn | OK :) | ||
| Got landed with some annoying early-morning phone meeting tomorrow. :/ | 22:36 | ||
| timotimo | oh, lookup and creation are in the same sub | 22:37 | |
| so actually if it compiles now i should be done and could start testing | |||
| d'aaw | |||
| jnthn | aye :) | ||
| OK, good luck...rest time... | |||
| timotimo | good night! | 22:38 | |
|
22:38
woolfy joined
|
|||
| timotimo | thanks for the help | 22:38 | |
| time for asan! | 23:00 | ||
| that stacktrace is useless :\ | 23:04 | ||
| yippie | 23:40 | ||
| i has a positive result d) | |||
| :) | |||
| dalek | arVM: c511cb7 | (Timo Paulssen)++ | src/ (5 files): NativeCallback hash is now a hash of lists. Generating multiple closures of the same code object would confuse NativeCall and only one of the callbacks would ever be reached. Now we compare addresses as well and store and mark all callbacks to all closure-cloned versions of the same MVMCode. |
23:43 | |