github.com/moarvm/moarvm | IRC logs at irclog.perlgeek.de/moarvm/today
Set by moderator on 1 September 2013.
diakopter 's head swims with contexts, frames, statics, and outers 00:06
it's kindof of a frankenweb of tangled concepts in current rakudo 00:07
00:42 jnap joined
dalek arVM/serialize: 356cd00 | diakopter++ | src/ (6 files):
finish first cut of serialization port.... harumph.
01:16
Heuristic branch merge: pushed 44 commits to MoarVM by diakopter 01:17
diakopter merged branch serialize to master
*phew*
nativecall's next
dalek Heuristic branch merge: pushed 152 commits to MoarVM/nativecall by diakopter 01:31
benabik serialize? 01:32
diakopter yeah porting serialization from parrot/jvm
mostly from parrot
untested... :)
that's for jnthn to muddle through once he needs it for bootstrapping
but at least 90% of it is there. 01:33
benabik Oh. We relied on Parrot's serialization before. OIC
diakopter no
benabik No?
diakopter 6model has its own
benabik Parrot/NQP, I meant.
NQP/Parrot(?)
diakopter yes 01:34
benabik diakopter++
diakopter parrot backend of nqp I meant
benabik should go.
diakopter github.com/perl6/nqp/blob/master/s...lization.c
to this:
github.com/MoarVM/MoarVM/blob/mast...lization.c 01:35
the diff is cute.
jnthn ported all the deserialization (2nd half) 01:37
bbiab
JimmyZ Good morning 01:45
38 files changed, 5910 insertions(+), 8728 deletions(-) 01:46
diakopter heh. 01:48
JimmyZ lib/MAST/Ops.nqp 01:52
530 additions, 4974 deletions not shown
diakopter did you look at the file? :) 01:53
JimmyZ: try nmake selftest in --optimize
should be loads faster
JimmyZ yes, I saw the irclog
Could be much faster if gmake -j4 selftest 01:55
dalek arVM: 8cd5249 | jimmy++ | src/io/procops.c:
free cwd
02:32
colomon diakopter: you have me all worried about how to handle your trig edge cases. :) 02:59
My first inclination is that, if you're not checking MVM_OP_div_n for division by zero, there's no point in worrying about it in the trig functions. 03:07
but we clearly need more tests
what's the relationship between nqp-cc and nqp? 03:15
JimmyZ /usr/local/bin/nqp --target=pir src/QASTRegexCompilerMAST.nqp > QASTRegexCompilerMAST.pir 03:17
moarop bindexcategory return arg index out of range
diakopter: ^^ after perl6 tool/update_ops.pl
diakopter ok 03:21
JimmyZ: fixed 03:22
dalek arVM: 314f3f5 | diakopter++ | tools/update_ops.p6:
oopsie
03:24
03:29 cognominal__ joined
JimmyZ diakopter++ 03:29
03:30 cognominal joined
JimmyZ colomon: nqp-cc is a cross-compiler 03:32
diakopter it runs in parrot
colomon written in nqp (parrot?), targeting MoarVM?
diakopter yes
it shares a couple files with the moarvm source, namely Ops.nqp Nodes.nqp and compiler.c 03:33
er, and ops.c, ops.h
(glance at those files and you'll see why)
colomon So… I'm thinking we need to add tests for the edge cases to the (general) NQP test suite. How would they get from there to something that we could test on MoarVM? 03:34
JimmyZ nqp-moar-cc.nqp is the main one
diakopter just put them in the main nqp test suite
JimmyZ nqp-c/t/nqp/
diakopter no
in nqp/nqp
er
perl6/nqp
not the moarvm repo 03:35
colomon okay.
I'll try to look at that tomorrow. :)
diakopter keep in mind we can test throw/catch yet on moar
*can't
... in nqp source anyway
JimmyZ I think we can
diakopter might be able to rig something in the native qast test files 03:36
JimmyZ just can't rethrow
diakopter oh
JimmyZ the nqp.moarvm already use CATCH
diakopter oh
colomon diakopter++ JimmyZ++ 03:37
diakopter colomon: I can't remember exactly what, but I seem to recall realizing there were one or two other edge cases we needed to catch other than division by zero 03:38
colomon diakopter: it's definitely possible. but I doubt we're doing much edge case catching in the other NQP versions. 03:39
At any rate, I'm planning on exploring the problem space, so to speak. :)
diakopter yay :(
ergh.
yay :)
t\\nqp\\56-role.t ....................... Cannot locate an outer frame for the call at nqp-src\\NQP.nqp:251 (nqp.moarvm:☻:137) 03:40
smiley face frame name is smiley
maybe I should finish my MVM_ASSIGN_REF and MVM_ROOT audit 03:48
dalek arVM: 341d489 | diakopter++ | / (9 files):
lots of misc cleanup
04:49
arVM: 9335b9e | diakopter++ | nqp-cc/src/nodes_parrot.h:
unbreak nqp-cc build
04:53
JimmyZ Ā» 05:05
☻
dalek arVM: b4c580b | jimmy++ | / (8 files):
implemented cwd/shell op
05:17
arVM: 952b5f0 | jimmy++ | src/io/dirops.c:
small fixes
05:22
JimmyZ diakopter: ping 05:45
diakopter JimmyZ: pong 05:48
JimmyZ diakopter: I think it's better to make Ops.nqp codes to multiline, otherwise every update makes git repo increase 21KB 05:50
diakopter oh... 05:53
ok
06:00 FROGGS joined
FROGGS nr: printf "%d", Inf 06:01
ww
morning 06:02
diakopter o/ 06:08
tadzik o/ 06:16
FROGGS t/serialization/01-basic.t ..... This representation (SCRef) does not support elems 06:19
t/serialization/02-types.t ..... This representation (SCRef) does not support elems
t/serialization/03-closures.t .. getstaticcode requires a static coderef
does it make sense to try to hunt these down now?
diakopter++ # btw :o) 06:20
ohh, JimmyZ++ # shell.t is doing something \\o/
diakopter FROGGS: no.. 06:21
FROGGS k
diakopter ignore until jnthn applies his practiced hand
FROGGS yeah
diakopter I just tried to get him 90%
FROGGS because I got stuck with 56-role... I'm thinking about working more at nqp::pack/unpack 06:22
diakopter there's a not small number of nuances remaining
JimmyZ doing segfault P
diakopter FROGGS: are those even spec'd?
FROGGS diakopter: there is no spec for nqp stuff
and I dont think there is a perl6/spec for it 06:23
so we'd go the same way like we have done with sprintf
JimmyZ Not Quite Perl6 Spec is the nqp spec
diakopter presumes lizmat will have wisdom in this
lizmat: PONG
FROGGS keep it close to Perl 5, but dont reimplement insanity :o)
diakopter don't reimplement insanity, reinvent insanity instead 06:24
FROGGS JimmyZ: so it is Not Quite Specced? :P
\\o/
yes
JimmyZ why make it nqp::pack?
FROGGS well, we'll see
JimmyZ not sub pack in v5?
FROGGS JimmyZ: rakudo has/needs it too
JimmyZ rakudo can't 'use v5'? :P 06:25
FROGGS JimmyZ: only if you have installed the module :o)
diakopter people use pack/unpack for speed
FROGGS that is another reason
diakopter they wouldn't want it to run hundreds of thousands of times slower
FROGGS but masak offered help and guidance so we can get it cope with Buf right
JimmyZ pack/unpack in c in MoarVM ? 06:26
FROGGS JimmyZ: not at this point
if we have a proper implementation+tests, then we can think about it (after rakudo has landed on moarvm)
JimmyZ rakudo has no p6pack? o_O
FROGGS so, I dont expect something like this to happen within the next twelve months 06:27
JimmyZ: it has, but incomplete
JimmyZ oh
dalek arVM/tinymt2: 6cdd904 | (Gerhard R)++ | 3rdparty/tinymt/ (4 files):
Import TinyMT64
06:35
arVM/tinymt2: 258195e | (Gerhard R)++ | build/ (2 files):
Build TinyMT
arVM/tinymt2: cfdddb3 | (Gerhard R)++ | / (9 files):
Wire up random number generator
arVM/tinymt2: b346c35 | (Gerhard R)++ | src/core/threadcontext.c:
Initialize random number generator on thread context creation
06:37 not_gerd joined
not_gerd o/ 06:37
JimmyZ good morning, not_gerd 06:39
FROGGS hi not_gerd
not_gerd tinymt2 should be ready for merge
computed goto doesn't perform any better than switch-based dispatch since nobanks has landed 06:41
diakopter heh.
well
which things did you use to benchmark
should use the man_or_boy tests
06:42 colomon joined
JimmyZ not_gerd: shouldn't as per eli.thegreenplace.net/2012/07/12/co...ch-tables/ 06:43
Did you forgot --optimize? 06:45
not_gerd actually, I did just now when rebuilding 06:47
but not when I did the test ;)
06:53 woosley joined
not_gerd basic fibinacci runs about 8% faster with cgoto 07:06
used to be 20% before nobanks
*fibonacci
JimmyZ not_gerd: got 11.7% here 07:09
faster
mingw32 on windows
on linux should be better?
diakopter hm, adding a global destruction phase adds a not small number of milliseconds 07:12
diakopter tries with optimize 07:13
a little better. ish. 07:14
not_gerd JimmyZ: I don't think it should look significantly different on linux
JimmyZ 11.7% , still a good win :P 07:19
not_gerd: test bench/dec_if.t, got 20% win! 07:29
about 20% ~ 22% win
not_gerd: +1 to merge :P 07:32
s/win/faster/ 07:33
07:35 odc joined
JimmyZ looks like dalek forgot cgoto2 branch 07:40
dalek arVM/cgoto2: d7336fc | jimmy++ | tools/update_ops.p6:
small fixed to update_ops.p6
07:44
arVM: b8e39e2 | jimmy++ | tools/update_ops.p6:
small fixed to update_ops.p6
07:46
jnthn dec_if.t is extremely biased towards opcode dispatch performance, but is less good as a measure of what normal user code will depend on. 07:54
If we're looking below 10% for normal code, it's an easy call fro me to make: supporting cgoto as well as switch ain't worth the complexity for now. 07:55
*for
JimmyZ dec_if.t is good for test cgoto vs no-cgoto 07:56
07:56 foo_bar_baz joined
jnthn If by "good" you mean "unrepresentative", sure. :) 07:56
JimmyZ jnthn: I don't think it add more complexity 07:57
just added a const table
and the diferent is 'make CGOTO=1' and 'make' 07:58
not_gerd jnthn: I'm adding support for auto-generating the ops table right now 07:59
once that's landed, take a look at interp.c before coming to any decisions ;)
JimmyZ 10% is still good, consider I compile rakudo core.setting needs 10 minute 08:01
jnthn JimmyZ: Note that I'm not arguing "not ever", simply that my priority is development ease over raw speed for the moment. 08:02
JimmyZ jnthn: what not_gerd++ said :P 08:03
not_gerd needs to comment out all ops from the oplist we don't actually implement 08:04
jnthn not_gerd: You can't just spot the missing label in interp.c? :)
not_gerd well, the compiler tells me which ones are missing 08:05
dalek arVM: ebab1af | jimmy++ | tools/update_ops.p6:
added indent to update_ops.p6
08:07
not_gerd actually implemented are 487 ops 08:09
(minus those that throw 'NYI')
dalek arVM/cgoto2: 2e3057b | jimmy++ | src/io/dirops.c:
small fixes
08:11
arVM/cgoto2: 372b247 | jimmy++ | tools/update_ops.p6:
added indent to update_ops.p6
arVM: 66aabfa | jimmy++ | src/io/ (2 files):
remove POOL(tc)
08:18
arVM/cgoto2: 3ed52f7 | (Gerhard R)++ | src/core/oplist:
Comment out ops we don't actually implement
08:21
arVM/cgoto2: cb3ba40 | (Gerhard R)++ | / (2 files):
Auto-generate list of op labels
arVM/cgoto2: f4ddd6a | (Gerhard R)++ | / (4 files):
Update op files
not_gerd jnthn: github.com/MoarVM/MoarVM/blob/cgot...e/interp.c
JimmyZ not_gerd++, it's good. 08:28
08:28 harrow joined
JimmyZ not_gerd: I think's it'll be better do #include "oplabels.h" after MVM_interp_run instead of runloop though 08:30
not_gerd JimmyZ: sure, you can put it $wherever 08:33
the RUNLOOP scope is just the one that actually uses the labels
perhaps it should also be runloop instead of RUNLOOP to math return_label 08:35
(whatever that one is for ;))
s/math/match/ 08:36
diakopter there was something there at one point.
not_gerd diakopter: do you expect something being there again? 08:40
diakopter no
08:41 donaldh joined
diakopter jnthn: I've added STable freeing and a global destruction phase... working out the kinks now 08:41
someone had removed the vm_destroy call... so unbitrotting that too 08:42
also fleshed out tc_destroy and vm_destroy
and other things
JimmyZ diakopter: git push origin nfg:nfg 08:48
diakopter yes, by this week 08:49
JimmyZ :P
dalek arVM/cgoto2: a49d2f4 | (Gerhard R)++ | src/core/interp.c:
Repaint the interp.c bikeshed
08:50
JimmyZ not_gerd: I think you will break nqp 08:53
diakopter :)
diakopter anxiously awaits jnthn's comment
jnthn diakopter: +1 to stable freeing. On global destruction, what's the motivation? 08:54
diakopter: Embedding friendliness?
diakopter well, filehandle closing and all that 08:55
jnthn diakopter: We may not want it to be the default thing; any good OS can be relied on to clean up after us at process exit, no doubt more efficiently than we can.
ah...yeah
JimmyZ not_gerd: shoulde break MVM_vm_run_file, since MVM_interp_run can't return
jnthn We may want to split up stuff we really should do and stuff we shoudl do if we want to leave no trace...
JimmyZ not_gerd: nerver mind 08:56
not_gerd: my eyes ...
diakopter jnthn: that's possible with a flag bit methinks
on the stable even
I don't think the global destruction will add that much.... I think I was getting an extra 40-50ms from the fact it was segfaulting silently 08:57
I guess my windows/msvc is hosed because it won't intercept segfaults anymore 08:58
bah.
might need to restart.
nwc10 jnthn: yes, the Perl 5 approach is to default to destroying objects and suchlike 09:01
jnthn: and optionally (and for embedders) freeing absolutely everything
diakopter in moarvm's case the non-object everythings are miniscule 09:02
nwc10 jnthn: with bugs (of omission). specifically one I'm aware of - dynamicly loaded shared objects. (complicated to fix because of ithreads and fork emulation)
jnthn diakopter: I guess we just need to be really careful to destroy STables last. 09:06
diakopter: After every other object.
diakopter: 'cus we need to st to locate the gc_free. :)
Most things don't have a gc_free though
diakopter jnthn: right, I added another gc phase, ish 09:07
jnthn for the nursery I was just gonna build a list of stables we want to free. 09:08
And then traverse that afterwards. Guess you got something like that...
diakopter right; for gen2 it needs to copy them
jnthn ?
That sounds...wrong. 09:09
diakopter because they get overwritten in the freelist
jnthn Just keep enough info around to add them into the freelist later, sounds much cleaner.
If you copy them, the pointers to them will not be updated?
diakopter hm, I guess that's the problem with updating the freelist at the same time as traversing gen2 09:10
jnthn Well, keep in mind that st freeing is not a common case. 09:11
Heck, we could even just not put them in the freelist, but flag them.
"Died last time"
Then actually put them in the freelist in the next run.
diakopter yeah.
jnthn That's actually probably a lot less code than any of the other approaches.
diakopter sounds good..
less++ code++
jnthn I suspect you'd have to have the craziest of mid-life crises to end up with loads of STs in gen2 dying. 09:12
diakopter jnthn: can I puhleaze mangle all the repr op static function names to prepend with repr name? I have a script to do it.. it would help immensely with debugging 09:13
jnthn The debugger don't show the file they come from?
diakopter nwc10: ID10T p5 n00b question - how do I get File::Slurp's read_file and write_file to preserve line endings on windows?
jnthn The REPR table has an ID right at the bottom, fwiw. I tend to use that if I want to know what REPR I have... 09:14
diakopter jnthn: well.. if my VS was working, it would
jnthn But no big objections to what you want to do, anyway...
diakopter but I was using Process Explorer *hangs head*
sigh, too many yaks
(.. and yakking)
jnthn .oO
nwc10 diakopter: I don't know. I don't use File::Slurp 09:15
diakopter empty thought bubble?
jnthn: I merged serialize branch.... should be a good start for you.. 09:18
dalek arVM/cgoto2: 74be0cb | (Gerhard R)++ | / (6 files):
Make some unimplemented ops throw to make nqp-cc happy
not_gerd ^ that should have made cgoto2 ready to merge
both cgoto2 and tinymt2 are ready, but there's no pressure to merge right now 09:21
if we want to do so, it should just be done before the op review before self-host
JimmyZ I'm +1 to both for merge 09:23
;) 09:27
diakopter jnthn: actually that way seems problematic 09:38
eh.
maybe.
nwc10: I'll give you [another] medal if you can coherently explain what each asterisk does in MVM_gc_collect_free_gen2_unmarked within 1 hour 09:47
:D
[sorry, it just took me a great number of hours to get them right] 09:52
not_gerd diakopter: validating prepargs..invoke - whitelist arg* ops or blacklist control flow ops? 10:20
not_gerd thinks whitelist and annotations in oplist 10:25
10:40 yoleaux joined 11:00 FROGGS joined
JimmyZ jnthn: ping 11:25
jnthn JimmyZ: pong 11:26
(though teaching, so may vanish at any moment :))
JimmyZ jnthn: github.com/MoarVM/MoarVM/blob/cgot...e/interp.c if you could take a quick review
:P
jnthn JimmyZ: I saw it, I will take care of it this evening. 11:27
JimmyZ jnthn: greate
*great
jnthn (reviewing it, that is)
JimmyZ ok :)
Good evening 12:05
FROGGS hi JimmyZ 12:17
JimmyZ Hi FROGGS 12:26
12:42 woolfy joined 13:11 donaldh joined
jnthn Just had chance to look at interp.c from the cgoto branch. Looks fine to me. 13:19
JimmyZ ;) 13:20
+1 to merge?
jnthn No harder to add new ops than before, at least.
If it builds on MSVC and doesn't cause any regressions.
JimmyZ jnthn: it builds
I tested on both
jnthn: how about tinyMT? create a new repo for it or add to 3rd? 13:21
jnthn wow, it's more lines of comments/license than code in that branch :P 13:24
JimmyZ hehe
jnthn Is there a libtinymt? It seems unlikely, given how, well, tiny it is :)
JimmyZ tinymt32 didn't added
only tinymt64
jnthn Yeah, it';s really tiny. So I guess it's fine to stay in 3rdparty/ 13:25
JimmyZ if you create a tinyMT repo, I'd like to add both tinymt 32 and tiny64 13:26
*tinemt64
tinyMT64
jnthn JimmyZ: I'm not sure it's worth adding a repo for so little code. This is more on the order of the sha-1 and base-64 code...
One file, essentially.
JimmyZ so we don't need tinyMT32? 13:27
jnthn Compared to libuv, libtommath, etc where in the future we'd like to probe for and use a system one rather than build it...
JimmyZ: I dunno, if we'd left it to be we'd have been calling C's rand and be done with it :P
I'm assuming somebody has more knowledge than I on good random number generation and can make a decent call on what we need :) 13:28
JimmyZ heh
dalek arVM: a1398e2 | (Gerhard R)++ | src/core/interp.c:
Add computed goto dispatch
13:29
MoarVM: d7336fc | jimmy++ | tools/update_ops.p6:
MoarVM: small fixed to update_ops.p6
13:29 dalek joined
dalek arVM/tinymt2: 952b5f0 | jimmy++ | src/io/dirops.c:
small fixes
13:52
MoarVM/tinymt2: a1398e2 | (Gerhard R)++ | src/core/interp.c:
MoarVM/tinymt2: Add computed goto dispatch
13:53 dalek joined 14:07 jnap joined
dalek arVM: 6cdd904 | (Gerhard R)++ | 3rdparty/tinymt/ (4 files):
Import TinyMT64
14:09
arVM: 258195e | (Gerhard R)++ | build/ (2 files):
Build TinyMT
arVM: cfdddb3 | (Gerhard R)++ | / (9 files):
Wire up random number generator
arVM: b346c35 | (Gerhard R)++ | src/core/threadcontext.c:
Initialize random number generator on thread context creation
arVM: 4df6b38 | jimmy++ | / (10 files):
Merge branch 'master' into tinymt2

