Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-05-04

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:15 vendethiel joined #moarvm
00:52 vendethiel joined #moarvm
00:56 timotimo hrm. now there'll be a bit of clutter ... until now there wasn't any
00:57 timotimo when adding pages, we always do a realloc for the pages of a bin
00:57 timotimo oh, actually
00:57 timotimo i may not want to make every page its own VALGRIND_MEMPOOL
00:57 timotimo yeah, that'll make things way easier
00:59 timotimo ==5796==  Address 0x5a3aa80 is 24 bytes inside a block of size 32 client-defined
00:59 timotimo ==5796==    at 0x4D7B5DD: MVM_gc_allocate_nursery (allocation.c:39)
00:59 timotimo sometimes the nursery parts work already <3
04:12 TimToady joined #moarvm
04:17 TimToady joined #moarvm
04:36 vendethiel joined #moarvm
06:15 vendethiel joined #moarvm
07:12 vendethiel joined #moarvm
07:14 TimToady joined #moarvm
07:42 rurban joined #moarvm
07:51 rurban joined #moarvm
07:59 Ven joined #moarvm
08:04 brrt joined #moarvm
08:16 Ven_ joined #moarvm
08:49 vendethiel joined #moarvm
09:02 brrt \o
09:09 lizmat brrt: /o
09:09 brrt :-)
09:21 vendethiel joined #moarvm
09:54 TimToady joined #moarvm
10:30 Ven_ joined #moarvm
10:46 TimToady joined #moarvm
10:51 vendethiel joined #moarvm
11:18 TimToady joined #moarvm
11:42 rurban joined #moarvm
12:21 brrt joined #moarvm
12:27 dalek MoarVM: 54f270c | jnthn++ | src/strings/ops.c:
12:27 dalek MoarVM: Re-implement simple say/print using MoarVM I/O.
12:27 dalek MoarVM:
12:27 dalek MoarVM: This reduces code duplication, and further means that nqp::say will
12:27 dalek MoarVM: certainly output the text and newline as a single operation.
12:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/54f270cde4
13:06 timotimo it could very well be that i'll have to toss the nice pool-oriented valgrind user requests because only memcheck understands them
13:06 timotimo that took me a while to notice
13:07 FROGGS joined #moarvm
13:08 dalek MoarVM: 58711b4 | jnthn++ | src/ (4 files):
13:08 dalek MoarVM: Thread ID handling cleanup.
13:08 dalek MoarVM:
13:08 dalek MoarVM: Differentiate VM-level ID from native thread ID. Make nqp::threadid
13:08 dalek MoarVM: be the former, as on JVM, so we can even know it before the thread is
13:08 dalek MoarVM: started. Make sure we give a thread ID early enough to answer the
13:08 dalek MoarVM: question. Also, never block on a request for a thread ID. We don't yet
13:08 dalek MoarVM: have an API to get the native thread ID, but keep the code around as
13:08 dalek MoarVM: we'll likely get one some day.
13:08 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/58711b45a7
13:08 jnthn timotimo: Aww :(
13:08 timotimo and without the ability to say "this memory pool is now completely freed, basically" i'm not sure how to handle nursery allocations at all
13:09 jnthn Yeah, we move objects, which I guess is tricky...
13:09 timotimo the code i currently have unpushed on my laptop is *very* wrong about how the gc run works
13:09 timotimo and thus it makes memcheck spit out oodles of invalid reads inside the nursery during gc
13:10 timotimo up to the point where it says "you've now made me spit out ten million errors. i won't go on. fix your damn program"
13:31 vendethiel joined #moarvm
13:53 zakharyas joined #moarvm
14:05 camelia joined #moarvm
14:10 timotimo so... brrt
14:11 timotimo were you planning on accidentally a whole trace jit as part of your grant? :P
14:16 brrt uhm... well....
14:16 brrt if i can help it
14:16 brrt but i think the tracing part is both too large to fit in the grant, and too small for a seperate grant
14:17 brrt because jnthn++ has done 90% of the work already (because of inlining support)
14:17 brrt maybe 80%, but you get my point :-)
14:17 jnthn It's still a bit tricky, but yeah, I had an idea we'd want to go there and tried to prep for it :)
14:17 timotimo hrhr
14:18 brrt everything about spesh is tricky though :-)
14:26 Ven joined #moarvm
14:26 brrt there are two things that i've not entirely made up my mind on
14:27 brrt a): what about inlining the same frame twice, totally possible in a trace
14:27 brrt b): what about a (non-tail) recursive function?
14:27 brrt in case of tail recursion, you could try loop rewriting, in case of non-tail-recursion, you're... well
14:28 brrt screwed, until you can add somehow a growing stack to the equation
14:28 brrt which you can if you're the JIT
14:28 brrt actually, which you also can if you're not the JIT, it's just trickier
14:28 brrt and we have no real support for that idea
14:29 brrt on one hand, it's just adding a pointer, on the other....
14:31 timotimo i ought to put a comment under that grant application, too
14:31 brrt if you wish, and if it's still open, that would be nice :-)
14:32 brrt i think there were supposed to be 2 weeks of review time? I haven't really kept tabs on progress of evaluation
14:32 brrt not that i'd know how or where
14:32 timotimo it's kinda hard to find on the perlfoundation website
14:50 dalek MoarVM: 183296e | jnthn++ | src/core/fixedsizealloc.c:
14:50 dalek MoarVM: Fix an ABA bug in the fixed size allocator.
14:50 dalek MoarVM:
14:50 dalek MoarVM: This could lead to freelist corruption in a multi-threaded scenario.
14:50 dalek MoarVM: We'll want a more efficient solution to this in the longer term, but
14:50 dalek MoarVM: for now this addresses the correctness bug.
14:50 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/183296e302
14:54 brrt is there some progress display?
14:56 timotimo sent my comment off :)
15:04 Ven_ joined #moarvm
15:08 brrt thanks :-)
15:09 brrt what's an ABA issue?
15:10 masak brrt: it's a potential problem with compare-and-swap
15:10 timotimo https://en.wikipedia.org/wiki/Compare-and-swap#ABA_problem
15:10 * timotimo reads
15:11 masak basically, if something changes *back* when you CAS, it will false-negatively register as "no change", though it was actually more than one change.
15:11 masak s/when/before/
15:11 timotimo kind of like a hazard error
15:11 masak dunno about those
15:11 brrt right...
15:11 brrt ok, i see
15:11 [Coke] masak: I wonder if recent NFG work has fixed RT #107204 in moar.
15:11 synbot6 Link:  https://rt.perl.org/rt3//Public/Bug/Display.html?id=107204
15:11 masak but it's one way CAS can show false negatives.
15:11 timotimo huh. it seems like the english name for that is just "glitch"
15:12 timotimo "electronics glitch"
15:12 masak oh, like an electric bug?
15:12 dalek MoarVM: dc11409 | jnthn++ | src/core/fixedsizealloc. (2 files):
15:12 dalek MoarVM: At least do a spinlock rather than a mutex.
15:12 dalek MoarVM:
15:12 dalek MoarVM: Eventually we'll go with per-thread free lists and some kind of way
15:12 dalek MoarVM: to steal, but this goes a long way to recover performance lost by the
15:12 dalek MoarVM: previous commit while keeping the bug fixed.
15:12 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/dc11409425
15:12 timotimo masak: it comes from the concrete implementation of transistor logic and timing
15:13 masak [Coke]: either way, that RT ticket doesn't have a decent observable, and should be rejected on principle.
15:13 timotimo where some input variable hasn't propagated the new value yet and so the result briefly becomes what it would be if that variable hasn't changed yet, and then updates again to correspond to the proper input value
15:13 masak timotimo: oh, I see.
15:13 masak timotimo: well, in concurrent programming, that's mostly just called a "race" :)
15:13 jnthn Given this bug could lead to all manner of memory corruption, it may be at the base of various bits of our multi-threaded instability
15:13 timotimo ah, i suppose that's an apt comparison
15:13 [Coke] masak: That was going to be my next bit, yes. "tests or..."
15:14 masak tests or it didn't happen.
15:23 timotimo jnthn: did you do a measurement for the temporary root handling change?
15:24 jnthn 2%
15:24 jnthn On the Rakudo startup
15:24 jnthn I'd guess maybe similar in other cases, maybe a bit more, depends.
15:25 timotimo thanks
15:25 timotimo just wanted a rough estimate :)
15:26 jnthn Guess you've got the hash memory decrease things going into the weekly too? :)
15:27 timotimo it'll be in
15:27 timotimo in its own section about hash order, actually
15:27 jnthn ah, ok
15:27 timotimo do i remember correctly that nwc10 is to blame^Wpraise for the recent memory leak fixes?
15:29 dalek MoarVM: 052aca0 | jnthn++ | src/core/ (2 files):
15:29 dalek MoarVM: Factor out code to avoid a "magic value" all over.
15:29 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/052aca0d3c
15:29 jnthn Memory leak?
15:29 jnthn I think ptc++ did some memory leak fixes
15:30 timotimo ah
15:30 timotimo good, then i remembered incorrectly
15:31 timotimo hm.
15:31 timotimo i'm not so sure i'll be able to fill a proper section with hash order changes
15:31 timotimo so it'll live in the performance improvements section after all
15:31 jnthn Well, it's not a speedup really
15:31 jnthn It's more a memory saving
15:31 timotimo aye
15:31 jnthn I think you measured a bit off startup memory
15:32 timotimo if you refer to the measurement i just did today, that includes lizmat's CUR lazyness patches
15:32 timotimo oh
15:32 timotimo i did do a measurement
15:32 brrt oh, for my clarity
15:32 timotimo but that also contains the "re-use compunit's string heap" thing
15:32 japhb timotimo: Can haz resultz?
15:33 brrt is the localref thingy, is that to make containers on the fly, for, e.g. object attributes?
15:33 timotimo 002847  timotimo │ i see about 1.5 megabytes less maxresidentk for a newer rakudo vs an older rakudo
15:33 timotimo 002925* timotimo │ to be exact: f4ff0a8..56cae10  nom    547d08a..18ece1f  master (nqp)    f04b1d8..0e6e0b6  master
15:33 timotimo │ (moarvm)
15:33 timotimo 003233  timotimo │ that contains both the "re-use string heap from comp-unit" and the "remove doubly-linked list from
15:34 timotimo brrt: there's also an attrref,b tw
15:35 brrt aye
15:35 brrt but that's what it's for/
15:35 brrt ?
15:35 brrt interesting
15:35 japhb timotimo: Ah, nice.
15:36 timotimo it's there so that a callee can have direct rw access to a local in a caller's frame
15:38 timotimo and later we'll be able to turn that into direct access to a local after inlining
15:39 brrt awesome
15:39 * brrt afk
15:40 jnthn japhb: I did a .tell to you on #perl6 earlier, but the bot wasn't there...dunno if you backlog :)
15:41 vendethiel joined #moarvm
15:45 japhb jnthn: I usually look for highlights if it hasn't been too long to lose lines in the scrollback.  I'll do so now.
15:48 [Coke] r: sub foo(X of X) { }
15:48 camelia rakudo-moar 87b1ee: OUTPUT«===SORRY!===␤Cannot find method 'parameterize'␤»
15:48 camelia ..rakudo-jvm 87b1ee: OUTPUT«===SORRY!===␤No such method 'parameterize' for invocant of type 'Perl6::Metamodel::PackageHOW'␤»
15:49 timotimo the what now
15:49 timotimo o_O
15:50 jnthn It's not a parametric type but you tried to parameterize it.
15:50 jnthn Not a great errror
15:50 [Coke] old RT.
15:51 [Coke] https://rt.perl.org/Ticket/Display.html?id=115400
15:51 [Coke] ... I really need to pick a channel and stick with it. :)
15:51 timotimo :)
15:51 japhb jnthn: OK, got to the one about the yield test being bogus.  That's fine; I kinda was working backwards from the Rakudo implementation supplemented by wild ass guesses, so I'm not surprised I got something wrong.
15:52 japhb Also, I clearly didn't manage to write all the tests we need for NQP ops -- got rather limited by $day-job commitments of late.
15:59 timotimo jnthn: do we actually have some good approach to making the libuv event loop in the event loop thread not spin?
15:59 timotimo someone else recently got bitten by that again
16:00 jnthn timotimo: I *think* the async send thingy
16:02 * japhb catches up with real time, but hasn't read the patch logs yet
16:02 japhb Anything else you wanted to ask jnthn before I get sucked into $day-job again?
16:02 jnthn japhb: No, I was mostly wanting to see if you agreed those yeidld tests were kinda bogus
16:03 jnthn japhb: If we agree on that I can toss those and then add the concurrency tests to Moar/JVM normal "make test" in NQP
16:03 jnthn japhb: Which'll make it easier to see if we regress on them or have further instability
16:03 japhb I'm all in favor.
16:04 japhb Sad that there is no way to more strongly suggest a yield, since it seems like a really mild hint, but I have no desire to protect broken tests.
16:04 japhb And I'd definitely rather have them in the regression suite.
16:08 japhb BTW, very happy to see the change in say/print to make them single operations.  Gad it's annoying to get interleaved ok() output
16:15 jnthn Well, if we want that in Perl 6 too we'll have to do it in Test.pm there also
16:16 dalek MoarVM: 6c9ee55 | jnthn++ | src/ (3 files):
16:16 dalek MoarVM: Concurrency control on multi-cache additions.
16:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6c9ee556e7
16:18 japhb jnthn: Sure ... but I'll take what I can get for now.  :-)
16:19 timotimo hm, that Proc::Async code TimToady linked to (https://gist.githubusercontent.com/anonymous/16e85e7c3e1b95ce1577/raw/e9de680c5dac8fa0be1c6be247de07217c15dd7a/gistfile1.txt) is still behaving erratically
16:19 timotimo *** Error in `/home/timo/perl6/install/bin/moar': double free or corruption (fasttop): 0x00000000033abb90 ***
16:19 timotimo yay :S
16:20 jnthn timotimo: I've no doubt we've more to find yet.
16:20 timotimo probably :)
16:25 jnthn Seems the next nasty to find is this one:
16:25 jnthn When invoking is_bindable, Provided outer frame 00000000049D44E0 (MVMStaticFrame bind_one_param) does not match expected static frame type 00000000049D4280 (MVMStaticFrame )
16:25 timotimo it's not *that* far away from the correct one! :P
16:30 TimToady btw, that gist is from https://raw.githubusercontent.com/kgoess/restart-concurrent/master/restart.p6 but fixed to remove the spurious return in the started block
16:32 TimToady and yeah, still very flaky
16:33 vendethiel joined #moarvm
16:50 nwc10 jnthn: for us students here, why are the atomics still needed if the section is now protected by a lock?
16:52 nwc10 also, doesn't a C compiler spot that
16:52 nwc10 while (i < 1024)
16:52 nwc10 i++;
16:52 nwc10 is side effect free and decide to just avoid doing the work entirely?
16:52 nwc10 or am I missing something (else)?
16:54 nwc10 oh, and a hat trick of silly questions - in https://github.com/MoarVM/MoarVM/commit/6c9ee556e7 you put two mutexs next to each other. Isn't that LTA?
17:14 nwc10 jnthn: at master/master/nom t/spec/integration/advent2013-day14.t can still fail: http://paste.scsys.co.uk/476288
17:58 TimToady joined #moarvm
17:59 zakharyas joined #moarvm
18:40 brrt joined #moarvm
19:08 TimToady joined #moarvm
19:27 jnthn nwc10: The atomics are needed because the "add to free list" is not protected by a lock, but rather using a lock-free design. The lock is used purely for serializing the allocations, which is the "obvious minimum ABA fix"
19:28 jnthn The loop actually needs to contain the nice thingy that doesn't horribly waste cycles under HT CPUs; I'll get there, but I'm more bug-hutning that performance tuning right now.
19:28 nwc10 the lock only covers adding? Removing from the free list is the (other part of) the lock-free design?
19:29 jnthn No, the lock only covers removing from the free list (that is, allocating from it)
19:29 jnthn Putting new items onto the list isn't vulnerable
19:30 nwc10 OK. I'm too tired to figure out why
19:30 nwc10 I've just got t/spec/S17-lowlevel/lock.rakudo.moar to fail after a very long time of looping it
19:30 jnthn http://en.wikipedia.org/wiki/ABA_problem describes ABA nicely at least.
19:30 jnthn Yeah, I'm well aware there are still plenty of gremlins
19:31 jnthn I've got a IO::Socket::Async ping server that I'm going to increasingly hammer until it runs for ages.
19:31 nwc10 this is probably one youv'e seen before: http://paste.scsys.co.uk/476307
19:31 jnthn (And fix what falls out on the way)
19:31 jnthn *nod*
19:32 nwc10 the earlier nopaste was ASAN barfage, but possibly also known-to-you
19:35 TimToady joined #moarvm
19:45 TimToady joined #moarvm
20:26 TimToady joined #moarvm
20:36 TimToady joined #moarvm
21:13 nebuchadnezzar hello
21:14 nebuchadnezzar could it be possible to automatically generate the release.html and homepage of moarvm.org to get accurate latest release version?
21:15 jnthn Just nudge somebody when it's out of date :)
21:15 jnthn The blurb is written manually
21:15 jnthn I guess it's *possible* to automate more of it...I'm not sure if it's worth it :)
21:15 nebuchadnezzar maybe a hook somewhere to update https://github.com/MoarVM/moarvm.org on new release tag?
21:16 nebuchadnezzar jnthn: erf, maybe yes
21:17 nebuchadnezzar it may took more time to make something quite automatic than several years of updating the html by hand :-D
21:17 jnthn nebuchadnezzar: Yes, that's what I figured too
21:17 jnthn I normally take care of it immediately after the release.
21:18 jnthn But probably got distracted (quite a bit going on offline at the moment :))
21:19 TimToady joined #moarvm
21:22 nebuchadnezzar speaking about distraction, I'll try to avoid it and work on packaging the latest nqp for Debian this week-end, maybe updating rakudo at the same time :-D
21:22 nebuchadnezzar for now, good night
21:25 jnthn Cool
21:25 jnthn And thanks for the poke, update coming very soon :)
21:25 jnthn 'night
21:27 dalek moarvm.org: 0365d91 | jnthn++ | / (3 files):
21:27 dalek moarvm.org: Update site for 2015.04 release.
21:27 dalek moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/0365d91aa2
21:29 dalek moarvm.org: 2e1c6e5 | jnthn++ | roadmap.html:
21:29 dalek moarvm.org: A few updates to the roadmap.
21:29 dalek moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/2e1c6e5844
22:10 japhb nebuchadnezzar: Make sure you package *after* Panda is working well again.  As of this morning, I was seeing fixes flying for Panda breakage due to latest startup performance improvements.
23:15 Peter_R joined #moarvm
23:22 xiaomiao joined #moarvm

| Channels | #moarvm index | Today | | Search | Google Search | Plain-Text | summary