dalek arVM: 5de8e14 | jnthn++ | src/core/continuation.c:
Simplify frame refcount handling in continuations.

Avoid a couple of seemingly unrequired fiddles. Doesn't help with the frame leak, but simpler/cleaner.		 00:23
arVM: 8d2fe21 | jnthn++ | src/6model/reprs/MVMContinuation.c:
Fix a source of frame leaks in continuations.

When we GC a continuation that sliced off some active handlers, and those handlers still reference frames, make sure we decrement the frame reference count. Can happen for a gather/take that does not ever complete its execution. So, not the big leak affecting all of the gather/takes, but a needed fix anyway.
jnthn OK, I have a clue. 00:27
44-try-catch.t leaks a frame. 00:28
Commenting out the test that resumes from an exception seems to remove the frame leak.
And gather/take uses resumable exceptions.
timotimo that seems conclusive
jnthn Well, it's certainly suggestive, yeah.
Looking at resumption now. 00:29
oh, yeah...
timotimo is expecting an "oh, how was this ever supposed to work?" :)
ah, there it is! :)
jnthn Well, I think I see what's wrong.
/* Clear the current active handler. */
ah = tc->active_handlers;
tc->active_handlers = ah->next_handler;
free(ah);
That's correct in terms of "will work"
But when we make an active handler record, it takes a ref to the frame. 00:30
yeah...
/* Install active handler record. */
ah->frame = MVM_frame_inc_ref(tc, lh.frame);
timotimo and there's no dec_ref there?
i mean ... yeah, there's no dec_ref there :) 00:32
jnthn I think that fixes the 44-try-catch.t leak... 00:33
TimToady pity my test case is so big :) 00:34
jnthn One line of Perl 6 can do a lot :P 00:35
Turns out that t/moar/01-continuations.t exhibits the leak also. 00:36
And still has it after the fix I just did.
So that wasn't the entire problem.
TimToady waits for the declaration that all our current behavior depends on a bug 00:38
timotimo perl 6 is just the result of the undefined behavior of a small subroutine in the computer that was built by Deep Thought to figure out the question to which the answer is 42 00:40
jnthn Well, currently working my way through the continuations tests, seeing what I have to uncomment to get a leak... 00:41
timotimo and i'm still wondering why and how i got the libpath problem in my moarvm :\ 00:44
(but that seems to be gone now, so ...) 01:12
TimToady suspects jnthn++ has passed out :) 01:20
timotimo drowned from all the leak 01:22
jnthn TimToady: Nah. Got it reduced down to something pretty small by now. :) 01:35
TimToady it's probably the thing that makes one statement happen after the previous one :) 01:38
either that, or the thing that makes the next statement happen after this one... 01:43
01:45 benabik joined
jnthn OK, time to cross fingers... 02:13
jnthn does an optimized build and spectests the patch. 02:14
TimToady alas, there is no unicode glyph for crossed fingers 02:17
crossed swords, or crossed flags
02:18 benabik joined, FROGGS_ joined
dalek arVM: 5d0209e | jnthn++ | src/core/exceptions.c:
Missing frame dec ref on exception resume.

Active handler's frame reference goes away, so decrement.		 02:21
japhb__ disbelieves that statement ... but is not actually planning to check.
dalek arVM: 7a2652c | jnthn++ | src/core/continuation.c:
Fix "on stack" continuation ref-count handling.

