jnthn *yawn* 01:05
I'll hunt that bug and cut the Moar release in the morning :)
Got too tired to do it now, after doing my other post-getting-internets-back errands.
'night o/
japhb__ o/ 01:08
02:04 colomon joined 04:03 jnap joined 05:04 jnap joined 05:10 woosley joined 06:04 jnap joined 07:05 jnap joined 07:57 FROGGS joined 08:06 jnap joined 08:10 zakharyas joined 09:07 jnap joined
nwc10 good *, MoarVM 09:33
FROGGS moin :o) 09:34
JimmyZ \o 09:36
09:53 zakharyas joined 10:07 jnap joined 11:07 sorear joined 11:08 jnap joined 12:09 jnap joined
jnthn The "precompile a thing that uses native calls" bug is urgh 12:42
I think I know what's going on. 12:43
It's actually nothing directly to do with native call after all
nwc10 "can you fix it?" 12:48
jnthn Mebbe, though I may do the fix specific to Moar for now and bring other backends in sync. 12:56
One of those places where Moar's stricter, thread-safer, less-leaky closure model drops by to say, "huh, how can that ever work" :) 12:57
JimmyZ magic 12:58
FROGGS I like that MoarVM is stricter btw, because we found quite some absurdities this way
jnthn aye 12:59
Also we need to switch JVM over at some point
There are some nasty things lurking
FROGGS urgh
jnthn In the way it currently does it, I mean.
13:10 jnap joined
JimmyZ Does panda work with p6-m? 13:14
jnthn Believe so. 13:17
13:17 jnap joined
tadzik it does 13:21
p6-m is OP
JimmyZ I thought it doesn't , I tried it on x64 and failed 13:24
about two days ago
13:24 jnap1 joined
jnthn err& # will get back to Rakudo fix in a bit 13:32
13:55 btyler joined 14:05 ingy^ joined, ingy^ left 14:43 colomon joined
jnthn OK, back to looking at it... :) 16:06
16:34 FROGGS joined
dalek arVM: 7b55013 | jnthn++ | docs/ChangeLog:
A couple more ChangeLog entries.
17:47
arVM: 3ac0ecb | jnthn++ | VERSION:
Bump VERSION.
17:52
18:01 jnap joined
dalek href="https://moarvm.org:">moarvm.org: cd91073 | jnthn++ | / (4 files):
Update site for 2014.03 release.
18:32
jnthn Release cut.
nwc10 \o/ 18:47
tadzik alright :) 18:51
I should be back home in 30-40 minutes, and I'll start the release process 18:52
19:02 brrt joined
brrt hi #moarvm 19:02
nwc10 hi brrt 19:04
brrt hi nwc10
i think i have a reasonable idea on how to create a JIT compiler now 19:05
nwc10 outsource it to edument? :-)
brrt lol
nwc10 This is perl 5, version 19, subversion 10 (v5.19.10) built for aix
oh, wrong channel
brrt - step 1: create tracing insfrastructure (ops, tables, etc) for recording type / method information 19:06
- step 2 (with many substeps): create a 'recompiler' that takes MVM bytecode, acts as if its a three-address-code (which it is), and compiles it to a simpler 'core' bytecode 19:07
step 2 is maybe already the step where we add speculative type-feedback to the compilation 19:08
step 3: take this highly simplfied 'core' bytecode and compile it to native bytecode using something like dynasm
why go through all this trouble to create not one but 2 compilers? because mvm has >500 ops right now 19:09
jnthn Hm, looks like you're going straight to trace JIT with doing the step 1 stuff.. 19:13
brrt .... 19:14
jnthn As for step 2 - I agree that something between the bytecode and assembly for a particular backend can help.
brrt waitaminute, i'm thinking exactly how i should phrase this 19:15
yes
jnthn But you'll want to go to that lower-level thingy from the CFG/SSA data strucutre I'm working on, I suspect. Not directly from the bytecode.
brrt yes
exactly
but you'll be basing that on top of the mvm bytecode, right?
jnthn It starts from the bytecode and makes the data structure, yes
brrt i've forgot what cfg is? call flow graph?
jnthn Control flow graph
Within a procedure.
brrt clear
jnthn Thing is, we can do all the stuff like inlining, type specialization, and escape analysis at that level. 19:16
And then JIT the results of that.
brrt ok, do you think i can say 'step 1 - create a graph representation of mvm bytecode' in my proposal
jnthn That's reasonable, and "collect type information" also is. 19:17
brrt ok
jnthn Though I think we'll end up sharing that with the bytecode specializer. As I see it, on platforms where we can JIT and we know how to JIT all the ops, we can go ahead and do so. When we don't, we can fall back to producing specialized bytecode that will still be a good speed win. 19:18
We may even want to JIT those asynchronously at some point.
But that's not something you need to worry over right now :) 19:19
brrt i've had good ideas about that i think
i'll let you know
by the way, there is another thing 19:22
somewhere in MVM documentation it says 'nested runloops - just say no'
which is dandy, but it will be a problem - or may be a problem - for JIT-ed code
because - how am i to know if a procedure that i'm calling will also be JIT-ed 19:23
nwc10 s/may even/likely will/ ?
brrt i think thats right :-)
nwc10 it's a good use of another core, if nothing else wants it 19:24
brrt oh, you mean asynchronous JIT-ing 19:25
v8 does that now
vms are such hotness these days
nwc10 IIRC Unladen Swallow saw that Rubinius was doing it, and planned to 19:26
brrt there are problems with that, though 19:27
some of the problems already appear in MoarVM - being that (in principle) the reference to a particular code segment could be changed from under an executing thread 19:28
i.e. bytecode is somewhat assumed to be immutable, isn't it? 19:29
and JIT-ing means replacing a part of bytecode with native code
so somehow, users of that code will need to be notified
jnthn So long as we can publish the availability of the JITted version as a single pointer update, we're good. And I think we can. 19:31
The invocation handler will just notice it's available next time around.
On the nested thing - if the next target ain't JITted, we can just save the return address in the JITted code and call back out into the interpreter. 19:32
brrt hmmm... won't that need a special new op?
return-to-native-code?
jnthn Probably. 19:34
brrt thats ok i guess
jnthn I suspect we'll have an enterjit/exitjit secret op :)
Worth it to keep the stack shallow :) 19:35
brrt i agree 19:36
consider also exceptions
that wasn't proper english
jnthn Yeah, though exceptions are really a jump or an invocation. But yes, they'll be a bit of fun :) 19:41
FROGGS interesting to see consensus on that topic :o) 19:42
brrt they're doable in a 'single runloop' situation, not so much for nested ones
jnthn Yeah, those and continuations are two reasons I've avoided them.
tadzik I wonder how much should I say about MoarVM in the Rakudo release announcement 19:44
like "huge amount of improvements on moarvm backend", or "moarvm backend is now practically as capable as parrot backend"?
brrt moarvm goes to the moon? 19:45
tadzik and beyond!
cognominal moarvm is a chinese thing?
tadzik moon, not mun :P 19:46
brrt ok, i have a few more steps for JIT-ing to the moon 20:10
step N: create a runloop from JIT-able fragments using dynasm 20:11
step N+1: generate native bytecode from said JIT-able fragments
masak jnthn++ # 2014.03 20:19
hoelzro is there a changelog for 2014.03? 20:35
jnthn yes 20:37
tadzik hmm. Is 'make stresstest' still a thing 20:39
japhb__ jnthn: Did you manage to find that perl6-debug-m segfault? 21:09
FROGGS I think I've seen a patch, dunno if it was related 21:10
jnthn japhb__: Yeah 21:11
japhb__ \o/
jnthn japhb__: You'll want an updated Debugger::UI::CommandLine
japhb__: However, there is one slightly unfortunate behavior. 21:12
japhb__ OK, since I rebuild everything anyway, that should be no problem.
Oh?
jnthn The debugger breaks on thrown exceptions, giving you a chance to understand what's wrong even in a program that you puts lots of error handlers into so the exceptions are never actually unhandled. 21:13
And it just turns out that the code that handles parameters tries to parse them all using numbers, then catches the resulting failure for non-numeric args.
So the first thing the debugger does now is tell you about a number fails to parse exception :) 21:14
I don't immediately have a good answer to that.
nwc10 how about "buy jnthn beer, to help him think"? :-) 21:15
japhb__ Heh. 21:16
jnthn heh :) 21:17
21:36 colomon joined 22:06 brrt joined 22:21 brrt joined 22:27 brrt left