Welcome to the main channel on the development of MoarVM, a virtual machine for NQP and Rakudo (moarvm.org). This channel is being logged for historical purposes.
Set by lizmat on 24 May 2021.
00:01 linkable6 left 00:02 linkable6 joined, reportable6 left 00:04 reportable6 joined 00:12 m6502 left 00:23 nine left, nine joined 01:23 committable6 left, squashable6 left, reportable6 left, bisectable6 left, statisfiable6 left, quotable6 left, shareable6 left, bloatable6 left, unicodable6 left, evalable6 left, coverable6 left, benchable6 left, sourceable6 left, tellable6 left, notable6 left, nativecallable6 left, linkable6 left, releasable6 left, greppable6 left 01:24 nativecallable6 joined, shareable6 joined, squashable6 joined 01:25 reportable6 joined, linkable6 joined, greppable6 joined, releasable6 joined, bisectable6 joined, committable6 joined, quotable6 joined, statisfiable6 joined 01:26 benchable6 joined, tellable6 joined, notable6 joined, sourceable6 joined, bloatable6 joined, evalable6 joined 01:27 unicodable6 joined, coverable6 joined 02:49 discord-raku-bot left 02:50 discord-raku-bot joined 04:21 frost joined 06:02 reportable6 left 06:04 reportable6 joined
nine I've let it run all night and neither MVM_SPESH_BLOCKING=1 nor MVM_SPESH_DISABLE=1 nor gdb failed 06:59
07:04 evalable6 left, linkable6 left 07:06 linkable6 joined 07:07 evalable6 joined
dogbert17 nine: what conclusions do you draw from that result? 07:48
nine None. Except that the bug is somewhat elusive. This is quite typical for bugs that depend on precise timing or memory layout to reveal themselves. Like errors you get when run in make test but not when running a test file individually. 07:51
dogbert17 I tried turning off some spesh features. MVM_SPESH_PEA_DISABLE didn't fix the problem nor did MVM_SPESH_OSR_DISABLE. I couldn't get the problem to occur when MVM_SPESH_INLINE_DISABLE was set but perhaps it just takes longer. 07:52
nine Oh, wait a minute! It did actually fail in rr :)
I just forgot that I started the rr run in the shell where I previously run it without any additions (the one case where I could get it to fail) 07:53
07:53 patrickb joined
nine Just took 1540 tries to fail in rr 07:53
dogbert17 that is fantastic 07:54
MasterDuke nice
nine And the bug may even be quite straight forward 07:57
We deserialize the method cache at github.com/MoarVM/MoarVM/blob/mast...on.c#L3171 07:58
Then run the work_loop to deserialize its entries. This may trigger GC. Since the cache at that point is not referenced by any root, we free it.
Serialization and deserialization runs with allocation in gen2 enabled, so we don't have tons of MVM_ROOT in the (de-)serialization code. But that only protects against pointers getting moved. Not actually against stuff getting freed. 07:59
MasterDuke move that ASSIGN_REF to right after the deserialize?
nine Yep, that sounds about right 08:00
Except for b4cd2a6555 08:05
So maybe MVM_ROOT is the way to go
08:06 linkable6 left 08:07 linkable6 joined
MasterDuke ha 08:07
nine git++ 08:09
08:15 patrickb left 08:16 patrickb joined
jnthnwrthngtn moarning o/ 09:36
jnthnwrthngtn wonders how many days he is away from killing off that method cache... :) 09:37
.oO( its days are numbered! )
Nicholas hacking days, or calendar days? 09:50
jnthnwrthngtn Given I've not got that much consulting stuff on my plate in July, those might be somewhat similar for the next while :) 09:51
Nicholas woohoo! Party on. 09:56
nine Oh darn....apparently the MVMROOT did not fix the issue. After 2 hours of running the test in a loop I got the error again 10:01
jnthnwrthngtn: MVMROOTing something should keep it from getting collected, shouldn't it?
jnthnwrthngtn nine: Only during the time the MVMROOT is in dynamic scope 10:03
But otherwise, yes, it counts as a GC root
nine I.e. MVMROOT(tc, cache, { if (sr->working == 1) work_loop(tc, sr); }); when deep inside work_loop GC gets triggered 10:04
jnthnwrthngtn Yes, that should suffice 10:06
If it doesn't, there's something else going on
But also, I thought everything deserialized ended up in gen2 anyway 10:07
lizmat maybe the process itself creates objects in the nursery?
jnthnwrthngtn "the process"? 10:08
lizmat the deserialization process
like a loop variable?
jnthnwrthngtn It shouldn't, in so far as the "please allocate directly in gen2" flag shuld be set at all times when we're in the deserialization process
nine jnthnwrthngtn: gen2_default is definitely set. But getting into gen2 doesn't protect something from getting freed, does it? After all we may still do a full collection 10:09
jnthnwrthngtn nine: This is correct, yes.
But. hm 10:10
The trigger for a full collection is a full nursery
nine I can trigger the bug reliably by adding an MVM_gc_enter_from_allocator(tc); after cache = MVM_serialization_read_ref(tc, sr);
While if I enter gc inside the MVMROOT, nothing happens
jnthnwrthngtn So I guess this only happens when there's another thread working while this one is deserializing
nine I wonder if my fix is correct but it's just that we have a similar bug elsewhere 10:13
It did take 2 hours to trigger it again after all 10:14
jnthnwrthngtn Possible; the deserialization code has probably usually always been inovked as the only running thread 10:15
nine cache = MVM_serialization_read_ref(tc, sr); 10:24
And once you start looking. At this point in read_param_intern, ptype and its STable are not rooted: github.com/MoarVM/MoarVM/blob/mast...on.c#L2695 10:25
They are in gen2, but not referenced
And we even do a nursery allocation
Geth MoarVM/new-disp: c370aa1bc1 | (Jonathan Worthington)++ | src/disp/boot.c
Correct a comment
MoarVM/new-disp: 35f3039b3f | (Jonathan Worthington)++ | src/disp/boot.c
Make boot-code-constant dispatcher handle C funcs

