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:03 reportable6 left 00:04 reportable6 joined 02:02 CaCode_ joined 02:05 CaCode left 03:33 reportable6 left, greppable6 left, statisfiable6 left, bloatable6 left, bisectable6 left, committable6 left, nativecallable6 left, notable6 left, sourceable6 left, tellable6 left, quotable6 left, coverable6 left, releasable6 left, unicodable6 left, squashable6 left, benchable6 left, shareable6 left, evalable6 left, linkable6 left, quotable6 joined 03:34 squashable6 joined, greppable6 joined 03:35 statisfiable6 joined, sourceable6 joined, bisectable6 joined, shareable6 joined, releasable6 joined 03:36 bloatable6 joined, coverable6 joined 04:10 frost joined 04:34 notable6 joined 04:36 committable6 joined, reportable6 joined 04:37 CaCode_ left 05:34 nativecallable6 joined 05:35 linkable6 joined 06:02 reportable6 left 06:04 reportable6 joined 06:33 benchable6 joined 06:34 tellable6 joined 06:35 unicodable6 joined
nine jnthnwrthngtn: yes, but we pass it to dispatch_monomorphic as *seen and it gets casted to MVMDispInlineCacheEntryMonomorphicDispatch* which it definitely is not 07:58
08:34 evalable6 joined 08:41 CaCode joined 08:43 CaCode left 08:44 CaCode joined, CaCode is now known as netester, netester left, netester joined
nine jnthnwrthngtn: Ah, now I get it! It's not that pointer that's wrong. We're calling the wrong function. The reason is that the JITed code dereferences ice_ptr twice, once to get the ice and once when looking for the run_dispatch pointer. The irony is that this is totally unnecessary. We have ice in ARG3 already and it's even easier to use that directly. 09:30
09:30 netester is now known as CaCode
nine So hard to find, so trivial to fix :) 09:31
MasterDuke are all the explicit `GET_REG(cur_op, 2).o` required here github.com/MoarVM/MoarVM/blob/mast...5566-L5567 because it's being changed? or could they just be `obj`? 09:44
nine I think they are not necessary. change_type does not seem to allocate via GC 10:25
10:30 linkable6 left, evalable6 left 10:31 evalable6 joined 10:32 linkable6 joined
nine I have the suspicion that the remaining segfault (val.o NULL pointer dereference) is caused by the expression JIT. At least the assembly code looks like it comes from the expr jit and I haven't been able to reproduce it with expr JIT disabled. But of course, since it takes about 10000 runs to reproduce one failure, confidence is still rather low. 11:15
MasterDuke: I thought we got rid of the obj check in if (obj && IS_CONCRETE(obj) && STABLE(obj)->container_spec) { in OP(decont)? 11:18
11:32 linkable6 left, evalable6 left, evalable6 joined 11:34 linkable6 joined 12:03 reportable6 left, reportable6 joined
MasterDuke i think we just discussed how it shouldn't be needed, but i don't see any history of it being removed or re-added or anything like that 13:10
jnthnwrthngtn nine: Ah yes, a single dereference is part of the safety requirement there. As you say, harder to find than to fix... 13:12
MasterDuke discussed in context of 9b94bab9eb2803e19c4616a4b0d163d96e41cd1b and its reversion (9481289950b89dabb553e63d277038518c590b92) and then re-reversion (a75a206afb2faf182af82b564ae9b56cdcb43fb1) 13:13
13:13 linkable6 left
MasterDuke i guess that really should be un-reversion. re-reversion would be if it was reverted, un-reverted, and then reverted again 13:14
nine: re segfault caused by expression jit, that sounds like my suspicion re ctxcallerskipthunks 13:15
Nicholas jnthnwrthngtn: you're not supposed to think about this until tomorrow, but new-disp-nativecall works on ppc64 (ie 64 bit big endian) with both dyncall and libfii. Likewise on arm32 for both. I don't have a great 32 bit big endian host to test on. 13:17
so, runes on "both kinds of OS - big *and* little endian 64 bit debian"
MasterDuke you could apply (part of) gist.github.com/MasterDuke17/82c5a...d4538f4af7 and see if that makes the problem more apparent. it causes reliable insta-fails (not segfaults though, just SORRYs)
Nicholas (not sure if the ppc64le machines are fedora or debian - suspect fedora. Else it would be "Both kinds of OS - BE and LE ppc debian GNU/linux" 13:18
jnthnwrthngtn: this on the assumption that nine shouldn't be reviewing his own branch, and I'm definately not competant to do so)
14:13 evalable6 left 14:55 frost left
Geth MoarVM: 08d41d5e39 | (Jonathan Worthington)++ | src/core/callsite.c
Avoid thread safety issues in intern lookups

The number of callsites and the pointer to the callsites memory may change. We carefully update these with a write barrier when doing the change, however the reading code also needs to take care to do that.
MoarVM: 9846945602 | niner++ (committed using GitHub Web editor) | src/core/callsite.c
Merge pull request #1591 from MoarVM/fix-intern-lookup

Avoid thread safety issues in intern lookups
MoarVM: ea5a86a1ef | (Stefan Seifert)++ | src/memdebug.h
Fix threading issues caused by misalignment in --valgrind builds

When MoarVM is configured with --valgrind, the fixed size allocator pre- and postfixes allocated memory with a number of red zone bytes, so valgrind can detect buffer over- and underruns. The number of red zone bytes was set to 4. This means that allocated memory blocks would start misaligned and the same would be true for pointers in arrays or structs in these blocks. On x86_64 ... (9 more lines)
MoarVM: 4c6755f47b | (Stefan Seifert)++ | src/jit/x64/emit.dasc
Fix race conditions in JIT compiled dispatches

The dispatch system's inline cache entries contain both a function pointer to call and function specific data for use in that call. Cache entries start out pointing to the unlinked_dispatch entry singleton which contains a pointer to the dispatch_initial function. This will run the dispatch program recording phase resulting in a dispatch program. At the end this dispatch program is ... (11 more lines)
nine hopes this explanation is actually corret
Ah, the irony of mis-typing "correct" :)
Geth MoarVM/remove_counterproductive_null_checks: 8aca849f90 | (Stefan Seifert)++ | 3 files
Remove counter productive NULL checks in decont ops

