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:02 reportable6 left 00:41 linkable6 joined 01:10 frost joined 01:11 frost left 02:04 reportable6 joined 02:07 frost joined 03:07 linkable6 left, squashable6 left, greppable6 left, reportable6 left, coverable6 left, bloatable6 left, committable6 left, benchable6 left, releasable6 left, shareable6 left, statisfiable6 left, evalable6 left, quotable6 left, tellable6 left, bisectable6 left, benchable6 joined, committable6 joined 03:08 releasable6 joined 03:09 shareable6 joined 03:10 reportable6 joined 04:07 squashable6 joined 04:08 bloatable6 joined, statisfiable6 joined 04:09 quotable6 joined 04:24 MasterDuke left 05:09 greppable6 joined 06:02 reportable6 left 06:08 tellable6 joined, coverable6 joined 06:34 japhb left
Nicholas good *, #moarvm 06:34
06:35 japhb joined 07:04 reportable6 joined 07:07 linkable6 joined, bisectable6 joined 07:08 evalable6 joined 07:19 patrickb joined
nine Good Friday! 07:41
It is Friday...even on IRC :)
Nicholas nine: ASAN is thoroughly bored by your bug fix branch. But this is not surprising 07:42
nine still good to know
Nicholas I wondered, however, if it would somehow be possible to add "Red zones" into the nursery allocator
or something
so that "writing beyond the end of the official allocated space" was a big explosion of ANSI pavement pizza 07:43
nine Note that in this case we actually allocated in gen2 directly
Nicholas oh. OK.
07:49 patrickb left 07:50 patrickb joined 09:30 squashable6 left 09:33 squashable6 joined
jnthnwrthngtn moarning o/ 09:47
timo raomorning
lizmat moan :-) 10:00
patrickb o/ 10:01
timo i have no remoarse about all these puns 10:29
lizmat refrains from uttering "the more the perlier" 10:30
jnthnwrthngtn Guess I should get back to the callwith thingy today... 10:34
10:34 Altai-man joined
timo "i used to be callwith it, but then they changed what callwith is and now i'm not callwith it any more and it scares me" 10:49
lizmat
.oO( it's always the callsame )
 10:50
.oO( so what's nextsame? )
 10:51
12:02 reportable6 left
jnthnwrthngtn Mmm...red curry 12:11
nine jnthnwrthngtn: what a splendid idea! 12:12
jnthnwrthngtn The place near the office remains as good as ever :) 12:13
grmbl, what on earth is wrong with my callwith thing... 12:14
This is weird. It creates a dispatch program to invoke exactly the right method...then somehow ends up with `callsame` invoked again?! 12:59
nine If the dispatch program is correct, but the results are wrong, doesn't that mean that the program must get interpreted incorrectly? 13:01
jnthnwrthngtn Well, it's wrong directly after the recording phase 13:02
As in, the wrong thing happens directly after it
Or so it seems
oh argh no, I've somehow confused myself with the debug output... 13:04
13:05 reportable6 joined
nine Ah, been there, done that...on a regular basis 13:05
jnthnwrthngtn hah, yes, it's not doing a crazy thing, the weird callsames that follow are legit, they are from exception reporting 13:08
13:27 frost left
Geth MoarVM/fix_mixin_repossession: c7be4282fc | (Stefan Seifert)++ | src/6model/reprs/P6opaque.c
Avoid possible threading issues with mixins

It's possible that one thread is currently accessing an object while another one mixes a role into it. As in the latter case we may replace the object's body, the first thread could end up accessing a body that we just freed in the thread performing the mixin. Better be safe and use the fixed size allocator to allocate the replaced object body and free a previously existing one at a safe point.		 13:30
13:43 patrickb left 13:44 patrickb joined
jnthnwrthngtn Seems it's going to be a problem in MoarVM rather than the dispatchers, and also looking like the problem is in the faked up temporaries 13:48
Nicholas use more 'tea'; ?
Geth MoarVM: f7e0d7d358 | (Stefan Seifert)++ | src/6model/reprs/P6opaque.c
Fix memory corruption caused by repossessed mixins losing their replaced body

When a mixin got repossessed during deserialization, the replaced body pointer would get NULLed. If the mixin needed more storage than the original type provided we could then end up overwriting adjacent objects when deserializing the mixin's attributes.
... (5 more lines)
MoarVM: c7be4282fc | (Stefan Seifert)++ | src/6model/reprs/P6opaque.c
Avoid possible threading issues with mixins

It's possible that one thread is currently accessing an object while another one mixes a role into it. As in the latter case we may replace the object's body, the first thread could end up accessing a body that we just freed in the thread performing the mixin. Better be safe and use the fixed size allocator to allocate the replaced object body and free a previously existing one at a safe point.
MoarVM: 24fd3043c1 | niner++ (committed using GitHub Web editor) | src/6model/reprs/P6opaque.c
Merge pull request #1564 from MoarVM/fix_mixin_repossession

Fix memory corruption caused by repossessed mixins losing their repla…
jnthnwrthngtn Nicholas: Tea is a good idea, but I think I've got a fix even without it :) 14:02
Turns out the code in Raku's dispatchers was right
Now I cross my fingers and run tests :) 14:04
Geth MoarVM: 61600a33b8 | (Jonathan Worthington)++ | src/disp/program.c
Don't duplicately set up fake temps

