|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:08
MasterDuke left
00:48
sivoais left
00:59
lucasb left
01:01
sivoais joined
01:16
AlexDani` joined
01:20
AlexDaniel left
06:37
domidumont joined
07:25
AlexDani` is now known as AlexDaniel,
AlexDaniel left,
AlexDaniel joined
07:27
squashable6 left
07:30
squashable6 joined
07:44
sena_kun joined
08:01
zakharyas joined
10:13
domidumont left
10:24
squashable6 left
10:25
squashable6 joined
10:41
zakharyas left
11:06
squashable6 left
11:08
squashable6 joined
|
|||
| nine | Oooh...learned about an important aspect of thread exit: there is actually almost no special handling for this in the GC. We just keep the thread alive for 2 GC runs and rely on them to completely clear the nursery (first run to move to the new nursery and mark as seen, second to promote to gen2). | 11:52 | |
| So when I extended the stay of objects in the nursery to 15 runs to flush out some more rooting issues, I broke this implicit part of thread exit. | 11:53 | ||
| Luckily knowing that makes it trivial to fix. Just as always really tricky to find out | |||
| jnthn | Ah, I tried to explain that somewhat before, but admittedly not so clearly, and it didn't occur to me it'd interact with what you were doing in that way :) | 12:14 | |
| nine | Well, I think time spent like this is never wasted, even though I could have made my life easier by connecting the dots a lot sooner. I still improved my debug skills and actually worked through the fine details of how those phases in the GC work. | 12:25 | |
| Guest23744 | nine: perhaps you should blog about it | 12:41 | |
| is anyone interested in merging github.com/MoarVM/MoarVM/pull/1181 | 12:42 | ||
| Geth_ | MoarVM: 3d83cb4694 | (Jan-Olof Hendig)++ | src/spesh/inline.c Add a few missing static keywords before a few functions Set the functions scope to the containing file (compilation unit) |
12:47 | |
| MoarVM: 2a796fe3c0 | niner++ (committed using GitHub Web editor) | src/spesh/inline.c Merge pull request #1181 from dogbert17/add-missing-static Add a few missing static keywords before a few functions |
|||
| Guest23744 | nine++ | 12:51 | |
|
13:20
zakharyas joined
13:48
lucasb joined
13:52
domidumont joined
14:25
domidumont left
16:00
domidumont joined
16:02
MasterDuke joined
|
|||
| timotimo | it's always just a tiny bit dangerous to do something implicitly | 16:15 | |
| Geth_ | MoarVM: acb04a448b | (Stefan Seifert)++ | src/spesh/plugin.c Fix possible memory corruption in resolve_using_guards add_resolution_to_guard_set replaces the old guard set of a StaticFrameSpesh's plugin_state with a new set. The old one is freed at the next safe point. If another thread starts resolving a spesh plugin before the replacement and during resolution a GC run is triggered, the old guard set's pointers may become outdated, as they are no longer anchored in the frame's StaticFrameSpesh. ... (5 more lines) |
16:45 | |
| nine | Still don't like this fix. But it works and I haven't found a better way yet. | 16:47 | |
| timotimo | does this have to prevent the guard set from being freed? | 16:49 | |
| nine | Excellent question! | 16:50 | |
| timotimo | because if it does have to, i don't see the mechanism that does that | ||
| and defensively copying sounds like a terrible time | |||
| nine | My first reaction would be yes. But then I wonder why I haven't seen anything blowing up there | ||
| timotimo | it'd only blow up with asan or valgrind, right? were you using that or was that too costly in terms of time? | ||
| though actually, you can tell if the thing has to be copied to be rescued from safepoint-freeing by virtue of the pointer having changed just before a potential gc run | 16:51 | ||
| nine | Well valgrind and asan certainly make it more blowy, but they'd not be necessary. | 16:52 | |
| timotimo | right, there's not only the fact that the guard set gets freed, but also that the pointers get outdated | ||
| nine | Anyway a valgrind run of a test that exploded during guard resolution has been running for about an hour. So just one or two more hours till I know more | 16:53 | |
| timotimo | ouch | 16:54 | |
|
17:01
dogbert11 joined
17:41
zakharyas left
18:05
domidumont left
18:32
chloekek joined
19:18
hoelzro joined
|
|||
| nine | Maybe the ugly fix doesn't actually fix anything | 19:34 | |
| Or it could indeed be the premature freeing that's still causing issues | 19:45 | ||
| In which case I wonder what a fix could be. Maybe turning the guard set into a full MVMCollectable? Because to the question of "when do we know that we can free this object", "use your GC!" sounds like a very appropriate answer | 19:48 | ||
|
20:05
zakharyas joined
20:32
chloekek left
21:09
zakharyas left
21:17
lucasb left
21:50
sena_kun left
22:07
MasterDuke left
|
|||