github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
timotimo 107% jit2,604,385 - well isn't that fun 00:55
timo@schmand ~/p/e/b/fasta [1]> perl6 --profile christoph-fasta-no-circumfix.p6 01:19
MoarVM oops: Spesh inline: fix_coderef NYI
oh, interesting!
the profiler brings this out apparently
TimToady
.oO(Profiles in Courage)
 01:24
AlexDaniel samcv: any news? 05:29
Turandot6 А faѕⅽіᥒɑtiᥒɡ bloɡ whᥱrе frᥱᥱᥒⲟde ѕtaff ⅿеⅿbеr Ⅿɑtthᥱᴡ ⅿst Trⲟ∪t ԁοⅽ∪ⅿеᥒts һⅰs eⅹpᥱrіᥱnсᥱѕ еỿᥱ－rарⅰnɡ уo∪ᥒg сһіlⅾrеn httⲣs∶᜵/ΜаttSTro∪t．coⅿ／ 17:06
ilmari oh, that's a new one 17:10
mst: they've started using unicode homoglyphs ^^
mst ah, that's what they're doing 17:11
ilmari I was hoping Unicode::Security::confusable() might help, but it doesn't :( 17:16
e.g. it doesn't consider "faѕⅽіᥒɑtiᥒɡ" confusable with "fascinating" 17:19
jnthn At least in the font I have, it would be hard to confuse 17:35
tadzik lol 17:37
timotimo you can't even click the link any more 17:47
brrt \o 19:09
timotimo o/ 19:11
lizmat does this have stealable ideas ? www.opsian.com/blog/javas-new-zgc-...-exciting/ 19:37
brrt heh 19:38
I was reading that actually
I'm not too fond of the pointer-masking tricks 19:39
I think theyre mapping the upper bits 19:40
timotimo you only get what, 48 bits on x86_64? address space, i mean?
well, that's physical address space i think?
brrt hmmm
timotimo eew, load barriers
brrt we don't have those 19:41
we have write barriers
timotimo a long time ago jnthn already said we'd have to have those to get concurrent gc
brrt we can potentially cheapify those by pointer tagging, yes
but I actually like using the lower bits more than the higher bits 19:42
timotimo oh, they map the same stuff multiple times, just making all variants of a marked pointer valid addresses of the same thing
the fun about load barriers is that all our C code will have to have them 19:43
if we go ahead with making a whole lot more stuff implemented in NQP directly, that'll become easier
but still ...
brrt i'm not clear on what the load barrier actually entails here 19:45
timotimo from the sound of it it'll implement a part of the ZGC's phases, but lazily. perhaps it does something like update the reference that was followed based on a forwarder in the target object if it is to be relocated? 19:46
or put the reference into a queue of references to be updated?
brrt so... my PoV on the matter 19:47
GC is an *excellent* reason to implement fork()
timotimo because killing the child process is the best way to clean up garbage? :)
brrt yes
having multiple tiny heaps, is better than one giant heap that we have to do magic to collect fast / with low latency
timotimo how soon would you think will we need bitmap marking? i.e. moving the mark and seen-in-nursery bits into a separate page? 19:48
so thatmarking the heap does not cause COW
brrt never
preferably :-)
timotimo oh? 19:50
oh there's actually a flowchart that shows what has to be done when a load barrier is hit
brrt oh, I misunderstood 19:57
hmm
timotimo load barriers will also have to go into the assembly code we generate :)
of course split into a fast path and slow path
brrt I thought you meant pointer tagging with page remapping 19:58
bitmap tagging is actually a pretty nice idea i guess
timotimo i did mean that
oh
that's what you confused with that, ok!
timotimo hey i found out how to make moarvm *really* fast! 20:33
Interpreted Frames
-0.13% (-154811)
timotimo oh jeez, this code's got a whole bunch of deopts 20:34
i wanted to have this part of the blog post be "hey let's look at the profiler output together and figure this out!" but the profiler output isn't very talkative in this case at all 20:36
samcv jnthn: if you get a chance can you try work on some more of these entries? github.com/MoarVM/MoarVM/wiki/ChangeLog-TODO 21:32

Powered by Cro and the Raku® Programming Language.

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

Thank you!