00:15 vendethiel joined 00:52 vendethiel joined
timotimo hrm. now there'll be a bit of clutter ... until now there wasn't any 00:56
when adding pages, we always do a realloc for the pages of a bin 00:57
oh, actually
i may not want to make every page its own VALGRIND_MEMPOOL
yeah, that'll make things way easier
==5796== Address 0x5a3aa80 is 24 bytes inside a block of size 32 client-defined 00:59
==5796== at 0x4D7B5DD: MVM_gc_allocate_nursery (allocation.c:39)
sometimes the nursery parts work already <3
04:12 TimToady joined 04:17 TimToady joined 04:36 vendethiel joined 06:15 vendethiel joined 07:12 vendethiel joined 07:14 TimToady joined 07:42 rurban joined 07:51 rurban joined 07:59 Ven joined 08:04 brrt joined 08:16 Ven_ joined 08:49 vendethiel joined
brrt \o 09:02
lizmat brrt: /o 09:09
brrt :-)
09:21 vendethiel joined 09:54 TimToady joined 10:30 Ven_ joined 10:46 TimToady joined 10:51 vendethiel joined 11:18 TimToady joined 11:42 rurban joined 12:21 brrt joined
dalek arVM: 54f270c | jnthn++ | src/strings/ops.c:
Re-implement simple say/print using MoarVM I/O.

This reduces code duplication, and further means that nqp::say will certainly output the text and newline as a single operation.		 12:27
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
that took me a while to notice
13:07 FROGGS joined
dalek arVM: 58711b4 | jnthn++ | src/ (4 files):
Thread ID handling cleanup.

Differentiate VM-level ID from native thread ID. Make nqp::threadid be the former, as on JVM, so we can even know it before the thread is started. Make sure we give a thread ID early enough to answer the question. Also, never block on a request for a thread ID. We don't yet have an API to get the native thread ID, but keep the code around as we'll likely get one some day.		 13:08
jnthn timotimo: Aww :(
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
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
and thus it makes memcheck spit out oodles of invalid reads inside the nursery during gc
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:10
13:31 vendethiel joined 13:53 zakharyas joined 14:05 camelia joined
timotimo so... brrt 14:10
were you planning on accidentally a whole trace jit as part of your grant? :P 14:11
brrt uhm... well.... 14:16
if i can help it
but i think the tracing part is both too large to fit in the grant, and too small for a seperate grant
because jnthn++ has done 90% of the work already (because of inlining support) 14:17
maybe 80%, but you get my point :-)
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 :)
timotimo hrhr
brrt everything about spesh is tricky though :-) 14:18
14:26 Ven joined
brrt there are two things that i've not entirely made up my mind on 14:26
a): what about inlining the same frame twice, totally possible in a trace 14:27
b): what about a (non-tail) recursive function?
in case of tail recursion, you could try loop rewriting, in case of non-tail-recursion, you're... well
screwed, until you can add somehow a growing stack to the equation 14:28
which you can if you're the JIT
actually, which you also can if you're not the JIT, it's just trickier
and we have no real support for that idea
on one hand, it's just adding a pointer, on the other.... 14:29
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 :-)
i think there were supposed to be 2 weeks of review time? I haven't really kept tabs on progress of evaluation 14:32
not that i'd know how or where
timotimo it's kinda hard to find on the perlfoundation website
dalek arVM: 183296e | jnthn++ | src/core/fixedsizealloc.c:
Fix an ABA bug in the fixed size allocator.

This could lead to freelist corruption in a multi-threaded scenario. We'll want a more efficient solution to this in the longer term, but for now this addresses the correctness bug.		 14:50
brrt is there some progress display? 14:54
timotimo sent my comment off :) 14:56
15:04 Ven_ joined
brrt thanks :-) 15:08
what's an ABA issue? 15:09
masak brrt: it's a potential problem with compare-and-swap 15:10
timotimo en.wikipedia.org/wiki/Compare-and-...BA_problem
timotimo reads
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
s/when/before/
timotimo kind of like a hazard error
masak dunno about those
brrt right...
ok, i see
[Coke] masak: I wonder if recent NFG work has fixed RT #107204 in moar.
synbot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=107204
masak but it's one way CAS can show false negatives.
timotimo huh. it seems like the english name for that is just "glitch"
"electronics glitch" 15:12
masak oh, like an electric bug?
dalek arVM: dc11409 | jnthn++ | src/core/fixedsizealloc. (2 files):
At least do a spinlock rather than a mutex.

