01:48 ilbot3 joined 05:49 brrt joined 06:25 brrt joined 06:31 domidumont joined 06:36 domidumont joined 07:53 zakharyas joined 09:51 zakharyas joined
jnthn Hm, we have a case where a p6definite is being optimized into a 10:45
const_i64_16 r6(2), liti16(0)
p6bool r4(6), r6(2)
However, with no guarding
The optimized sequence being 10:46
decont r4(5), r2(3)
isconcrete r6(2), r4(5)
p6bool r4(6), r6(2)
The opt itself seems OK; the fact it kicked out the guard it depends on is the problem. 10:49
dalek arVM: 33c04ce | jnthn++ | src/spesh/facts. (2 files):
Widen scope of fact dependency function.
 11:06
arVM: 330b1b4 | jnthn++ | src/spesh/optimize.c:
Add missing fact dependencies.
jnthn Those seem needed, but unfortunately do not nail the actual problem.
lunch & 11:13
So, to explain the big problem behind this. 12:15
It's not actually a missing guard problem
Rather, it's a "facts changed since the guard" problem
We assume that between the point we looked inside a Scalar and guarded by content, and by the time we pull the content out, things didn't change. And they usually haven't, but of course there are constructs where that can happen 12:16
A true fix for this has much in common with escape analysis 12:17
(More generally, it's an alias analysis problem)
nine reads that as jnthn will just go ahead and implement escape analysis this afternoon to get it over with once and for all 12:18
jnthn No :P
lizmat jnthn: would an extra scope help in that code ?
gather { while { } } 12:19
rather than
jnthn It's a pretty hard problem
lizmat gather while { }
jnthn Thankfully, there's also a fairly easy fix
That kinda over-compensates and rules out some optimizations that would be safe, but probably not too many
We always know the guarded write, so we look backwards from our current instruction to see if we can find that write. If it's across a BB boundary we treat it as unsafe. If we encounter an alias-introducing operation along the way, same thing. 12:20
lizmat: No, this wants a fix in spesh, I think, and I don't think that extra scope would help either :) 12:21
Spesh probably wants to be one of the things next in line for me to look at after the concurrency stuff. 12:22
In so far as there's a bunch of things I'd like to change. :) 12:23
12:44 kjs_ joined 12:49 kjs_ joined 12:53 kjs_ joined 12:55 kjs_ joined
dalek arVM: 0cb920b | jnthn++ | src/spesh/ (3 files):
Avoid use of possibly invalidated decont facts.

