github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:06 Redfoxmoon joined 00:07 p6bannerbot sets mode: +v Redfoxmoon 01:31 ZzZombo left 02:54 ggoebel left 02:55 Redfoxmoon left 03:03 Redfoxmoon joined, p6bannerbot sets mode: +v Redfoxmoon 03:08 ggoebel joined 03:09 p6bannerbot sets mode: +v ggoebel 03:13 lizmat left 04:33 Redfoxmoon left, Redfoxmoon joined, asimov.freenode.net sets mode: +v Redfoxmoon, p6bannerbot sets mode: +v Redfoxmoon 05:25 robertle left 06:20 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo, ZzZombo left 06:21 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo 06:22 robertle joined, p6bannerbot sets mode: +v robertle 06:27 patrickb joined, p6bannerbot sets mode: +v patrickb 06:56 brrt joined 06:57 p6bannerbot sets mode: +v brrt
brrt \o 06:57
nwc10 o/ 07:01
brrt ohai nwc10 07:02
I decided I may want to destroy the per-thread uv_loop_t
since all 'real' async use goes over the eventloop thread these days anyway
the exception being a few directory operations 07:05
the whole current_frame_nr business may be eliminated as well 07:08
hmm. but maybe not today though :-) 07:14
07:18 domidumont joined 07:19 p6bannerbot sets mode: +v domidumont 07:30 zakharyas joined 07:31 p6bannerbot sets mode: +v zakharyas
Geth MoarVM/fork-safety: 5 commits pushed by (Bart Wiegmans)++ 07:33
MoarVM/fork-safety: d1eb3371ff | (Bart Wiegmans)++ | src/io/eventloop.c
[IO] Wake up event loop to notify it of being closed

Otherwise the event loop will hang forever		 07:34
07:47 lizmat joined 07:48 p6bannerbot sets mode: +v lizmat 08:04 zakharyas left 08:05 zakharyas joined 08:06 brrt left, p6bannerbot sets mode: +v zakharyas
timotimo brrt, the blocker for the release is github.com/MoarVM/MoarVM/issues/951 08:12
robertle I am currently bisecting that... 08:13
timotimo cool 08:14
08:34 brrt joined, p6bannerbot sets mode: +v brrt 09:02 zakharyas left, zakharyas joined 09:03 p6bannerbot sets mode: +v zakharyas 09:05 zakharyas left, zakharyas joined 09:06 p6bannerbot sets mode: +v zakharyas 09:32 brrt left 09:55 domidumont left, domidumont joined 09:56 p6bannerbot sets mode: +v domidumont 10:16 ZzZombo left 10:56 lizmat left 11:05 lizmat joined 11:06 p6bannerbot sets mode: +v lizmat
robertle timotimo, brrt: I got a fix on 951, details in the ticket 11:14
AlexDaniel M#951 11:15
synopsebot M#951 [open]: github.com/MoarVM/MoarVM/issues/951 [āš  blocker āš ] Problem running programs on RPi with 2018.08
11:16 zakharyas left 11:23 japhb_ left
timotimo oh, so it *was* a missing pointer alignment thing after all 11:33
the reason why it gets memory corruption rather than a sigbus is that there's code to walk the nursery for objects that have to be freed
robertle oh, and that assumes they are aligned!
of course!
timotimo and if some objects don't get aligned properly, we'll be looking at the wrong data inside an object
AlexDaniel robertle++ 11:34
robertle in that case I think the MVM_ALIGN_SIZE should really be within allocate_nursery, not where we call it. it seems a property of the nursery itself that stuff needs to be aligned
11:44 ZzZombo joined, p6bannerbot sets mode: +v ZzZombo
dogbert2 robertle++ 11:49
11:55 brrt joined 11:56 p6bannerbot sets mode: +v brrt
Geth MoarVM: robertlemmen++ created pull request #961:
Fix alignment of nursery allocations		 11:56
brrt robertle++ that looks very sane 12:03
timotimo isn't it nice to have only one blocker for a change? ;) 12:04
lizmat so why isn't it merged yet ? 12:11
Geth MoarVM: ccf3dd373e | (Robert Lemmen)++ (committed by Bart Wiegmans) | 2 files
Fix alignment of nursery allocations