Eventually we'll go with per-thread free lists and some kind of way to steal, but this goes a long way to recover performance lost by the previous commit while keeping the bug fixed.
timotimo masak: it comes from the concrete implementation of transistor logic and timing
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
masak timotimo: oh, I see.
timotimo: well, in concurrent programming, that's mostly just called a "race" :)
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
timotimo ah, i suppose that's an apt comparison
[Coke] masak: That was going to be my next bit, yes. "tests or..."
masak tests or it didn't happen. 15:14
timotimo jnthn: did you do a measurement for the temporary root handling change? 15:23
jnthn 2% 15:24
On the Rakudo startup
I'd guess maybe similar in other cases, maybe a bit more, depends.
timotimo thanks 15:25
just wanted a rough estimate :)
jnthn Guess you've got the hash memory decrease things going into the weekly too? :) 15:26
timotimo it'll be in 15:27
in its own section about hash order, actually
jnthn ah, ok
timotimo do i remember correctly that nwc10 is to blame^Wpraise for the recent memory leak fixes?
dalek arVM: 052aca0 | jnthn++ | src/core/ (2 files):
Factor out code to avoid a "magic value" all over.
 15:29
jnthn Memory leak?
I think ptc++ did some memory leak fixes
timotimo ah 15:30
good, then i remembered incorrectly
hm. 15:31
i'm not so sure i'll be able to fill a proper section with hash order changes
so it'll live in the performance improvements section after all
jnthn Well, it's not a speedup really
It's more a memory saving
timotimo aye
jnthn I think you measured a bit off startup memory
timotimo if you refer to the measurement i just did today, that includes lizmat's CUR lazyness patches 15:32
oh
i did do a measurement
brrt oh, for my clarity
timotimo but that also contains the "re-use compunit's string heap" thing
japhb timotimo: Can haz resultz?
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
002925* timotimo ā”‚ to be exact: f4ff0a8..56cae10 nom 547d08a..18ece1f master (nqp) f04b1d8..0e6e0b6 master
ā”‚ (moarvm)
003233 timotimo ā”‚ that contains both the "re-use string heap from comp-unit" and the "remove doubly-linked list from
brrt: there's also an attrref,b tw 15:34
brrt aye 15:35
but that's what it's for/
?
interesting
japhb timotimo: Ah, nice.
timotimo it's there so that a callee can have direct rw access to a local in a caller's frame 15:36
and later we'll be able to turn that into direct access to a local after inlining 15:38
brrt awesome 15:39
brrt afk
jnthn japhb: I did a .tell to you on #perl6 earlier, but the bot wasn't there...dunno if you backlog :) 15:40
15:41 vendethiel joined
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:45
[Coke] r: sub foo(X of X) { } 15:48
camelia rakudo-moar 87b1ee: OUTPUTĀ«===SORRY!===ā¤Cannot find method 'parameterize'ā¤Ā»
..rakudo-jvm 87b1ee: OUTPUTĀ«===SORRY!===ā¤No such method 'parameterize' for invocant of type 'Perl6::Metamodel::PackageHOW'ā¤Ā»
timotimo the what now 15:49
o_O
jnthn It's not a parametric type but you tried to parameterize it. 15:50
Not a great errror
[Coke] old RT.
rt.perl.org/Ticket/Display.html?id=115400 15:51
... I really need to pick a channel and stick with it. :)
timotimo :)
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.
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:52
timotimo jnthn: do we actually have some good approach to making the libuv event loop in the event loop thread not spin? 15:59
someone else recently got bitten by that again
jnthn timotimo: I *think* the async send thingy 16:00
japhb catches up with real time, but hasn't read the patch logs yet 16:02
Anything else you wanted to ask jnthn before I get sucked into $day-job again?
jnthn japhb: No, I was mostly wanting to see if you agreed those yeidld tests were kinda bogus
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
japhb: Which'll make it easier to see if we regress on them or have further instability
japhb I'm all in favor.
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
And I'd definitely rather have them in the regression suite.
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:08
jnthn Well, if we want that in Perl 6 too we'll have to do it in Test.pm there also 16:15
dalek arVM: 6c9ee55 | jnthn++ | src/ (3 files):
Concurrency control on multi-cache additions.
 16:16