When we guard a container, we also guard against its content. Since a container is mutable, however, the contents will change over time. A more accurate tricking of this needs alias analysis; for now, a more conservative analysis that treats any aliasing operation as invalidating should be sufficient protection against mis-optimization.		 13:00
14:07 zakharyas joined 14:59 edehont joined 15:15 zakharyas joined 15:42 domidumont joined 16:09 TheLemonMan joined
TheLemonMan ok, I did some more digging into #128803 and found out that it's being caused by keep_caller not being correctly set on some frames 16:12
synopsebot6 Link: rt.perl.org/rt3//Public/Bug/Displa...?id=128803
TheLemonMan it also seems to happen when you throw a 'take' object using MVM_exception_throwobj 16:13
if you no-op this condition github.com/MoarVM/MoarVM/blob/mast...ame.c#L808 you can see the list of frames isn't truncated anymore 16:15
timotimo wow, that's some good detective-work! 16:32
TheLemonMan I hope it's useful for somebody more knowdlegeable than me to come up with a fix, I think I've reached my limit heh 16:50
timotimo i myself don't really know what keep_caller is about, exactly. probably just CALLER:: related stuff? 16:53
TheLemonMan it's an optimization introduced in cecf5729 that allows the GC to reclaim the caller frames (at least that's what I think it does :) when you don't need those anymore 16:59
timotimo oh, that's interesting
when you just no-op that condition, how does a full spec test run look?
17:00 brrt joined
TheLemonMan hmm, how do I run one ? 17:02
timotimo with the env var TEST_JOBS set to something like your number of cpu cores run "make spectest" in rakudo's folder 17:03
brrt hey TheLemonMan: just for my sake, do you know / would you like to test if this is senstive to the MVM_JIT_DISABLE env flag
TheLemonMan brrt, I've already tried disabling both the jit and the spesh, but let me retry one more time 17:04
brrt hmm, i've you've done that, then it is unlikely to be the source of the problem
also, TheLemonMan++ for persistence
eh
perseverance :-) 17:05
jnthn The whole keep_caller thing is a little interesting
It dates back to the earliest days of callframes
When they were all ref-counted 17:06
And being able to decrement the ref count on the caller sooner was useful
These days, however, we have two cases:
1) The frame is on the call stack. It's thus going away, and there'll be nothing in existence to ever read ->caller 17:07
2) It'll be on the heap, having been promoted. The ->caller will also be on the heap. Neither will go away until the next GC run.
So there's actually no advantage in clearing ->caller.
So it's entirley possible we can entirely remove not only that NULLing, but also the keep_caller flag. 17:08
timotimo neat, another little bit of ram saved
jnthn Saving us CPU cycles and fixing a bunch on the way
Maybe not RAM, given it's probably a byte and we've probably packed a bunch of them together
So most likely alignment will mean no real RAM saving 17:09
brrt well, code, at any rate
jnthn fixing a *bug*
Saving code is certianly worth it
And saving a branch/write every single return is very worth it.
So I'd probably just try killing off the 5 lines under /* Unless we need to keep the caller chain in place, clear it up. */ and the keep_caller flag, spectesting, seeing if there's negative fallout, and if not we can go with that. 17:10
brrt nods intelligently 17:13
TheLemonMan ok, I just pulled a fresh rakudo and started the spectest
17:13 brrt joined
jnthn The trouble with fixing the worst bugs that afflicted the Perl 6 implementation of the test harness is that the remaining ones don't show up much 17:16
(Currently well into S06 and going strong) 17:17
timotimo has anyone looked into using a deterministic scheduler thingie library replacement for pthreads or whatever yet? 17:18
i know there's something out there
i'm not sure what it can do for us, though
jnthn Not me 17:20
Damn, it's up to S32
nine jnthn: you sure there's issues left?
TheLemonMan definitely needs moar cores heh
jnthn Yes. 17:21
t/spec/S32-str/utf8-c8.t .................................. ok 0/? 0/? 0/? 0/? 0/?)===
===( 0;450 4/23 0/? 46/165 151/159 0/? 0/? 0/? 0/? 0/? 0/? 0/?)===Heap corruption detected: pointer 0x2b2506ed5ef8 to past fromspace
make: *** [m-spectest6] Error 1
hoelzro timotimo: something that deterministically schedules pthreads for debugging?
timotimo something like that, yeah
TheLemonMan t/spec/S15-nfg/regex.t -> dubious
jnthn I dunno how well that'd work in this case in so far as this involves other processes
timotimo like Dthreads
jnthn TheLemonMan: Your NQP is probably outdated
timotimo i *think* gnu has something for that? 17:22
hoelzro Dthreads?
brrt timotimo: why would you want that?
timotimo emeryblogger.com/2011/07/06/dthrea...threading/
brrt DrThreads
TheLemonMan jnthn, it's the one that rakudo pulls in
timotimo brrt: reproducible crashes
brrt ah, i see
hmm
hoelzro oooo, neat
I had an idea for debugging pthreads a while ago 17:23
using LD_PRELOAD and some linker magic to make pthreads cooperatively scheduled and injecting yields into certain locations
sadly, it's NYI =/
how would that work for threads waiting on I/O, though? if I/O is taking longer in the Nth run, the thread isn't schedulable 17:24
TheLemonMan the run is over, ptpb.pw/Jdcm 17:26
nwc10 jnthn: if I wanted to try to reproduce that "Heap corruption detected" how would I? 17:31
17:38 zakharyas joined 17:41 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Add missing fact dependencies.' 17:41
travis-ci.org/MoarVM/MoarVM/builds/152938597 github.com/MoarVM/MoarVM/compare/2...0b1b44ab07
17:41 travis-ci left 17:50 brrt joined
TheLemonMan the former failure is gone with an updated nqp, the one in error-reporting.rakudo.moar is still there 17:56
jnthn nwc10: HARNESS_TYPE=6 make spectest 17:59
nwc10: With TEST_JOBS set to something non-zero to try the concurrent case
Does it go away without your change? 18:03
If so, worth looking in to
nwc10 ho ho ho, it doesn't do the perl5 thing of keeping its line length under $whatever with a ... if there are more cores than the terminal is wide 18:08
TheLemonMan jnthn, yep, the test fails because now 'Actually thrown at:' is being printed 18:16
the test's been introduced in rt.perl.org/Public/Bug/Display.html?id=127425
jnthn nwc10: oh, is that way it looks shocking? :) 18:20
nwc10 it doesn't keep the output on one line
it's accidentally scrolling the terminal
anyway, it failed 18:21
===( 0;648 1/1 3/3 3/3 3/4 1/8 19/19 1/4 2/13 40/40 50/50 39/39 51/51 45/45 1/2 5/334 314/327 30/30 0/? 0/? 0/? 2/2 0/? 0/? 0/? 0/?)===Internal error: zeroed target thread ID in work pass
make: *** [m-spectest6] Error 17
no obvious ASAN
jnthn Aww, too bad 18:22
What about in the single threaded case? I managed to get a SEGV out of that earlier...
unmatched} TheLemonMan: what does it show now for say <a b c>.rotor: 1 => -Inf ?
TheLemonMan: I mean if you run perl6 -e 'say <a b c>.rotor: 1 => -Inf' with your change, what's the output?
TheLemonMan unmatched}, ptpb.pw/V2N6 18:23
unmatched} TheLemonMan: that test can be tossed.
TheLemonMan unmatched}, tossed as in, deleted ? 18:25
unmatched} TheLemonMan: yeah. And methinks this commit can be reverted too then: github.com/rakudo/rakudo/commit/67b6544e48
TheLemonMan it might also be useful to check for possible performance regressions/gains 18:27
jnthn suggests callgrind
TheLemonMan don't you have an automated testing harness for that ? :P 18:28
18:29 kjs_ joined
nwc10 jnthn: this might take some time, as I'm normally using 24 cores 18:30
don't wait up
(or delay eating)
jnthn I won't :) 18:31
I'm about done for the day, I think. Getting tired.
And wife will be home soon :)
(And thus it'll be dinner time :))
jnthn hungry already 'cus it smells nice :) 18:33
brrt hunger is important.... or something 18:35
brrt is also hungry but still in train
jnthn :P
brrt and i can't get energy usage under control with this damn laptop 18:36
i suspect it's firefox
nom well :-) 18:37
nine brrt: but but but you are master of energy, aren't you? 18:39
timotimo holy hell, the remote code execution thing that person found in jetbrains ides was worth 50k dollars and he donated "the bulk of the money" to the pypy project
brrt well, almost :-P 18:40
timotimo i ought to go into security research %)
brrt or in pypy
i still have to fix little bugs in the thesis report before it is finally considered complete
timotimo i've contributed a few lines of code to pypy
it was hard for me to learn all the nitty-gritty, so contributing was hard; especially when compared to rakudo and friends 18:41
brrt yeah
the interesting thing about contributing to pypy is that due to their nonstandard toolchain, contributing is /harder/ than it would be if they had used C 18:42
and much less practical
compile moarvm: ~20s
compile pypy: what kind of cluster have you got
decommute & 18:43
timotimo you don't have to compile pypy to test your changes 18:44
jnthn OK, dinner :) 18:45
18:49 TheLemonMan joined
TheLemonMan I've opened a PR for MoarVM 19:30
timotimo just thinking about what quality-of-like improvements i could get with such a bug bounty 19:44
*sigh* 19:45
19:48 kjs_ joined
nwc10 jnthn: 20:26
moar: 3rdparty/libuv/src/unix/stream.c:1499: uv_read_start: Assertion `((stream)->io_watcher.fd) >= 0' failed.
make: *** [m-spectest6] Aborted
jnthn That's a new one...
No stack trace or ASAN barf, I'm guessing? 20:27
timotimo that's like a filesystem change watcher or more like something else?
nwc10 correct, neither
timotimo like ... watching if a file handle has something ready to read or is ready to be written to?
nwc10 have started building current nom
jnthn timotimo: Given it's in stream.c I'd say it's about "normal" filehandle reading rather than an explicit filesystem notification thing 20:28
timotimo ah, right, i read over that part 20:32
20:42 edehont joined 21:52 kjs_ joined 21:58 Zoffix joined 22:21 stmuk_ 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!