00:47 timotimo joined 01:39 vendethiel joined
diakopter CACKLE "learn the c" 01:55
01:56 zakharyas joined
konobi arnsholt: portableumem is really useful for memory testing 01:56
and for use during production! 01:57
timotimo can you tell more about why it's cool to have? 02:04
konobi timotimo: blogs.oracle.com/dlutz/entry/memor...th_libumem 02:54
timotimo for some reason, the version of the variable is incremented by one after the guardconc happens ... and that makes removing the guard problematic if i want to also reduce the usages 03:15
because then the writer of that variable/version gets exploded, but the readers of the variable/version+1 don't get their variable set to something sensible and *bam*
huh, or am i wrong about this ... 03:16
could also be we've got a "known concrete" flag that's wrong 03:17
need to sleep before i can properly figure out what's going on 03:20
OH! 03:23
of course it's known concrete when we have a guard guarding it 03:24
but that's "known from a log guard"
damn, this'd require some extra cleverness
05:56 domidumont joined 05:58 vendethiel- joined 06:00 domidumont joined 06:43 pyrimidine joined 06:52 domidumont joined 07:42 brrt joined
nwc10 jnthn: ASAN still tolerates you(r branch) 09:17
also, setting built under valgrind
jnthn Nice :) 09:22
10:37 brrt joined 12:19 MadcapJake joined 12:50 brrt joined
brrt hey, #moarvm 12:51
any idea why in reframe-jit, i get a SEGV in nativecall on getlex
actually,waitaminute
who assign tc->cur_frame 12:59
jnthn brrt: Well, various things can 13:02
brrt it's fairly evident we've jumped up in the frame
jnthn brrt: Anything that invokes, and anything that causes stack -> heap promotion
Where you don't really move frame, but the frame moves. 13:03
brrt basically, my cur_frame points to a frame that was generated 200 alloc_frames ago
however, and here is the point, tc->current_frame_nr does /not/
i've taken some care to make sure that tc->current_frame_nr is updated on entry (MVM_frame_invoke, iirc) and in exceptions (unwind_to, iirc) 13:04
actually, that's in remove_one_frame 13:05
evidently, we're somehow in the NativeCall tests jumping up the stack and not assigning the current_frame_nr 13:19
and that probably causes the invokish to fail... 13:20
continuations....
jnthn brrt: NativeCall does funky things if you've got callbacks 13:21
brrt how does it do them
jnthn Well, it needs a "nested" interpreter 13:24
Look in nativecall_dyncall.c and search for backup_
But that'd only explain bustage in the callback tests, not all of nativecall tests
brrt uhuh
i'm looking at assignments to tc->cur_frame... the cur_frame is set in uninline 13:25
jnthn Continuations are used all over the place
Yeah, but after an uninline you'd have fallen out of the JIT?
'cus that's part of deopt
brrt ehm, yeah.... 13:31
true
still, it ought to be assigned there
(i see the nativecall thing)
brrt wonders why he didn't think of ack 'tc->cur_frames+=' before 13:41
dalek arVM/reframe-jit: 13666ec | brrt++ | src/core/ (4 files):
Make frames identifiable using a sequence number

Because frames can now be garbage-collected, they can be moved, and the identity check used in the JIT will no longer work. Thus, we'd 246c941 | brrt++ | src/ (5 files): Update the tc current_frame_nr in all cases
There were a number of cases which I missed, causing 'weird' errors. This makes rakudo pass sanity checks.		 13:47
brrt sorry dalek...
13:47 dalek joined
arVM/reframe-jit: 529e061 | brrt++ | src/jit/emit_x64.dasc:
Add DynASM definition for our frame_nr
brrt t/spec/S17-supply/syntax.t .................................... Failed 9/60 subtests :-( 13:50
otherwise cleanish 13:51
so far
13:54 vendethiel joined
jnthn brrt: That may not be your fault 13:57
brrt let's hope :-)
i've sent a PR 13:58
for reframe-jit on top of reframe
jnthn will look at the PR shortly :) 14:34
[Coke] jnthn: are you doing the moar release this month? Should we get someone else to do one of them? 15:04
jnthn [Coke]: I don't mind doing it but it'd be good to scale it :) 15:14
[Coke] ok. I hoelzro++ is doing the rakudo/nqp releases this month. 15:18
diakopter I wish dalek could report pull requests 16:26
well, not to mention issues as well
16:36 domidumont joined
[Coke] diakopter: developer.github.com/v3/activity/e...questevent 17:53
seems like we could sub to those too. (might need dalek code change to lsiten) 17:54
dalek arVM: e7031d0 | niner++ | src/core/compunit.c:
Fix Windows build broken by pointer arithmetic on void*
 18:08
arVM: b441c94 | jnthn++ | src/core/compunit.c:
Merge pull request #366 from niner/master

