github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
01:06 konvertex left 03:15 lucasb left 04:53 raku-bridge left 04:54 raku-bridge joined, raku-bridge left, raku-bridge joined, raku-bridge1 joined, raku-bridge1 left, raku-bridge1 joined 04:55 Geth_ joined 04:58 raku-bridge left, raku-bridge1 is now known as raku-bridge 05:07 raku-bridge1 joined 05:10 Geth left 05:12 raku-bridge1 left 05:24 Geth joined 05:28 raku-bridge2 joined, raku-bridge2 left, raku-bridge2 joined 05:33 raku-bridge2 left 05:37 raku-bridge3 joined, raku-bridge3 left, raku-bridge3 joined 05:39 raku-bridge3 left 05:40 raku-bridge4 joined, raku-bridge4 left, raku-bridge4 joined
Geth_ MoarVM: 2922f3d1af | (Nicholas Clark)++ | src/6model/containers.c
mutex_container_registry should be held while reading from container_registry.

The mutex is held in MVM_6model_add_container_config - the corresponding read in MVM_6model_get_container_config should also hold it.		 06:40
nwc10 good *, #moarvm 06:41
07:29 zakharyas joined
nwc10 the fixed size allocator is global (enough) that one can allocate from it in one thread, and free that pointer in another? 07:33
07:48 sena_kun joined
nwc10 timotimo: debugserver.c uses HASH_ITER instead of HASH_ITER_FAST. Does that make sense? In that, if you have access to the debug server, do you already "have the keys to the kingdom"? 07:57
ie, there's no point in attempting to keep the random hash secrets secret
can you inject code with the debug server?
MasterDuke why do we use MVM_string_ascii_encode instead of MVM_string_utf8_encode_C_string to create a string for an error message in some places? 08:06
08:09 Altai-man_ joined 08:12 sena_kun left 09:12 leont joined 09:13 konvertex joined
jnthn morning o/ 09:19
MasterDuke: Maybe in the cases where we know it's an ASCII string?
MasterDuke that makes sense 09:21
jnthn nwc10: About the FSA: yes, and it even has mitigation for the case where you have a producer/consumer thing that allocates a lot on one thread and threads a lot on another.
nwc10 jnthn: in copy_to in MVMHash.c there's a MVM_gc_write_barrier(). In copy_to in HashAttrStore.c there is not. Is that omission a bug? 09:25
I'm not sure what the uncitiondional write barrier call is about 09:26
IIRC the write barrier is to maintain the invariant that gen2 objects can't point to nursery objects (without the GC knowing)
and I forget if there's a Fine Manual that I'm supposed to have Read. 09:27
MasterDuke i guess we just declare that REPR names are ascii only?
nwc10 Given how far Unicode is going with combining emojii characters, I think that I'd be fine (ish) with this. 09:28
jnthn MasterDuke: Yes, there's no reason we'd do otherwise 09:29
MasterDuke and the string heap is ascii-only also? 09:31
jnthn nwc10: copy_to is always used as part of a clone operation, so the dest_root would always be in the nursury
MasterDuke: No, the string heap can from bytecode files can contain anything 09:32
nwc10: So the barriering in there is abundance of caution
nwc10 OK. I saw seeming inconsistency and assumed one of them had to be wrong
MasterDuke jnthn: then github.com/MoarVM/MoarVM/blob/mast...on.c#L2164 might not be safe? 09:33
nwc10 jnthn: in the nursery unless a "force gen2" is enabled? 09:34
jnthn nwc10: I guess, yes, though quite when we'd be doing a clone is another matter... 09:35
*doing a clone while in that mode
Anyway, the safe thing is to do it, the fast thing that's probably right (and could be asserted) is to not
nwc10 but the macro version of the write barrier avoids the function call if not needed? 09:36
jnthn MasterDuke: Yeah, if we have, for example, a non-ASCII filename, I think we'd be in trouble there
nwc10: Correct
Well, I think that the function you mentioned is an inline function
Rather than a macro
MVM_ASSIGN_REF is a macro, I think 09:37
So...what was I doing on Monday...
oh right, sigsegv :)
nwc10 jnthn: sadly not. It's in src/gc/wb.c
MasterDuke jnthn: ah, that's a filename? then MVM_string_utf8_c8_encode_C_string is probably the right choice? 09:38
jnthn Which bit?
nwc10 I figure that I should make a patch and send it to you for review
jnthn MasterDuke: yes
nwc10 MVM_gc_write_barrier(tc, &(dest_root->header), &(key->common.header));
and in src/gc/wb.c: void MVM_gc_write_barrier_hit(MVMThreadContext *tc, MVMCollectable *update_root) 09:39
jnthn MVM_STATIC_INLINE void MVM_gc_write_barrier(MVMThreadContext *tc, MVMCollectable *update_root, MVMCollectable *referenced) {
Yes, notice the extra _hit
nwc10 oh, dammit yes
I didn't
thanks
jnthn :)
nwc10 seems that *everyone's* coffee is better than mine
clearly I need to get back to the office, where the coffee is "curated by others"
jnthn And since I was in there: yes, MVM_ASSIGN_REF is a macro. Actually one defined in different ways depending on GC debugging or not
jnthn just had his first coffee since the weekend 09:40
nwc10 (most importantly by Matthias, who is much better at it than me)
10:10 sena_kun joined 10:12 Altai-man_ left
Geth_ MoarVM/new-disp: 23c2c70adc | (Jonathan Worthington)++ | 5 files
Uphold GC inter-gen invariant on inline cache
 10:19
