Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2015-05-14

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

All times shown according to UTC.

Time Nick Message
00:35 colomon joined #moarvm
01:19 timotimo i'm not 100% sure where a dispatcher would come from given an inlined spesh graph
01:19 timotimo because there's a takedispatcher in each of the inlined BB's (single BB's, which is pretty good IMO) and the only thing i can see it do is reset cur_dispatcher to be VMNull
01:20 timotimo the graph it's inlined to doesn't do any *dispatcher things, though ... the only thing i can think of is that it comes from an onlystar proto perhaps?
02:28 colomon_ joined #moarvm
02:32 colomon_ joined #moarvm
03:45 FROGGS_ joined #moarvm
05:01 timotimo i'm having trouble sleeping, it seems ... and thoughts about how stuff i've wanted in moar could work have been swirling around in my head
05:02 timotimo in particular, right now i'm thinking about what i'd call "deopt bridges"
05:02 timotimo which would be a bit of code we could generate that a deopt would jump to before doing the actual frame deopting/uninlining
05:03 timotimo for example: we've still got a const_s "&infix:<==>" in our code even though we inlined the call to that code, because if we need to deopt, we require that string to be in that particular register
05:04 timotimo so we could detect that a particular guard is keeping some registers alive and move that const_s into the "deopt bridge", then change the guard into a guard variant that jumps to a BB instead of deopting outright and then we add (or move?) an identical deopt annotation to the end of the bridge so that the deopt target bytecode address is correct
05:05 timotimo though it occurs to me that maybe instead of duplicating and switching the instructions for guards, we may want to build a deopt annotation that jumps to a BB instead of doing the deopt
05:09 dalek moarvm.org: b1da568 | timotimo++ | roadmap.html:
05:09 dalek moarvm.org: [roadmap] tick off the repr op devirtualization task
05:09 dalek moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/b1da568dc6
05:13 jepeway joined #moarvm
05:14 timotimo a reason we may not want to just paste the contents of inlined BBs into their caller's bodies is that they have an "inlined" flag ... but perhaps we only need that flag because we don't fix up enough of our helper data structures yet to keep the dead bb elimination from throwing them out wrongfully?
05:16 dalek MoarVM: c76197c | timotimo++ | src/spesh/dump.c:
05:16 dalek MoarVM: display "Inlined" flag in the spesh log
05:16 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c76197cdcc
05:17 timotimo does something depend on the dominance children staying the same during a run through the optimization?
05:51 timotimo it's a bit upsetting to see &prefix:<++> be inlined by neither the static optimizer nor spesh ...
05:51 timotimo add insult to injury, a sink check is emitted for "++$pos"
06:18 TimToady hmm, usually it's $pos++ that needs the sink check, to turn it into ++$pos
07:02 zakharyas joined #moarvm
07:43 dalek MoarVM: 1882d3e | FROGGS++ | src/6model/reprs/NFA.c:
07:43 dalek MoarVM: fix thinko in NFA_EDGE_CODEPOINT_M_NEG, skids++
07:43 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/1882d3ecd9
07:48 jepeway joined #moarvm
08:05 vendethiel joined #moarvm
08:27 brrt joined #moarvm
08:27 brrt \o
08:27 brrt timotimo++ i think that is an awesome idea
08:28 brrt second point - if you're sure it's not caffeine related, that insomnia of yours may become problematic in due course, and if it *is* caffeine related, well...
08:28 brrt third point, i just got mail my grant app has been accepted :-)
08:29 brrt but yeah, a deopt bridge would be awesome
08:29 brrt not entirely sure how to do it yet
08:30 jnthn brrt: YAY!
08:32 brrt yes, that is what i thought too :-D
08:32 brrt i have to run an errand, bbiab
09:01 dalek MoarVM: ea10ed6 | jnthn++ | src/6model/reprs/MVMMultiCache.c:
09:01 dalek MoarVM: Add a missing barrier.
09:01 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ea10ed6762
09:01 dalek MoarVM: 0334215 | jnthn++ | src/core/frame.c:
09:01 dalek MoarVM: Fix a typo.
09:01 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/0334215af8
09:11 masak brrt++ # grant app accepted \o/
09:11 brrt joined #moarvm
09:12 * brrt back
09:14 FROGGS[mobile] joined #moarvm
09:14 FROGGS[mobile] \o/
09:20 dalek MoarVM: 673b113 | jnthn++ | src/core/frame.c:
09:20 dalek MoarVM: Tweak error reporting of wrong outer frame.
09:20 dalek MoarVM:
09:20 dalek MoarVM: REPR will always be MVMStaticFrame, but it's useful to include the
09:20 dalek MoarVM: compilation unit unique ID.
09:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/673b113475
09:47 dalek MoarVM: 10d00bb | jnthn++ | src/core/frame.c:
09:47 dalek MoarVM: Include cuuid of invokee in error also.
09:47 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/10d00bbd2f
09:47 jnthn I have weak evidence that our frame pool is at the heart of various threading issues.
09:48 jnthn At least, disabling it makes an async echo server run and run, rather than explode after a while.
09:48 nwc10 there must be a joke something like:
09:49 FROGGS ohh, a sigspace joke :o), gotcha
09:49 nwc10 ABBA: "There is nothing we can do"
09:49 nwc10 ABA: maybe this
09:49 jnthn I'm not sure if this one is ABA :)
09:49 nwc10 sorry for the pause - Unicode wasn't helping me
09:50 jnthn But yeah, with the frame cache disabled a whole load of different failures go away
09:51 FROGGS what's aba?
09:51 nwc10 something I only learned about last week: http://en.wikipedia.org/wiki/ABA_problem
09:53 FROGGS ahh, interesting
09:53 FROGGS it is all about assumption, isnt it?
09:55 FROGGS just told a colleague yesterday that believing that a condition must be true (in a certain SAP report generating script) is not a good way to debug something
09:55 jnthn With the frame cache it would always bomb with a variety of exceptions after around 5,000-25,000 requests
09:55 FROGGS "I don't know what is going on, but I don't need to check that because that condition cannot be false"
09:55 jnthn With it disabled I've had it make it well over 100,000 twice in a row and still running.
09:55 nwc10 FROGGS: I thought it was more about Ascension today. Assumption is 15th August (and a Saturday, so not a useful holiday) :-)
09:56 FROGGS :o)
10:04 brrt that is a pretty interesting result jnthn :-)
10:05 jnthn Doesn't seem to matter whether I disable placing in the pool or taking out of the pool, either fixes it.
10:06 jnthn The handling of the pool decidedly isn't thread safe, but otoh it should only ever be accessed by a single thread.
10:07 brrt now there's an assumption
10:08 jnthn Indeed.
10:11 FROGGS ahh, now I know what I can do until jnthn got enough of concurrency... I wanted to add tests for LTM
10:17 jnthn Aha...I may have figured what's going on.
10:18 FROGGS ohh, me is curious
10:18 vendethiel joined #moarvm
10:18 * FROGGS loves jnthn++'s ommit messages
10:18 FROGGS commit*
10:19 jnthn In summary: when we do GC, we only stop the world for part of the time (that is, until we agree we saw all of the living things); then we unblock things and threads are free to do the final bits of the GC themselves (finalizing the collected objects) since they may have very different amounts to do at this stage
10:19 brrt when you create a new bug in a commit, it could be called an 'omit' message
10:20 jnthn If thread X is blocked during GC due to waiting on IO, a lock, etc. then work stealing happens
10:20 jnthn The thread that work-stole is responsible for GCing the threads it stole
10:22 jnthn The assumption about the frame pool gets broken I think because in some cases, a thread stops blocking on I/O and starts executing, but in another thread we're sweeping its nursery, and collecting closures, and since we "impersonate" the thread context we're collecting on behalf of then we end up with concurrent mutation of the frame pool
10:22 jnthn And thus corruption of it.
10:24 brrt that seems.. plausible
10:24 nwc10 I'm a bit confused as to why this only affects the frame pool. Why other stuff is robust against/unaffected by this class of unlawful concurrency
10:25 brrt can you force the work-stolen thread to block until gc is done
10:25 jnthn nwc10: Largely because many other places where the concurrency can crop up have been designed to cope with it.
10:26 jnthn nwc10: The frame pool is held per thread
10:26 * brrt lunch &
10:26 jnthn nwc10: I can't think of a single other case anywhere that has an object we finalize hold per-thread resources.
10:27 nwc10 OK
10:27 jnthn The frame pool is decidedly an optimization
10:28 jnthn Unfortunately, this time it got caught cheating.
10:37 * jnthn hasn't look all that closely at the frame pooling before
10:37 jnthn (Didn't impl it)
10:38 jnthn It doesn't acocunt for if a frame is hot, and so everything we ever invoke - even if it's only run once ever - gets a remembered pool entry
10:39 jnthn Turning it off and doing a "loop { }" shows it accounts for over 1.4MB worth of memory in a bsae Perl 6 process
10:41 * jnthn does some timing measurements to see what it *wins*
10:41 jnthn Because it was written before we had our own fixed size allocator
10:41 timotimo cool, i like this news of bug finding
10:42 jnthn uh
10:42 jnthn It wins...nothing by my measurements.
10:43 jnthn o.O
10:43 timotimo huh, that's ... wow
10:43 jnthn I can imagine in more heavily threaded code it'd win more
10:43 jnthn Except our heavily threaded code is busted 'cus of it.
10:43 timotimo brrt++ # grant proposal accepted \o/
10:44 jnthn timotimo: You got a moment to test what I'm seeing also?
10:46 timotimo OK, please instruct me
10:46 jnthn OK
10:46 jnthn disable spesh inline for these so we actually measure invocation time
10:46 jnthn I'm trying with "sub foo() { sin(1e0) }; for ^10000000 { foo() }"
10:46 jnthn Which is just loads of calls
10:47 jnthn Tiem it
10:47 jnthn And then apply this patch to Moar, and time it again:
10:47 jnthn https://gist.github.com/jnthn/219169639acd3cb91890
10:51 timotimo that patch improves performance
10:51 timotimo by a very tiny amount
10:51 jnthn Uh, yes, I was thinking "noise" but all my measurements from it were a tiny bit below those I took beforehand.
10:52 timotimo i made many measurements; most with the patch were below 4.00 user and most without it were above 4.00 user
10:53 jnthn Wowser.
10:54 timotimo and then there's almost a megabyte saved in maxrss
10:54 jnthn So I think we may have an easier option than "fix it"
10:54 jnthn ;)
10:54 FROGGS "rip it"
10:54 timotimo rip in peace, frame-pool
10:54 jnthn To be fair, it probably *did* help a lot when it was put in and we used malloc
10:55 timotimo maybe at some point in the future someone'll dig it back up, figure out why it doesn't help performance, and re-enable it with a fix
10:55 timotimo ah, that could very well be
10:56 timotimo another musing i had while between awake and asleep was this: since we know inlined pieces of spesh graph are "mutually exclusive", so are their registers. in theory, the registers could be re-used, so that the frame doesn't grow to the sum of all registers used, but instead the number of registers of the inliner plus the number of registers of the biggest inlinee
10:56 timotimo but then i noticed registers are typed, so they can't just be re-used without care
10:57 timotimo and that means there'd have to be some kind of register allocator, but also more work done when uninlining
10:57 timotimo i haven't actually looked at how uninlining works, so i don't know if the same approach with the deopt bridge code-gen would help with that exact situation
10:58 jnthn It'd be tricky 'cus of the uninlining, yes
10:58 timotimo our deopt is super cheap, but it costs us in other places
11:01 timotimo are you +1 on introducing a facts flag that points out if a register had its "users" counter "inflated" because of deopt?
11:03 jnthn What will we use it for?
11:03 timotimo i don't have a design yet, but i thought it would/could help with the deopt bridge
11:03 jnthn OK, I didn't understand that quite yet ;)
11:03 timotimo can you shoot questions my way to help figure it out?
11:05 jnthn Not while I'm in the middle of cleaning up the frame pool :P
11:05 timotimo of course
11:08 jnthn But yeah, I was seeing the "invoking a null object", "can't flatten null string" and, most often, "wrong outer" errors with the IO::Socket::Async ping server before now.
11:08 jnthn And it seems to run rather better at this point.
11:08 FROGGS that sounds awesome
11:08 jnthn It's leaking madly, but I know the async task pool leaks.
11:09 jnthn It's the same place I need to look at to fix the "pushes CPU load up to a full core" bug
11:09 timotimo at the moment i have a usleep(50) in that tight code that makes the cpu usage pretty much perfect
11:09 timotimo as in: almost 0 if moar's not doing anything
11:15 timotimo i realize it's not what we want, of course
11:15 jnthn *nod*
11:16 jnthn Yeah, the thing we have now is "I want something that works at all so we can explore the Perl 6 API for these things"
11:16 timotimo and that flag for the facts will at least show us - in the spesh dump - what registers have possibly been kept alive because of deopt safeness
11:16 timotimo these things mean the async/tasks/eventloop things?
11:16 jnthn Right
11:17 timotimo mhm
11:17 jnthn Well, Supply and so on.
11:17 jnthn We came out ahead overall, 'cus TimToady++ could get on with getting things named decently, and lizmat++ implemented us loads of extra functionality and tests.
11:17 * timotimo writes a bit of code to show flags as a bunch of names on top of the number
11:18 jnthn But it still left a good bit to clear up.
11:18 timotimo because /me isn't very good at reading bitmasks as numbers in decimal
11:19 timotimo should a coderef argument be dumped as the cuuid + filename + linenumber of the ref'd MVMCode object and perhaps also that of the ->outer?
11:25 jnthn Not sure about the outer bit, but the other bits may well be useful
11:25 timotimo i'll probably just note if it has an outer or not
11:25 dalek MoarVM: 46899d2 | jnthn++ | src/core/ (5 files):
11:25 dalek MoarVM: Remove the frame pool.
11:25 dalek MoarVM:
11:25 dalek MoarVM: Before we had a fixed size allocator (and so malloc'd frames), it was
11:25 dalek MoarVM: a good win. These days, it seems to have no measurable effect on speed
11:25 dalek MoarVM: but costs around 1.4MB of memory for Rakudo. More seriously, however,
11:25 dalek MoarVM: it was vulnerable when the GC was freeing up closures in a thread it
11:25 dalek MoarVM: stole work from (because it used to be blocked), and that thread then
11:25 dalek MoarVM: woke up and started executing. This could have been fixed, but given
11:25 dalek MoarVM: the current frame cache design not seeming to help a great deal anyway
11:25 dalek MoarVM: the easier fix is to remove it.
11:25 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/46899d2283
11:25 brrt joined #moarvm
11:26 timotimo sweet
11:27 nwc10 5 files changed, 19 insertions(+), 139 deletions(-)
11:27 timotimo the best code is removed code, right?
11:29 timotimo r29(7): usages=4, flags=269 KnTyp Dcntd Concr LogGd
11:29 timotimo i find this helpful
11:29 nwc10 the bugs aren't in the code that isn't there
11:30 jnthn OK, so now I've got the IO::Socket::Async ping server to survive into the hundreds of thousands of requests with a single thread hammering it, time to work out why it gets upset when two request threads hammer it. :)
11:30 jnthn Well, actually I think lunch first...
11:31 timotimo bon appetit :)
11:31 timotimo (om nom bugs)
11:32 dalek MoarVM: 01ecd8a | Timo++ | src/spesh/dump.c:
11:32 dalek MoarVM: spesh dump shows little words for fact flags
11:32 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/01ecd8a819
11:33 timotimo oh
11:33 timotimo mind if i re-push that commit? the author mail is wrong
11:35 dalek MoarVM: 3bed66e | timotimo++ | src/spesh/dump.c:
11:35 dalek MoarVM: spesh dump shows little words for fact flags
11:35 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/3bed66e07f
11:35 * timotimo does it; it was quick enough i bet
11:35 vendethiel brrt++ # grats for the grant!
11:35 timotimo \o/
11:43 timotimo sorry for the rude push
11:47 travis-ci joined #moarvm
11:47 travis-ci MoarVM build errored. Timo 'spesh dump shows little words for fact flags'
11:47 travis-ci http://travis-ci.org/MoarVM/MoarVM/builds/62536504 https://github.com/MoarVM/MoarVM/compare/46899d228351...01ecd8a8196f
11:47 travis-ci left #moarvm
11:47 timotimo d'oh?
11:48 timotimo yeah, travis got rude'd
11:48 FROGGS aye
11:50 timotimo src/spesh/dump.c:231:46: warning: trigraph ??) ignored, use -trigraphs to enable [-Wtrigraphs]
11:50 timotimo append(ds, "???)");
11:50 timotimo why does this feel like a "blast from the past" to me?
11:54 timotimo getcode r1(1), coderef(gen/moar/stage2/NQPCORE.setting:92)
11:55 timotimo takeclosure r1(2), r1(1)
12:05 dalek MoarVM: 8640ee1 | timotimo++ | src/spesh/dump.c:
12:05 dalek MoarVM: speshdump coderefs as filename + line number and "(closure)"
12:05 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/8640ee1ee8
12:06 nebuchad` nwc10: thanks for the ABA wikipedia link, I finally ends in the Actor model page and rediscover what I liked in Erlang ;-)
12:43 vendethiel if one wanted to figure out how moarvm works, should nqp be the starting point?
12:43 vendethiel (some things are confusing, i.e. grepping for an opcode only finds matches in src/jit
12:43 vendethiel )*
12:44 timotimo ah
12:45 timotimo nqp gives you an overview of how moar ticks with relatively little "magic" in the way
12:45 timotimo what exactly are you grepping for for the opcodes?
12:45 timotimo in interp.c they are "implemented" (most of them as calls to the implementing functions, actually)
12:46 timotimo and in there, it looks like "OP(abs_i)"
12:46 vendethiel timotimo: ah, I just looked at ops.h and grepped some of the #define s
12:46 timotimo ah
12:46 timotimo those are the generated ones :)
12:47 vendethiel ...I'll read the jit code later :P
12:47 timotimo hehehe
12:47 timotimo jit isn't necessarily the right place to start, i agree :)
12:47 timotimo anything in particular you'd like to hack on?
12:48 vendethiel not sure yet, probably get a feel on how it all works
12:48 timotimo OK
12:48 timotimo well, hit me up if you have any simple questions :P
12:48 timotimo but i'll be AFK for a bit first
12:48 timotimo also, are you interested in #perl6-gaming?
12:49 * jnthn back
12:49 vendethiel I'll try again to get cairo working, I guess :-)
12:49 timotimo cool
12:49 timotimo i figured out i probably want to supply bindings to more SDL2 related libraries
12:49 timotimo like SDL2::gfx for some shape drawing and stuff
12:49 vendethiel I wrote a toy register-based vm (in c) for $school, I want to give a stack-based VM a try before dwelving deeper into "real" ones
12:50 vendethiel .oO( a real virtual machine )
12:50 timotimo moarvm is basically register-based
12:51 vendethiel that's how it looked in interp.c, at least
12:52 vendethiel do we have tools to dump mast/qast once parsed?
12:52 timotimo for qast, you want to --target=ast and --target=optimize
12:52 timotimo for mast, you'd want to have a .moarvm file and moar --dump that
12:53 vendethiel (is that a human-readable format, or just moarvm bytecode?)
12:53 timotimo human-readable
12:53 vendethiel amazing, thanks
12:53 timotimo i mean --dump is human-readable, .moarvm obviously not :)
12:53 vendethiel yes, I guess the .moarvm files are the ones actually used
12:54 timotimo you already seem to know alot
12:54 vendethiel not really, know. don't worry, I'll ping you with my stupid questions :P
12:54 vendethiel s/know/no/
12:54 timotimo OK. well you should get to know alot, alot is very nice
12:55 vendethiel alot++
12:55 timotimo i like reading the spesh log output much more than i like reading moarvm dumps; they look similar, but the spesh log is in a control flow graph format and single static assignment
12:57 timotimo env MVM_SPESH_LOG=/dev/stdout perl6 -e 'say 1' gives you a whole crapton of output that you can use as an example to get a feel for it, if you want
12:59 vendethiel noted, thanks
13:01 FROGGS m: 'äaÄAÁbbBB' ~~ m:m/A+|bb|a/ # :o(
13:01 camelia rakudo-moar 2ea008: OUTPUT«(signal SEGV)»
13:02 dalek MoarVM: c65fd72 | FROGGS++ | src/6model/reprs/NFA. (2 files):
13:02 dalek MoarVM: handle LTM for ignorecase+ignoremark
13:02 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/c65fd7295e
13:02 brrt joined #moarvm
13:03 arnsholt timotimo: Holy output batman! That's a lot of stuff =)
13:13 FROGGS ahh, now I know why it segfaults
13:20 dalek MoarVM: 751a1d9 | FROGGS++ | src/6model/reprs/NFA.h:
13:20 dalek MoarVM: update NFA_EGDE_* constants
13:20 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/751a1d9726
13:35 vendethiel what's the 'a' block_id? seems like that's the only "validated" one (in, err, validate_block)
13:39 timotimo seems like some kind of "type" marker for different things
13:39 timotimo like, an 's' there would stand for a spesh op
13:42 vendethiel if (val->cur_mark && *(val->cur_mark) == 's') fail(val, MSG(val, "Illegal appearance of spesh op"));
13:42 vendethiel right
13:43 vendethiel why is *(val->cur_mark) sometimes used, and val->cur_mark[0] some other times?
13:44 FROGGS just because you can probably
13:55 jnthn grmbl. Seems removing the frame pool has exposed a bug that affects pre-comp
13:56 jnthn Could somebody else try t\spec\integration\precompiled.rakudo.moar with Moar HEAD to verify?
13:57 timotimo # When invoking cuid_3563_1431474887.30505 'STORE', provided outer frame 0x5139910 (cuid_6_1431611824.40465 '<load>') does not match expected static frame 0x16d8b60 (cuid_3686_1431474887.30505 '')
13:57 timotimo this?
13:57 jnthn Yeah, exact same, except addresses
13:57 timotimo sure
13:58 nwc10 http://paste.scsys.co.uk/478957
13:59 nwc10 so yes, I also see that
13:59 jnthn yeah, and just backed up a few commits and it's gone
13:59 jnthn didn't re-comp
13:59 jnthn So it's something during loading
13:59 jnthn Most odd
14:00 timotimo i wonder if we were sometimes hitting this exact same bug before, but now we are able to catch it with a test file?
14:00 jnthn Very possibly
14:00 timotimo that's progress, then :)
14:00 jnthn I suspect the frame pool opt was hiding the bug.
14:00 jnthn Yeah
14:00 jnthn Seems I get all the fun today. Conc bugs and pre-comp bugs :P
14:01 jnthn Planning to work on the annoying one with the handles too
14:01 timotimo sounds satisfying :)
14:01 jnthn But, should un-bust this first given it blocks bumping MOAR_REVISION.
14:01 danaj joined #moarvm
14:01 timotimo well, froggs already bumped moar_revision for the NFA changes up there
14:01 jnthn oops
14:02 jnthn Then everyone'll be seeing the issue in spectest
14:02 FROGGS :S
14:02 jnthn No biggy. I'll bump again once I figure it
14:02 jnthn It's a really odd one.
14:02 timotimo i'll be afk for a little bit and maybe then i can figure out the "deopt bridge" thing in better detail with you?
14:03 jnthn Maybe so, though I promised FROGGS some time to look at the serialization of the module DB today also...
14:03 timotimo right, that seems more useful at the moment :)
14:03 timotimo since froggs is so close to delivering something, as compared to me, who still has some design work to do
14:03 timotimo o/
14:04 [Coke] brrt++ # grant accepted.
14:06 FROGGS jnthn: btw, when is the best time for you to help me wrt serialization?
14:07 jnthn FROGGS: This evening maybe?
14:07 [Coke] (the best code is removed code, amiright?) --- I heard this in the voice of one of the guards in skyrim. Perhaps I've been playing too much. :)
14:08 FROGGS jnthn: that'd be lovely
14:08 jnthn OK, cool
14:12 jnthn aha
14:12 jnthn Seems to be a premature reclamation
14:13 nwc10 ASAN doesn't complain
14:13 nwc10 was building to try with valgrind
14:14 jnthn It likely won't
14:14 jnthn However if you flip fixed size allocation into debug mode it probably might
14:15 nwc10 ah OK. I think I have the patch to do that in git stash somewhere
14:17 jnthn *nod*
14:17 jnthn It's certainly a deserialized context
14:24 brrt joined #moarvm
14:27 dalek MoarVM: 27ee300 | jnthn++ | src/core/frame.c:
14:27 dalek MoarVM: Fix ref-count management of deserialized contexts.
14:27 dalek MoarVM:
14:27 dalek MoarVM: They should get a count purely out of the SC holding them, otherwise
14:27 dalek MoarVM: we can end up reclaiming them prematurely.
14:27 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/27ee30026f
14:32 nwc10 jnthn: shouldn't it be possible to spot that off-by-one error, if the refcnt dec code goes "-1? WTF! abort()" ?
14:34 jnthn nwc10: I don't think it woulda in this case
14:34 nwc10 OK
14:34 jnthn nwc10: The memory would get re-used for another frame and the count would be positive again
14:34 dalek MoarVM: df18912 | ven++ | src/core/validation.c:
14:34 dalek MoarVM: Fix "instruction" typo in error message
14:34 dalek MoarVM:
14:34 dalek MoarVM: Also replace a `*(val->cur_mark)` with `val->cur_mark[0]` for consistency.
14:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/df189124ff
14:34 dalek MoarVM: bfa81c6 | FROGGS++ | src/core/validation.c:
14:34 dalek MoarVM: Merge pull request #217 from vendethiel/patch-1
14:34 dalek MoarVM:
14:34 dalek MoarVM: Fix "instruction" typo in error message
14:34 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/bfa81c6842
15:05 FROGGS[mobile] joined #moarvm
15:25 FROGGS[mobile]2 joined #moarvm
15:31 dalek MoarVM: ead50fd | jnthn++ | / (9 files):
15:31 dalek MoarVM: Provide a "never repossess this" mechanism.
15:31 dalek MoarVM:
15:31 dalek MoarVM: Used for things that we should never repossess. Will be used to avoid
15:31 dalek MoarVM: the bugs that result from PROCESS in Perl 6 getting repossessed.
15:31 dalek MoarVM: review: https://github.com/MoarVM/MoarVM/commit/ead50fd658
15:47 synbot6 joined #moarvm
16:45 vendethiel joined #moarvm
17:15 vendethiel joined #moarvm
17:41 vendethiel joined #moarvm
18:12 vendethiel joined #moarvm
18:58 vendethiel jnthn:I have a question related to lexical scope and precompilation
18:58 vendethiel how do you make, say, lexical scope of macros work correctly with precomp
18:59 vendethiel module A: my $a; macro D($x) { $a = $x; }; # or something
19:02 jnthn Is it a different case from where one module gets a closure from another module and stashes it away somewhere?
19:27 masak don't think so.
19:28 jnthn Then it works 'cus you can serialize a closure taken during module B's compile time in module B's precomp blob, even if it's of a code object from module A
19:29 jnthn It's just another kind of cross-reference, like objects.
19:41 vendethiel that's interesting. I kinda want to read more about that
19:41 vendethiel I wanted to write a toy language with macro, and separate parsing/codegen/vm, but couldn't figure out how to get macros into the mix :)
19:43 [Coke] I think masak already wrote that language.
19:43 vendethiel no, because masak wrote that language.
19:43 vendethiel (yes, I put that dot to align it :P)
20:01 dalek MoarVM/jsoff: 4b48730 | FROGGS++ | src/core/interp.c:
20:01 dalek MoarVM/jsoff: add MVM_get_idx_of_sc to debug output
20:01 dalek MoarVM/jsoff: review: https://github.com/MoarVM/MoarVM/commit/4b48730e79
20:19 dalek MoarVM/jsoff: 7a34a45 | jnthn++ | src/core/interp.c:
20:19 dalek MoarVM/jsoff: Sketch code we need for allocated SC idx.
20:19 dalek MoarVM/jsoff:
20:19 dalek MoarVM/jsoff: Should factor this "clear SC" logic out.
20:19 dalek MoarVM/jsoff: review: https://github.com/MoarVM/MoarVM/commit/7a34a45650
20:19 dalek MoarVM/jsoff: b4feb1a | jnthn++ | src/6model/sc.c:
20:19 dalek MoarVM/jsoff: Check owning object wasn't disclaimed.
20:19 dalek MoarVM/jsoff:
20:19 dalek MoarVM/jsoff: Some objects are serialized as part of an enclosing object (more for
20:19 dalek MoarVM/jsoff: historical reasons than good ones at this point, alas). Check we did
20:19 dalek MoarVM/jsoff: not clear an SC when doing repossession.
20:19 dalek MoarVM/jsoff: review: https://github.com/MoarVM/MoarVM/commit/b4feb1a3a4
21:34 japhb jnthn++  # concurrency fixes!  \o/
21:39 colomon_ joined #moarvm
21:43 colomon joined #moarvm
22:18 jepeway joined #moarvm
23:53 vendethiel joined #moarvm

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