github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: 1eeae85fa0 | (Timo Paulssen)++ | docs/heapsnapshot.markdown
Document heapsnapshot format version 3.1
 00:01
timotimo jnthn: would be glad to hear what you think, it's possible i've missed something obvious. it's likely i've explained one or two things just imprecisely enough to make implementators confused or frustrated ;)
nine Aaaah...I finally understand why even running the GC on every allocation does not catch all cases of missing MVMROOT. We can literally collect too often that way. This will cause objects to get promoted to the old generation (thus fixed in memory) before they get passed to the buggy code. 08:13
So I guess to get the most out of it, we'd have to prohibit promotion to gen 2 and run with a huge nursery instead. 08:15
Unfortunately with that even a perl6 -e '' takes > 4 minutes to run. That reduces its usefulness somewhat 08:32
nwc10 pubs are open! 08:33
nine But it indeed catches more cases 08:57
jnthn nine: Another approach is to reallocate fromspace each time and mprotect the old one so any access to it blows up 09:03
jnthn Which has a memory cost but probably less of a performance one :) 09:03
nwc10 I should did up my old branches from 4 or 5 years ago which tried various things like this, and see if they can be ressurected
but there are many things that I also should do 09:04
and things like "Tax Return" have actual deadlines
jnthn Ah, right, it was *you* who came up with this. :)
nine jnthn: way ahead of you :) That's exactly what I've already implemented
But I still need it to collect often 09:05
nwc10 I think one had something like 256 nurseries, cycled round them, and all were marked unreadable except for the current one (and the "two" during GC)
jnthn Cool. Though nwc10 was ahead of us both by years :D
nwc10 yes and no
I just *found* problems. You fixed them
nine is
nine++ # finds *and* fixes problems.
nine There's e.g. an MVMROOT(tc, handler) missing here: github.com/MoarVM/MoarVM/blob/mast...lize.c#L37 09:06
If only test runs didn't take ages :) 09:07
Anyway, have to go to the office, so I'll just keep it running while I'm away
nwc10 I think that he must be in a different time zone from me. I'm thinking about going *from* the office. 09:08
:-)
nine Nah, there's just this one meeting where I have to be there in person
Guest15407 nine: I have a juicy SEGV for you should you be interested 11:14
Geth MoarVM: 539f1d0314 | (Stefan Seifert)++ | src/gc/finalize.c
Fix possible access to fromspace in finalize_handler_caller

An untimely GC run may move *handler before we access it to find the invokee. Fix by MVMROOTing handler.		 12:17
MoarVM: 241be06be0 | (Stefan Seifert)++ | src/io/dirops.c
Fix possible access to fromspace in MVM_dir_open

Allocating the result may trigger a GC run which could move dirname which we access later on. Fix by MVMROOTing dirname.
Guest15407 nine: I believe there's a bug lurking here: github.com/MoarVM/MoarVM/blob/mast...ops.c#L496 12:32
timotimo i just glanced over the v8 compressed pointers doc 13:10
and one thing that caught my eye is the small integer stuff
i wonder how big the impact would be to teach REPR and STABLE about the lowest bit of a pointer to return P6int and BOOTInt respectively, and making the P6int REPR understand pointers that, rather than point at something, have a value inside themselves 13:11
hmm. 13:12
more likely that we'd want to implement this for p6bigint rather than p6int 13:13
since p6int is mostly embedded in other objects anyway and as such doesn't have the overhead of object headers and such in the first place 13:14
hum. our NFAs and such have arrays that are object-typed but often contain integers. small ones at that. 13:15
maybe there's an opportunity there
actually the heap snapshot of core setting compilation that i took has boatloads of BOOTInt collectables in it 13:20
lizmat www.reddit.com/r/perl6/comments/d3...ated_with/ 13:26
discord6 <RaycatWhoDat> The more I work with grammars, the more I realize Perl 6 is akin to Racket in regards to building DSLs. 13:58
Geth MoarVM/expr-jit-devirtualize: 4e982f0932 | (Bart Wiegmans)++ | 2 files
[JIT] Deoptimization in the expression JIT

Now that sp_guard* ops are non-special (because they use the deopt index directly) it's relatively straightforward to implement them as expression template. So we did.
It turns out that the deoptimization code doesn't unwind the JIT stack, so we need an explicit jump-to-exit, which is fine. We can optimize this stuff by further by taking it out of the mainline code, but that's interesting for another day.		 15:21
MoarVM/expr-jit-deopt: 5 commits pushed by (Bart Wiegmans)++ 15:26
jnthn brrt++ 15:28
Geth MoarVM: bdw++ created pull request #1176:
Deoptimization in the expression JIT compiler		 16:19
brrt \o 16:20
nine After 4 hours my make test is starting to progress into t/02-rakudo
japhb nine: Is this the run with no gen 2 and huge nursery? 16:24
nine hes
yes
dogbert17 clickbaits nine with gist.github.com/dogbert17/bd5a41e0...d8a1536915 16:27
MasterDuke nine: that's a very dramatic slowdown. is it really to be expected? would optimization of those conditions help regular runtime? 17:35
nine MasterDuke: this is turning every allocation into a garbage collection. And every GC into a full GC with practically every object getting copied and all pointers updated. 18:28
dogbert17: I'm too tired to figure this out but may have a look tomorrow 18:29
MasterDuke ah, didn't realize it was quite that extensive of a change

Powered by Cro and the Raku® Programming Language.

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

Thank you!