jnthn Hurrah, that does get rid of the SEGVs in `make test` after switching to using the dispatcher instead of a spesh plugin 10:20
And with a code-gen fix gets me down to two make test failures 10:21
grumble, actually those are SEGVs too, but presumably a different one 10:22
Different indeed.
Both 'cus we somehow end up with a NULL inline cache entry 10:23
(When we should instead be getting an unlinked callsite there) 10:24
D'oh, I confused myself 10:44
Forgot to stick in the MVM_SPESH_DISABLE=1 when running it under gdb
Turns out the real issue is a panic about soemthing I need to implement :) 10:45
"Unknown call stack record type in GC marking"...ah, right :) 10:46
10:46 lizmat left 11:02 lizmat joined
jnthn hmm...maybe MVMDispProgramRecordingCapture having both `capture` and `captures` elements wasn't the best bit of naming... 11:09
Hmm...though I wonder if it might accidentally cause a module to leak its EXPORTHOWs 11:22
e.g. if I `use OO::Monitors` in a module M, I get `monitor` available. But if something uses M then it does not get monitor (good since we don't want language tweaks to "escape") 11:24
11:24 zakharyas left
jnthn oops, wrong channel 11:24
nwc10 that happnd at work too. In that case, it was i.imgur.com/i1IwkRL.gifv 11:31
(safe for work)
Geth_ MoarVM/new-disp: cbd0f5ce2d | (Jonathan Worthington)++ | 3 files
Mark dispatch recording callstack frames
 11:32
jnthn oops, lunch 11:33
nwc10 not *too* bad. ilmari can manage much "better" :-) 11:34
Geth_ MoarVM: MasterDuke17++ created pull request #1303:
Use correct encoding for deserializing strings		 11:35
11:53 leont left 12:05 leont joined 12:09 Altai-man_ joined 12:11 sena_kun left
nwc10 jnthn: paste.scsys.co.uk/589638 12:14
I think that that'
master/master/master and I think that it's t/spec/S17-promise/nonblocking-await.t
(was running 4 tests frmo a shell loop) 12:15
about to go AFK on a quest for coffee
Geth_ MoarVM: 7a799da872 | (Daniel Green)++ | src/6model/reprs/MVMStaticFrame.c
Copy lexical_names_list when copying a StaticFrame

Copied frames aren't usually run, but the lexical_names_list should be copied for correctness sake.		 12:17
MoarVM: aeec50e0ab | (Daniel Green)++ | 3 files
Simplify counting of lexical_names

  "lexical_names and lexical_names_list are [...] always created at the same
