github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
Geth MoarVM: ad3a80cb6e | (Zoffix Znet)++ | src/math/bigintops.c
Fix coredump with mul_I -> div_I ops

Fixes R#2280 github.com/rakudo/rakudo/issues/2280
The issue in the ticket stems from -2147483648 being big enough to fit into 32bit int, yet its negation, 2147483648, being 1 bit too big. The assumption in the small-int portion of the div_I op is that if we divide MVMint32 by ... (19 more lines)		 00:09
synopsebot R#2280 [open]: github.com/rakudo/rakudo/issues/2280 [math][regression] Core dump when dividing some Rats with denominator 2**30 by -2
Geth MoarVM: MasterDuke17++ created pull request #970:
Cleanup _I ops		 01:47
brrt \o 07:58
nwc10 o/ 07:59
timotimo \o 08:52
lizmat #moarvm o/ 08:54
brrt ohai timotimo, lizmat, nwc10 08:57
brrt I have a theory wrt to my fork problem. It is called 'MVMROOT' 12:04
... the instance->threads object is moved, but not forwarded 12:17
well, not updated, I should say
yes. instance->threads is not updated 12:20
hmmm
patrickb brrt: Out of curiosity, what can one do with a fork-safe MoarVM? ("Forking!" - Duh. But why should I?) 12:23
diakopter decades ago it was a slick way to "pre-fork" handlers of http requests without having to worry about insecurity or instability (or total lack) of memory-sharing threads 12:38
brrt forking, that's basically it 12:41
patrickb: you can make the case that with async IO, 'real' threads etc. that fork() is no longer necessary 12:42
I don't believe that argument.
fork() is an *excellent* way to add adhoc concurrency / parallelism 12:43
patrickb so the idea is to provide a way to do a real fork() from within perl6 itself?
brrt I find that if you want to use threads, you'd better design that from the outset
yes
fork() is also well suited for things like online replacement of daemons 12:45
I know that nobody does that anymore because docker...
I forgot what the name was for the process, where you replace on daemon with another 12:48
patrickb Makes sense. Thanks for the elaboration! 12:50
brrt :-)
(I mean, I'm fully aware that this is a fools errand... but that's why it's open source, I guess) 12:51
brrt recalls the situation at a $previous-employer where I'd suggest to 'just fork and write to a pipe' and got stares of confusion 12:52
lizmat
.oO( build impossible programs :-)
brrt :-)
nine I still think fork() has a place. It's good for separation of resources and privileges. 13:06
timotimo brrt, do you know about the temp roots being cleared out whenever the code returns to the interp loop? that could give a hint for doing it right perhaps? 14:52
brrt oh, i think i understand 16:07
there's a bunch of nursery-to-gen2 refs between threads 16:10
MVM_thread_cleanup_threads_list breaks that, because it reverses the threads
and we don't do a full collect 16:11
brrt yep, that's very likely to be the issue 16:52
brrt yay, I think I fixed the problem 17:25
Geth MoarVM: 3893a6ce8e | (Jonathan Worthington)++ | 4 files
Perform parameter logging at entry time

Rather than doing it for each of the parameter instructions. This lets us log parameter types even when their target will be a slurpy, meaning we can make a type specialization rather than a certain specialization for calls to things taking slurpy parameters. This helps, among likely quite a few things, calls like `.new(x => 1, y => 2)` for the standard
  `new` constructor: when the `BUILDALL` is small enough, it can now be
inlined into the specialization of `new`.		 17:28
MoarVM: 196fa224a1 | (Jonathan Worthington)++ | src/spesh/optimize.c
Optimize eqaddr into a constant if possible
 17:30
MoarVM: 5103e9f8ae | (Jonathan Worthington)++ | 4 files
Simplify/improve optimization of decont

We don't need to track "is this decontainerized" everywhere; we can just look at the facts about the type to see if it's a container type or not. By doing so, we spot optimize some cases where we forgot to set the "it's decontainerized" flag, so this is not only a cleanup, but also a performance win.
MoarVM: 8501e2e8f1 | (Jonathan Worthington)++ | src/6model/reprs/MVMMultiCache.c
Fix off-by-one in multi cache spesh lookup

Which caused us to miss resolving some multis when named arguments were involved, in turn leading to missed specialization linking and inlining opportunities.
MoarVM: b5eb48c2e0 | (Bart Wiegmans)++ | 3 files
[fork] Fix corruption in threads list

MVM_thread_cleanup_threads_list() would create nursery-to-gen2 references in the threads list, which was very upsetting to GC, which would be heavily exercised by a repeated fork().
Also, child processes might be trying to reinitialize a dead threads uv_loop, which isn't very good.		 17:37
travis-ci MoarVM build passed. Bart Wiegmans '[fork] Fix corruption in threads list 18:06
travis-ci.org/MoarVM/MoarVM/builds/433070342 github.com/MoarVM/MoarVM/compare/8...eb48c2e0bb
lizmat jnthn: looks like we could use another bump ? 18:22
ah, I missed Zoffix already doing that
dogbert11 lizmat: did you see |Tux| latest run above? 18:32
lizmat dogbert11: on #perl6-dev you mean ?
dogbert11 yes 18:33
dogbert11 test-t 1.770 - 1.824 18:33
lizmat dogbert11: yeah, I know, was even texted about it while cycling :-) 18:50
dogbert11 lizmat: and tomorrow it will be even better
lizmat well, not so sure: I didn't see so much improvement in my own test-t benchmarking 18:51
samcv i ran into an issue i have had personally updating moarvm sometimes. essentially i Configure.pl and make install moar, but the binary does not update 18:53
and so when i go to install nqp, it tells me it's out of date. i had to manually delete ~/perl6/bin/moar and ~/perl6/lib/libmoar.so before Rakudo Star would install
japhb samcv: In general, I recommend at least occasionally using one of the "clone and rebuild from scratch" scripts, because sometimes upgrades just stop working right. 19:26
lizmat timotimo: I've got a reliable "P6opaque: no such attribute '@!caps' on type Regex in a NQPRoutine when trying to get a value" 19:27
on doing a profile on -e 'Rakudo::Internals::JSON.from-json("projects3.json".IO.slurp)'
something I should report ? 19:29
timotimo that could be a bug somewhere in some nqp code 21:25

Powered by Cro and the Raku® Programming Language.

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

Thank you!