github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:03 Hobby12 left 01:17 UncleSamuel joined 01:21 UncleSamuel left
timotimo stumbled upon an sp_guard followed later by an sp_guardconc (that the enhanced guard opt turned into a sp_guardjustconc) on ... the result of sp_fastcreate 01:31
that should really not need any guards at all i think
maybe i can find out what's wrong
could be time to freshen up the spesh trace script for the new function names and such 01:35
MasterDuke would i ever want something other than 1 in the MVM_dump_bytecode_stackframe(tc, 1) call? 01:38
timotimo to see what your stuff is called from further and further up the stack i guess
02:01 lizmat left
timotimo spesh dumping violently explodes when trying to dump one annotation's filename 02:06
it's going about 8k past the number of strings that actually exist in the cu
fortunately, i can "just" put a range check in here
timotimo just implemented comments for the spesh log 02:09
i.e. you can put a comment onto an instruction and it'll be printed into the speshlog
wants to become a utility function, of course 02:10
Geth MoarVM/spesh_comments: 4 commits pushed by (Timo Paulssen)++ 02:26
timotimo this branch also contains an optimization, but i wanted the comments for debugging why some guards stick around
Geth MoarVM/spesh_comments: b7c4e21da4 | (Timo Paulssen)++ | src/spesh/graph.c
don't even need to allocate when spesh log is off
 02:36
timotimo i'll want functions that dump an instruction including facts for its registers next 02:39
bedtime first 02:40
no sleep to be had just yet :\ 04:10
04:23 strugee joined 04:26 strugee left
timotimo the issue was just that P6opaque's spesh function should set the facts after turning create into fastcreate 04:40
the 'Loop' method of src/Rakudo/Iterator goes from 414 bytes to 342 bytes with that simple addition 04:41
in infix:«=>» we were missing lowering bindattr for $!key and $!value because the facts from sp_fastcreate were being added too late 04:54
364 (176 from inlines) went down to 254 (80 from inlines) for that infix 04:55
it might be a good idea to backport this to master, actually 05:07
it's a benign change
though i haven't checked if master suffers from the problem this commit tries to solve, since some ordering was changed
so perhaps it was the postrelease-opts branch that introduced this regression in the first place
05:13 Ritche27 joined 05:16 Ritche27 left 05:20 justif29 joined 05:22 justif29 left
Geth MoarVM/postrelease-opts: 71020ce698 | (Timo Paulssen)++ | 3 files
set type and concrete facts for fastcreate

do it immediately in the spesh function of the reprs VMArray, MVMHash, and P6opaque. This throws out a bunch of guards that were being left in the code in a test i did.		 05:33
MoarVM/postrelease-opts: 8c872360e3 | (Timo Paulssen)++ | 3 files
add type/concrete to box_* spesh, too

also, no need to get_and_use_facts when we're changing the operation that writes that register.
timotimo the guard opt is somehow not getting invoked on a bunch of guards in the .tc.flip example 05:37
i added the sp_guard* ops to the second_pass and that changed things. we might have to think about whether the second pass is a better place for the opt in general 05:39
i mean post_inline_pass 05:40
maybe i'll retry the sleep thing 05:41
05:47 Geeky_Bear joined 05:52 Gentle joined 05:54 EvilRoey15 joined 05:55 Geeky_Bear left 05:57 EvilRoey15 left, Gentle left 06:12 bungle2 joined 06:16 bungle2 left 06:28 brrt joined 06:29 p6bannerbot sets mode: +v brrt
Geth MoarVM/fork-safety: 9f342dd8ce | (Bart Wiegmans)++ | 6 files
[Spesh] Tear down spesh worker in full_cleanup

For the purposes of
  - clean teardown in full_cleanup mode
  - testing for memory leaks with ASAN		 06:44
MoarVM/fork-safety: dd9eda8ee6 | (Bart Wiegmans)++ | 3 files
[ConcBlockingQueue] Unmoving body

