Perl 6 - the future is here, just unevenly distributed

IRC log for #moarvm, 2017-07-27

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

All times shown according to UTC.

Time Nick Message
01:19 statisfiable6 joined #moarvm
01:19 benchable6 joined #moarvm
01:20 samcv yay. new script to generate the collation C data is much better and shorter and cleaner
01:20 samcv seems to work at least. i have more failures but i quickly checked some of the multi cp sequences and they seem to have passed to i'm guessing the data must be right
01:24 samcv uhm maybe not quite. well getting closer :)
01:52 ilbot3 joined #moarvm
01:52 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
03:06 eater joined #moarvm
05:24 Geth_ ¦ moarvm.org: CharleyPeng1++ created pull request #6: Update roadmap.html
05:24 Geth_ ¦ moarvm.org: review: https://github.com/MoarVM/moarvm.org/pull/6
05:39 brrt joined #moarvm
05:58 samcv reading the "Avoiding Normalization" section of the unicode documentation
05:58 samcv some of these failing are failing because a decomposed character gets different collation keys than a composed one. and so the test is relying on it getting the decomposed ones
05:59 samcv "LATIN CAPITAL LETTER U WITH HORN" + "COMBINING TILDE OVERLAY" compared to "LATIN SMALL LETTER U WITH HORN AND ACUTE" + "COMBINING TILDE OVERLAY".  in unicode, there is a specific order that accent marks go after a character. so the ones closest to the letter go closer to the letter and the ones that are higher/lower than really close to the letter come after based on the canonical combining class of the accent character
05:59 samcv and so because it's a letter U with a horn and acute. it can't reorder the combining tilde overlay because the horn and acute are part of the codepoint
06:05 brrt good * samcv
06:05 samcv hey :-)
06:06 brrt re: perl6 popularity
06:06 brrt at $work, i may have gotten some people enthusisastic about perl6 and moarvm
06:07 samcv going to try decomposing all decomposable characters and just see what happens... then try and figure out what to do about the issue since i don't want to decompose everything
06:07 samcv nice!
06:18 samcv weird. so i'm looking at this and the order of the codepoits they list is not in sorted order. so i don't know
06:18 samcv this is confusing
06:19 brrt hmm, that's odd
06:19 samcv maybe i'll just ignore that test i dunno
06:19 samcv i'll igore it for now at least
06:38 lizmat joined #moarvm
06:41 brrt joined #moarvm
06:46 domidumont joined #moarvm
06:52 domidumont joined #moarvm
07:19 TimToady joined #moarvm
07:43 zakharyas joined #moarvm
07:54 AlexDani` joined #moarvm
07:58 nwc10 jnthn: (as best I can tell from skimming the spectest harness end summary) ASAN makes no comment on moar-frame-extras
08:01 AlexDani` joined #moarvm
08:51 jnthn nwc10: Yay, good to hear :)
08:51 yoleaux 08:09Z <lizmat> jnthn: any thoughts on the performance difference between "1".match(/1/) and 1.match(/1/) ?  ( easily seen in a for ^10000)
08:52 Geth_ ¦ moarvm.org: 5627a7f16f | CharleyPeng1++ (committed using GitHub Web editor) | roadmap.html
08:52 Geth_ ¦ moarvm.org: Update roadmap.html
08:52 Geth_ ¦ moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/5627a7f16f
08:52 Geth_ ¦ moarvm.org: a842bc0de7 | (Jonathan Worthington)++ (committed using GitHub Web editor) | roadmap.html
08:52 Geth_ ¦ moarvm.org: Merge pull request #6 from CharleyPeng1/patch-3
08:52 Geth_ ¦ moarvm.org:
08:52 Geth_ ¦ moarvm.org: Update roadmap.html
08:52 Geth_ ¦ moarvm.org: review: https://github.com/MoarVM/moarvm.org/commit/a842bc0de7
08:57 jnthn 2 more steps to go on the "easy" MVMFrame wins
08:57 jnthn Which will give a pointer reduction each
08:57 jnthn So far 40 bytes (on 64-bit) saved, and callgrind reckons 295 million instructions less during CORE.setting compilation
09:10 brrt nice
09:10 brrt the bug density in the prepare_arglist_and_call is humbling...
09:16 zakharyas joined #moarvm
09:20 Geth ¦ MoarVM/frame-extras: bddafb2452 | (Jonathan Worthington)++ | 5 files
09:20 Geth ¦ MoarVM/frame-extras: Move continuation tags into frame extras.
09:20 Geth ¦ MoarVM/frame-extras:
09:20 Geth ¦ MoarVM/frame-extras: A very small number of frames have them.
09:20 Geth ¦ MoarVM/frame-extras: review: https://github.com/MoarVM/MoarVM/commit/bddafb2452
09:27 Geth ¦ MoarVM/even-moar-jit: 6b7bdd2a9d | (Bart Wiegmans)++ | 2 files
09:27 Geth ¦ MoarVM/even-moar-jit: Stack transfers don't count for toposort
09:27 Geth ¦ MoarVM/even-moar-jit:
09:27 Geth ¦ MoarVM/even-moar-jit: Not that it had any effect, but we thought we needed to do more
09:27 Geth ¦ MoarVM/even-moar-jit: moves than we really did. And also remove the auto-scheduling of
09:27 Geth ¦ MoarVM/even-moar-jit: the call/arg resolution, because these will be handled by the free-
09:27 Geth ¦ MoarVM/even-moar-jit: edges loop a few lines lower anyway.
09:27 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/6b7bdd2a9d
09:27 Geth ¦ MoarVM/even-moar-jit: 4374536973 | (Bart Wiegmans)++ | src/jit/linear_scan.c
09:27 Geth ¦ MoarVM/even-moar-jit: Store range start and end in struct
09:27 Geth ¦ MoarVM/even-moar-jit:
09:27 Geth ¦ MoarVM/even-moar-jit: Not only does this save us from recomputing, it doesn't cost any
09:27 Geth ¦ MoarVM/even-moar-jit: additional storage, since the synthetic-tile position markers are
09:28 Geth ¦ MoarVM/even-moar-jit: now redundants.
09:28 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/4374536973
09:28 Geth ¦ MoarVM/even-moar-jit: fee7630082 | (Bart Wiegmans)++ | src/jit/linear_scan.c
09:28 Geth ¦ MoarVM/even-moar-jit: Extend ARGLIST children range to include CALLL
09:28 Geth ¦ MoarVM/even-moar-jit:
09:28 Geth ¦ MoarVM/even-moar-jit: This prevents us from allocating a value for registers used by CALL
09:28 Geth ¦ MoarVM/even-moar-jit: that would overwrite a value still used in ARGLIST. Conceptually,
09:28 Geth ¦ MoarVM/even-moar-jit: an ARGLIST child should be live until the CALL, because it is still
09:28 Geth ¦ MoarVM/even-moar-jit: in use .
09:28 Geth ¦ MoarVM/even-moar-jit: review: https://github.com/MoarVM/MoarVM/commit/fee7630082
09:28 brrt this makes even-moar-jit work on windows
09:30 jnthn brrt++
09:30 Geth ¦ MoarVM/frame-extras: 2bd3bd8b0b | (Jonathan Worthington)++ | 3 files
09:30 Geth ¦ MoarVM/frame-extras: Move invoked_call_capture to frame extras.
09:30 Geth ¦ MoarVM/frame-extras:
09:30 Geth ¦ MoarVM/frame-extras: It shows up quite rarely.
09:30 Geth ¦ MoarVM/frame-extras: review: https://github.com/MoarVM/MoarVM/commit/2bd3bd8b0b
09:30 jnthn Total savings up to 56 bytes
09:32 jnthn Currently getting a measure of the ratio of frames that cache a dynamic lexical
09:45 nine jnthn: wow, almost a full cache line
09:51 jnthn About 4.5% of frames have a dynamic lexical cached on them
09:51 jnthn That's during CORE.setting compilation
09:52 jnthn Which is something I'd expect to be among the higher users of the cache
09:54 jnthn Guess that means it makes some sense to move it
09:59 samcv yay 65 failing tests now :)
09:59 samcv down 5
10:04 jnthn :)
10:04 jnthn samcv++
10:09 Geth ¦ MoarVM/frame-extras: 659c68b35d | (Jonathan Worthington)++ | 6 files
10:09 Geth ¦ MoarVM/frame-extras: Move dynamic lexical cache to frame extras.
10:09 Geth ¦ MoarVM/frame-extras:
10:09 Geth ¦ MoarVM/frame-extras: Less than 5% of frames in CORE.setting compilation use this. The 95%
10:09 Geth ¦ MoarVM/frame-extras: can save at least 16 bytes per call frame.
10:09 Geth ¦ MoarVM/frame-extras: review: https://github.com/MoarVM/MoarVM/commit/659c68b35d
10:13 jnthn I think throw_address can go away also, saving a further 8 bytes
10:14 jnthn Then I'll re-order things and I think we can squeeze another little saving out of needing less padding
10:20 brrt hehe, just about 12 merge conflicts between spesh-worker-master and even-moar-jit :-)
10:21 jnthn Not bad given you're merging a 3-digit number of commits :)
10:22 zakharyas joined #moarvm
10:24 brrt :-)
10:24 brrt so far nothing really ugly, just git being confused
10:24 brrt i'm thinking of a better jit logging / debugging 'framework'
10:24 brrt or rather
10:25 brrt i'd like to be able to have very verbose JIT output for a select few frames, and very little output otherwise
10:25 brrt and i'd be okay with those frames selected as env vars or during compile time as definitions
10:27 Geth ¦ MoarVM/frame-extras: 9c3a640d46 | (Jonathan Worthington)++ | 5 files
10:27 Geth ¦ MoarVM/frame-extras: Eliminate throw_address from frames.
10:27 Geth ¦ MoarVM/frame-extras:
10:27 Geth ¦ MoarVM/frame-extras: The information can instead be stored in exception objects, which is
10:27 Geth ¦ MoarVM/frame-extras: where it belongs anyway.
10:27 Geth ¦ MoarVM/frame-extras: review: https://github.com/MoarVM/MoarVM/commit/9c3a640d46
10:39 Geth ¦ MoarVM/frame-extras: 19cf730ee4 | (Jonathan Worthington)++ | 3 files
10:39 Geth ¦ MoarVM/frame-extras: Force MVMReturnType to be a single byte.
10:39 Geth ¦ MoarVM/frame-extras:
10:39 Geth ¦ MoarVM/frame-extras: This, with a little re-ordering, saves another 8 bytes (on 64-bit) off
10:39 Geth ¦ MoarVM/frame-extras: MVMFrame, partly by its own size reduction and the rest from no longer
10:39 Geth ¦ MoarVM/frame-extras: needing a padding hole.
10:39 Geth ¦ MoarVM/frame-extras: review: https://github.com/MoarVM/MoarVM/commit/19cf730ee4
10:39 jnthn I think that's all the size reduction we can reasonably have
10:40 jnthn We could pay an extra indirection every time we access the spesh slots but I don't know that it's worth it, 'cus we can need them quite often
10:47 solarbunny joined #moarvm
11:17 brimonk joined #moarvm
11:20 Geth ¦ MoarVM/frame-extras: b15874e816 | (Jonathan Worthington)++ | src/core/args.c
11:20 Geth ¦ MoarVM/frame-extras: Toss never-used nameds re-use logic.
11:20 Geth ¦ MoarVM/frame-extras:
11:20 Geth ¦ MoarVM/frame-extras: We never re-use frames any more, so we can never re-use this either.
11:20 Geth ¦ MoarVM/frame-extras: review: https://github.com/MoarVM/MoarVM/commit/b15874e816
11:20 Geth ¦ MoarVM/frame-extras: 994a757ad7 | (Jonathan Worthington)++ | src/core/frame.c
11:20 Geth ¦ MoarVM/frame-extras: Eliminate need to memset MVMFrame.
11:20 Geth ¦ MoarVM/frame-extras:
11:20 Geth ¦ MoarVM/frame-extras: With many things moved off to extras, nearly every remaining member of
11:20 Geth ¦ MoarVM/frame-extras: MVMFrame is set by the invocation sequence. Zero/NULL the handful of
11:20 Geth ¦ MoarVM/frame-extras: remaining things that need to be (many conditionally) and eliminate
11:20 Geth ¦ MoarVM/frame-extras: the memset. In CORE.setting compilation this will save about 79
11:20 Geth ¦ MoarVM/frame-extras: million calls to memset (one per frame invocation).
11:20 Geth ¦ MoarVM/frame-extras: review: https://github.com/MoarVM/MoarVM/commit/994a757ad7
11:23 brrt here's hoping the merge was right
11:23 jnthn :)
11:24 jnthn Righty, time for lunch, and callgrind can do some measuring on my changes this morning to see what it makes of them :)
12:02 jnthn Back
12:02 jnthn callgrind not done yet
12:03 jnthn But getting there
12:12 jnthn oops, I think I mighta misread what a column was when I wrote that 79 million
12:13 jnthn ah no, seems it was right
12:15 jnthn Aww, instruction count is up :-(
12:19 brrt :-(
12:20 brrt (okay, building rakudo on even-moar-jit-merged
12:46 jnthn Does shave a couple of megs off CORE.setting memory use though, guess just out of every closure being smaller
12:46 [Coke] jnthn: are all instructions created equal?
12:47 jnthn [Coke]: No
12:48 jnthn And memory accesses sure ain't
12:48 jnthn It's also not up by much
12:48 jnthn I was just hoping it'd be down a bit is all
12:52 jnthn Also the cache use improvements are worth something too
12:55 [Coke] mm
12:57 jnthn Hm, oops, I introduced a small leak also
12:57 jnthn So that couple of megs off low-balls it
13:22 brrt i'm getting abort on my merged build...
13:31 AlexDani` joined #moarvm
13:33 brrt jnthn, i get aborts on the multi-cache-add thingy
13:33 brrt panic!
13:33 brrt or something
13:34 jnthn o.O
13:34 jnthn That's...odd
13:34 brrt aye
13:34 jnthn I didn't touch that part, I don't think
13:34 brrt let's try with a clean master..
13:39 jnthn While I wait for a fresh callgrind, been having a crack at not allocating a byte array for the named args used thing
13:39 jnthn Or rather, only doing that if there's > 64 of them
13:39 jnthn And otherwise using a bit field
13:40 jnthn Turns out that manually NULLing the extras entries, 'cus there's various of them, comes out worse than just calling memset
13:48 jnthn Seems the named used bitfield thingy works
13:55 Geth ¦ MoarVM/frame-extras: dbad6b8c41 | (Jonathan Worthington)++ | 2 files
13:55 Geth ¦ MoarVM/frame-extras: Remove historical, now-unrequired, nullings.
13:55 Geth ¦ MoarVM/frame-extras: review: https://github.com/MoarVM/MoarVM/commit/dbad6b8c41
13:55 Geth ¦ MoarVM/frame-extras: 743796be4a | (Jonathan Worthington)++ | 5 files
13:55 Geth ¦ MoarVM/frame-extras: Use a bit field for named args used when possible.
13:55 Geth ¦ MoarVM/frame-extras:
13:55 Geth ¦ MoarVM/frame-extras: When there only 64 named arguments, we can use a bit field instead
13:55 Geth ¦ MoarVM/frame-extras: of allocating a byte array. This saves an allocation, a memset to
13:55 Geth ¦ MoarVM/frame-extras: zero it, and a free, in pretty much every use of named arguments (we
13:55 Geth ¦ MoarVM/frame-extras: have to handle the case where there are more than 64 of them, but it
13:55 Geth ¦ MoarVM/frame-extras: is likely incredibly rare).
13:55 Geth ¦ MoarVM/frame-extras: review: https://github.com/MoarVM/MoarVM/commit/743796be4a
13:56 jnthn Alright, I think that's all I'll do in this branch. Even that last commit is a bit of a stretch for the scope of the branch :)
14:06 * jnthn merged it
14:06 jnthn Geth seems a bit shy to report it :)
14:07 Geth ¦ MoarVM/master: 11 commits pushed by (Jonathan Worthington)++
14:07 Geth ¦ MoarVM/master: review: https://github.com/MoarVM/MoarVM/compare/d6d7d5eb71...743796be4a
14:09 brrt the abort happens when the pthread_mutex_unlock fails, which happens (probably)because a different thread from the one that owns it unlocks it
14:10 timotimo damn
14:11 brrt no, why?
14:11 timotimo hm, how do we fare when you have a lock.protect around an await in v6.d?
14:11 brrt (i mean, don't say 'damn', say 'why?' :-))
14:11 timotimo hah
14:11 jnthn timotimo: Badly, I think; Lock.protect should really declare my $*AWAITER to be the blocking one
14:11 timotimo why, brrt? :)
14:13 brrt i have no idea :-P
14:14 brrt so, i'm consistently seeing a failure in t/nqp/105-multicache.t
14:14 brrt on OS X
14:14 timotimo damn :)
14:14 brrt that is on master, as well on even-moar-jit-updated-to-master
14:14 jnthn o.O
14:15 jnthn I think I did touch that to ensure it always locks
14:15 jnthn Rather than having the "maybe lock" branch
14:16 brrt well, it appears to try and unlock on a differen branch
14:17 brrt https://gist.github.com/anonymous/5d25ac82c7e541e3708d90cc3610507a
14:18 jnthn ohh
14:18 jnthn huh, this musta been busted in any multi-threaded app before now
14:19 brrt which is now all of them :-)
14:19 brrt (i do wonder what 'this' exactly is)
14:19 jnthn Odd now it never whined off OSX
14:19 dogbert17 jnthn: do you need to use a branch from rakudo/nqp in order to use your latest changes? I'm getting 'src/vm/moar/ops/perl6_ops.c:731:18: error: ‘MVMFrame’ has no member named ‘special_return’ when trying to build rakudo
14:19 Geth ¦ MoarVM: 6a1c6e871e | (Jonathan Worthington)++ | src/6model/reprs/MVMMultiCache.c
14:19 Geth ¦ MoarVM: Don't release lock before we acquired it.
14:19 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6a1c6e871e
14:19 jnthn dogbert17: yes, the branch in Rakudo moar-frame-extras
14:20 jnthn Will bump and merge shortly
14:20 jnthn brrt: Try that :)
14:20 dogbert17 cool, I'll wait then :)
14:20 jnthn Just waiting for a callgrind run to finish
14:20 dogbert17 hoping for big improvements?
14:21 brrt jnthn: that fixes it
14:21 jnthn yay :)
14:21 brrt \o/
14:21 jnthn dogbert17: Not massive, but something :)
14:22 jnthn I mean, a should be avoiding a load of allocations
14:22 jnthn *it should
14:24 dogbert17 sounds like a win to me
14:27 timotimo it won't single-branchedly make your code blazing fast, but it'll be nice
14:37 lucasb joined #moarvm
14:41 jnthn Yeah, lowest instruction count I've seen on it today
14:41 jnthn By some 300 million instructions
14:45 * jnthn also has another patch for NFA stuff that he stashed away a couple of days ago to try out
14:49 jnthn I'll measure that, and then afterwards will do revision bumps
14:49 dogbert17 o.O (a hidden patch)
14:50 jnthn I stashed it away
14:50 jnthn Oh, I said that
14:50 jnthn Got distracted by other bits :)
14:50 jnthn But it in theory cuts out a very expensive memset
14:51 dogbert17 so even more instructions could be saved
14:53 jnthn Yup
14:53 jnthn Well, here goes callgrind again
15:02 timotimo jnthn: i have a branch that applies memory pressure on string operations. want me to merge it?
15:02 jnthn Ummm
15:03 jnthn Maybe in a day or two? I'm worried that the bump I'm about to do bring in some really huge amount of changes
15:03 timotimo https://github.com/MoarVM/MoarVM/commit/bb7e757265dccc4c5d51da4443bb656d54f7b9fd
15:03 jnthn Not sure we want to add more to that pile :)
15:03 timotimo right
15:05 brrt joined #moarvm
15:06 brrt dunno if geth has told you yet, but i've just pushed the merge with master
15:16 brrt by the way
15:16 brrt jnthn++ for awseome work on spesh
15:36 jnthn Another 14 billion instructions off for the NFA improvement :)
15:40 Geth ¦ MoarVM: 6941cada41 | (Jonathan Worthington)++ | 2 files
15:40 Geth ¦ MoarVM: Improve NFA memory performance.
15:40 Geth ¦ MoarVM:
15:40 Geth ¦ MoarVM: We only need 32-bit arrays, not 64-bit ones; we'll never have an
15:40 Geth ¦ MoarVM: NFA with billions of states! Even with that, the `memset` of the
15:40 Geth ¦ MoarVM: `done` array turned out to account for a ghastly number of CPU cyles.
15:40 Geth ¦ MoarVM: Since in most cases we get just in the single digits of things set
15:40 Geth ¦ MoarVM: to `done`, it's cheaper to use an array for that and do lookups in it.
15:40 Geth ¦ MoarVM:
15:40 Geth ¦ MoarVM: There are probably some further wins to be had in this area, but in
15:40 Geth ¦ MoarVM: the meantime this gets 5% of the CPU cycles off the compilation of
15:41 Geth ¦ MoarVM: CORE.setting.
15:41 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/6941cada41
15:49 [Coke] Nice.
15:52 lizmat joined #moarvm
16:20 domidumont joined #moarvm
16:21 zakharyas joined #moarvm
16:45 nine "we'll never have an
16:45 nine NFA with billions of states!" famous last words ;)
16:49 Geth ¦ MoarVM: 86b70a2736 | (Jonathan Worthington)++ | src/core/interp.c
16:49 Geth ¦ MoarVM: Only log decont value when we did a decont.
16:49 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/86b70a2736
16:58 nwc10 jnthn: twice now during parallel nqp tests:
16:58 nwc10 MoarVM panic: Internal error: invalid thread ID -1094795586 in GC work passt/nqp/076-capture.t .................... Dubious, test returned 17 (wstat 4352, 0x1100)No subtests run
16:58 nwc10 thank your irssi
16:58 nwc10 newlines - om nom nom
16:59 nwc10 but reliably passes when run alone
16:59 jnthn Urgh, wonder what's caused that
16:59 jnthn Home time now though, so will investigate tomorrow.
16:59 nwc10 "me too" but I'm also wondering "why can't I replicate this and give you a better backtrace"
17:00 nwc10 hope there's no congestion on your commute :-)
17:00 jnthn The biggest congestion risk is having to walk past the pub :)
17:00 nwc10 oh, that's sort of like taking the children from here to the granparents
17:00 nwc10 250m can take 30 minutes, as there is a playground midway
17:01 jnthn :-)
17:01 * jnthn wanders home for dinner
17:03 AlexDani` joined #moarvm
17:35 committable6 joined #moarvm
17:35 bisectable6 joined #moarvm
17:35 greppable6 joined #moarvm
17:35 evalable6 joined #moarvm
17:35 coverable6 joined #moarvm
17:35 unicodable6 joined #moarvm
17:35 benchable6 joined #moarvm
17:35 statisfiable6 joined #moarvm
18:10 evanm joined #moarvm
19:01 dogbert2 joined #moarvm
19:05 dogbert2 oops, SEGV when running t/spec/S15-nfg/many-threads.t
19:07 dogbert2 trying a few more times the error is now "Invalid owner in item added to GC worklist"
19:09 timotimo sounds like you had GC debug on there?
19:10 dogbert2 :)
19:10 dogbert2 timotimo: https://gist.github.com/dogbert17/8be88015a305ddd31fe1c51d5dbe5b7c
19:10 timotimo oh, temp roots, eh?
19:11 dogbert2 I had the nursery down quite a bit as well
19:12 timotimo should be able to figure out what temp root it was
19:13 timotimo going up until you see that you're in a MVMROOT
19:13 timotimo and of course you'd have to count backwards from the top of the temp root stack
19:13 dogbert2 perhaps something for rr?
19:14 timotimo shouldn't be needed, but it could help
19:17 timotimo i just finished a nodelay + blocking run
19:17 dogbert2 where are those 'temps' which should be added to the worklist? Are they hidden in the tc?
19:17 timotimo one failed test in S14-roles/mixin and one test failed + one todo passed in repl
19:17 timotimo they are visible in the tc d)
19:17 timotimo :)
19:18 timotimo MVMROOT manages them for you, but you can also blah_temp_push and blah_temp_pop
19:19 dogbert2 num_temproots = 4, mark_temproots = 0, alloc_temproots = 16, temproots = 0x9f09cf0,
19:19 timotimo okay that sounds simple
19:19 timotimo there ought to be a loop there that goes through the temp roots
19:19 timotimo from that you should be able to see which of these roots was b0rked
19:20 dogbert2 242     if (worklist) {
19:20 dogbert2 243         for (i = 0; i < num_roots; i++)
19:20 dogbert2 244             if (!is_stack_frame(tc, temproots[i]))
19:20 dogbert2 245                 MVM_gc_worklist_add(tc, worklist, temproots[i]);
19:21 dogbert2 246     }
19:22 timotimo right, so i should be the variable that's interesting
19:22 dogbert2 i = 1
19:22 timotimo ok, so the second from the top
19:23 timotimo so we can go up the stack and see what MVMROOTs are there
19:23 dogbert2 (gdb) p temproots[1]
19:23 dogbert2 $3 = (MVMCollectable **) 0xb56fdc94
19:23 dogbert2 what now
19:24 timotimo more interesting is what piece of the code added it
19:24 timotimo but you can print **temproots[1]
19:25 dogbert2 {sc_forward_u = {forwarder = 0x832ead0, sc = {sc_idx = 60112, idx = 2098}, sci = 0x832ead0, st = 0x832ead0}, owner = 260, flags = 0, size = 0}
19:25 timotimo owner being 260 is weird
19:26 dogbert2 the other three have owner = 1
19:29 dogbert2 size being zero feels a bit strange as well
19:30 * dogbert2 tries valgrind
19:32 timotimo size can be 0 if it's an STable
19:32 dogbert2 o.O
19:32 timotimo you can tell by the flags
19:32 dogbert2 reload the gist and look at the bottom
19:34 timotimo aha, that's interesting
19:34 timotimo let me have a look
19:34 dogbert2 ++timotimo
19:34 timotimo huh, that's weird
19:38 dogbert2 ran it again, same warning (Conditional jump or move depends on uninitialised value(s))
19:38 timotimo right
19:41 timotimo maybe things'll be a tiny bit clearer with disabled jit?
19:42 timotimo running it a hundred times and not getting the crash now :\
19:42 timotimo ah, found one. but it's not the same as yours
19:42 * jnthn returns rather damp
19:42 timotimo oh no :(
19:42 jnthn Dry, said the forecast.
19:42 timotimo something moist fell on you
19:43 jnthn Just rain.
19:43 timotimo so, jnthn, anything change about stack frames identifying themselves as on the stack?
19:43 jnthn There's a macro that should be being used for that everywhere
19:43 timotimo because we get valgrind complaining about uninitialized values there
19:44 jnthn It sets frame->header.flags in allocate_frame
19:44 jnthn To zero
19:44 timotimo is_stack_frame in roots.c additionally checks for ->owner == 0
19:44 * dogbert2 was supposed to be cloudy with a bit of rain today but alas the sun shone instead
19:44 timotimo i.e. it doesn't use the macro
19:44 jnthn timotimo: ohh
19:45 timotimo i'll go fix it :)
19:45 jnthn timotimo: It probably should ;)
19:45 jnthn I'm somewhat surprised I managed to get through all nqp test, Rakudo test, and Rakudo spectest with this :)
19:46 jnthn https://github.com/MoarVM/MoarVM/blob/master/src/core/frame.c#L228 fwiw :)
19:46 timotimo the macro is safe if we're not sure if it's actually a frame at all?
19:46 timotimo i expect so
19:49 jnthn Yeah, it just checks if flags are 0
19:51 timotimo okay, collectable from fromspace accessed, i.e. something's not being rooted now
19:52 timotimo oh, that happens always now, eh?
19:55 timotimo can't help but think i must have messed up the fix since it crashes every program now :D
19:55 jnthn Do you have GC debug mode on?
19:56 jnthn (And could it be that it also is making a bad assumption?)
19:56 timotimo set to 2, i just set it down to 1 to see if basic things are non-explosive
19:56 timotimo still explosive with just level 1
19:58 Geth ¦ MoarVM: a354389f55 | (Jimmy Zhuo)++ | src/strings/ops.c
19:58 Geth ¦ MoarVM: small optimazation to string_equal, remove repeated checks
19:58 Geth ¦ MoarVM: review: https://github.com/MoarVM/MoarVM/commit/a354389f55
20:05 timotimo anyway, even with it set to 0 i get the corruption detection, just a bit later
20:06 timotimo i.e. the wording is different
20:07 jnthn Hmm
22:41 hoelzro_ joined #moarvm
22:41 jnthn_ joined #moarvm
22:44 ilbot3 joined #moarvm
22:44 Topic for #moarvm is now https://github.com/moarvm/moarvm | IRC logs at  http://irclog.perlgeek.de/moarvm/today
22:47 eater joined #moarvm
23:14 lizmat joined #moarvm

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