shoulda deleted long ago..
JimmyZ hmm, make selftest failed only on msvc, don't know what's the problem 14:25
msvc win32 x86 14:26
14:35 colomon joined 14:54 benabik joined
TimToady python standardized on Mersenne Twistor, fwiw, so it could at least serve as a checklist item 15:04
yoleaux 4 Sep 2013 22:10Z <diakopter> TimToady: are the links on the Perl_6 rc page supposed to link to the p6 section anchors?
TimToady .tell diakopter iiuc the links point to the pages because the script is just written that way; but also there's a slight philosophical bias to point people at the task so they spend more time looking at all the solutions and not just the Best Language's. :) 15:06
yoleaux TimToady: I'll pass your message to diakopter.
TimToady on ubuntu64, 59-nqpop now fails (is this expected?), trying reconfig of cc... 15:40
diakopter .tell not_gerd I agree with you - whitelist 15:52
yoleaux 15:06Z <TimToady> diakopter: iiuc the links point to the pages because the script is just written that way; but also there's a slight philosophical bias to point people at the task so they spend more time looking at all the solutions and not just the Best Language's. :)
diakopter: I'll pass your message to not_gerd.
jnthn hm, nqpop segv's here... 16:05
diakopter whazzat
jnthn www.youtube.com/watch?v=G8CeP15EAS8 16:06
oops
t\\nqp\\59-nqpop.t (Wstat: 1280 Tests: 0 Failed: 0) Non-zero exit status: 5
Explodes before it even runs any tests.
diakopter dutifully clicks the mis-paste
jnthn uh-oh...
:)
It's SFW, but maybe not safe for your sanity :) 16:07
diakopter everyone needs a USB cigarette ligher
jnthn Makes me sad I'm not making it to YAPC::Asia this year... 16:10
JimmyZ jnthn: make selftest all failed only on msvc, I don't know what's the problem 16:14
msvc win32 x86
jnthn JimmyZ: msvc passes here
JimmyZ: x64 though
JimmyZ: Guess, make clean? And maybe try to bisect... 16:15
JimmyZ jnthn: I tried clean and git clean -xdf
TimToady git clean doesn't fix it for me 16:16
JimmyZ ah... mingw32 also failed, on x86
some segfault in compile.c 16:17
Good night
diakopter oh, blame it on not_gerd ;)
jnthn I'm unclean and most the only thing I see newly failing is the nqpop test...
16:17 not_gerd joined
not_gerd o/ 16:18
yoleaux 15:52Z <diakopter> not_gerd: I agree with you - whitelist
not_gerd note that you might need to do a `make distclean` as git clean doesn't clean submodules
(or make realclean if you don't want to reconfigure)
not_gerd feels totally blameless 16:19
it's all the other guys who merge my code without sufficient testing ;)
16:54 cognominal joined 17:20 colomon joined 18:20 FROGGS joined 19:13 dalek joined
FROGGS ../moarvm nqp.moarvm t/nqp/59-nqpop.t 19:29
Internal error: invalid thread ID in GC work pass
diakopter augh
FROGGS that happens when I comment line 116 till the end in the test file
diakopter that's an interesting one
jnthn Well, it's just memory corruption. 19:30
FROGGS if I run it like it is I get a segfault in MVM_string_substring
yeah
I guess getting the GC right everywhere is the hardest part 19:32
jnthn Yeah. Though at least by the time we get it into a user's hands, we'll have used it plenty ourselves to run non-small things... 19:33
diakopter If I hadn't mucked with it, it'd be flawless ;)
jnthn Probably not :P 19:34
diakopter giggles at jnthn using allison's definition of "user"
FROGGS what I dont understand is that in bytecode.c for example, there a a bunch of functions that allocate and there is no MVMROOT and no gen2_set... 19:35
diakopter (/me agrees with allison's definition/usage of 'user', 'shipping', 'usable')
(in case anyone was wondering)
FROGGS but at least I think I understand know *why* exactly we need MVMROOT 19:37
diakopter "inform the gc of a pointer it might need to update if it moves the object it points to" 19:38
FROGGS right, and that a gc run is triggered by a malloc for example
diakopter well, MVM_gc_allocate, but yeah 19:39
FROGGS so having a malloc in the middle of a function that plays with pointers without things like mvmroot is bad
diakopter right
FROGGS diakopter: malloc too, no?
diakopter no
FROGGS hmmmm
diakopter mallocs we don't care about
FROGGS that might explain it
diakopter can't manage that memory.. 19:40
benabik malloc is non-GC memory
FROGGS ahh, so it is only about MVM_gc_allocate beause that allocates in from- / tospace?
diakopter until I write the replacement malloc that's tons and tons faster :)
FROGGS hehe
diakopter (jnthn, don't worry, I'll fork moarvm for that one) ;) 19:41
(kidding, just a branch)
(until it's proven)
FROGGS (kidding, doing it in master)
:P
benabik Re-writing malloc feels so... unnecessary. Even if you don't like the system malloc for whatever reason there are lots of existent solutions, like dlmalloc 19:42
diakopter well, there are a couple advantages I've thought of 19:43
one is that you can make the memory slightly more managed, so it can be moved or even resized
(while still retaining the same api) 19:44
it's just extending the gc to be able to handle "memory that shouldn't be moved", unless I say it's ok 19:45
er, move the " there
another benefit is integrating that with the ability to "pin" other "managed" memory 19:46
(I mean, if we really want to be able to implement C#... </heresy>)
benabik Extending the GC to handled pinned memory is probably useful. Replacing malloc with it? I dunno.
You'd have to root every single bit of it. 19:47
diakopter the system malloc is usually far from lockless, and most cases of malloc (small allocations) really don't need to be so threadsafe
no, because this sort of memory would be where you say "don't worry, I'll manually root any pointers I put in this memory anyway" 19:48
(just like we do with existing malloc'd regions)
benabik Asking the GC to handle memory you don't want to garbage collect seems like wasting its time. 19:49
diakopter but what I'm saying is it wouldn't use the gc's time
because nothing additional would be done during a gc run
we already have a permgen of sorts 19:50
benabik I thought gen2 was just collected infrequently.
diakopter that memory doesn't really move (well, if it's allocated in the main thread)... until we start compacting
it's collected, but not compacted/moved
benabik Right. So s/malloc/gen2alloc/ means that gen2 gets a pile of memory it shouldn't traverse and must always mark as used. 19:51
diakopter not always mark as used; it has an inline linked list
.. which I think is a very innovative invention... I haven't read about it anywhere else anyway 19:52
(jnthn's idea of threading linked list pointers through the object slots themselves) 19:53
benabik So you replace free with "remove from GC list and it will be collected eventually"?
diakopter free()? no
has anyone else ever seen that done? 19:54
benabik? sorear? not_gerd? is this just a common thing I haven't yet learned?
(jnthn too)
benabik fails to see the point of adding non-swept, non-marked memory to a mark/sweep collector's pools.
Using object headers to store GC meta-data is pretty old. 19:55
diakopter no..
such as.. you have an array of pointers
and you interpret pointer values to other slots in the array as having a special meaning different from normal pointers
(this slot is free; here's the pointer to the next free slot) 19:56
you can make a multiple producer, single consumer threadsafe queue that way
benabik array of pointers being the GC's list of objects? 19:57
diakopter then if your allocation system only locks pools/slabs/lists of particular slot sizes, it limits contention of the locks dramatically
no, the actual memory area
I'm doing a poor job explaining several things at once 19:58
probably should abort until I have it better organized
Util: my memory is very very poor.. can you remind me, did we meet at austin? 19:59
Util: I was reading #parrotsketch logs and saw your name there
Util diakopter: Yes, we met in Austin. 20:00
diakopter can you remind me who you are? :(
Util diakopter: Pic here: www.yapcna.org/yn2013/user/1813 20:01
Util is Bruce Gray
diakopter oh, you helped me when I had that anxiety attack
or exhaustion, or whatever it was 20:02
Util diakopter: Either my memory fails me, or I did not register it as anxiety attack
diakopter I over-exerted my shoulder and was .. extremely exhausted 20:03
the pain hit me very hard
Util That starts to ring a bell. How did I help? 20:04
diakopter I was resting in the hallway and someone asked you to make sure I made it to someone's car to get to the dinner
Util Ah, yes. You are correct. I was glad to help. 20:05
diakopter yes, thank you
sorry to keep typing so quickly and changing subjects... just I should mention: someone gave a comment to my talk - that I obviously hadn't slept for weeks and it severely detracted from my presentation 20:06
in case you're here... I wanted to reply - I hadn't been getting full nights of sleep, but I had been sleeping. Also, I didn't think the talk was that bad, and especially that it didn't come through in how I spoke. 20:07
anyway.. back to debugging this branch. 20:08
jnthn: well now this is strange... now it seems to be trying to free an STable in a normal GC run 20:10
not_gerd: ping 20:14
jnthn back-ish... 20:20
Util diakopter: I am not listed as being in your talk ( www.yapcna.org/yn2013/talk/4734 ), but I was there for all but the first 10 minutes. 20:23
I just remember trying to soak up the knowledge; no flaws come to mind.
They just started loading the Monday YAPC talks yesterday, so soon you should be able to check your performance for yourself :)
www.youtube.com/user/yapcna/videos
jnthn bytecode.c almost certainly wants to be running with gen2 allocation
Util heads to Atlanta.pm meeting (2 hours away)
jnthn Didn't we fix that the other day? :) 20:24
diakopter jnthn: well you mentioned it 20:26
jnthn I thoght I read a patch but maybe I dreamed it? 20:27
diakopter not from me
FROGGS jnthn: github.com/MoarVM/MoarVM/commit/e3...67774a86f8 20:28
jnthn: but create_code_objects might need that too, right? 20:29
diakopter I recommend making it a counter
jnthn oh, is that not surrounding the whole thingummy?
grr, I should just read the code...
jnthn is REALLY looking forward to sleeping in on Saturday 20:30
FROGGS has not seen a thingummy :o)
jnthn FROGGS: no, it looks correct I think...
FROGGS k 20:31
jnthn It covers the whole bytecode laoding process I think
diakopter jnthn: oh lolz. I forgot to check the 'dead' value.
jnthn Please try to avoid creating undead... :P
20:33 not_gerd joined
not_gerd diakopter: pong 20:33
arVM: 90b3b0d | diakopter++ | src/ (9 files):
stable freeing and global destruction
arVM: 98fcc94 | diakopter++ | src/gc/ (2 files):
gen2 needs a bit different
arVM: 8d4a756 | diakopter++ | src/gc/collect.c:
bugfix.
diakopter oops, didn't mean to push necessarily
jnthn: you saw my note about the serialize branch? 20:40
jnthn diakopter: That it's 90%ish there and needs my TLC? 20:41
diakopter yeah.. your touch was always going to be necessary anyway.. you're much better at debugging from this stage than I am 20:42
jnthn *nod* 20:44
20:53 foo_bar_baz joined
diakopter jnthn: oo you did a double free 20:57
jnthn FREEEDOOOOM
oops :)
FROGGS free early - free often 20:58
jnthn Where, ooc? :)
diakopter well. 21:00
erm, maybe not 21:02
thought it fixed it
dalek arVM: 98b2f4e | diakopter++ | src/6model/reprs/P6opaque.c:
li'l better, ish.
21:03
not_gerd is working on 'improving' validation.c 21:05
diakopter well lit's definitely *some* free() in a repr.
*it's 21:06
not_gerd: thanks :P
not_gerd I haven't quite convinced myself that the end result will actually be better
I'm trying to get annotations such as gist.github.com/gerdr/8df9c69e83dc3a83b886 to work
21:07 cognominal joined
diakopter not_gerd: what do those mean 21:13
not_gerd we annotate ops with single-char labels - eg .r is just a plain annotation 21:14
:j means any .j following it are special
+a and -a delimit a block that may only contain *a
jnthn Will this end up much more complex than just hardcoding the rules? ;) 21:15
jnthn sometimes pretends to be an ordinary person who doesn't like abstraction... :)
not_gerd jnthn: right now, it is because I started from the existing factoring
control flow turned... 'interesting' 21:16
jnthn :)
not_gerd I believe I know how to make it right, though
jnthn git diff
bother...
21:34 donaldh joined
not_gerd good night 21:57
diakopter NFA! 21:59
jnthn It...has a bug? 22:00
:)
diakopter yeah, oh. 22:02
jnthn Not F**king Awesome /o 22:03
\\
oh, that reminds me, I'm teaching regexes in the morning and should maybe rest... :) 22:04
diakopter o/
we haz global destruction 22:06
vs really doesn't like it when you pass a non-pointer to free() 22:14
dalek arVM: 0c8cf07 | diakopter++ | src/ (8 files):
various memory cleanup cleanups
22:15
arVM: d39e357 | diakopter++ | src/gc/ (3 files):
free STables in the global destruction...
22:27
22:29 benabik joined 22:53 jnap joined 23:01 tadzik joined
dalek arVM: 0fa95ec | diakopter++ | / (3 files):
fix MVMDEBUG dump output capability for nqp-cc make test...
23:31
diakopter .tell jnthn adding global destruction didn't measurably change the duration of selftest 23:33
yoleaux diakopter: I'll pass your message to jnthn.
diakopter .tell not_gerd --optimize doesn't recompile the 3rdparty stuf... should it? 23:34
yoleaux diakopter: I'll pass your message to not_gerd.
diakopter masak: heh, 88 garbage collections in 240ms 23:39
(unoptimized)
5-thread, even 23:40
heh, the gc debug log generated a 10-million line debug out file. for 152 gc runs. 23:52
800MB. 23:57
masak :) 23:58
masak sleeps