github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
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
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
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
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
dogbert2 robertle++ 11:49
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
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
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
jnthn
.oO( I hope it's a curry...please let it be a curry... )
 13:05
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
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

Powered by Cro and the Raku® Programming Language.

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

Thank you!