Which is just wiring it up to code that has since been written for other purposes.
MoarVM/new-disp: 938291229b | (Jonathan Worthington)++ | 5 files
Implement the boot-code dispatcher

Which is like boot-code-constant, except it does not imply that the object should be considered a constant. The latter would cause bother with invoking closures, since we'd fixate on a given closure clone.
MoarVM/new-disp: 95b7435c3c | (Jonathan Worthington)++ | src/disp/boot.c
Cats may be pure, but captures they are not

  MasterDuke++ for noticing
.oO( it haz cats? )
jnthnwrthngtn meow 11:15
Time for lunch
11:23 discord-raku-bot left 11:32 discord-raku-bot joined 11:37 discord-raku-bot left 11:39 discord-raku-bot joined 12:02 reportable6 left 12:03 reportable6 joined
Nicholas jnthnwrthngtn: you know about this? 12:28
./rakudo-m -Ilib t/spec/S06-signature/closure-parameters.rakudo.moar
moar: src/core/interp.c:129: MVM_disp_inline_cache_get: Assertion `slot < cache->num_entries' failed. 12:29
jnthnwrthngtn Nicholas: You mentioned it before. I failed to repro it. 12:39
Nicholas Was it the same testcase? 12:57
that's a spectest. I think that the previous was nqp
jnthnwrthngtn I already fixed the NQP build valgrind barf 12:58
I'm pretty sure the order was this one (failed to repro), the NQP one (fixed), and this one again. The assertion fail and test name look familiar, anyway 12:59
Nicholas *at least* one of us is confused :-) 13:00
FSA assertion panic in NQP. Seems to be only on one machine I have access to 13:01
valgrind error was NQP
the assertion failure is a spectest
oh wait, it's me 13:02
you're tracking this better than me 13:03
13:05 RakuIRCLogger left 13:07 RakuIRCLogger joined
jnthnwrthngtn Ah, I had forgotten the FSA one, I'm not sure if I conclusively failed to repro that 13:07
13:18 patrickb left
Nicholas IIRC I only had it on that machine, so I thought it might be compiler dependant 13:24
MasterDuke just a plain checkout of new-disp+setting FSA_DEBUG doesn't repro it for me 13:37
but i did get some sort of crash in rakudo's t/04-nativecall/01-argless.t once, but i can't repro it 13:38
is it expected that a lot of spectests fail? 13:47
jnthnwrthngtn MasterDuke: Probably 14:20
MasterDuke: I've not run spectest in a while on that branch; it feels like a long shot that it'd be close to passing given things are half way between two dispatch systems 14:21
MasterDuke ok, won't mention the failing ones then 14:22
jnthnwrthngtn Segfaults are useful to know about as those absolutely shouldn't happen, but other failure modes aren't surprising. Certain things always end up in the new dispatcher, but then encounter things that aren't set up for it. 14:23
I think I've probably gone about as far as I can with "sort of keep things working but turn on new-disp with an env var"; any next step runs into too many discrepancies. 14:24
Upcoming commits will work towards switching every call and callmethod compiled on MoarVM to the new dispatch mechanism. 14:25
And then getting NQP happy again. I expect during that time even the Rakudo build will be busted.
I can't really go any further with Rakudo because the next step is to compile the setting with new-disp used for multi dispatch 14:26
Well, and everything really
But that immediately runs into the problem that trying to call trait modifiers from the compiler blows up, because NQP calls aren't using new-disp 14:27
With that road having run out under me, there's not much for it than going for switching NQP over.
[Coke] Makes sense to me, FWIW - Will others be able to chip in to help, or will that make it harder? 14:31
(or, I suppose I mean, will others not be able to help because you'll be fixing the one next broken thing each time?)
jnthnwrthngtn [Coke]: I think once we're at the point where the big switchover is done and we're hunting regressed spectests, yes 15:02
Yay, got lang-call working 15:15
(dispatcher that will delegate to the appropriate HLL dispatcher)
Nicholas you have the beer fridge ready for later? 15:16
jnthnwrthngtn Yes
Nicholas Good. (Just checking)
jnthnwrthngtn Going to try and get lang-meth-call working before language class, though :)
Well, almost got it... 15:49
15:51 patrickb joined
jnthnwrthngtn Seems Geth is giving my push the silent treatment, but the lang-call and lang-meth-call are in :) 17:22
The next step will be to change the QAST compiler to emit dispatch ops using them for `call` and `callmethod` nodes. 17:23
And then fix the world that results :)
Nicholas useless bot
jnthnwrthngtn Anyway, all that sounds too much effort for a sunny evening when there's beer in the fridge. :) 17:28
Oh! I also have mead... 17:29
Nicholas #firstworldproblems
have fun - it's still a bit too hot and humid outside here for me to find it enjoyable to sit outside 17:30
jnthnwrthngtn I'm about to test how it is here. I think it is hot and humid but there seems to be a breeze that will make it tolerable... 17:31
leont @jnthnwrthngtn: didn't know you were also a mead drinker 🙂 17:35
18:02 reportable6 left 18:04 reportable6 joined
Nicholas I realse. I think I last drank mead before I learned perl. 18:17
MasterDuke i always thought i would like mead, and want to, but never really have 18:52
but there is a bigger cider selection here than in the us, so i've been trying lots of different ciders 18:53
20:21 patrickb left
jnthnwrthngtn leont: I wasn't until relatively recently, when I ordered a bunch of beer, the shop were out of one, and by cunning or incompetence substituted it with another product of the same brewery...which happened to be a mead. 22:15
Instead of complaining, I drank it, found it pleasant enough, and ordered some more the next time. I've nowhere near enough experience to know if what I'm drinking counts as a good mead. :) 22:16
www.eshop-axiombrewery.cz/axiom-br...sion-mead/ fwiw 22:17
Also: wow, this brewery have their own eshop now, that's new.
Now I don't have to figure who has their stuff in stock this time. 22:18
leont has about 15 liters of homebrew mead in his cellar (a)
jnthnwrthngtn Oh wow :)
22:19 linkable6 left, frost left, sourceable6 left, tellable6 left, statisfiable6 left, bisectable6 left, releasable6 left, greppable6 left, shareable6 left, nine left, timo left, discord-raku-bot left, dogbert17 left, Voldenet left, Kaiepi left, cognominal left, MasterDuke left, reportable6 left, evalable6 left, coverable6 left, unicodable6 left, bloatable6 left, notable6 left, benchable6 left, quotable6 left, committable6 left, squashable6 left, nativecallable6 left, lizmat left, LizBot_ left, [Coke] left, rypervenche left, leedo left, jdv left, kjp left, JRaspass left, camelia left, AlexDaniel left, nebuchadnezzar left, harrow left, Nicholas left, bartolin_ left, rba left, Geth left, ugexe left, ilogger2 left, leont left, moon-child left, samcv left, vrurg left, tbrowder left, jnthnwrthngtn left 22:21 leedo joined, rypervenche joined, jdv joined, jnthnwrthngtn joined, tbrowder joined, vrurg joined, discord-raku-bot joined, dogbert17 joined, Voldenet joined, Kaiepi joined, cognominal joined 22:22 cognominal joined, Kaiepi joined, Voldenet joined, dogbert17 joined, discord-raku-bot joined, samcv joined, moon-child joined, leont joined, ilogger2 joined, leedo joined, rypervenche joined, jdv joined, jnthnwrthngtn joined, tbrowder joined, vrurg joined, linkable6 joined, frost joined, sourceable6 joined, tellable6 joined, statisfiable6 joined, bisectable6 joined, releasable6 joined, greppable6 joined, shareable6 joined, nine joined, timo joined, rba joined, MasterDuke joined 22:23 reportable6 joined, evalable6 joined, coverable6 joined, unicodable6 joined, bloatable6 joined, notable6 joined, benchable6 joined, quotable6 joined, committable6 joined, squashable6 joined, nativecallable6 joined, lizmat joined, LizBot_ joined, [Coke] joined, camelia joined, AlexDaniel joined, nebuchadnezzar joined, harrow joined, Nicholas joined, bartolin_ joined, ugexe joined, Geth joined 22:24 kjp joined, JRaspass joined
leont My stuff is a bit stronger than that though, more comparable to wine than beer. Probably quite a different drink. 22:26
22:28 AlexDaniel left
jnthnwrthngtn Yeah, sounds like. This one is on the sweet side, but pleasant in the summer. 22:33
japhb Mead always seemed to be more desert than general drink 23:58