00:21 btyler joined 01:28 FROGGS__ joined 01:49 ilbot3 joined 03:15 cognominal joined 05:45 cognominal joined
sergot o/ 06:08
06:49 brrt joined
brrt \o 06:52
07:03 odc joined
brrt hmm, how would i trigger a decont? 07:09
hmm, i've a failing test case 07:20
yay
(better yet: an isolated failing test case)
as in, it's not failing in the compiler but in the script 07:23
now, why does this fail 07:34
interestingly, it seems that unless_o Just Works 07:36
FROGGS__ well, that's good to hear :o) 07:46
brrt emphasis on /seems/ :-) 07:49
ok, confusing stuff halfway through the frame 07:57
08:43 klaas-janstol joined 09:02 brrt joined, daxim joined 09:07 FROGGS[mobile] joined
brrt it almost seems the locals are wrong 09:11
jnthn It's not that an exception somehow got thrown at some point? 09:15
I realized, though, that throws from C-land actually lngjmp back into the interpreter... 09:16
brrt frankly, though, i have no idea 09:18
dalek arVM/latin2: 4bb41be | (Tobias Leich)++ | / (5 files):
stub latin2 support
 09:28
09:34 teodozjan joined 09:53 brrt joined 10:54 carlin joined 11:15 brrt joined
jnthn brrt: Any luck? 11:16
brrt not yet
interestingly, if i remove the branch in the nqp file, the script works well 11:17
jnthn Can you isolate the issue to the JITting of a particular op? 11:18
Could it be to do with the "did it invoke" code?
brrt likely
hmm check this out: github.com/MoarVM/MoarVM/blob/moar...oo.nqp#L24 11:22
change that 100 to 50, and the script outputs 50
jnthn wtf... 11:25
brrt yes 11:26
jnthn | is_type_object TMP5; 11:38
// object is type object (not concrete)
| jz >1;
That does jump if zero?
brrt yes
jnthn We want to *not* decont if it's a type object. 11:39
brrt letmesee
and that seems to be what it does?
oh, right 11:40
ugh, much confuse
let's fix that and see what it does
(i'm afraid not much in this case)
jnthn Well, is_type_object sounds like it will put non-zero if it *is* a type object... :)
brrt right 11:41
that's precisely what it ought to do
jnthn errands, bbi15 11:44
brrt see you in a bit, then :-) 11:45
12:06 jnap joined
jnthn back 12:06
12:19 carlin joined 12:26 brrt joined
brrt too 12:27
dalek arVM/moar-jit: c69b835 | (Bart Wiegmans)++ | src/jit/ (5 files):
Fix concreteness check in decont

  jnthn++ for pointing it out		 12:30
