github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:30 sxmx left 03:20 lucasb left 04:40 squashable6 left 04:42 squashable6 joined 04:44 squashable6 left, squashable6 joined 05:53 Kaiepi left 05:54 Kaiepi joined 06:12 Kaiepi left, Kaiepi joined 06:21 domidumont joined 06:56 domidumont left 07:10 domidumont joined 07:44 eaterof joined 07:46 domidumont left 07:47 eater left 08:06 zakharyas joined, sena_kun joined 08:33 frost-lab joined 08:37 MasterDuke left
nwc10 good *, #moarvm 09:04
(I am AFK mostly - have a table to assemble)
09:15 Kaiepi left 09:16 Kaiepi joined
jnthn moarning o/ 09:22
nwc10 \o 09:31
09:49 sivoais_ left, sivoais joined 10:15 domidumont joined 10:41 lizmat_ joined 10:44 lizmat left 10:45 lizmat_ is now known as lizmat 11:17 zakharyas left 11:43 domidumont left 11:49 MasterDuke joined 12:13 patrickb joined 12:15 patrickb left
MasterDuke . 12:29
tellable6 2021-03-30T10:12:09Z #raku-dev <lizmat> MasterDuke: I'd be in favour of merging now and a blin run
nwc10 I have a table. It passed the unit test (1 bottle of beer) 12:31
I guess acceptance testing requires more than one person
MasterDuke i need to put together two radiator covers and then secure them plus one i already constructed to the walls 12:32
jnthn nwc10: Is a bottle of beer really only one unit? :) 12:33
nwc10 I feel that I mostly prefer underfloor heating to radiators. The two use cases I miss for radiators are (1) leaning against them (2) putting/hanging things on them to dry out
jnthn: dammit, you, um, exacting person 12:34
I think 2.5 UK units
but this is an Austrian beer bottle (now empty)
So a €0.09 deposit 12:35
MasterDuke agree with both points. and yeah, i wouldn't choose radiators for new construction. but they seem to be pretty popular here in the uk
nwc10 UK (and at least some of north west France, it seems) favour masonary walls with wooden joists and then wooden floorboards at right angles. (Would guess Ireland is going to be the same, but [citation needed]). Most of the contintent seems to favour solid concrete floors 12:38
meanwhile, I wonder where the rocket is: www.youtube.com/watch?v=sTA0GTgFn5E 12:39
jnthn My apartment has underfloor heating. I really like it. Had it in a previous place I rented a decade and a bit ago, and was keen to have it again when buying a place here in Prague, but it's not common here at all, so I didn't have it as a "blocker". 12:41
Was very glad to find a place that was good in a bunch of other ways *and* had such heating.
Only slight mis-feature in warmer months is that if you let the sun shine onto the floor then this also seems to heat the fluid in the floor quite effectively, which then warms the room further. 12:42
MasterDuke i've never lived in a house on the continent, so can't really compare. but everywhere i've lived in the states was wood frame and wood flooring (some had parts in tile)
nwc10 I guess underfloor heating is only in things here built in the past 30-40 years. (Yes, OK, I know that the Romans did it too, but with air not water) 12:43
jnthn The first time it happened I was like "why on earth is the heating working???" :)
MasterDuke our neighbor has underfloor heating in their kitchen (otherwise identical to ours) and i'm very jealous
nwc10 jnthn: we've not had that
nine I got spoiled by the underfloor heating in the house my parents built in '89. Didn't have it in my first flat, but I'm glad I have it now. Compared to radiators it just takes out any consideration about heating once you got the setting right. You just leave it at that and everything's right. Also because you can't change it short term anyways as it takes ages to react :) 12:45
tellable6 2021-03-29T13:46:23Z #raku-dev <raiph> nine Thanks for your response in Feb about using IP6 for callbacks. :)
jnthn Anyway...finally new-disp hacking time 12:46
MasterDuke my parent's house had (and still has) radiators, but everywhere else i've lived until now had central heating/cooling
which i do prefer, especially if it also has underfloor heating (though that doesn't necessarily have to be for heating the environment, just for comfort walking) 12:47
nwc10 jnthn: well, maybe in 15 muinutes: www.youtube.com/watch?v=gjCSJIAKEPM 12:56
T -04:00
leont But fog? 12:59
jnthn uff, the rebase is quite some effort...
Goodness, the fog made it hard to see much there 13:00
Seems that didn't go entirely to plan. 13:10
13:10 zakharyas joined
nine Yeah, the fog blocked the view of the exciting spectacular test end they had planned 13:12
13:14 travis-ci joined
travis-ci MoarVM build failed. MasterDuke17 'Merge pull request #1450 from MasterDuke17/simplify_time_in_ops 13:14
travis-ci.org/MoarVM/MoarVM/builds/765050200 github.com/MoarVM/MoarVM/compare/1...220f95a813
13:14 travis-ci left 13:15 brrt joined
MasterDuke jnthn: i probably just made the rebase more annoying with that merge, since the oplist, etc have now changed 13:19
jnthn The changes in frame.c/deopt.c are far more painful, alas 13:26
MasterDuke hm, then there might be some more pain in the future when my remove optimizations pr is merged 13:27
jnthn The bit that logs deopts isn't actually master yet, correct? 13:39
13:41 klapperl left, klapperl joined
MasterDuke correct 13:42
jnthn Good, then I didn't lose it by accident :) 13:46
Argh, so I got through the rebsae but 14:09
Bytecode validation error at offset 258, instruction 40:
string index 47054861 out of range 0..1763
When building NQP
I'm guessing there was a rebootstrap or something.
MasterDuke i had to rebootstrap for the nqp::time PRs 14:11
jnthn oh that's dumb, I didn't pull MoarVM master before doing the rebase 14:18
So miss the time op changes
I should probably have just got on with stuff and left the rebase for another time. 14:21
14:29 frost-lab left
jnthn Sigh, and now this: 14:31
+++ Compilinggen/moar/stage1/nqpmo.moarvm
MoarVM panic: Internal error: zeroed target thread ID in work pass
make: *** [Makefile:371: gen/moar/stage1/nqpmo.moarvm] Error 17
MasterDuke has seen that one so many times when working on various PRs... 14:33
jnthn I suspect that somewhere in new code I added there's a MVMSpeshCandidate that needs MVMROOTing or some such 14:35
MasterDuke i'm sure there's some git reflog magic to get you back to before you started the rebase
jnthn Well, I didn't push it, so I also just have origin/new-disp as that 14:37
But that'll just put off solving this anyway 14:39
Guess this month's grant report will just be "my arm hurt and when it finally stopped I did a rebase" :P
MasterDuke ha
rebases can certainly be non-trivial
jnthn Well, it's not so much the rebase itself now as the fact that I've probably got changes that made assumptions that no longer hold up 14:40
MasterDuke i was chatting with pmurias about how i tried once or twice to rebase the truffle branch on nqp up to master...
and it quickly had conflicts i had no idea how to resolve 14:41
jnthn Anyway, turning on GC debug mode tells me MVM_spesh_arg_guard_gc_mark adds something with a zeroed owner
Which is surely a candidate
MasterDuke yeah, that sounds familiar
jnthn oh, it's not 14:42
MVM_gc_worklist_add(tc, worklist, &(ag->nodes[i].st))
It's marking an STable
In the guard tree
That's a bit more strange 14:43
brrt I thought STable wasn't collectible, or am I mistaken
nwc10 I thuoght that they were always allocated in gen2, but other than that, not special 14:44
MasterDuke e75ba1daac fwew, not me 14:45
14:45 linkable6_ left 14:46 linkable6 joined
MasterDuke weird bracing going on in that switch/case 14:46
jnthn They are collectible, and there's no gen2 promises about them in general, though a lot of them will be
The nice thing about doing this with rebase, is that I can bisect the commits in the rebased new-disp 14:57
And then, hopefully, get just one commit to look at
This was a nice idea, but the first bad commit doesn't have the problem :/ 15:04
OK, somehow the commit it landed on is fine but the one *after* it reliably has the problem 15:16
Yup, tried a bunch of times, got a commit that is somehow to blame, and the somehow is a bit odd 15:20
15:22 brrt left 15:26 brrt joined
jnthn Intresting, it now blows up in MVM_gc_worklist_add(tc, worklist, &(candidate->type_tuple[i].type)); 15:26
In MVMSpeshCandidate.c
And the commit in question twiddles with args handling 15:27
So it all fits...somehow :)
Hm, did anything change recently-ish with args/capture handling? 15:39
nine not that I'm aware of 15:50
jnthn Oh wow, I think I found it
nine aaaaaaaaaaaaaaaaaaaaand? 15:51
jnthn So I have a terrible temporary hack that maps the old calling conventions into the new when we invoke anything implemented as an MVMCFunction
Terrible enough that it just sets/clears the "allocate in gen2" flag while it runs
So in theory that's just the KnowHOW metamodel boot functions. No big deal. But. 15:52
We also use that mechanism to run C code on a new thread. Which is what we do for the event loop and spesh thread. 15:53
Which for the event loop thread is ineffecient but OK
The spesh thread never used to allocate at all
Now it allocates spesh candidates, however
And allocates them in the nursery, which is maybe not optimal
Except my hack makes it allocate in gen2 15:54
It doesn't write barrier on the things assigned into it, however
(in the spesh candidate setup) 15:55
Which means we can end up with a gen2 -> nursery reference without being in the remembered set, and thus the crash
I guess allocating something long-lived like a spesh candidate probably makes sense to go directly into gen2, but if we tried to do that in master we'd be in bother 15:56
nine what would be the problem with trying that in master? 16:02
jnthn None; it's easy to try there and easy to apply a fix there
nine What's the proper way to handle an array like spesh_slots that's already filled when added to the spesh cand? Just call MVM_gc_write_barrier for each item in the array? 16:08
jnthn IMO the safest way is just th call MVM_gc_write_barrier_hit(tc, candidate) if it's allocated in gen2, and if it doesn't need to be in there the GC will boot it out on the next GC run 16:10
nine AFAICT spesh_slots is the only thing pointing at collectables in spesh candidates
jnthn No, the type_tuple also does 16:11
Also the inlines table points at code objects, iirc
nine Ah, indirectly
jnthn The type tuple is was to blame in this case 16:12
Well, more like, it's what showed up when I set GC_DEBUG
And yay, with that fix the NQP tests, including all the dispatch ones, pass 16:14
nine MoarVM panic: Internal error: invalid thread ID 5898880 in GC work pass
That was....faster than expected :D 16:15
jnthn Ah, you also managed to make it blow up that way? :)
nine Despite the MVM_gc_write_barrier_hit
jnthn Pushed all the rebases of new-disp in moar/nqp/rakudo 16:19
The head commit of new-disp is the tweak for gen2 candidates
nine Wrapping the MVM_repr_alloc_init in MVM_gc_allocate_gen2_default_set/MVM_gc_allocate_gen2_default_clear and doing an unconditional MVM_gc_write_barrier_hit afterwards still gives me GC trouble with types in arg guards 16:25
jnthn As soon as NQP build, or elsewhere? 16:29
nine t/02-rakudo/03-cmp-ok.t 16:31
With MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 I managed to catch it in rr
With MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 it even happens during nqp build 16:32
16:34 patrickb joined
jnthn Ah, with those I get an NQP blowup too, although of course new-disp has so much else at play that it's not immediately clear this is the reason 16:34
16:40 Geth joined
Geth MoarVM: patrickbkr++ created pull request #1452:
Disable Travis and AppVeyor		 16:51
17:11 zakharyas left 17:44 linkable6 left 17:45 linkable6 joined 17:48 brrt left 18:20 Kaiepi left 18:21 Kaiepi joined
nwc10 jnthn: I think that it used to work, but I forget the details 19:31
if you clear them for NQP build, then set them again for rakduo, the setting build is failing in some interestign (and silent) way
but I'm too tired to investigate for now. 19:32
ASAN says nothing.
sorry I can't be more helpful
19:46 MasterDuke left 19:48 MasterDuke joined
nine jnthn: progress! 19:57
jnthn: allocating the spesh candidate in gen2 means that when we assign it into the StaticFrameSpesh's candidates list, there's no longer a reason for adding the latter to the gen2 list, as the reference we assign isn't in the nursery. 19:59
Adding a MVM_gc_write_barrier_hit(tc, (MVMCollectable*)spesh); makes the GC trouble go away. So now we just need to find out where we need to use MVM_ASSIGN_REF, to make the need for that workaround go away. 20:00
Actually it's kinda obvious. MVM_spesh_arg_guard_regenerate doesn't even get a pointer to the MVMStaticFrameSpesh, yet it adds stuff containing pointers to MVMCollectables to the MVMStaticFrameSpesh spesh_arg_guard tree 20:03
Oooooh....when turning spesh candidates into collectables, we lost these 3 lines of code from MVM_spesh_candidate_add: 20:05
/* May now be referencing nursery objects, so barrier just in case. */
if (spesh->common.header.flags2 & MVM_CF_SECOND_GEN)
MVM_gc_write_barrier_hit(tc, (MVMCollectable *)spesh);
MasterDuke i think i asked about those and someone they wouldn't be needed anymore. but they are? 20:06
nine So my workaround was actually a legit solution once. It was just unneeded when the spesh candidate was allocated in the nursery, as MVM_ASSIGN_REF(tc, &(spesh->common.header), new_candidate_list[spesh->body.num_spesh_candidates], candidate); took care of the write barrier. 20:07
But when the spesh candidate is allocated in gen2 directly, they become vital 20:08
MasterDuke ah
20:13 zakharyas joined 20:19 zakharyas left 20:26 zakharyas joined 20:37 patrickb left 20:40 MasterDuke left 20:41 MasterDuke joined 20:55 MasterDuke left 20:56 MasterDuke joined 21:20 zakharyas left 22:38 cog_ joined, samcv_ joined 22:40 nebuchad` joined, tobs` joined 22:41 cog left, samcv left 22:42 nebuchadnezzar left, tobs left, tobs` is now known as tobs 23:05 samcv_ is now known as samcv 23:06 samcv left, samcv 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!