time, and we can't have duplicate lexical names, and so HASH_CNT() on lexical_names should always be the same as num_lexicals, and would be cheaper written as that." - nwc10, colabti.org/irclogger/irclogger_lo...-06-01#l20
MoarVM: d510fef9fe | nwc10++ (committed using GitHub Web editor) | 3 files
Merge pull request #1301 from MasterDuke17/some_staticframe_fixups
jnthn nwc10: Hmm...that's interesting ASAN output...no immediate guesses how it happens, alas 12:21
12:31 raku-bridge2 joined, raku-bridge2 left, raku-bridge2 joined, MasterDuke left, raku-bridge5 joined, raku-bridge5 left, raku-bridge5 joined, lizmat_ joined 12:32 dogbert11 joined, Kaeipi joined 12:33 nebuchad` joined 12:36 lizmat left, raku-bridge4 left, raku-bridge left, Kaiepi left, nebuchadnezzar left, Geth left, sivoais left, dogbert17 left, krunen left, sivoais joined, sivoais left, sivoais joined 12:37 raku-bridge2 is now known as raku-bridge, krunen joined
Geth_ MoarVM/new-disp: 1bfa3309a5 | (Jonathan Worthington)++ | 5 files
GC marking of dispatch run records
 12:37
jnthn yay, now the only failure in `make test` with the dispatcher in place of the return value type check plugin is about the profiler being busted 12:39
nwc10 There's More Than One Way To Abort It: paste.scsys.co.uk/589640
slightly different point where it explodes
NQP liked your previous commit
or at least, ASAN didn't express an opinion 12:40
jnthn Hm, though same subsystem..hm.
nwc10 yes, sorry, wasn't clear. Everything looked to be the same, apart from the top of the stack that actually hits the error 12:41
12:49 lizmat_ is now known as lizmat 13:09 nebuchad` is now known as nebuchadnezzar 13:17 zakharyas joined
jnthn Hm, seems all roads lead to Rome^Wimplementing the attribute read stuff 13:42
nwc10 is your beer fridge doing better than mine was? 13:43
jnthn Stocks are good. 13:44
nwc10 good. My stocks *were* good (and still are). They just weren't in the right place. (ie some inside)
13:48 MasterDuke joined
jnthn Turns out that after the discussion of whether it should be nqp::dispfoo(...) or nqp::dxfoo(...) or nqp::dispatcherfoo(...) I was too lazy to make any of them happen so now it's nqp::dispatch('boot-syscall', 'dispatcher-foo', ...) :P 13:49
OK, this attribute stuff...
nine lazyness++ 13:50
nwc10 ooh, a new-disp branch for rakudo. I missed that. Until now. 14:06
[Coke] my beer fridge has never been well stocked, but quarantine isn't helping. 14:09
14:10 sena_kun joined 14:12 Altai-man_ left
nwc10 :-( 14:13
I seem to have gone the other way - on the assumption that I'm not really supposed to go shopping that much, I've stocked up (a bit more than usual) when the good offers appear 14:14
I didbn't actually *need* more beer on Tuesday, but by some strange chance the supermarket chain I picked was having a beer offer
So I bought some for Andrea's mum (to take on Saturday, because I keep helping drink her beer) 14:15
and it seems that I've had enough of writing work docs, as I declare it beer o'clock, even though it's a bit early for the london.pm (virtual) meeting
jnthn: No registered operation handler for 'dispatch' 14:16
(ie no ASAN)
jnthn nwc10: Needs new-disp in NQP too
nwc10 er, I thought that I had that
mmm, was I up to date enough 14:17
redo!
anyway, have beer, no ASAN
14:29 MasterDuke left
Kaeipi i'm having trouble getting async dns queries to work without forcing them to be handled synchronously 14:29
uv_getaddrinfo won't do for a number of reasons, so i'm trying to use c-ares atm 14:30
jnthn What doesn't it do, ooc?
If there's a Node.js binding of whatever you're using, that's often a good place to look for clues, 'cus it'll also be dealing in libuv 14:31
nwc10 jnthn: again: 14:35
+++ Compiling blib/Perl6/BOOTSTRAP/v6c.moarvm
No registered operation handler for 'dispatch'
at gen/moar/stage2/QAST.nqp:1501 (/home/ghdev/Sandpit/moar1-SAN/share/nqp/lib/QAST.moarvm:compile_op)
...
jnthn nwc10: That's really odd... In your NQP test output, do you see it run t/moar/53-dispatch.t? 14:36
nwc10 um, not sure if I can find the make test output
but
running it manually, ASAN gets excited
Kaeipi i find the behaviour of getaddrinfo too inconsistent from platform to platform, and with the jvm in particular it'd be simpler to make the A and AAAA queries and make the complete address info like getaddrinfo does in rakudo instead 14:37
nwc10 paste.scsys.co.uk/589649
commit dc2d111dedf29bd335d2be140f324d6fd21138ca 14:38
I believe that that is all correct. I have 5 trees on this machine, so there is potential to mess up
I have 14:40
+#define FSA_SIZE_DEBUG 1
and also
+#define MVM_ARRAY_CONC_DEBUG 1
+#define MVM_SPESH_CHECK_DU 1
+#define MVM_HASH_THROW_ON_ITER_AFTER_ADD_KEY 1
export MVM_SPESH_NODELAY=1 MVM_SPESH_BLOCKING=1 MVM_SPESH_CHECK_DU=1
jnthn Ah, trying to build Rakudo with spesh enabled will go very badly at the moment
nwc10 ah OK. I think you'd implied that, but I'd forgotten this. 14:41
jnthn timotimo++ has been looking at that
That ASAN barf...hmm
Will look at it after getting this attribute thingy done
nwc10 OK, no worries 14:42
I think it has found it thanks to FSA_SIZE_DEBUG
I'm going AFK for a bit
Kaeipi ah, node takes advantage of the fact that c-ares has a few different ways to get the fd used for a dns query, which plays nicely with uv_poll_t 14:54
15:13 raku-bridge5 left 15:22 MasterDuke joined
Geth_ MoarVM/new-disp: c75cc472ff | (Jonathan Worthington)++ | 5 files
Implement dispatcher-track-attr recording logic

So that we make the required entries in the program record data structure. They are not yet compiled into a dispatch program, however.		 15:25
MoarVM/new-disp: d8a7e1e3b8 | (Jonathan Worthington)++ | 2 files
Compile attribute loads in dispatch programs
 15:55
MoarVM/new-disp: efd846e196 | (Jonathan Worthington)++ | src/disp/program.c
Interpret the attribute loading dispatch ops
 15:59
jnthn Will do until we need to guard the attrs... 16:08
16:09 Altai-man_ joined 16:12 sena_kun left
timotimo i've been afk, haven't continued on spesh vs new-disp since last night 16:16
jnthn bah, I will immediately need to do the guarding of atters 16:29
Well, "immediately" as in "I might be a bit tired to do it right now"
timotimo what's missing for that, a bit of recording logic and/or an op or two in the interpreter and/or a bit of execution of disp program stuff and/or some logic for tracking the source of data? 16:36
jnthn Just some new ops for doing guards on temporaries instead of arguments, and the compiling into them, really 16:38
timotimo if i don't get distracted again i may be able to implement a bit of that 16:40
gotta get a rakudo compiled to run update-ops, LOL
but i can just turn spesh off for that i guess, or temporarily switch to master moarvm
jnthn I don't mind doing it; stick to the spesh stuff
(I've got all the bits needed to do it in my head, and you have the spesh stuff in yours, so...) 16:41
nine My quick way out to get a working rakudo for update_ops is just sudo zypper in rakudo :) 16:43
jnthn grrr...also ran directly into "Can only use dispatcher-track-attr on a vivified attribute"
That's a pain. 16:45
timotimo i think i'm kind of stuck with the spesh stuff tbh 16:46
oh let's see what happens when i dump a backtrace so i can see what the stack actually looks like, LOL 16:47
Geth_ MoarVM/new-disp: 64b6fcb1ed | (Jonathan Worthington)++ | 2 files
Implement guarding of tracked attributes also
 17:14
timotimo cannot work now, cat has my hand again 17:36
jnthn Cats seem quite bad for productivity, despite their numerous other benefits.
17:39 zakharyas left
timotimo destressing ought to have a pawsitive overall benefit 17:40
the cat is almost asleep and i laughed just a bit too loudly and she was so surprised 17:44
daww
18:10 sena_kun joined 18:12 Altai-man_ left
timotimo teaches bytecode dumping about vararg ops 18:25
m: say Blob.new(0o342, 0o200, 0o257).decode("utf8") 18:29
camelia  
timotimo m: say Blob.new(0o342, 0o200, 0o257).decode("utf8").&uninames
camelia (NARROW NO-BREAK SPACE)
timotimo something is wrong with my keyboard or something
nwc10 jnthn: and you were pretty much correct - PEBKAC
in that, I had the wrong nqp checkout. (with the "Right" MoarVM checkout) 18:30
timotimo 00144 const_i64_16 loc_5_int, 666 18:39
00145 dispatch_o loc_12_obj, 'wrap-wrap-identity', Callsite_1, loc_5_int
00146 decont loc_12_obj, loc_12_obj
19:00 zakharyas joined
Geth_ MoarVM/new-disp: 9a5cc96603 | (Timo Paulssen)++ | src/core/bytecodedump.c
teach bytecode dump about vararg ops (dispatch_*)
 19:03
MoarVM/new-disp: fa4969be7b | (Timo Paulssen)++ | src/core/bytecodedump.c
don't crash when MVM_dump_bytecode on a code-less thread
jnthn nwc10: Ah, this explains quite a bit 19:14
nwc10 indeed :-/
now (on go two) I have got past the nqp install 19:33
SEGV in^H^H^H 19:34
#0 0x7f3c7f85bc2d in build_cfg src/spesh/graph.c:660
jnthn Hm, did the ASAN barf on that test you mentioned before go away?
nwc10 yes, ASAN barfed on that test now that I used the correct checkout
19:39 squashable6 left 19:40 squashable6 joined 19:44 squashable6 left 19:45 squashable6 joined
timotimo i also get that segv, or at least i think that's the one 20:08
it's where it gets an out-of-range extop number 20:09
not sure what exactly i got wrong :)
20:09 Altai-man_ joined
jnthn timotimo++ for fixing bytecode dumping just in time for me needing it 20:11
20:11 sena_kun left
timotimo nice 20:12
jnthn Got something really odd going on where one dispatcher ends up producing a null return value even though the bytecode it invokes should never do that 20:13
Not immediately sure what's to blame
aha, it ends up getting a NULL arg into it 20:17
Geth_ MoarVM/new-disp: f3e3fe2b9c | (Jonathan Worthington)++ | src/disp/program.c
Correct copying of the args tail