When a frame is on the current call stack, it gets its reference count incremented by 1 to indicate it's active at the very least as a result of currently being running. When we take a continuation, to make sure frame lifetimes are handled correctly, we just decrement this count as we slice frames away. Similarly, continuation invoke should re-instate the count as we splice the frames back onto the active call stack. Fixes gather/take memory leak reported by TimToady++.
TimToady \o/ 02:23
jnthn TimToady: perl6-m -e "my @bar = (gather take 42) while 1;" # now memory stays constant
timotimo 151.68user 0.70system 2:33.51elapsed 99%CPU (0avgtext+0avgdata 1650512maxresident)k 02:24
japhb__ timotimo: Any more improvement in maxresident for the setting build on your machine now?
timotimo this is parrot, btw
japhb__ Ah, you were already on it. :-)
jnthn japhb__: The setting compile doesn't gather/take, afaik.
msvc++ # debug malloc can find leaks 02:25
japhb__ jnthn: You had other fixes since the last time he reported in channel. 02:26
timotimo the timing is on my desktop vs my laptop, btw
so don't compare those.
japhb__ I just didn't want to ask until you'd done all the fixes.
jnthn japhb__: ah, k
japhb__ Was it nwc10 who tried r-m builds on a Raspberry Pi? 02:28
timotimo that would be an impressive feat
given it took like 0.75 gigabytes of ram
where the fattest raspi has half a gig in total
jnthn We're down to 0.6something now, though :) 02:29
japhb__ We're getting close with swap, I should think, depending on how many of those resident K are touched continuously.
timotimo 65.74user 0.18system 1:06.21elapsed 99%CPU (0avgtext+0avgdata 619072maxresident)k
hardly any measurable memory saving from the frame reference counting improvements
japhb__ Another 224K
timotimo not necessarily. it fluctuates quite a bit.
but it's still more than twice as fast as parrot 02:30
and takes more than 1 gig less ram.
though IIUC parrot will just keep memory it once allocated around forever, rather than freeing it
so it's hard to tell if the memory usage is really that more dramatic
japhb__ Ah, I misunderstood, I thought you meant the maxresident didn't change when you said they were "quite stable" -- you just meant not multiple MB change, I take it?
timotimo about 1 megabyte from run to run 02:31
japhb__ Ah, OK
japhb__ wonders where that variance comes from.
timotimo let me verify
jnthn too :)
timotimo yeah, fluctuations of about 0.75 megabyte 02:32
could be ordering of things going on in the uv event loop that throws off gc timings or maybe hash randomization? 02:35
1 megabyte of fluctuation for that amount is about 1/6th of 1%
dalek arVM: e9b018f | jnthn++ | src/mast/compiler.c:
Some missing cleanup in MAST compiler.
 03:05
jnthn Guess I should sleep a bit :)
'night o/
JimmyZ good night jnthn++ 03:06
08:22 tgt joined 08:49 ggoebel11110 joined 09:14 lue joined
dalek arVM: 10785df | svatsan++ | build/probe.pm:
Update probe.pm