brrt it's kind of hard to breakpoint smrt_numify 12:36
and to be honest.. it's kind of unlikely that it's really the problem 12:37
because /without/ if_o and unless_o It Just Works 12:39
timotimo damn :(
brrt yes 12:40
timotimo but decont works fine? 12:41
brrt who knows?
it's kind of hard to test without an explicit test case
timotimo ah, fair enough
could always go back to writing your frames with the mast compiler ;) 12:42
brrt possibly
ok, smrt_numify is broken, that's for sure 12:44
somehow
jnthn Is it not missing the control_invokish? 12:46
oh, that's done automatically 12:47
brrt it ought to be, and it doesn't seem to be missing
somehow, it seems as if the Bool() frame walks all over the bar frame 12:51
jnthn I guess the Bool frame is JITted too? 13:01
brrt doesn't seem to be 13:03
takes param_rp_o
anyway, i'm in the breakpoint as we speak
brrt wonders whether it has anything to do with special_return 13:06
jnthn I don't immediately see an issue there; you're using the normal return code-path that triggers that... 13:07
brrt is still stepping through the code 13:08
brrt thinks this is exhausting 13:32
jnthn Was stepping through the code not informative? 13:33
brrt hmm... yes, in the sense that 'all appears to be normal' 13:34
timotimo the perl6.org/compilers/features matrix still lists Promises and Supplies as "no time based", i can fix that to be a green + now, right?
jnthn Yeah, time-based stuff works on Moar now 13:35
timotimo i knew most of it did, i wasn't sure if we're at 100% 13:37
that's good to know
i'll update it later today. AFK for an unknown amount of time now.
brrt no progress yet :-( 13:49
jnthn aww :( 13:51
Hard problem is hard.
13:52 btyler joined
brrt very hard indeed 14:46
14:53 btyler joined 15:00 raiph joined
brrt :-( 15:01
jnthn brrt: Is that "argh now I know why it's wrong", or "argh I can't figure it out"? 15:02
brrt argh can't figure it out
*nothing* seems wrong
except that somehow, the 50 in the value is the value that is printed by nqp::say 15:03
15:03 jnap joined
jnthn Is nqp::say one of the ops we JIT? 15:07
brrt yes, and i'm in the breakpoint
as we speak
jnthn If you look at the spesh log, does the register passed to the say correspond to a register that 50 is put into inside of Bool? 15:08
brrt hmm that'd be weir 15:09
d
i'll check 15:10
jnthn Well, if we think it might be using the wrong registers, that might confirm or break the hypothesis.
brrt very well :-) 15:11
it seems.. the Bool() frame is never speshed 15:31
jnthn Oh? 15:32
brrt yes
jnthn That's odd given how often it's called.
If you can get at it, what does sf->body.invocations have in it? 15:33
brrt however... it is indeed the case that the 50.0 constant is in the 4th register
so that's got to be worth something
(the say is also in the 4th register)
jnthn Also you put an nqp::say in the Bool method, does it get used?
brrt yes
jnthn s/get used/get said/
OK 15:34
brrt :'-(
jnthn Is it "never spesh'd" or "never finishes specialization"?
(There is the initialization of specialization which inserts logging, then the actual final spesh after logging which is triggered at frame exit time) 15:35
brrt spesh doesn't seem to see it
the name of Bool() never comes up in the spesh log
anyway, i'll see if i can get at the invocations nr
jnthn Oh...
I think I can guess
I'll bet the callsite doesn't have the "is interned" flag set. 15:36
brrt that could well be, since it is a constant
defined at src/core/coerce.c line 10 15:37
jnthn OK, so it's something about returning
brrt actually, returning is what seems to be fine 15:38
jnthn if (MVM_jit_enter_code(tc, cu, tc->cur_frame->spesh_cand->jitcode)) {
Do we return 0 there?
So we aren't actually forcing the just-invoked frame to return? 15:39
brrt good question
jnthn | mov RV, 1;
| jmp ->out;
Is what I see for MVM_JIT_CONTROL_INVOKISH
Which'd cause it to attempt the return, *if* I'm reading this all correctly.
brrt well, no, because MVM_jit_enter switches this all arround 15:40
good fun, huh
brrt agrees this is confusing and will change it arround
but fwiw, the interpreted frame is actually invoked and i can step through it
invocations is 14, spesh_threshold is 10 15:42
jnthn OK, and is tc->cur_frame->static_info->body.name pointing to a string Bool? 15:45
Where is the code that handles returning into JITted stuff, ooc?
brrt i'll look at the first thing first 15:54
hmm... how to print the MVMString in gdb? 15:55
yes 15:56
(you can call a function in gdb, apparantly)
jnthn Look inside of the codepoints buffer
ah, nice :)
in VS too
timotimo brrt: my python extension for moar can print MVMString for you
jnthn OK, then what happens if you trace things back to after the return and when you're in the JITted code again, about the print the 50?
brrt will have to see how that's done 15:57
timotimo - how to use that extension?
i can breakpoint MVM_string_say, i think
timotimo tools/moar-gdb.py ā† read the beginning of that
brrt thanks :-) 15:58
the most mysterious thing of all is that the work buffer of the JIT frame is /not/ the same as the work buffer of the interpreted frame 16:01
so how can a value in one end up in the other
timotimo oh, moar-gdb.py may need changes due to the strref? 16:03
jnthn Question: can this be reproduced with if nqp::istrue($x) instead of if $x ?
Uh, or whatever the variable was called :)
brrt hmm 16:04
i'll try
actually, that'll give us another bug 16:05
ain't that fun
carlin -Ofun :) 16:06
brrt -Omadness :-) 16:08
dinner & 16:10
16:10 brrt left 16:38 btyler joined 17:12 btyler joined 17:29 tgt joined 17:38 brrt joined
brrt ok, i'm kind of out-of-strategies right now 17:39
FROGGS__ :/ 17:42
timotimo :( 17:43
FROGGS__ brrt: you tried valgrind?
brrt good idea
let's try that out :-)
FROGGS__ :o)
I hope it shows something 17:44
brrt well, no :-)
FROGGS__ :/
brrt can't always get what you want
FROGGS__ yeah, sadly
rurban gdb stepi 17:50
and disassemble /r %rip 17:51
brrt has tried that, and everything seems correct 17:56
rurban then I would suspect one of your nonvolatile registers 17:57
brrt well... that's possible of course 18:00
what type is type 2? 18:02
ok, hmm 18:05
i think i'm getting at something now
timotimo cool! :) 18:07
brrt or rather, a case wherein we /should/ jump out but don't, or something like that 18:11
i.e. the current frame isn't restored properly, or something like that 18:12
jnthn ooh, mail tells me I have 2 accepted talks at YAPC::EU. 18:23
timotimo \o/
congrats
looking forward to seeing the recordings :)
brrt congrats indeed 18:25
very nice
FROGGS__ jnthn: you do a talk about the performance improvement over the last year... what is the other talk about? 18:26
jnthn async things
FROGGS__ .oO( "Implement NFG during this talk" )
ahh
:o)
jnthn Implement NFG in a *talk*? I'm Not F**king God! :P 18:27
brrt sure you are
nwc10 God would need a full talk, whereas Chuck Norris would only need a lightning talk? 18:28
timotimo god would write the code to disk by striking it with lightning. 18:32
and the thunder would sound like speech. 18:33
FROGGS__ jnthn: well, you could stub some parts the day before the talk, so the presentation would be smooth :P
18:37 carlin joined
tgt Hi. I just received the error "Heap corruption detected: pointer 0x10d4817c8 to past fromspace". GC issue? 18:39
timotimo ooooh 18:40
please do paste your code
something's not using the GC right, possibly 18:41
jnthn: did you see #122306 just now? is probably the same underlying problem that someone recently showed happening with a for loop and the LAST phaser behaving differently with "is copy" and "is rw" 18:42
synopsebot Link: rt.perl.org/rt3//Public/Bug/Displa...?id=122306
tgt gist.github.com/tgt/07bf0b5d9dcaf32760e8
Reading a file with 540 lines. 18:43
timotimo oh wow, that's very well golfed!
brrt command_eval, where should that be? 18:46
timotimo t/roast/lib? 18:47
er, t/spec/lib?
brrt hmm no, its directly under command_line
this .. is weird
jnthn brrt: src/HLL/Compiler.nqp if you are looking for where it's impl'd.
timotimo oh!
brrt i just skipped remove_one_frame, but i suspect something really funky has just happened 18:48
timotimo i was quite confused there for a moment :)
i think i thought of "eval_ok" or something
tgt Is there a bug tracker I should submit the bug to? 18:49
brrt one moment, my current frame's caller was Bool(), and after remove_one_frame, it's command_eval
hmm
jnthn tgt: github.com/MoarVM/MoarVM/ has an issue tracker
brrt takehandlerresult
jnthn brrt: Hm, that'd mean an exception was thrown somewhere... 18:50
brrt ok, weird
jnthn Try breakpoinging MVM_exception_throw_adhoc 18:51
brrt good idea :-) 18:55
tgt Issue added. 18:56
jnthn tgt: thanks 18:58
FROGGS__ tgt: I'd just need a text file that has >540 lines? 19:00
does line length matter?
tgt I just had incrementing numbers. I'm using OS X. Perhaps it varies by platform. 19:01
FROGGS__ ahh, okay
gist/07bf0b5d9dcaf32760e8$ perl6-m -e '(^1000)>>.say' | perl6-m gistfile1.p6 19:04
Heap corruption detected: pointer 0x7f1bed39ef20 to past fromspace
brrt *ahum* istrue is invokish, istrue_s is not 19:07
that fixes that part, at the very least
timotimo aaaah 19:08
which part gets fixed? 19:09
jnthn istrue_s is way simpler, yes.
dalek arVM/moar-jit: def5e98 | (Bart Wiegmans)++ | / (4 files):
Istrue is invokish, while istrue_s is not
brrt the part wherein the invokish istrue failed because it wasn't invokish-guarded 19:10
jnthn FROGGS__: The standard trick for trying to isolate those is reducing MVM_NURSERY_SIZE a bunch
brrt: Grrr...I shoulda spotted that when I read the patch :/
brrt not your fault 19:11
i was stepping through the asm, and suddenly i thought 'hey, that's weird, i'm at the gc sync point already'
FROGGS__ jnthn: the I'll get near the spot that causes it?
jnthn FROGGS__: yes 19:12
timotimo tgt: in any case, thank you for the report! 19:15
FROGGS__ jnthn: is the nursory size too small when I get a core dump? 19:17
nursery*
tgt No problem :) 19:18
jnthn FROGGS__: Yes :P
Well
Or you found the problem
You can get it at 1024 and all should work 19:19
I had it at that last night
brrt problems around smart_numify persist 19:28
jnthn Ah, so there were two bugs... 19:29
brrt obviously :-)
at least two bugs, even 19:31
that said
i can't really find a fault wrt to unless_o and if_o
they Just Work, even though it is the Bool() frame that seems to override the current frame
i'll make this so much worse for all of us right now 19:32
because smrt_numify /does/ work w/o unless_o 19:33
jnthn o.O
It's not some weird stateful thing going on?
What happens if you have multiple smrt_numify or multiple if_o in a frame? 19:34
brrt good question
hahahaha 19:35
well, it is actually probably a weird / stateful thing
jnthn oh my... :) 19:36
brrt because in fact, the second time i call smrt_numify, i get a zero where a number should be
jnthn Well, there we go then.
brrt now really suspects some kind of frame corruption
jnthn So, diff the assembly we produce for the two cases to make sure the weird stateful thing isn't in the code-gen, and actually is at runtime? 19:37
brrt good idea
jnthn hopes he's not being too much of a backseat debugger :)
"No, turn LEFT at the breakpoint!"
FROGGS__ "Are we there yet?"
jnthn "Can we stop to get icecream?" 19:38
FROGGS__ "I need a toilet!" :P
brrt no, you're being a good help :-)
fascinating 19:39
FROGGS__ O.o
brrt (what is fascinating, you ask? i'll tell, oh boy i'll tell)
jnthn Did anybody else, as a kid, see "TO LET" signs on buildings up for rent and want to grafiti in an "I"? :) 19:40
brrt no
but mostly because of non-native english, i think
jnthn yes. :)
brrt very few 'to let' signs here
jnthn Right
Te huur or something, right?
brrt right
zu mietung, i believe, in german
lizmat zu vermieten
jnthn hopes he actually got the word for "rent" and not a similar sounding one... :)
brrt yes, you got the right word 19:41
jnthn phew :)
FROGGS__ jnthn: about "TO LET", that doesn't work out well in germany :o)
lizmat well, they're also for rent, in a way :-)
brrt it's really freaky to see a dutch word in the english-language channel
FROGGS__ but the first time I saw such a sign I thought: to let WHAT! WHAT?!
brrt anyway, what's fascinating is this 19:42
i take a frame that numifies an object
when the JIT compiler kicks in, it 'stops working' so to speak
ehm... that's not right
it still seems to work
now i numify the object a second time
this time, after JIT, the second num is always 0 19:43
now instead of re-numifying the object, i copy the value of the first-numification
i.e. a set
still 0!
FROGGS__ jnthn: it seem to take hours using a 1024 nursery size :/
jnthn FROGGS__: Well, that is the minimum...you could probably go somewhere in the middle... 19:44
FROGGS__ k
will try that now
jnthn brrt: huh...
brrt yeah 19:45
FROGGS__ jnthn: when I disable spesh it hangs in an uv loop triggered by MVM_io_syncstream_read_line -> read_to_buffer 20:19
brrt so many breakpoins 20:21
FROGGS__ :/ 20:22
brrt it means 'im getting there, though 20:29
jnthn brrt++ # half of debugging is persistence...
brrt thinks it's 90% today 20:30
FROGGS__ in the assignment here: 20:44
multi postfix:<-->(Num:D \a is rw) { # XXX
my $b = a;
in op assign, the object 'cont' points to has all its attrs set to zero 20:45
like owner and size
this is called by: 20:46
method lines($limit = *) {
my $l = $limit ~~ Whatever ?? Inf !! $limit;
gather while $l-- > 0 {
(the example code calls lines())
timotimo huh, that's curious 20:47
brrt no, i'll tell you curious 21:38
somehow
my num64 argument is 0
even though the relevant register isn't 0
21:38 klaas-janstol joined 21:39 klaas-janstol left, klaas-janstol joined
brrt what the 21:40
ok, know what? i'm out, i don't get this /at all/ 21:41
apparantly, MVM_coerce_n_s doesn't take the second argument as xmm1, after all 21:42
jnthn o.O
brrt MVM_coerce_n_s takes the second argument as xmm0
jnthn 'cus the first argument is passed floating point?
brrt now! what is really the question, is WHY DID THIS EVER WORK IN THE FIRST ****** PLACE 21:43
apparantly
timotimo oooooh 21:44
brrt the first argument is actually the threadcontext, in %rdi, where it ought to be
jnthn brrt++ # finding the bug where it wasn't expected
brrt still can't believe that's really the cause of the bug 21:45
timotimo oh 21:46
will jitted code that handles "num" values benefit from the wider registers the cpu has to offer for floating point calculations?
rather than collapsing it to a "shorter" register between each operation?
brrt not yet timotimo 21:47
timotimo but it could do that in the future?
brrt currently, jitted code does nothing to keep intermediate values in the registers, but stores them into memory (work space) on every op
it will do that in the future, once i get full register selection in dynasm 21:48
timotimo ah
brrt once that happens, though, quite a few things will still have to change in the JIT :-)
nothing undoable, though
timotimo we can't undo it once we've done it? oh no! 21:49
brrt that was a dutch-ism, it seems
:-)
i meant nothing impossible :-)
hoelzro "I always get my sin"
brrt :-)
right
there must be german variants of that as well? 21:50
slight annoyance: win64 does what i implemented, but posix doesn't 21:53
msdn.microsoft.com/en-us/library/zthk2dkh.aspx see 3rd example of argument passing
argh, posix abi 21:58
jnthn ugh
brrt i quote for you: "Right-to-left order on the stack makes the handling of functions that take a variable number 21:59
of arguments simpler. The location of the first argument can always be computed statically, based
on the type of that argument. It would be difficult to compute the address of the first argument if
the arguments were pushed in left-to-right order."
yes, you read that correctly; if there's too much stuff, we push arguments on the stack, but - in right-to-left order 22:00
unlike microsofts abi
jnthn oh my :)
And, wtf. :)
brrt i suspect i'll have some work rewriting MVM_jit_emit_call_c 22:02
:-)
as far as i can tell, microsoft just has you push arguments in left-to-right order
microsoft, fwiw, has just won quite a few karma points in my book
22:02 ren1us joined
ren1us m: class A{}; my $a = A.new; my $ref = $a.WHERE; my $bogus = False; for ^10000 { if $ref ne $a.WHERE { $bogus = True; }; }; say $bogus; 22:05
camelia rakudo-moar 1372dc: OUTPUTĀ«Trueā¤Ā»
ren1us apparently that's fine and the GC can do whatever it wants with regard to moving things around (so sayeth masak), but this makes the use of object keys in hashes a mess. 22:06
hoelzro (it seems like, at least on mokudo, .WHICH should not use .WHERE as the default impl) 22:07
jnthn .WHERE is completely allowed to change.
.WHICH is using .WHERE as a stop-gap. 22:08
The issue exists on JVM too, giving it can also move objects and we use the default object hash code.
The challenge is fixing this without making every single object - whether we hash it or not - bigger. 22:09
(Yes, there's some ideas for how. Just didn't get to the top of the todo list yet. But I agree it needs dealing with, and .WHICH needs to be stable.)
brrt i... think i'm going to sleep over the fix tonight
hoelzro jnthn: the JVM can move objects? I think that the default hashCode() impl used ojbect location
s/think/thought, s/ojbect/object/ 22:10
brrt i'd be very surprised if the JVM couldn't ever move objects
i've heard of more than one implementation of a moving gc
(in fact, JVM's have been a hotbed of GC research for a while now)
a totally correct solution doesn't seem all that easy 22:11
hoelzro no =/ 22:12
jnthn hoelzro: Well, curiously, here's what the docs say: "As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects." 22:13
hoelzro ah ha 22:14
interesting
brrt see you tomorrow!
\o 22:15
22:15 brrt left, klaas-janstol joined
hoelzro night brrt 22:15
jnthn I *think* glancing the HotSpot code in hg.openjdk.java.net/jdk7/jdk7/hotsp...onizer.cpp that it's actually cheating and storing the hash value in some GC related slot... 22:18
hoelzro weeee
figures 22:19
jnthn Anyway, the solution is heavily GC-intertwined
Which is what all the ones I've come up with would be too
hoelzro I figured =) 22:21
ren1us why not just make the hash the instant (now()) of the object's creation or something, effectively removing the whole memory address thing from the equation?
hoelzro ren1us: thanks for bringing this up
ren1us: I think jnthn wants to avoid increasing a moar object's size if he can 22:22
jnthn ren1us: Yes, but how/where do we store that?
hoelzro decommute &
jnthn Also, that's a really bad hash code, given multi-threading...
ren1us fair point.
lizmat jnthn: maybe calling .WHICH should move an object from the nursery and then give it a fixed .WHICH value stored in a slightly larger header ? 22:23
jnthn lizmat: Moving an object from the nursery means doing GC, which is gonna get costly on every WHICH. ;)
lizmat: But that is along the right lines.
lizmat: ONce an object reaches gen2 it actually doesn't move.
lizmat maybe each thread needs it's own gen1.5 ? 22:24
for those objects we call .WHICH on ?
jnthn Object refs can be shared over threads :)
lizmat true :-(
jnthn Anyway, my idea was that if an object is in gen2 already, use the memory address
lizmat yup 22:25
also: if calling .WHICH would trigger a GC, we potentially could have a lot more GC runs
but they would be smaller ?
jnthn And if it's not, then reserve a gen2 address for it, and make an entry in a hash table of nursery address => gen2 address
And then look in that table when upgrading or sweeping objects. 22:26
GC runs carry a fixed overhead
lizmat well, hash and threads, sounds dangerous
jnthn As well as the "how many"
So protect the hash (in fact, the whole WHICH process for non-gen2 objects) with a mutex :)
lizmat ok, but that screams deadlock to me 22:27
jnthn Deadlock relies on being able to construct a circular wait.
So long as we don't do anything that could lock while holding the lock, we're good. And in this case we quite easily cna.
*can
lizmat two threads calling .WHICH on the same thing at the same time ?
jnthn One gets the lock first, sees it's nursery and needs a stable address, and so allocates it one, and makes the hash entry. Releases the lock. 22:28
lizmat well, you have more experience in that :-)
yup, ok feels like doable :-)
jnthn Second thread then gets the lock, sees it's nursery, sees we already made it an entyr in the hash table, grabs it, releases the lock, and done.
*entry 22:29
lizmat indeed
jnthn When I teach on deadlock I typically end up talking about the aggregate pattern as a decent structure that can avoid circular waiting arising. 22:31
Turns out you can spend days talking about the aggregate pattern too, though... :) 22:32
lizmat :-) 22:40
I guess we would need some code for the case that .WHICH gets called on something in the nursery, but it gets abandoned before a GC happens 22:42
so the reservation in gen2 would need to be undone
or always move it to gen2 (even though it should be reaped already) and leave it to the gen2 GC run ? 22:43
jnthn Well, the GC sweeper could just clear up the entry in the table and add the gen2 slot into the free list
lizmat indeed, but we shouldn't forget that :-) 22:44
jnthn Indeed :)
dalek arVM: 6cce876 | jnthn++ | docs/ChangeLog:
Update ChangeLog for 2014.07.
 23:09
arVM: f6e89c4 | jnthn++ | README.markdown:
Minor README feature updates.
 23:13
jnthn Will cut the release tomorrow morning, so it's done in time for the Rakudo monthly 23:24
'night
lizmat gnight jnthn 23:25

Powered by Cro and the RakuĀ® Programming Language.

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

Thank you!