github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
nwc10 good *, #moarvm 05:26
jnthn morning o/ 09:07
nwc10 \o
brrt \o 15:06
[Coke] o/ 15:07
MasterDuke anybody have any suggestions after looking at this backtrace gist.github.com/MasterDuke17/9a7e3...ab6714f873 ? 17:55
MasterDuke i get the occasional panic when building nqp, but the build does succeed sometimes. the rakudo build always panics 18:36
nine Can you catch such a panic in rr?
timotimo masterduke doesn't have access to rr; i have rr but at the moment not the time/energy to investigate sufficiently 18:37
MasterDuke i'd have to switch to my laptop
which would be slow going right now (i only have one hand free and can't easily move) 18:38
will be able to later 18:40
MasterDuke kids fell asleep faster than expected. trying to get a rr recording on the laptop now 19:04
nine I managed to do so with rakudo build. The item in the work list is a candidate->spesh_slots[i] that's completely zeroed out 19:07
MasterDuke huh, how does it get zeroed? 19:12
did you build with MVM_GC_DEBUG set at all? 19:13
nine yes 2
MasterDuke hm, i don't see any obvious memsets of candidates 19:17
nine It's the object put into a spesh slot that's zeroed out 19:18
nine which is odd as you did not change anything about spesh slots 19:19
MasterDuke can you run it backwards and see if it was ever non-zero? 19:22
nine trying to 19:24
jnthn But when you allocate the candidate, is anything keeping the spesh slots alive? 19:26
tellable6 2020-09-10T18:55:31Z #raku-dev <vrurg> jnthn Could you have another look at github.com/Raku/problem-solving/issues/227? It might have consequences for RakuAST too.
jnthn There wasn't a GC allocation on that path before 19:27
nine Well the object gets collected 19:28
MasterDuke i'm not sure i understand the question. are you suggesting another MVM_ASSIGN_REF is needed for the slots to the candidate? 19:30
nine MasterDuke: no, you need to MVMROOT the spesh slots when allocating the candidate 19:31
they are stored in the spesh graph at that time
jnthn Right, but iirc the spesh graph is held for some time in a place the GC knows about, so it may be a case of moving that later 19:32
Will glance the PR again in a moment, just gotta take care of some home task.
MasterDuke well, `MVMROOT(tc, sg->spesh_slots, { candidate = (MVMSpeshCandidate *)MVM_repr_alloc_init(tc, tc->instance->SpeshCandidate); });` causes a quick and consistent panic when building nqp 19:35
jnthn Yes, that makes no sense, alas.
nine More like for(int i = 0; i < sg->num_spesh_slots; i++) MVM_gc_root_temp_push(tc, (MVMCollectable **)&sg->spesh_slots[i]); candidate = (MVMSpeshCandidate *)MVM_repr_alloc_init(tc, tc->instance->SpeshCandidate); MVM_gc_root_temp_pop_n(tc, sg->num_spesh_slots);
jnthn aha, yes 19:36
/* Clear active graph; beyond this point, no more GC syncs. */
tc->spesh_active_graph = NULL;
Try to move that after the line:
candidate = (MVMSpeshCandidate *)MVM_repr_alloc_init(tc, tc->instance->SpeshCandidate)
What nine suggests is an alternative, but just moving the nulling probably does it and is less code 19:37
MasterDuke nqp built... 19:38
but rakudo dies the same way 19:39
with just moving the nulling
i'll try nine's suggestion now
jnthn .tell vrurg I did read through the posts today; it's quite a bit to think about (in a week with a lot else to think about at work... :)) 19:40
tellable6 jnthn, I'll pass your message to vrurg
jnthn .tell vrurg Will mull it over some and try and get back to you soon.
tellable6 jnthn, I'll pass your message to vrurg
jnthn MasterDuke: One other thing to try: make it allocate in gen2 19:42
I forget the exact function name to set/clear that mode
vrurg jnthn: ok, thanks! Just didn't want it to be overlooked. Even if the experiment considered a failure it reveals a few rough edges worth considering for the future.
jnthn vrurg: Yeah, fixing coercions is certainly something we need to do. 19:43
Plus fully implementing them, so they can work on assignments too
MasterDuke moved nulling plus nine's suggestions dies same way in rakudo build. investigating gen2 alloc now
jnthn So I'm very glad to see it worked on 19:44
MasterDuke: github.com/MoarVM/MoarVM/blob/mast...tion.h#L12 fwiw
MasterDuke wrap the candidate allocing in MVM_gc_allocate_gen2_default_set + MVM_gc_allocate_gen2_default_clear ?
jnthn Yesa
*yes
MasterDuke well all three things combined dies with a panic in the nqp build, just moved nulling plus gen2 alloc causes `moar: src/spesh/arg_guard.c:104: add_type_check_node: Assertion `type->st != NULL' failed. make: *** [Makefile:394: gen/moar/stage1/QRegex.moarvm] Aborted (core dumped)` 19:47
jnthn wow
MasterDuke and only the gen2 alloc also panics in the nqp build 19:48
if it matters, this is all with MVM_GC_DEBUG set to 1
jnthn OK, last idea before I'll probably need to actually get out a debugger: move candidate = (MVMSpeshCandidate *)MVM_repr_alloc_init(tc, tc->instance->SpeshCandidate); to the very start of the function, then push it as a temp root, and pop it at the end 19:53
MasterDuke k
jnthn So that the allocation of it is done before we need to go marking things 19:54
Though given how many things haven't worked yet, I fear our problems are not about the candidate allocation.
MasterDuke nqp built 19:57
but rakudo panicked the same way 19:58
jnthn OK, I think it probably is not about that candidate allocation, but about some other missing marking, then. 20:00
MasterDuke hm, i'll keep looking 20:04
nine There are probably a couple issues left. So even if something doesnt help immediately (or seems to make things worse) it can still be correct 20:05
MasterDuke think any of those things suggested should stay? 20:06
jnthn Probably the move of the NULLing of the graph attached to the tc 20:08
MasterDuke i'll add that to the pr 20:11
MasterDuke oh, i'm pretty sure the unmanaged_size i added is not 100% correct. but that shouldn't cause serious problems, right? 22:12
jnthn No 22:23
It's used for heap snapshots and to help make decisions about when to do full collections, but it's not important for correct execution. 22:27
MasterDuke thanks 22:28
jnthn just took 3 attempts to calculate .arity and .count correctly after adding slurpy param support to RakuAST, and is now glad he decided to do something relatively easy... 22:30
sleep o/ 22:43
MasterDuke same

Powered by Cro and the Raku® Programming Language.

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

Thank you!