Object registers must never contain NULL values, so there should be no reason to check for NULL values when deconting. Historically bugs in other parts of the code have caused NULL values to appear in registers and these checks have worked around these bugs. But in truth they just hide them and make it more difficult to debug, so better to remove them. This might cost some stability in the short term, but should enable us to fix the underlying bugs for good.
MoarVM: niner++ created pull request #1593:
Remove counter productive NULL checks in decont ops
MoarVM: MasterDuke17++ created pull request #1594:
Jit ctx(outer|caller)(skipthunks)?
16:14 linkable6 joined 16:16 evalable6 joined 17:01 patrickb joined
MasterDuke nine: you might find github.com/MoarVM/MoarVM/pull/1594...96bbc5f684 interesting 17:39
dogbert11 nine: made the following changes locally but they don't seem to help, gist.github.com/dogbert17/7bfbdc82...f62c6d00cf 17:41
nine dogbert11: too bad, but it was worth a shot 17:45
MasterDuke: shouldn't the template for atkey_u look almost exactly the same as atkey_i except for MVM_reg_uint64 instead of MVM_reg_int64? The interpreted versions do 17:51
MasterDuke: looks like 848f74e370edb0c2f8b7f294be37f585da280180 missed atkey_u 17:52
MasterDuke it is exactly the same except that there isn't a macro for the MVM_reg_uint64 constant, but i even made a macro for it just to be sure and same fails
17:52 linkable6 left
nine How do you know atkey_u isn't another victim like the ctx ops? 17:53
MasterDuke could be
18:02 reportable6 left 18:03 reportable6 joined
dogbert11 nine: what about this array, can threading cause havic here? github.com/Raku/nqp/blob/master/sr...ntf.nqp#L2 18:07
havic, sigh, an entirely new concept :) 18:12
19:39 patrickb left 19:43 squashable6 left 19:44 squashable6 joined
nine I don't think so. AFAICT it's only read during sprintf. Gets initialized on startup 20:18
20:52 CaCode left 22:29 evalable6 left, tellable6 left 22:31 evalable6 joined 22:53 linkable6 joined 23:30 tellable6 joined