We allow resume init values from one resumption to be used in the next one. This works out because while we only keep info around about the resumption we are currently handling, the resume init arg will have been loaded into a temporary at the right time, and then the dispatch program can later reference that temporary. When we are producing a dispatch ... (5 more lines)		 14:24
lizmat feels like it is time for another bump ?
Altai-man perhaps, if there is a test case we add? 14:32
or we do have one and was it just fixed?
15:18 vrurg left 15:21 patrickb left
lizmat is not sure jnthnwrthngtn ? 15:42
jnthnwrthngtn Just pushed the bumps along with the callwith work 15:45
And yes, some spectests :)
Altai-man yay
jnthnwrthngtn++
jnthnwrthngtn hah, you just beat me to closing the ticket :P 15:46
Closed the one nine++ fixed 15:47
(fix was also in the bump)
Altai-man I hope the spectest one will be luckily simple. 15:48
jnthnwrthngtn Will check if #4541 is still an issue
I doubt it
Unless it was already fixed
Sigh, this is not so fast on this machine 15:51
nine Odd: In `loop (my int $i = 0; $i < 20; $i = $i + 1) { TakeTwoShorts(10, $i); }` $i gets passed as a native int. But in loop (my int32 $i = 0; $i < 20; $i = $i + 1) { Foo.new.MethodInt($i); } $i is suddenly an IntLexRef 15:59
jnthnwrthngtn Methods are late-bound, so it'd have to assume that? 16:03
(Assume that the target may be `is rw` I mean)
nine I'd figured that new-disp would remove that difference 16:04
jnthnwrthngtn Well, only with work. I did include doing that work in my next grant app. :)
It's an extension of the "pass decontainerized" mechanism 16:05
But probably needs 1) some further dispatch ops for reading native refs, and 2) teaching spesh to eliminate the native ref once it sees the take/deref pairing 16:06
nine But anyway, nqp::isrwcont does detect this situation. Now the question is how does that IntLexRef turn into an Int on it's way to MVM_nativecall_dispatch? MVMDispOpcodeUnboxInt still sees the IntLexRef and fails at MVM_repr_get_int, while if I let it get passed through, MVM_nativecall_unmarshal_int doing the same thing succeeds 16:07
jnthnwrthngtn Is it really calling repr_get_int, or is it doing some slightly higher level unbox operation? 16:08
nine MVM_nativecall_unmarshal_int just does return (signed int)MVM_repr_get_int(tc, value); At that point though value is a P6opaque/Int 16:09
jnthnwrthngtn Huh, I wonder where that happens 16:10
Does it always read objects out of the capture or some such and it happens there? But even that doesn't entirely make sense...
('cus the ref *is* an object) 16:11
nine Especially considering that in my branch there's not much magic left. Dispatch arrives at MVM_nativecall_dispatch(tc, result_type, site, record->outcome.args);
And the dispatcher doesn't know about lex refs: github.com/rakudo/rakudo/blob/new-...kumod#L272 16:12
s/dispatcher/dispatch program/
16:14 MasterDuke joined
jnthnwrthngtn nine: github.com/MoarVM/MoarVM/compare/n...4f854bR438 16:18
Bleh, I think that link may be useless, but see handle_arg and the container mention
nine Oooh..it's hidden in the macro 16:19
I wonder if I should even bother thinking about RW args before your work on the next grant? 16:22
jnthnwrthngtn Well...for ones that are actually rw you'll still need nativecall handling for them 16:23
All I was going to do was make sure we strip off the containers caller side when the parameter is ro
But in terms of doing that part, yeah, could leave handle_arg to do it for now 16:24
OK, the `MVM_SPESH_BLOCKING=1 MVM_SPESH_NODELAY=1 make spectest` took a very long time but...it is clean!
MasterDuke nice 16:25
nine The old implementation had the native function write into the argument register and generated code for reading a value from the arg buffer and assign it back into the native ref. Not sure I can replicate this with a dispatcher
jnthnwrthngtn No, in fact, the arg buffer needs to go away :) 16:26
(It's now only still there due to nativecall) 16:27
MasterDuke jnthnwrthngtn: re the new warning when building moarvm, should `tc` here github.com/MoarVM/MoarVM/blob/mast...er.c#L1010 (and line 1016) be `dtc`?
jnthnwrthngtn I think for rw things the containers are going to have to make it all the way to the dispatch terminal
MasterDuke: yes 16:28
MasterDuke k
nine jnthnwrthngtn: seems to me, the best way to do this would be to pass a pointer to the actually referenced native var to the native function. So it can write its value and we're done 16:29
jnthnwrthngtn You can't do that
A native ref might be to an attribute, and GC can run during a native call (we mark the calling thread blocked) 16:30
And so the object in question can move
Rendering the pointer out of date
Probably we need to allocate a bit of space (can just be on the C stack when we JIT, I guess) for rw params, copy the values there, and pass pointers in to that. Then do the assignments after the call. 16:31
Well, can be on the C stack via alloca in the case we reach the terminal too 16:32
nine New best way: in the JITed version, reserve some space on the stack for these rw args and somehow make that available to HLL code for assigning
jnthnwrthngtn I'm not sure I'd expose this at all, tbh
Keep it as an implementation detail of how the JITted version works
Or at the very least, restricted to spesh ops 16:33
nine I guess I can just compile calls to the right C functions for writing back those args. But which function to call seems to depend on the kind of native ref that got passed 16:34
jnthnwrthngtn It does, but that can be guarded against 16:36
(The kind of native ref is part of the type, so a type guard will do it)
Sigh. I discovered something rather annoying. new-disp assumes that if you guard against a literal value, then a type guard is automatically covered by that 16:38
This is usually reasonable.
Except...mixins.
When we .wrap something we didn't previously wrap, it's the same literal object...but now has a new type 16:39
But since the dispatch program is told about the literal value it's like...oh no, no need to guard that.
Probably that needs to change 16:40
nine Yeah, mixins have a way of ruining your day
jnthnwrthngtn I guess it'll cost a little more in interpreted DPs, but in spesh it'll drop away 16:41
And be left for global deopt to cope with
Or proven that this will never happen
lizmat hmmm... after the bump, zef stopped working for me 16:42
Type check failed for return value; expected IO::Path but got Any (Any)
Geth MoarVM: 4e7fa7704d | (Daniel Green)++ | src/debug/debugserver.c
Use right MVMThreadContext in check for debugging
lizmat apparently only for zef install . 16:43
hmmm... seems to be specific to App::IRC::Log 16:45
lizmat checks further
MasterDuke oh, i saw this yesterday, but forgot just now, github.com/MoarVM/MoarVM/blob/mast...er.c#L1029 should also be `dtc` i assume (even though the `tc` it's using is presumably not uninitialized)?
jnthnwrthngtn Really doesn't matter, since we are only using it to find the instance 16:46
Maybe for consistency it's nice
But for correctness it's irrelephant.
lizmat nou moe... the problem has disintegrated 16:47
MasterDuke ok 16:48
jnthnwrthngtn Home time, I think 17:08
17:10 Altai-man left 18:02 reportable6 left 18:04 reportable6 joined
nine jnthnwrthngtn: thanks for the inspiration on what to make for dinner :) 18:46
jnthnwrthngtn :D 18:48
18:51 Geth left, Geth joined 18:52 RakuIRCLogger joined
lizmat the new logs server is now live: logs.liz.nl/home.html 19:01
running on Rakudo 2021.09 for now 19:02
jnthnwrthngtn Wow 19:04
There are channels I didn't even know exist :)
Not really important, but there's a slight layout issue with the channel dropdown (the names overflow the background of the dropdown) 19:05
lizmat yeah... I hope someone with more layout knowledge will be able to fix that 19:06
there are more nits like that
but I felt I should bring it out now here on the channel for the people here to have a look at
and potentially find problems 19:07
before announcing it to a broader audience, e.g. in the weekly :-)
jnthnwrthngtn Well, didn't manage to break it in any way so far 19:08
lizmat good :-)
jnthnwrthngtn On 2021.09 for any reason other than "it's good to use releases for production things"?
lizmat well, partly 19:09
jnthnwrthngtn (e.g. no regression I've missed that might be for me to look at?)
lizmat I didn't want to have too many variables at this stage of release to a wider audience
jnthnwrthngtn Ah, makes sense. 19:10
lizmat I'll probably move to master sometime tomorrow
nine lizmat: that max-height: 450px; on .navbar .navbar-channels-dropdown .dropdown-content in main.scss:239 looks fishy 19:12
Apparently the intention is for the menu to get a scroll bar via the overflow-y: auto in main.scss:247, but it probably doesn't due to the position: relative; in dropdown.sass:58. But honestly a scrollbar in a drop down menu doesn't sound like a usability win 19:17
MasterDuke on mobile it might be necessary? 19:18
19:18 sena_kun left
nine On mobile a fixed limit of 450px makes even less sense with the widely ranging display sizes and pixes densities 19:23
19:35 sena_kun joined
lizmat nine: PR's are welcome :-) 19:53
that kind of layout issues are still a bit above my paygrade :-) 19:55
20:06 vrurg joined
MasterDuke codesections: do you have any code you can share to repro github.com/MoarVM/MoarVM/issues/1565 ? 20:28
20:48 RakuIRCLogger left 20:49 RakuIRCLogger joined
japhb lizmat, are you *currently* changing things? Literally every refresh is giving me something different on the logs site. 21:37
lizmat I just restarted the server a few times to fix some obvious mobile issues 21:38
japhb Ah, seems to have settled down now
By the way, for the dropdown list of channels, the list goes beyond the background 21:39
lizmat yeah... I have no idea why, PR's are welcome :-)
japhb All right, first I have to catch up with several days of backlog. :-) 21:40
timo japhb: i just posted my investigation results in #raku for that issue 21:41
lizmat and I just used that and it works for me :-) 21:43
and that concludes my hacking for today, and what a day it was... 21:44
22:15 linkable6 left 22:16 linkable6 joined 22:33 timo left

Powered by Cro and the Raku® Programming Language.

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

Thank you!