We need to look at the callsite of the initial args, not that of the invokable result.		 20:25
jnthn Duh, that was a silly one
timotimo :D
jnthn And of course my test cases managed to get lucky and not trigger the bug 20:26
20:27 zakharyas left
jnthn And now I seem to have a working decont return value impl using the dispatcher instead of the spesh plugin 20:41
The most common cases don't need to do an invoke (unlike spesh plugins which assumed you were always going to do one)
Though the fact we have got both type check and decont done as two separate dispatchers will have to go away at some point 20:42
(That is the case 'cus there were two spesh plugins, which is the case 'cus there were two ext ops) 20:44
timotimo is that not necessary to do return vs return-rw? 20:45
jnthn Well, those cases need different handling, but we don't need to do it as one dispatch after another 20:49
There's probably a neat factoring in terms of delegated dispatch actually
The way dispatch programs are recorded and compiled automatically does duplicate read and duplicate guard elimination 20:50
Up to and including on paths of reads
So we could even have one dispatcher delegate to the other and even if it duplicately requests guarding or reading of attributes, the compiled dispatch program will still only do it once. 20:51
The whole "you can delegate, but you're still writing one dispatch program overall" thing is one of the ideas that's worked out really well in this. I'm not exactly sure at what point I realized it. 20:53
timotimo cool 20:55
nwc10 jnthn: now SEGV is 21:21
==16736==Hint: address points to the zero page. 21:22
#0 0x7fd486b3f308 in build_cfg src/spesh/graph.c:660
#1 0x7fd486b417a4 in MVM_spesh_graph_create src/spesh/graph.c:1342
Geth_ MoarVM: softmoth++ created pull request #1304:
nativecall: Don't obliterate lib_name in exception text		 21:38
timotimo switch (cur_bb->last_ins->info->opcode) { 21:46
i wonder which one of these breaks
could it be something isn't breaking up bbs correctly around dispatch_* ops? 21:47
22:10 sena_kun joined 22:12 Altai-man_ left 22:36 chansen_ left 22:37 tbrowder left 22:38 chansen_ joined, SmokeMachine joined 22:39 tbrowder joined 23:26 sena_kun 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!