|
00:18
MasterDuke joined
00:27
AlexDaniel joined
00:28
buggable joined
01:56
ilbot3 joined
06:30
evalable6 joined
06:36
FROGGS joined
|
|||
| FROGGS | .tell AlexDaniel sure, I'll commit that today | 07:13 | |
| yoleaux | FROGGS: I'll pass your message to AlexDaniel. | ||
|
08:53
AlexDaniel joined
10:41
domidumont joined
10:49
domidumont joined
|
|||
| Geth | MoarVM/lazier_inline_fixups: c2d20bab9b | (Timo Paulssen)++ | 2 files more WIP on lazier inline fixups |
11:28 | |
| dogbert17 | oh, it's timotimo | 11:34 | |
| timotimo | oh no! | 11:44 | |
| dogbert17 | you're in some trouble :) | 11:45 | |
| look here: github.com/rakudo/rakudo/issues/1733 | |||
| timotimo | guess what lazier_inline_fixups is for | 11:53 | |
| the bigpackids sub is not being speshed because it has a wval in it that's from a foreign cu after inlining | |||
| dogbert17 | aha | 11:54 | |
| AlexDaniel | ♥ | 12:14 | |
| timotimo | wow, fascinating | 12:20 | |
| memory corruption or something related to spesh slots? | |||
| huh, how is this happening :D | 12:56 | ||
| dogbert17 | perhaps it's a bug :) | ||
| timotimo | well, somehow we end up with num_spesh_slots being 11, but alloc_spesh_slots being 0 | 12:57 | |
| dogbert17 | does valgrind have anything to say? | ||
| timotimo | yeah | 12:59 | |
| i have a theory, but i'll verify before i explain | 13:00 | ||
| ah, yes | 13:02 | ||
| when inlining, we create a spesh graph directly from a SpeshCand | |||
| that code only sets the number of spesh slots and the spesh slot array | |||
| not how many were allocated | |||
| the new code i have was adding extra spesh slots to the inlinee, which is something that never happened before, and wasn't supposed to happen | 13:03 | ||
| i'll also need to copy the spesh slots array over, rather than keeping the original, otherwise things will go rather wrong | |||
| dogbert17 | is this an old problem? | 13:07 | |
| timotimo | no | ||
| dogbert17 | damn :) | ||
| was hoping you'd found some old crusty bug relating to inlining | 13:09 | ||
| brrt is looking for one I believe | 13:10 | ||
| timotimo | 00013 sp_findmeth loc_10_obj, loc_11_obj, '$!known', sslot(5) | 13:14 | |
| this looks kind of wrong :D | |||
| but yeah, i have a clue what's wrong here | |||
| fixing up strings with "the new way" is NYI, that's what's wrong | 13:17 | ||
| dogbert17 | "the new way" ? | 13:20 | |
| timotimo | ah, allow me to explain | 13:23 | |
| so, there's this op called "wval" that takes two integers and it looks up a serialization context based on the first integer and then an object based on the second, which is an index into that serialization context | 13:24 | ||
| now, these serialization contexts hang off of the CompUnit, because every comp unit has a list of SCs that it depends on | |||
| when we inline code, we may be taking code from one compunit and transplanting it into another, so the wval instruction will either not find an SC at the given index at all, or no object at the specified index (index too high), or simply the wrong index (whatever has the same index in that other SC) | 13:25 | ||
| so we have to fix this up | |||
| until now, we would grab the object from the SC and stash it away in a spesh slot, i.e. make it a constant with a different mechanism | 13:26 | ||
| but grabbing the object from the SC can cause deserialization, because we do that lazily, which allocates objects that are GC-managed | |||
| that also means if we happen to fill up the nursery at that point, or if another thread was waiting for us to join in on GC, we'd be running GC inside spesh | 13:27 | ||
| which spesh does not support, and making it support GC in the middle would be a major hassle | |||
| that's what caused the MVM panic in the past | |||
| so that's what we used to have | 13:28 | ||
| but at the GPW, jnthn came up with a simple solution to this problem | |||
| dogbert17 | that sounds interesting | 13:29 | |
| timotimo | we can just stash away the SC we need to look stuff up in into a spesh slot, and store the index for the object inside it | ||
| hence the sp_getwvalfrom op is born | |||
| dogbert17 | and you're implementing it now? | 13:30 | |
| timotimo | that one seems to already work | ||
| there's more, though | |||
| any op that has a constant string argument also needs fixing up | |||
| i've added a sp_getstrfrom op that can replace const_s, but there's a bunch of ops that have constant strings in their operands | 13:31 | ||
| some getattr ops, and some findmeth ops | |||
| i don't want to duplicate all of those | |||
| dogbert17 | so how will you fix them then? | 13:32 | |
| timotimo | the old string fixing way isn't problematic in the same way the wval one is | 13:33 | |
| because we put strings we take from a compunit into the old generation, it won't cause GC | 13:36 | ||
| i also have a fixup for callsites, but that one was giving me trouble | 13:38 | ||
| i can also revert that back to the way it was and that seems to make things better | 13:39 | ||
| i'll do a full nqp/rakudo build/test with that | |||
| dogbert17 | so if your fix works the blocker will be resolved while at the same time getting a wval fix? | 13:42 | |
| timotimo | yes | ||
| dogbert17 | cool | 13:43 | |
| timotimo | looks like i'll only be adding a lazy wval fixup and a lazy const_s fixup, not callsites and also not coderefs | ||
| but fixing up coderefs causes a panic at the moment anyway | 13:44 | ||
| so i suppose that never happens | |||
| huh, wow, a rakudo build succeeds, but the test program fails | 13:47 | ||
| P6opaque: get_boxed_ref could not unbox for the representation 'P6bigint' of type Signature | |||
| ^- that's rather wrong | |||
| dogbert17 | uh oh | 13:49 | |
| timotimo | i've fixed the problem, but really only by masking the bug | 14:01 | |
| time for a rest break for my RSI, though | 14:02 | ||
| spec tests are clean with this version :\ | 14:12 | ||
| oh, haha, i think i have the problem | 14:26 | ||
| no, i don't | 14:27 | ||
| dogbert17 | rest well | 14:29 | |
| timotimo | too late! | 14:32 | |
| it's a good idea to read 64bit integers into 64bit variables rather than into 16bit ones | 14:37 | ||
| jnthn | You don't say! :) | 14:38 | |
| jnthn waves from a train taking home sorta towards home :) | |||
| timotimo | it's taking home towards home? | 14:39 | |
| :D | |||
| jnthn | hah, s:1st/home/him/ :) | ||
| timotimo: You still working on the inline fixups stuff we talked about during GPW, or onto the next problem by now? | 14:41 | ||
| timotimo | it's still that | ||
| though i haven't invested a whole lot of time since i came back | |||
| jnthn | eek, "fun" | ||
| Ah, well, that's something at least :) | |||
| timotimo | well, i'm staring at a looooong column of "ok"s now | ||
| jnthn | That's nice :) | 14:42 | |
| timotimo | t/spec/S07-hyperrace/stress.t ..................................... | 14:43 | |
| does this usually take ages? | |||
| it seems to be only really using one single core | 14:44 | ||
| perhaps something's not quite right in that test | |||
| run in isolation it finishes quickly | 14:46 | ||
| jnthn | Can't say I've noticed it doing so, but I've hardly run spectest at all in the last couple of weeks. | ||
| timotimo | Test run interrupted! | 14:47 | |
| All tests successful. | |||
| so i'd call this success | |||
| i'm not sure why prepargsfrom doesn't work, but it's not as important so i can postpone it, possibly forever :P | 14:53 | ||
|
15:05
Kaiepi joined
|
|||
| Geth | MoarVM/lazier_inline_fixups: 5cceda1caa | (Timo Paulssen)++ | 9 files Fix fixing of wvals during inline |
15:22 | |
| MoarVM/lazier_inline_fixups: 16c43c1751 | (Timo Paulssen)++ | 5 files get rid of spesh retry mechanism |
|||
| timotimo | ah, i meant to write a long commit message before pushing | ||
| RSI rest break time again, though | |||
| Geth | MoarVM/lazier_inline_fixups: 587e08d48d | (Timo Paulssen)++ | 9 files Fix fixing of wvals during inline Whenever we inline a frame from one MVMCompUnit into a frame from another MVMCompUnit we have to fix up several ops and operands that are references based on "the current CU". One of those cases was the wval operations. ... (21 more lines) |
16:09 | |
| MoarVM/lazier_inline_fixups: 8a5615ead7 | (Timo Paulssen)++ | 5 files get rid of spesh retry mechanism |
|||
| MoarVM/lazier_inline_fixups: 9655e15488 | (Timo Paulssen)++ | src/spesh/inline.c we can re-use these spesh slots. |
16:18 | ||
| MoarVM/master: 4 commits pushed by (Timo Paulssen)++ | 16:23 | ||
|
16:42
Kaypie joined
18:50
zakharyas joined
19:02
Merfont joined
19:08
Merfont joined
19:44
Kaiepi joined
20:53
releasable6 joined
20:56
Kaiepi joined
21:10
Zoffix joined
|
|||
| Zoffix | Reminder, release will be in 7 days and there are still 7 release blockers on the list. Please help fix: github.com/rakudo/rakudo/issues?q=...2%9A%A0%22 | 21:11 | |
| R#1709 is already partially golfed to some GC issue with `moar: src/gc/collect.c:218: process_worklist: Assertion `*item_ptr != item->sc_forward_u.forwarder' failed.` | 21:12 | ||
| synopsebot | R#1709 [open]: github.com/rakudo/rakudo/issues/1709 [ASYNC][⚠ blocker ⚠] A race in HyperRace causing rare crash/hang | ||
|
22:03
p6lert joined
22:05
Kaypie joined
23:31
bloatable6 joined,
quotable6 joined,
evalable6 joined,
notable6 joined,
undersightable6 joined,
committable6 joined,
coverable6 joined,
nativecallable6 joined,
benchable6 joined,
releasable6 joined,
unicodable6 joined,
squashable6 joined,
bisectable6 joined,
shareable6 joined,
statisfiable6 joined
23:32
greppable6 joined
|
|||