github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
MasterDuke wow, the MVM_SPESH_INLINE_DISABLE=1 run is still going. i gotta get to bed, but i'll continue a bit tomorrow 00:15
jnthn Yeah, I should sleep soon too. Sunday night's 4 hours of sleep are still being felt a bit... 00:18
'night o/
02:25 leont left
nwc10 good *, #moarvm 07:25
08:38 MasterDuke joined
nwc10 MasterDuke: I believe that we're accidentally not accidentaly quadratic. 08:43
ie we're fine.
MasterDuke ha, nice 08:44
nwc10 the specific problem case was copying a hash by iterating it in the internal storage order, where the robin hood "displacement" is also forwards
er, where the target hash isn't pre-sized to be big enough for the final number of keys, so has to "grow" 08:45
for the externally visible MVMStrHashTable we randomise key order per hash, so it won't matter
and we don't have iterators on most of the internal hashes
and our iterators only run "backwards" anyway (ie the reverse direction from the Robin Hood "displacement" direction) 08:46
because they are "backwards" it's trivial to delete the hash entry at the iterator location without messing up the future iteration
it also made the "end?" check simple - "is it zero?"
MasterDuke good deal 08:48
jnthn: that MVM_SPESH_INLINE_DISABLE=1 run finished without error sometime overnight. interestingly, if i remove MVM_SPESH_INLINE_DISABLE=1 (so run it how i've been for most of the past discussion) and set GC_DEBUG=1, it doesn't segv. so i did a run to completion with the deopt log and GC_DEBUG=1, now doing a run with the deopt log and GC_DEBUG=3 08:52
to compare
nwc10 The vestigial assembler programmer in me always prefers loops down to 0 as you don't need another register to hold the end value
and hopefully 1 fewer instruction as "did we reach zero?" might be a side effect of "decrement by one" 08:53
nine and registers are precious
nwc10 although I have observed that C compilers are scary effective, and manage to translate umpteen different ways of writing the same loop to byte-for-byte *identical* output
so sometimes clarity is free. 08:54
but I suspect only within a for or while loop local to a function
09:10 MasterDuke left 09:14 MasterDuke joined
MasterDuke jnthn: last 3 lines in the failing deopt log are `Completed deopt_one in 'arglist' (cuid '346') with potential uninlining`, `Deopt one requested by interpreter in frame 'arglist' (cuid '346')`, `Will deopt 616 -> 584` 09:14
09:14 zakharyas joined
MasterDuke if i set GC_DEBUG=0 and restart the whole nqp build i get a segv much faster, but it's in hash code. gist.github.com/MasterDuke17/57cb4...64a93fd292 09:24
09:27 leont joined 09:56 domidumont joined
jnthn Hmmm...so it fails in a deopt that had already worked out OK in the past 10:32
(The very immediate past)
That whiffs like memory corruption indeed
lizmat there is a deopt log ? 10:35
jnthn lizmat: Deopts are included in the profiler for user-facing analysis. There's also a preproc condition one can turn on (thus needing a MoarVM source tweak to enable) that gives some debugging clues about what it's doing 10:38
lizmat ah, so no env variable then to easily tweak and build an interface for 10:39
jnthn No, but I don't think the added info (bytecode offsets, deopt indices, etc.) are terribly useful to anybody not debugging the deopt logic itself 10:40
lizmat perhaps, but I'd say having an interface for it, could make some automatic sanity checking a possibility
jnthn The fact that a local/global deopt took place and in what function is the actionable information, and that's in the profile output.
lizmat crossreffing all those numbers in debug output feels... tedious ? 10:41
jnthn They're only meaningful if one has a spesh log to hand too, and then it's a text search... tbh, though, matching those up is probably the shortest part of hunting a deopt bug :) 10:44
lizmat Hmmm... I once tried to create an interface for the spesh log, would it make sense to revive that ? 10:45
jnthn I guess the question is "who is it for" :) 10:49
I'm sufficiently used to text searching the spesh log (and knowing how to do that) that I can get around it in pretty quickly 10:53
Others may have ideas on what they'd find useful, though 10:54
11:14 MasterDuke left
jnthn Sigh, my coffee machine's latest failure mode involves spraying moist coffee grounds across the kitchen. I suspect its 13 years of service are drawing to a close... 11:27
nwc10 it must be well travelled 11:28
jnthn Yes, 3 countries, 4 apartments 11:36
jnthn is making attempt N (I've lost count) at getting a dispatch resumption design that covers the cases and is optimizable 11:37
lizmat there's potential for a lot of rubberducks on this channel :-) 11:51
12:27 zakharyas left
[Coke] we have a k-cup that we switched to before the pandemic, when most of our coffee was consumed at the office. Really need to rethink this approach with the new normal. 12:42
An early (for me) g'morning to everyone.
nwc10 So, for Christmas I (finally) got an AeroPress
12:42 MasterDuke joined
nwc10 (and also another tea infuser - keep the balance) 12:43
so now the French press is mostly unused
(and therefore not perpetually needing to be washed up)
MasterDuke i've kept an aeropress at the office, since that's where i used to drink the most coffee. now i drink more at home, but i just use the french press (or the k-cup if i just want a smaller cup in a hurry) 12:44
i think i prefer the aeropress over the french press though. i got my dad one for christmas a couple years ago, mom wasn't so pleased because he liked it so much he packed it everywhere/time they traveled 12:46
nwc10 :-) 12:47
MasterDuke jnthn: think an `MVM_barrier()` between the regenerate and the assign is required? 12:49
well, it doesn't change anything 12:52
jnthn MasterDuke: Technically maybe yes but at least x64's memory model is probably not weak enough to really need it 13:20
MasterDuke and/or before the frees? 13:22
jnthn Before the publish point 13:23
So all writes to memory are known to be done before the pointer into the new candidates/arg guard tree is updated
MasterDuke stuck it in both branches, before the `spesh->body.spesh_cands_and_arg_guards     = new_cands_and_arg_guards;` and the `spesh->body.spesh_cands_and_arg_guards = NULL;`, but no change 13:29
jnthn Yeah, I didn't expect it would 13:38
One more experiment: if you add the MVMSpeshCandidate that's going away as a pernament root (so it doesn't get collected ever), does the crash go away? 13:42
MasterDuke something like `MVM_gc_root_add_permanent(tc, &cands_and_arg_guards->spesh_candidates[i]);`? 13:45
where should that go? right before the frees? 13:46
dogbert2 could this be something for jnthn? www.researchgate.net/publication/2...nheritance
jnthn MasterDuke: Why the `&` there? 13:47
spesh_candidates should be an array of pointers to MVMSpeshCandidate
oh argh, I see, MVM_gc_root_add_permanent wants a location 13:48
That won't work
It'll be a pointer into freed memory really soon 13:49
I guess one could do that and comment out the freeing also though
Since the frees are just to not leak, rather than for correct semantics
MasterDuke that added, frees+arg_guard_discard commented out, GC_DEBUG=0 gets same segv 13:52
with GC_DEBUG=3, looks like the same MVM_panic 13:56
jnthn Hm, I guess that tells us that it's not about trying to dereference a freed candidate or arg guard set then 13:57
MasterDuke what about those 0xfefe that show up? (if you recall, i've added `memset(cands_and_arg_guards->spesh_candidates, 0xfe, (new_num + 1) * sizeof(MVMSpeshCandidate *));` before the frees) 13:59
jnthn Ohhh. :/ 14:01
Wasn't that one solved the moving the publish point though?
And we're already onto a different problem?
MasterDuke i think you're right 14:02
i'm not seeing them now
jnthn Ah, but I guess we'd have to remove that in order for the permanent reference to the spesh candidate to be meaningful 14:06
Otherwise we're not keeping it alive
nine I'd suggest writing 0xfd or something like that instead of 0xfe, so you can distinguish it from memory freed by the GC with GC_DEBUG=3 14:08
Of course only if you'd actually free it :)
MasterDuke well, i uncommented the frees, changed to 0xfd, and commented out the MVM_gc_root_add_permanent. now let's see what happens... 14:11
jnthn: oh, you mean move the publish point back? 14:12
oh, remove the memset 14:13
i did have it commented out with the frees
14:26 zakharyas joined 14:30 lizmat_ joined 15:00 lizmat joined 15:03 lucasb joined 15:04 lizmat_ left 15:26 MasterDuke left, MasterDuke joined
MasterDuke i'm not seeing any 0xfd 16:05
Geth MoarVM/new-disp: 6e47e6e4ac | (Jonathan Worthington)++ | src/6model/reprs/MVMCapture.c
Fix a further use of FSA to allocate 0 bytes
 16:29
16:38 lucasb left 16:39 SmokeMachine joined 16:42 kawaii joined 16:45 chansen_ joined, lucasb joined, tbrowder joined 17:00 linkable6 joined 17:06 sena_kun joined 18:00 chansen_ left, chansen_ joined 18:04 kawaii left 18:05 kawaii joined 18:14 chansen_ left, kawaii left 18:18 kawaii joined, chansen_ joined 18:22 zakharyas left 18:24 chansen_ left 18:25 kawaii left 18:26 domidumont left 18:30 chansen_ joined 18:31 kawaii joined
nine Adapting CStr to be able to hold an MVMObject instead of just MVMStrings was quite trivial :) 18:45
18:55 kawaii left 19:06 MasterDuke left 19:19 kawaii joined 19:40 kawaii left 19:42 kawaii joined 20:44 kawaii left, kawaii joined 20:58 squashable6 joined 21:02 leont left 21:50 samcv joined 22:21 MasterDuke joined 23:07 MasterDuke left, cog__ joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!