Recent changes used a path to nursery allocation that are not aligned, leading to segfaults on e.g. armhf. Alignment is really a property of the nursery as it is also encoded in the collector, so doing the alignment within the allocator, not at the call site.
Fixes github.com/MoarVM/MoarVM/issues/951		 12:13
brrt because I'm waiting for the results to come in ;-)
lizmat aha... ok :-) 12:14
brrt bump time, I'd think? 12:27
12:44 zakharyas joined 12:45 p6bannerbot sets mode: +v zakharyas
Geth MoarVM/pea: e9cbb7f1f1 | (Jonathan Worthington)++ | 13 files
Minimal escape analysis and scalar replacement

This only handles the case where:
  * No aliasing
  * No deoptimizing instructions
  * No control flow (conditionals, loops)
... (7 more lines)		 12:55
MoarVM/pea: a13e416e5f | (Carl Masak)++ (committed by Jonathan Worthington) | src/spesh/usages.h
Reset MVM_SPESH_CHECK_DU to 0
MoarVM/pea: dab77573d4 | (Carl Masak)++ (committed by Jonathan Worthington) | src/spesh/manipulate.c
Add missing comment to a new function
jnthn Just a rebase :) 12:57
Geth MoarVM/pea: fc0d9ece23 | (Jonathan Worthington)++ | src/spesh/pea.c
Handle int64, num64, and str attributes in PEA
12:57 robertle left
jnthn That one's new, though :) 12:57
lizmat pea?
jnthn is on his way home, and will be back proper on Monday or so :)
partial escape analysis 12:58
lizmat ah
ok
I guess I expected mea :-)
nine jnthn: JFI, I'm cooking something that I think will interest you: gist.github.com/niner/037905ca666f...b948568b22 12:59
13:04 zakharyas left 13:05 zakharyas joined
jnthn
.oO( I hope it's a curry...please let it be a curry... )
 13:05
13:06 p6bannerbot sets mode: +v zakharyas
jnthn nine: ooh, nice ) 13:06
nine: You saw my gist with the proposed ops for doing this more efficiently too? :) 13:07
nine nope?
jnthn oh.
Moment...I find the gist
nine: gist.github.com/jnthn/1e865a06d213...2908858a57
The first comment I agree with, fiw. The second one is a mixed bag, though mostly relates to the Perl 6 API, and I don't much care about that part right away. 13:09
*fwiw
brrt ohai jnthn :-) 13:10
jnthn Oh, and that last comment totally misunderstood the point that I was specifying a low level API to build the user level ones on. :)
So it's kinda interesting, but I purposefully didn't try to design a high level API because I knew that'd be a bike-shed :) 13:11
o/ brrt
nine jnthn: oh, yes, that sounds helpful. I guess the bytecode writer can also become a good use case for testing such an API. 13:12
jnthn Yes, that was my intention :) 13:15
Prove the ops on a real-world problem first :)
nine Then I have another good reason for continuing this experiment :) 13:16
jnthn nine++ :) 13:18
brrt yeah, i'm still in favor of that design 13:19
nine++ that is pretty cool 13:23
but.
I've been looking into the ELF format, and I can't find a reason why we couldn't fit MBC into ELF 13:24
timotimo what will that offer?
brrt native linking, for one thing
jnthn nine: fwiw, I was also thinking we could switch away from the MAST tree along the way
brrt debugging support, for another
timotimo we could make moarvm files executable to just print out "This program cannot be run in Linux mode." 13:25
brrt better yet, you can associate ELF with an interpreter
timotimo bleeeehhh, nose bleeds *again*?
brrt so you can even make executables
jnthn nine: Getting rid of all of the allocations in the code gen phase 13:26
nine: Or at least, getting rid of loads of them
I suspect that'd make compilation significantly faster
nine jnthn: yes, my understanding is that getting rid of the MAST tree is what could make the NQP bytecode writer useful from a performance (and memory usage) perspective. I'm starting with MAST to get something up and running quickly and will later replace more and more of the MAST compiler by this, piece by piece. 13:27
jnthn nine: Yeah, that's a good strategy.
jnthn is very much in favor
nine the QAST -> MAST step is not quite trivial :) But I guess even just getting rid of representing all ops and their arguments by generated byte code will save a lot of allocations already 13:28
err... "getting rid of reresenting all ops and their arguments by tree nodes and replacing that with generated byte code"
timotimo ... resenting all ops ... 13:29
jnthn nine: Yeah, at the very least labels will need fixups after the fact 13:31
But that's still just keeping a table of fixups and doing it later ;)
timotimo even then, they can be kept around as sets of offsets into the bytecode
yeah
the more we get from C to nqp, the closer we get to being able to implement the trickier GC techniques, like concurrent or incremental 13:34
brrt ... at which point I reiterate my stance that I'd rather not, if all were the same 13:36
timotimo fair enough. we'll see when we get there how much C we still have that'll require us to write code enormously carefully
one day i'd like to look into methods of making nurseries of less-active threads not promote to the old gen as fast 13:47
perhaps it could be as simple as "don't set the 'seen in nursery already' bit unless the nursery in question has been filled up to 25%" 13:49
13:50 brrt left
timotimo also, perhaps auditing the source code for assumptions of "gen2 means never moves" could be a good idea, in case we want compaction of the old gen at some point. which i think would be good to have for very-long-running processes like, say, a cro web app 13:59
jnthn That's very widely assumed :) 14:00
timotimo it is, yeah
so maybe we'll never get compaction in gen2? :S 14:01
jnthn We'd need evidence to know we've got a problem there for real programs bbefore worrying about it, I think 14:03
nine never say never...
jnthn gen2 is organized into fixed-size bins and then falls back to malloc for oversized
For the first to be an issue, we need the app to dramatically change its alocation patterns during its runtime 14:04
A Cro webapp is likely serving the same kind of requests over and over again so should get a good hit rate on the sizes used, so that seems a less likley candidate for problems to me 14:05
timotimo it'll at least do that whenever it enters the compiler, for example if you have a template library that EVALs
but it'll always come back from that, and the number of times it'll do that is probably bounded, unless you do hot template reloading 14:06
14:15 zakharyas left 14:16 zakharyas joined 14:17 p6bannerbot sets mode: +v zakharyas 14:19 ZzZombo_ joined 14:20 p6bannerbot sets mode: +v ZzZombo_ 14:21 ZzZombo left 14:32 MasterDuke left 14:46 ZzZombo_ left, ZzZombo_ joined, card.freenode.net sets mode: +v ZzZombo_, p6bannerbot sets mode: +v ZzZombo_, ZzZombo_ is now known as ZzZombo 14:50 lizmat left 14:56 robertle joined 14:57 p6bannerbot sets mode: +v robertle 15:04 zakharyas left, brrt joined 15:05 zakharyas joined, p6bannerbot sets mode: +v brrt 15:06 p6bannerbot sets mode: +v zakharyas 15:42 dogbert17 left 15:59 patrickb left 16:02 domidumont left 16:05 zakharyas left 16:06 brrt left 16:12 zakharyas joined 16:13 p6bannerbot sets mode: +v zakharyas 16:20 robertle left 16:44 zakharyas left 17:00 robertle joined 17:01 p6bannerbot sets mode: +v robertle 17:18 lizmat joined 17:19 p6bannerbot sets mode: +v lizmat 18:19 zakharyas joined 18:20 p6bannerbot sets mode: +v zakharyas 19:03 zakharyas left 19:37 Kaiepi left 21:13 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 21:17 MasterDuke left 21:46 Kaiepi joined, p6bannerbot sets mode: +v Kaiepi 22:56 MasterDuke joined, p6bannerbot sets mode: +v MasterDuke, MasterDuke left, MasterDuke joined, herbert.freenode.net sets mode: +v MasterDuke, p6bannerbot sets mode: +v MasterDuke 23:39 ZzZombo_ joined 23:40 p6bannerbot sets mode: +v ZzZombo_ 23:41 ZzZombo 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!