Fix Windows build broken by pointer arithmetic on void*
arVM: 3198112 | tomboy64++ | / (3 files):
update the build system to autodetect system provided libs

  - uses raw pkg-config to determine include directories
  - failover to the old behaviour when errors occur
  - fix DT_RPATH when @libdir@ has no / prepended		 18:19
arVM: 126cb2a | tomboy64++ | Configure.pl:
small updates to the patch

  - test for existence of $config{pkgconfig} before attempting to run it
  - adding \n to error messages
  - re-adding entry to create include dir for libtommath
timotimo ah, cool, the pkgconfig stuff landed?
18:20 brrt joined
timotimo how expensive actually are guards that are 100% superfluous? 18:23
nine infinite 18:24
jnthn timotimo: Yeah, I gave it the promised "does this bust Windows" test, noted it didn't, and merged it 18:25
timotimo in that case i can just remove a single guard that i can prove will never fail and moar will be infinitely better
18:30 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Merge pull request #366 from niner/master 18:30
travis-ci.org/MoarVM/MoarVM/builds/129807202 github.com/MoarVM/MoarVM/compare/8...41c949cb11
18:30 travis-ci left
jnthn is giving reframe-jit a spin 18:30
timotimo W: Failed to fetch downloads-distro.mongodb.org/repo/d...tion-en_US Unable to connect to downloads-distro.mongodb.org:http: 18:31
noooooo, not mongodb %)
jnthn bah
timotimo so our travis builds are failing because mongodb's repositories are down, eh? fantastic 18:32
jnthn It'll work eventually :D
timotimo maybe "apt-get update" isn't the right thing to have in our travis configuration
jnthn Immediate working is overrated
timotimo i *guess* the travis images they're spinning up for testing are updated "in the background" every now and then
jnthn reframe-jit looking good so far 18:39
timotimo jnthn: do you have an intuition if it's correct that going through a guard will increment the version of a register? or is it just that there was something there in the past that actually sensibly caused the increment and it just got kicked out in the mean time?
jnthn (up to S05)
brrt \o/
jnthn timotimo: No, I highly doubt it
Guards are inserted after SSA is formed
And they only read
Usage across a guard bumps the number of uses though 18:40
timotimo yup
the more i consider "rebuild between successive passes", the more i gravitate towards "just do a complete, full rebuild, rediscover all facts, re-number all register versions" %)
that speaks volumes about how confident i am about making spesh transformations that keep up a lot of useful invariants 18:41
dalek MoarVM/reframe: 13666ec | brrt++ | src/core/ (4 files): 18:49
MoarVM/reframe: Make frames identifiable using a sequence number
MoarVM/reframe:
MoarVM/reframe: Because frames can now be garbage-collected, they can be moved, and
MoarVM/reframe: the identity check used in the JIT will no longer work. Thus, we'd
jnthn brrt: Merged; there's one comment on it from vendethiel that I'm not smart enough to understand right now, and I spotted a typo... :) 18:50
18:50 dalek joined
jnthn (Which is second comment) 18:50
Feel free to look at those :)
brrt oh, will look
jnthn (If you do any changes, just do them direct in reframe :))
Otherwise, I think I'm good to merge reframe to master :) 18:52
vendethiel jnthn: uh, I don't remember being "smart" at all recently. or even a long time ago
jnthn vendethiel: I'm generally exhausted this week, so if I don't understand something I'm defaulting to assuming it's me not having the brane for it. :-) 18:53
brrt vendethiel: i think your comment is about the sizeof (MVMReturnType) 18:54
vendethiel yes
brrt hmmm
well, i'd rather have it at compile time , but i'm not sure that's possible 18:55
vendethiel why not?
brrt how?
jnthn sizeof(MVMReturnType) is a compile-time constant.
brrt #if sizeof(MVMReturnType) != 4 - not a preprocesor constant surely? 18:56
vendethiel that's allowed
sizeof() is compile-time, since the struct is compile-time
jnthn But yeah, now I see what the commnet was about. But I think it'll get constant folded
vendethiel well, not #if, because it's the CPP
jnthn Seems highly likely
vendethiel jnthn: thought so as well, but just making sure :) 18:57
jnthn I can imagine something like Rakudo not nailing such a thing
But C compilers have had some decades to get smart enough :)
vendethiel well, yeah
but having a check here seemed... weird
brrt i agree 18:58
it's an old check though
jnthn Can't cash that... 18:59
Time for a walk, I think :)
bbl
timotimo wait what, reframe goes into master, master goes into this month's release? 19:09
nwc10 yes, if it's merged, it ends up in the release. So the question is "is it good enough to be in the release (or fixable by then)?" 19:13
jnthn nwc10: I think "yes", in that the more risky of the two parts has been stress-tested to the point that we've fixed bugs that were in master too 19:17
And we've a week to understand any fallout. 19:18
timotimo well, i've checked it out locally in any case, so ... :) 19:19
i'll be trying it out
jnthn Anyone against pulling the trigger? 19:20
timotimo wether or not it'll end up in this month's release
brrt afk for now 19:22
nwc10 jnthn: ASAN is somewhere in th emiddle of a spectest 19:28
I think about 5 more minutes to go 19:29
19:35 dalek joined
nwc10 jnthn: flapping assertion abort in t/spec/S17-supply/syntax.t 19:35
otherwise perfect
paste.scsys.co.uk/513650 19:36
and not a new flapper
timotimo \o/ 19:37
it's about a mutex escaping the wrath of our code-gen again
nwc10 (and double checked, JIT was enabled) 19:38
that was MoarVM origin/reframe, nqp at 73befe524cde66b663e5c339e5304b973a8c71dc and rakudo at origin/moar/reframe 19:40
I see from dalek's temporary departure that rakudo has moved on a bit
jnthn :) 19:41
timotimo right, that seems to be nine's merge for load bytecode api work
jnthn Hm, maybe I should wait until tomorrow unless there's a little dust to settle from that :)
nine Yes, we now load modules without having to lock the files :)
jnthn uh, in case, not unless :)
nine++ \o/
nwc10 I think wiser to wait until tomorrow morning 19:42
jnthn Aye
OK, will do it then :)
Thanks for testing
nine aaah...and I was so curious about the performance impact of reframe
nwc10 I've merged things locally - will re-run the ASAN build
jnthn nine: So significant difference for most programs yet, but this is mostly the big scary chance before a bunch of smaller optimization-focused changes. 19:43
um, *no significant
Parallel programs are likely to get a more immediate win
And things that keep thousands and thousands of closures around also. 19:44
nine Actually it may be wise to not merge right before going to bed anyway. I thought I had already learned that :) 19:45
timotimo oh, reframe doesn't have the new bytecode op yet 19:53
i don't remember what code i recently discovered was crashy with reframe and which was heavily slowed down by competing to allocate frames 20:03
ah, the logic puzzle with the prime numbers in the square 20:05
it seems like there was another, different one, too 20:07
ah, on my desktop!
nwc10 ASAN happy merged MoarVM and merged Rakudo and nqp master 20:17
timotimo oh, we still go through the FSA? 20:18
jnthn timotimo: Not for frames themselves, for env and work, yes 20:26
nwc10 Ooh, I can disable the FSA and try ASAN again...
jnthn timotimo: env looks like it'll be a fairly easy move to the stack
timotimo cool 20:30
timotimo has already forgotten what the difference between env and work is; is env about things like autoviv and such? 21:13
oh, probably lexicals vs locals
jnthn yeah, env is the lexical *env*ironment 21:16
work is working space, and the only time it ever outlasts a frame being on the stack is with continuations.
mst continuations overcomplicate everything 21:17
(I <3 continuations, but still)
jnthn That's probably why Perl 6 doesn't actually expose them directly :)
(We have 'em for gather/take, and - in 6.d - await) 21:18
mst ah, so your continuations are only resume-once? 21:21
jnthn Yes
Which simplifies things.
mst the one use I've put continuations to that wasn't basically 'await' was ... the moral equivalent of the 'amb' operator from original lisp
but that was because I was implementing a prolog derivative in an fexpr (i.e. operative) microlisp written in perl 21:22
jnthn Fun!
mst I'm now doing something more like minikanren's stream composition approach, which removes the need for multiple-resume 21:23
well, it does and it doesn't, but it pushes the problems into different corners of the design that cause me less pain
timotimo do we actually skip allocating a lexical environment for frames that don't have lexicals? 21:28
jnthn yes 21:30
timotimo nice, so when work moves away from FSA, we might have a bunch of frames that don't contend on the FSA at all
jnthn Should do
Well, ->env will not need it either
timotimo it's still a bit hard to come by those in complex code, however
jnthn env is actually a far easier more than work 21:31
*move
timotimo oh! env is the one that's easier to move, not work
i confused the two, sorry
jnthn Yup :)
timotimo so we should be optimizing our code to use only lexicals, no locals at all
jnthn I'll probably do it shortly after the monthly :)
heh, it doesn't work like that :P
timotimo to make it work faster in multi-threaded situations :D
jnthn It's only good if you don't end up with a heap promotion
timotimo right 21:32
will we be getting any kind of diagnostic for that?
jnthn Yeah, in the normal allocation profiler, I expect. But not totally sure how to do it yet :) 21:33
timotimo sounds good so far
there's no way to make the locks on the FSA more fine-grained, right? 21:34
like, one lock per size group or something silly like that
jnthn We can surely do better
21:35 cognominal joined
jnthn Though need to do so very carefully. The original "better" lock-free implementation I did ended up with a really nasty AB bug. :/ 21:35
(Which, you might imagine, was hard to find.) 21:36
timotimo oh, yeah, that's pretty terrible :( 21:38
jnthn wanders of to some hopefully non-terrible sleep 21:41
*off
&
timotimo good luck!

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!