Using the newer 'make_path' and 'remove_tree' causes build/configure to bail out on older versions of File::Path (especially those shipped with perl v5.10). Please see [File::Path#APIChanges][1]
  [1]: metacpan.org/pod/File::Path#API-CHANGES		 09:21
arVM: eae662b | (Tobias Leich)++ | build/probe.pm:
Merge pull request #79 from svatsan/patch-1

Update probe.pm
09:28 camelia joined 09:32 FROGGS_ joined 09:37 camelia joined 09:41 tgt joined 10:34 cognominal joined 10:46 tgt joined 11:47 tgt joined
dalek arVM: 537a176 | jnthn++ | src/6model/reprs/MVMCallCapture.c:
Don't leak named_used in MVMCallCapture.

This caused over 300,000 1-byte leaks in CORE.setting compilation.		 12:18
arVM: 054c086 | jnthn++ | src/io/fileops.c:
Don't leak C string in library lookup.
arVM: adfa8fc | jnthn++ | src/core/loadbytecode.c:
Don't leak C string in bytecode loading.
jnthn There's more to be had, but this'll do me for now :) 12:26
Eyeballing it, seems I just got a setting build in under 600MB. 12:28
JimmyZ wonders how to build a moarvm with crt dmalloc 12:51
12:51 tgt joined
timotimo \o/ 12:57
jnthn JimmyZ: msdn.microsoft.com/en-us/library/e5...s.90).aspx 12:59
timotimo 68.67user 0.24system 1:09.43elapsed 99%CPU (0avgtext+0avgdata 606624maxresident)k
so another 13 megabytes less
JimmyZ jnthn: thanks 13:00
jnthn Not bad :)
timotimo considering one of the leaks you fixed was a single byte big :) 13:02
jnthn Yeah, but I bet tracking that allocation had overhead...
timotimo yeah
hm. wasn't nqp-m -e 'say(1)' once at 10 megabytes? or am i misremembering? 13:08
because it's at 20 right now
jnthn Misremembering, I think. 13:14
Turns out rt.perl.org/Public/Bug/Display.html?id=121298 golfs further 13:21
FROGGS[mobile] how much further? 13:47
I am eager to see the solution, though I think I probably won't unterstand it 13:48
jnthn I don't have one yet :(
Constants.pm golfs to
module MoarMoneyMoarProblems::Constants;
our sub get-value { say 'ok' }
The other pm golfs to: 13:49
need MoarMoneyMoarProblems::Constants;
And then test.p6 is just
use MoarMoneyMoarProblems;
say MoarMoneyMoarProblems::Constants::get-value;
FROGGS[mobile]: Here's a patch, if you have time to try it: gist.github.com/jnthn/9431169 14:16
With that the original code now outputs the correct value 14:17
FROGGS compiles 14:18
jnthn spectests look fine with it 14:28
FROGGS jnthn: it seems to fir it for moar but not for jvm, right? 14:37
I get a NPE for jvm with the snippets you posted
perl6-j test.p6 14:38
java.lang.NullPointerException
in sub get-value at lib/MoarMoneyMoarProblems/Constants.pm:2
and it also only fails when using precompiled modules 14:40
jnthn Aww, too bad. I'd hoped it'd maybe fix it for both.
I guess when JVM adopts the same closure model as Moar then it fixes it...
Still, good it helps on Moar. Does it help URI? 14:41
FROGGS let my try
jnthn ok. btw, the bug wasn't to do with the data structure; it was about the our-scoped sub... 14:46
Gonna take a walk while the weather's nice :) bbl 14:47
FROGGS yes, that was my guess too :o)
have fun
jnthn: ==> Successfully installed URI
timotimo i'll go on a little jog while the weather is so lovely :)
jnthn yay!
FROGGS: And that failed before, yes? 14:48
FROGGS jnthn: I think so
jnthn k
&
timotimo that's something very nice for the weekly changes :) 14:57
along with the memory leak removals
jnthn aye :) 15:33
wow, so sun
masak much bright 15:38
jnthn figures he can get back to concurrency stuff now he fixed some leaks and the SC bug :) 15:41
timotimo aye! :D 15:42
dalek Heuristic branch merge: pushed 43 commits to MoarVM/moar-conc by jnthn 16:07
timotimo jnthn: what's next on the plan for moar-conc? 16:24
jnthn Refactor Promises to use cond ars 16:25
uh, cond vars
timotimo i like the sound of that :)
jnthn And then provide those on Moar too
And then get promises to work on Moar.
TimToady promises, promises...
jnthn :P 16:26
timotimo does the thread pool scheduler come directly after that? or did i miss it and it's already done?
jnthn It's there for non-time-based things. 16:27
The time-based scheduling is NYI
timotimo ah, i remember even writing about that
jnthn I'll probably do the time-based stuff after getting the rest going...
timotimo what is missing for that, ooc? 16:28
jnthn Me figuring out how to implement it :P
Not quite sure how it should be factored yet. 16:29
timotimo hehe. ok
17:31 hoelzro joined 20:53 remiznik joined 21:57 denysenko joined
dalek arVM/moar-conc: b77debf | jnthn++ | / (12 files):
Implement condition variables.
 22:24
arVM/moar-conc: 75edce9 | jnthn++ | src/6model/reprs/ConditionVariable.c:
Fix pointer-o.
 22:40
23:08 woolfy1 joined
dalek arVM/moar-conc: 13706df | jnthn++ | / (8 files):
Implement queuepoll.
 23:12
23:19 grekspb joined
[Coke] jnthn++ 23:25
23:30 lizmat 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!