japhb jnthn: Sure ... but I'll take what I can get for now. :-) 16:18
timotimo hm, that Proc::Async code TimToady linked to (gist.githubusercontent.com/anonymo...file1.txt) is still behaving erratically 16:19
*** Error in `/home/timo/perl6/install/bin/moar': double free or corruption (fasttop): 0x00000000033abb90 ***
yay :S
jnthn timotimo: I've no doubt we've more to find yet. 16:20
timotimo probably :)
jnthn Seems the next nasty to find is this one: 16:25
When invoking is_bindable, Provided outer frame 00000000049D44E0 (MVMStaticFrame bind_one_param) does not match expected static frame type 00000000049D4280 (MVMStaticFrame )
timotimo it's not *that* far away from the correct one! :P
TimToady btw, that gist is from raw.githubusercontent.com/kgoess/r...restart.p6 but fixed to remove the spurious return in the started block 16:30
and yeah, still very flaky 16:32
16:33 vendethiel joined
nwc10 jnthn: for us students here, why are the atomics still needed if the section is now protected by a lock? 16:50
also, doesn't a C compiler spot that 16:52
while (i < 1024)
i++;
is side effect free and decide to just avoid doing the work entirely?
or am I missing something (else)?
oh, and a hat trick of silly questions - in github.com/MoarVM/MoarVM/commit/6c9ee556e7 you put two mutexs next to each other. Isn't that LTA? 16:54
jnthn: at master/master/nom t/spec/integration/advent2013-day14.t can still fail: paste.scsys.co.uk/476288 17:14
17:58 TimToady joined 17:59 zakharyas joined 18:40 brrt joined 19:08 TimToady joined
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:27
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?
jnthn No, the lock only covers removing from the free list (that is, allocating from it) 19:29
Putting new items onto the list isn't vulnerable
nwc10 OK. I'm too tired to figure out why 19:30
I've just got t/spec/S17-lowlevel/lock.rakudo.moar to fail after a very long time of looping it
jnthn en.wikipedia.org/wiki/ABA_problem describes ABA nicely at least.
Yeah, I'm well aware there are still plenty of gremlins
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: paste.scsys.co.uk/476307
jnthn (And fix what falls out on the way)
*nod*
nwc10 the earlier nopaste was ASAN barfage, but possibly also known-to-you 19:32
19:35 TimToady joined 19:45 TimToady joined 20:26 TimToady joined 20:36 TimToady joined
nebuchadnezzar hello 21:13
could it be possible to automatically generate the release.html and homepage of moarvm.org to get accurate latest release version? 21:14
jnthn Just nudge somebody when it's out of date :) 21:15
The blurb is written manually
I guess it's *possible* to automate more of it...I'm not sure if it's worth it :)
nebuchadnezzar maybe a hook somewhere to update github.com/MoarVM/moarvm.org on new release tag?
jnthn: erf, maybe yes 21:16
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
I normally take care of it immediately after the release.
But probably got distracted (quite a bit going on offline at the moment :)) 21:18
21:19 TimToady joined
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
for now, good night
jnthn Cool 21:25
And thanks for the poke, update coming very soon :)
'night
dalek href="https://moarvm.org:">moarvm.org: 0365d91 | jnthn++ | / (3 files):
Update site for 2015.04 release.
 21:27
href="https://moarvm.org:">moarvm.org: 2e1c6e5 | jnthn++ | roadmap.html:
A few updates to the roadmap.
 21:29
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. 22:10
23:15 Peter_R joined 23:22 xiaomiao joined

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!