The locks structure was already malloc'd, and I extended this to include the entire body. This prevents the GC from moving the body while we are blocked on acquiring a lock, simplifying the code, and has negligible cost.
06:45 lizmat joined 06:46 p6bannerbot sets mode: +v lizmat 06:59 zakharyas joined 07:00 p6bannerbot sets mode: +v zakharyas 07:16 benchable6 joined, p6bannerbot sets mode: +v benchable6
Geth MoarVM/fork-safety: 417509598d | (Bart Wiegmans)++ | 5 files
[Spesh] Tear down spesh worker in full_cleanup

If the spesh worker is still active the GC can try to free a lock that is being held, which leads to an abort in libuv. Stopping the thread makes full-cleanup work (although it still leaks).
Thread is stopped by signalling with VMNull. Ideally we'd unshift this to the front of the queue, but that is more complicated.		 07:16
MoarVM/fork-safety: b7c500963f | (Bart Wiegmans)++ | 3 files
[ConcBlockingQueue] Unmoving body

The locks structure was already malloc'd, and I extended this to include the entire body. This prevents the GC from moving the body while we are blocked on acquiring a lock, simplifying the code, and has negligible cost.
07:20 lizmat left 07:52 ^MillerBoss joined, ^MillerBoss left 08:11 ilmari_ left, AlexDaniel` left 08:12 brrt left 08:13 committable6 left, bisectable6 left 08:14 krysjonaz joined, shareable6 left, greppable6 left, statisfiable6 left, nativecallable6 left 08:20 krysjonaz left 08:21 AlexDaniel` joined, p6bannerbot sets mode: +v AlexDaniel` 08:40 bairdmich joined 08:41 brrt joined 08:42 p6bannerbot sets mode: +v brrt 08:45 bairdmich left 08:48 ilmari_ joined, wictory[m] joined, p6bannerbot sets mode: +v ilmari_, p6bannerbot sets mode: +v wictory[m] 09:05 lizmat joined 09:06 p6bannerbot sets mode: +v lizmat 09:11 nativecallable6 joined, bisectable6 joined, committable6 joined, statisfiable6 joined 09:12 p6bannerbot sets mode: +v nativecallable6, p6bannerbot sets mode: +v bisectable6, p6bannerbot sets mode: +v committable6, p6bannerbot sets mode: +v statisfiable6 09:23 lizmat left 09:27 Carlos061112 joined
jnthn timotimo: No, I don't think the second pass is better for the guard elimination opts, since we'd then miss the deopt retention removal with them 09:32
09:32 Carlos061112 left 09:42 robertle joined 09:43 p6bannerbot sets mode: +v robertle 09:54 brrt left 09:55 bmos18 joined 09:56 bmos18 left 10:00 cyberzeus16 joined 10:01 p6bannerbot sets mode: +v cyberzeus16 10:05 cyberzeus16 left
Geth MoarVM/postrelease-opts: 41132cc4f4 | (Jonathan Worthington)++ | 3 files
Box lowering for P6[int|num|str]

This is aimed at helping NQP code rather than Perl 6 code, but does the same trick that we've done for the Perl 6 ones. Alas, the int one loses the use of the int box cache, so needs a bit more work yet.		 10:33
jnthn Hmm...tricky to decide how exactly to re-integrate the int box cache here
I guess having these picked apart is kinda nice for EA 10:34
Though maybe we could have a spesh op that is a box cache lookup + a fastcreate + a bind 10:35
And have the EA understand enough to pick it apart
10:44 sysdef joined, sysdef is now known as Guest16236 10:48 lizmat joined 10:49 p6bannerbot sets mode: +v lizmat 10:50 lizmat left 10:52 lizmat joined, lizmat left 10:53 Guest16236 left 11:02 brrt joined 11:03 p6bannerbot sets mode: +v brrt 11:17 brrt left, brrt joined 11:18 p6bannerbot sets mode: +v brrt 11:19 lizmat joined 11:20 p6bannerbot sets mode: +v lizmat 11:22 brrt left 11:24 lizmat left 11:26 zakharyas left 11:38 robertle left 11:44 timeless29 joined 11:47 timeless29 left 12:52 lizmat joined 12:53 p6bannerbot sets mode: +v lizmat 12:59 zakharyas joined 13:00 p6bannerbot sets mode: +v zakharyas 13:01 zakharyas1 joined 13:02 p6bannerbot sets mode: +v zakharyas1 13:04 zakharyas left 13:05 zakharyas joined 13:06 p6bannerbot sets mode: +v zakharyas 13:08 zakharyas1 left 13:24 darkmagic joined 13:25 darkmagic left 13:32 brrt joined, p6bannerbot sets mode: +v brrt
brrt \o 13:37
timotimo o/ 13:38
brrt ohai timotimo 13:44
do you have an opinion on the choice between a): a release branch on which we port only fixes and continue to work on master, or b): a development branch from which we update master every so often? 13:45
postrelease-opts is a kind of de facto development branch, but I'd like to keep the advantage of branches-as-change-isolation 13:46
point is, i'm kind of annoyed at the 'pause' introduced by the release proces 13:47
*process
timotimo i'm not quite sure about it 13:48
i assume the percentage of users who build MOAR_REVISION is pretty high, right? 13:49
so it's not quite as important which of the two we'd do 13:50
brrt hmm.. right. 13:53
btw, the debug server is another system thread that needs to be stopped for fork safety 14:01
timotimo: ooc, why didn't you use libuv?
timotimo i'm not used to using libuv :S
would i actually have a benefit from it?
since i only accept a single connection anyway, i'm not sure how much win there'd be
brrt it's kind of simpler 14:02
I think....
also because it kind of abstracts over the distinction between windows and linux
or other unixes
also, and more important for my selfish purposes; I can *stop* a libuv thread
timotimo ah 14:03
so i'd have to have a select and maybe a condition variable otherwise?
brrt i'm not sure how to do that if the debugserver thread is blocked on the accept()
yeah, if you did select(), that'd probably work?
timotimo what happens if you just close the socket from another thread while the debugserver thread is accepting or receiving? 14:04
brrt i don't know
timotimo it might give a helpful errno value that i can just interpret as "well, fine, i'll stop"
brrt stackoverflow says it might not 14:10
hmm 14:16
I might just not support fork() until we can interrupt debugserver somehow
maybe select() would work. but that's not going to work on linux 14:21
eh, windows, i think
brrt has half a mind to rewrite the networking stuff to use libuv 14:22
in fact, MoarVM provides a ready made uv_loop for every threadcontext 14:36
that's funny
and if i'm honest, maybe not what we want...
jnthn We decreasingly need that, tbh 14:37
Most sync I/O is no longer done using libuv 14:38
It'd be interesting to see what does need the per-thread loop
And potentially just start it "on demand"
Might save us a bit of startup effort
brrt yeah, that would need some analysis :-) 14:39
14:47 lizmat left 14:56 lizmat joined 14:57 p6bannerbot sets mode: +v lizmat 15:03 zakharyas left 15:04 zakharyas joined 15:05 zakharyas left 15:06 zakharyas joined 15:07 p6bannerbot sets mode: +v zakharyas
Geth MoarVM/fork-safety: d409b909e8 | (Bart Wiegmans)++ | 3 files
[IO] Stop event loop thread

Stop loop with uv_stop(uv_loop) and join the thread		 15:24
timotimo jnthn: did you see spesh_comments? :) 15:29
jnthn Yeah, I've wondered about that, in part for explaining what happens :) 15:30
timotimo i'm not sure how to parse that 15:31
15:32 robertle joined
jnthn I'd wondered about such a feature in the past 15:32
timotimo ah!
jnthn In part because I thought it could be interesting to provide information about what kinds of optimizations were performed
timotimo yes, i think i've been part of a little bit of discussion on that
15:33 p6bannerbot sets mode: +v robertle
jnthn Maybe we can even collect such things when profiling 15:33
timotimo currently the profiler doesn't separate call graph nodes into individual spesh candidates 15:35
jnthn Yeah, true 15:36
It's not clear the average profiler wants this either
timotimo so comments from speshing would possibly be muddled together there, and there now isn't even really a simple correspondence to what call graph node was "responsible"
aye
might be more advantageous to eventually add a spesh viewer to the profiler frontend 15:38
jnthn I did ponder a little bit making it possible to pull them out via the debug server interface, so you can do a run of a program (or even interrogate a long-running program) about its specializations 15:39
timotimo yeah, i'd kind of like that, too 15:40
i wanted to build a messagepack output format for the spesh graph including facts anyway
jnthn Then finding a way in Comma to intersperse source with spesh output and maybe JIT output disassembly :P
timotimo so it would not only be an output mode for MVM_SPESH_LOG, but also immediately useful for the debug server as well 15:41
jnthn ooh, yes
15:44 avar left 15:45 avar joined, avar left, avar joined, p6bannerbot sets mode: +v avar 15:46 p6bannerbot sets mode: +v avar
timotimo do we want to keep spesh graphs around after they've been jitted so that the debugserver can query them, or should the debugserver stream out whatever got speshed, or should you be able to ask it to re-generate the spesh for you on demand? 15:47
jnthn Stream 'em, I think
Provided they were asked for, of course
And maybe we'll want to be able to ask them with certain things included/excluded
15:48 lizmat left
jnthn Like "I don't care about all the compiler guts" :) 15:48
timotimo oh, you know, just get at EVAL via nqp::getcomp, and compile a regular expression :)
anyway, the next step for the comment branch is a quick function that dumps an instruction just like the spesh log dumper itself would, including a bitfield that lets you select what operands to dump facts for, which for example could also output the contents of a spesh slot 15:54
i'll be factoring out a bunch of that code for this purpose
jnthn | mov dword OBJECT:RV->header.owner, TMP1d; // does this even work? 16:02
...gee, I hope so, it's been there some years by now :P
timotimo is this fastcreate?
16:04 zakharyas left
jnthn yes :) 16:05
timotimo oh, i thought you put that comment there for the irc message; but it's actually in the code :D
jnthn yeah :) 16:06
timotimo if i'm already adding a datastructure that holds information about types - the managed size, in particular - i might as well add more info. any ideas what'd be potentially interesting? 16:13
anything from the repr_data would be fair game, i think
jnthn wonders what the correct way to write | mov TMP2, TMP2[TMP1] 16:26
is
brrt: Any hints? :) 16:27
gist.github.com/jnthn/ad791530757f...eeb9aa2058 is the context, fwiw
timotimo perhaps [TMP2 + TMP1]? 16:30
jnthn Well it compiles 16:31
But I'm getting TMP1 needs to be scaled?
timotimo could be, yeah 16:32
16:32 thisisbilly2 joined
timotimo not quite good at the assembly either 16:32
me, that is
jnthn given the crashes everywhere, I figure "yes" :)
timotimo oh, i can take the "type" key out of every allocation node and put it into the type infos list instead 16:36
jnthn gist updated with compiling but busted code :)
timotimo that'll save one hash entry for every allocation data piece; except i'm not sure it even makes a difference in actual memory allocations
16:37 thisisbilly2 left
timotimo since hashes are already always bigger than their contents 16:37
i wonder if perhaps you have to deref TMP2 before calculating the offset?
timotimo tries to figure that out 16:38
jnthn oh, maybe
timotimo perhaps that can just go in the line above, mov TMP2, [qword cache] 16:39
jnthn no :)
timotimo OK %)
jnthn [qword cache] ain't valid; [cache] compiles but still behaves terribly :) 16:40
oh, I did a think elsewhere and broke the usual case... 16:42
Think I got it working 16:45
timotimo \o/
i don't quite see how fastbox does any boxing if the cache isn't used 16:46
so it probably just doesn't do it yet?
jnthn It's the fastcreate and bind just below 16:49
170s ain't a bad spectest time, especially when I'm sure I was seeing 190+ at the start of the week... 16:54
timotimo we're getting somewhere, eh? 16:56
jnthn Maybe it was last week
Still :)
Geth MoarVM/postrelease-opts: cd0020e7ab | (Jonathan Worthington)++ | 11 files
Re-instate use of int cache in fast boxing

For JIT, we now emit assembly that does the comparisons and then does a fetch from the integer cache if applicable. Thus the only real call is to obtain memory from the GC if we need to box, the value then being poked into the object at the appropriate location.
Also stub in as-yet unimplemented and unused spesh ops that we'll use for optimizing boxing to a P6bigint embedded in a P6opaque.		 16:58
jnthn I suspect that sequence could be a tad shorter by using a callee save register
And so only loading the value ones in the good case 16:59
17:09 brrt left 17:11 mobijubo7 joined 17:17 mobijubo7 left
mst what. the fuck. 17:27
yoleaux 13 Aug 2018 15:36Z <Zoffix> mst: FYI: I set the channels to +z and made p6bannerbot watch the traffic. It waits 45 seconds to +v a new user, but if that user sent any messages 20s before the end of those 45s, the bot doesn't voice.
timotimo what's wrong, mst?
mst timotimo: that (invisible to you) spam blast was really bizarre 17:28
timotimo oh, OK
mst .note Zoffix seems to be working pretty nicely
Geth MoarVM/postrelease-opts: 8fac6c3dd7 | (Jonathan Worthington)++ | 6 files
First attempt at a fast box for big integers

Almost works, but the range check for whether to store it as a small int always comes out false, so it always takes the bigint path.		 17:47
jnthn I gotta go cook, but if any kind soul fancies fixing my wrong assembly... :P
& 17:48
17:49 alphor22 joined
timotimo i wonder if you just gotta use cmpq there 17:53
17:53 alphor22 left
timotimo or if that's automatically selected for you 17:53
nope, "unknown statement cmpq" 17:55
welp, there goes my idea
18:18 cloe5 joined 18:22 cloe5 left 18:53 norkle15 joined 18:56 norkle15 left 19:09 xous13 joined 19:12 xous13 left 19:26 Aprexer joined 19:27 lizmat joined 19:28 p6bannerbot sets mode: +v lizmat 19:30 Aprexer left 19:37 KellerFuchs29 joined 19:38 KellerFuchs29 left 20:00 dogbert17 joined 20:01 p6bannerbot sets mode: +v dogbert17
dogbert17 hmm, the postrelease-opts branch is a bit borked atm it seems (unless I'm doing something wrong ofc) 20:03
MasterDuke timotimo: i want to break on a function in gdb while building rakudo, but it's going to hit tons of times before i'm really interested in it. could i use the debugserver to set a breakpoint in the rakudo build so that when that hits i then go and set the gdb one? 20:13
jnthn dogbert17: I didn't spectest the latest patch, and it's certainly doing *something* wrong in the JITted output 20:17
dogbert17: A step back from HEAD seemed pretty OK 20:18
timotimo MasterDuke: yes, i think that would work 20:42
20:47 lizmat left
MasterDuke hm, good to know in the future (i approximated it by sticking a little used nqp op before the line i was interested in and breaking on its function) 20:55
timotimo i do that all the time :) :) 20:57
Geth MoarVM/postrelease-opts: d699863c52 | (Jonathan Worthington)++ | src/jit/x64/emit.dasc
Correct somehow typo'd integer constant
 20:58
jnthn Duh. And it works after that :P
MasterDuke timotimo: what's that sequence of gdb command to run something every time you break, but then continue? 21:01
21:02 lizmat joined, p6bannerbot sets mode: +v lizmat
dogbert17 jnthn: I still have plenty of spectest fails 21:04
dogbert17 I must be doing something wrong, getting a SEGV in t/spec/S17-promise/start.t 21:08
crashes at github.com/MoarVM/MoarVM/blob/mast...ugin.c#L76 21:16
jnthn dogbert17: I meant works as in "gets the expected speedup" :) 21:25
21:26 celyr23 joined
jnthn I left spectest to run while I went for a walk and indeed it's got some failures 21:26
21:26 celyr23 left
dogbert17 jnthn: ah, I thought you meant spectest clean :) 21:27
jnthn No, no :) 21:29
I coded this up just before I left the office and pushed it so I could continue playing back home 21:30
It blows up without JIT so it's not inept assembly programming this time 21:34
And the spesh guard blowup is actually 'cus there's a null pointer somewhere that there's not meant to be one
(e.g. the input to that code, which would be from an argument) 21:35
So that's also probably one step back from the symptom too
Inept C programming this time :P 21:36
The JIT was right, the interpreter was wrong :)
Which goes to show how much we manage to JIT 21:37
Geth MoarVM/postrelease-opts: 5ef7fc60b8 | (Jonathan Worthington)++ | src/core/interp.c
Fix missing result register writes
MoarVM/postrelease-opts: 3b3b9948f4 | (Jonathan Worthington)++ | src/core/interp.c
Correct op names in error messages

Spotted by MasterDuke++.		 21:39
timotimo MasterDuke: you'd set the breakpoint, then "commands" or "commands <number of breakpoint>", then you can type "call something()" "c" "end" 21:44
21:48 stmuk_ joined 21:49 p6bannerbot sets mode: +v stmuk_ 21:50 stmuk left
jnthn Yeah, that's much better 21:50
dogbert17 jnthn: indeed, only one fail left 21:52
jnthn t/spec/S32-exceptions/misc.rakudo.moar ?
dogbert17 which seems to be GC related so perhaps it's old
t/spec/S12-methods/default-trait.t 21:53
21:53 sparr24 joined
dogbert17 Program received signal SIGSEGV, Segmentation fault. 21:53
0xb7b639e2 in MVM_gc_mark_collectable (tc=tc@entry=0x804c628, worklist=worklist@entry=0xa5148a0, new_addr=new_addr@entry=0xa674088) at src/gc/collect.c:370
370 MVM_gc_worklist_add(tc, worklist, &(tc->instance->all_scs[sc_idx]->sc)); 21:54
Y
21:55 sparr24 left 21:56 clonak9 joined 22:03 clonak9 left
Geth MoarVM: 7277670061 | (Samantha McVey)++ | tools/release.sh
Make release.sh more clear as to which we want written to MANIFEST

Also restricts the scope of what is output to MANIFEST to a specific section of code and not the entire script.
Indent the for/do loop as well.		 22:28
timotimo oh hey samcv 22:32
22:32 Guest3399 joined
timotimo i saw your talk, though really only parts of it because the beginning - felt like more than half - was cut off before the stream started or something :< 22:33
samcv oh hi
yeah
technical issues sadly. mine was the first talk of the day
timotimo :<
22:34 Guest3399 left
samcv i will upload my slides though 22:35
timotimo the part of it that i saw was good 22:36
samcv timotimo: cry.nu/TPC-EU-2018/#/ 22:47
22:48 travis-ci joined, p6bannerbot sets mode: +v travis-ci
travis-ci MoarVM build failed. Samantha McVey 'Make release.sh more clear as to which we want written to MANIFEST 22:48
travis-ci.org/MoarVM/MoarVM/builds/417031753 github.com/MoarVM/MoarVM/compare/8...77670061a1
22:48 travis-ci left
samcv not me! 22:50
Geth MoarVM/postrelease-opts: 8fc798aeb6 | (Jonathan Worthington)++ | 2 files
Start work towards lowering unbox operations

Sometimes a decont really is an unbox in disguise, so handle those too. So far, implemented it for P6opaque box around a native num and native str.		 23:47
MoarVM/postrelease-opts: a6b3e0a7a5 | (Jonathan Worthington)++ | src/spesh/optimize.c
Do basic block merging as the last step

Nothing else depends on it, and there's a potential risk of it not leaving the dominance tree in good shape.
jnthn 'night o/ 23:53

Powered by Cro and the Raku® Programming Language.

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

Thank you!