github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:21 leont left 03:05 releasable6 left, quotable6 left, benchable6 left, coverable6 left, tellable6 left, shareable6 left, bisectable6 left, bloatable6 left, greppable6 left, sourceable6 left, committable6 left, squashable6 left, evalable6 left, nativecallable6 left, reportable6 left, statisfiable6 left, unicodable6 left, notable6 left, linkable6 left 03:06 committable6 joined, unicodable6 joined, reportable6 joined, evalable6 joined, sourceable6 joined, quotable6 joined, squashable6 joined 03:07 coverable6 joined, shareable6 joined, greppable6 joined 03:08 benchable6 joined, tellable6 joined, linkable6 joined, notable6 joined, statisfiable6 joined, bloatable6 joined, bisectable6 joined, releasable6 joined 03:09 nativecallable6 joined 04:41 MasterDuke left 06:24 domidumont joined
nwc10 good (I hope) *, #moarvm 07:03
nine: where did you say that P6Opaque memory layout is figured out these days? It's NQP, not C, but where? 07:04
in that, if I do this:
do this in src/6model/reprs/P6opaque.c
if (repr_data->flattened_stables[i] == NULL) {
+ align_to(&cur_offset, ALIGNOF(void *));
/* Store position. */
which I felt should work, then everything goes wrong (SEGV due to a crazy sc index when reading the stage0 files)
ie, what other thing "knows" about storage layouts, and prevents me from changing then in deserialize_repr_data? 07:05
07:20 domidumont left 08:00 sena_kun joined 08:30 MasterDuke joined
nine nwc10: no, memory layout is still in C. Bytecode writing is in NQP 08:36
nwc10 aha 08:37
About 3 minutes ago I spotted that I need to also add align_to(&cur_offset, ALIGNOF(MVMObject *)); into deserialize_stable_size() to be consistent 08:38
but then everyting just gets wierder
oh no, it's back to the same crazy sc_idx 08:39
MasterDuke so, to make MVMSpeshCandidate an MVMCollectable via adding a REPR. rename the existing MVMSpeshCandidate (github.com/MoarVM/MoarVM/blob/mast...date.h#L2) to MVMSpeshCandidateBody and create a new MVMSpeshCandidate that's just an MVMObject header and the MVMSpeshCandidateBody a la MVMSpeshLog 09:28
(github.com/MoarVM/MoarVM/blob/mast...g.h#L113)?
nine MasterDuke: yes 09:32
MasterDuke ok. then (almost) everywhere that works with MVMSpeshCandidates change to get and use the MVMSpeshCandidateBody instead? 09:36
those things seem relatively straightforward 09:37
what i'm not sure is about when to be using MVM_repr_alloc_init 09:38
nine You use it instead of MVM_malloc(sizeof(MVMSpeshCandidate)) or MVM_calloc(1, sizeof(MVMSpeshCandidate)) 09:42
MasterDuke ok, i'd sort of suspected that, glad i was at least near the right track 09:50
hm. does it need an STable? at first i thought it wouldn't, since it's an implementation detail and not a HLL thing, but MVMSpeshLog has one 09:57
nine MasterDuke: you can look at commit c61236f96e where I turned MVMSpeshPluginState into a collectable 10:05
linkable6 (2019-09-28) github.com/MoarVM/MoarVM/commit/c61236f96e Fix access to freed memory in resolve_using_guards
nine Plus commit bb239a91df14218f9fd1ab8130af410f087e8a16 I guess 10:07
linkable6 (2019-10-24) github.com/MoarVM/MoarVM/commit/bb239a91df Fix MVMSpeshPluginState type defined twice
10:18 leont joined 10:26 harrow left 10:28 camelia left, Geth left, Geth joined 10:29 camelia joined 10:32 harrow joined
MasterDuke nine++ thanks, looks helpful 11:10
11:18 Altai-man joined 11:20 sena_kun left 12:20 lizmat_ joined 12:23 lizmat left 12:30 lizmat_ is now known as lizmat 12:50 raku-bridge2 joined, raku-bridge left, raku-bridge2 left, raku-bridge2 joined 12:51 raku-bridge2 is now known as raku-bridge 14:38 zakharyas joined 15:19 sena_kun joined 15:21 Altai-man left
MasterDuke i assume i MVM_gc_worklist_add anything in the MVMSpeshCandidateBody that is itself an MVMCollectable? 16:28
timotimo well, an MVMCollectable * 16:30
but yeah
you do that in the repr's gc_mark, and optionally you can have an "explain" function that gives names to the pointers for use in a heap snapshot 16:31
MasterDuke and i can do that by looking to see if the MVMFoo struct has `MVMObject common;` as it's first member? 16:32
for `MVMCollectable **spesh_slots;` i would need to mark each element of the array? 16:36
timotimo there's already code that marks spesh slots, that will also want removed 16:41
MasterDuke github.com/MoarVM/MoarVM/blob/mast...pesh.c#L42 ? 16:46
actually, pretty much this whole block will be removed, right? github.com/MoarVM/MoarVM/blob/mast....c#L30-L46 16:47
and the code in the gc_free 16:48
timotimo ah, yeah, that looks about right 16:54
candidates become collectables, so marking everything in these objects is now the job of the new repr 16:55
i'm not sure if the spesh stats and such are still part of the candidate, i would assume so
MasterDuke i wasn't planning to move anything 17:07
timotimo that's fine 17:08
i think the stats are per-staticframe rather than per-candidate
MasterDuke hm. does the whole block get removed? or just changed to call MVM_gc_worklist_add for each candidate? 17:09
i.e., MVM_gc_worklist_add(tc, worklist, &body->spesh_candidates[i])
timotimo there'd still be the array of pointers to spesh candidates, so they would be added
yeah just like that
MasterDuke but then everything related to body->spesh_candidates in gc_free can be removed? 17:11
timotimo i believe so, yeah
MasterDuke am i correct in thinking that only the spesh_slots are MVMCollectable here github.com/MoarVM/MoarVM/blob/mast...andidate.h ? 17:17
timotimo quite possibly, yeah 17:18
MasterDuke doh. i just needed to look at github.com/MoarVM/MoarVM/blob/mast....c#L30-L46 and see what it was marking... 17:21
timotimo oh, haha 17:22
17:55 sena_kun left 18:20 Kaiepi left, Kaiepi joined 18:45 sena_kun joined 19:18 Altai-man joined 19:21 sena_kun left 19:36 Altai-man left
Geth MoarVM/P6opaque-debug: 1161bc4e0f | (Nicholas Clark)++ | src/6model/reprs/P6opaque.c
Add an option MVM_P6OPAQUE_DEBUG to immediately use body.replace.

This stress-tests all the code that handles P6opaque objects.		 19:47
nwc10 If you want some fun, enablign that breaks spesh. 19:48
with spesh diabled all NQP tests pass
but Rakudo setting compilation hits a NULL pointer
I'm trying to figure all of this out
I am assuming that these are all bugs.
but I suspect that I'm going to bed "soon" without any real progress 19:49
19:49 brrt joined
nwc10 your nice simple test case is: ../MoarVM/moar --libpath=src/vm/moar/stage0/ src/vm/moar/stage0/nqp.moarvm -e0 19:50
brrt \o 19:51
nwc10 o/
nine Mmmh 0xFE good value for marking unused memory 19:52
nwc10 it was good enough to SEGV 19:53
AND 19:54
even better
it's good enough to make ASAN very excited on my other branch
without needing to fix the actual bugs in spesh
(again, my test case there is -e0) 19:56
nine In any case an excellent test :)
nwc10 indeed. I don't have to build nqp. It's much faster that way.
nine quite explody indeed 20:03
nwc10 having now found the static function spesh() 20:05
(while looking for somethign elsE)
I'm going to assume that the spesh bug is in there, because it fails to check for body.replaced
but I have not checked this.
I'm more interested in the other bug (related to sparc64 alignment) 20:06
MasterDuke src/6model/reprs/MVMSpeshCandidate.h:39:22: error: field ‘deopt_pea’ has incomplete type 39 | MVMSpeshPEADeopt deopt_pea;
MVMSpeshPEADeopt is declared in src/types.h though... 20:07
nine nwc10: turns out, MoarVM is a bit smarter than we give it credit for. It knows that an object can only have a body.replaced if the type is a mixin type. So to be not as explody, you need to set st->is_mixin_type in P6opaque's initialize 20:19
nwc10 aha. 20:20
I shall test that tomorrow
nine or probably in type_object_for
nwc10 I have my other bug turned into an assertion failure that makes sense
nine since that is where we allocate the STable
Oh, it gets more complicated, since that field is serialized, meaning it's in the stage0 files as well 20:21
So better just override it in the two places in spesh() where it's read 20:23
nwc10 OK, thanks. 20:25
I have found my (actual other) bug
and I have just realised that I really need to go to bed as tomorrow is school, which means the whole house has to get up early 20:26
nine NQP build and make test succeed with MVM_SPESH_BLOCKING 20:28
But rakudo's build explodes with MVM_SPESH_BLOCKING! 20:31
timotimo nwc10: i do believe we rely on p6opaque not being replaced immediately after creation 20:43
in spesh, that is
oh, nine already found it 20:44
20:50 zakharyas left 20:55 brrt 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!