| [Tux] | This is Rakudo version 2016.05-54-g48fe6ae built on MoarVM version 2016.05-18-g1339332 | 09:00 | |
| test 19.601 | |||
| test-t 12.155 | |||
| csv-parser 33.951 | |||
| AlexDaniel | [Tux]: is there any graph to see how it was changing over time? | 09:03 | |
| [Tux] | yes: tux.nl/Talks/CSV6/speed4.html | 09:04 | |
| nine | cu.codeRefs[10] = "org.perl6.nqp.runtime.CodeRef@71870f2c" | 12:05 | |
| this should be in cu.qbidToCodeRef[2] but is missing | |||
| It's the last slot in cu.codeRefs | |||
| From my limited understanding of nqp-j this could occur if a code ref is in code_ref_blocks, but not a method of the CompilationUnit's generated class. | 12:09 | ||
| If someone can confirm or deny this, that would be a great help already | 12:10 | ||
| timotimo | is that similar to when the optimizer optimizes out a block by in-lining, but the block still has to be there otherwise the compler asplodes? | 12:11 | |
| nine | I do see similarities. No idea if they're relevant though. | ||
| timotimo | OK | ||
| nine | There are indications that he missing method may be a <unit-outer> | 17:05 | |
| Which gives me a bit of a deja-vu. I remember digging around this when I first worked on EVAL | |||
| Or...maybe it's not the <unit-outer> but the code generated for calling <unit-outer> | 17:08 | ||
| The equivalent code for MoarVM works with %!mast_frames, which did need a part of the fix that we still lack on the JVM because things are very different there | 17:14 | ||
| Ok, I think, I made some progress. Seems like $*JCLASS is the closest equivalent to %!mast_frames for my purposes. So let's see if I can share it between the QAST::Compilers same as I do with %!mast_frames. | 17:19 | ||
| psch_: ^^^ | 17:31 | ||
| psch | nine: the bit about the missing entry in qbidToCodeRef sounds vaguely familiar, i think i stumbled across that too | 18:04 | |
| nine: still, MAST_Frames conceptually don't mean anything to me. i had thought $*JMETH would be the equivalent, because it appears in a similar spot in the QAST->{J,M}AST compilers, but that's obviously just a guess | 18:05 | ||
| nine: not having a $*JMETH (which should be equivalent to "the CodeRef doesn't belong to the class", afaiu) seems like it could be the cause, yes | 18:06 | ||
| mind, this all just half-knowledge vOv | 18:07 | ||
| the way i understand it, we generate a java class for a CompUnit | |||
| and the methods of that java class (more or less) correspond to lexical scopes inside the CompUnit | 18:08 | ||
| but this might all very well be only kinda-sorta true, or even almost completely false - compilers are kinda hard :) | 18:09 | ||
| nine | Yes. And the root of our problem is that during compilation of the EVAL's comp unit a $*JCLASS is created and methods added for those lexical scopes but the result is not used anywhere. Instead we get a new $*JCLASS for the outer comp unit (the module we precompile) which lacks those methods. | 18:10 | |
| So we have the coderef thingies and everything, but not the methods on the $*JCLASS | 18:11 | ||
| Same happened on MoarVM. There those executable code blocks are stored in a %!mast_frames hash instead of a class with methods | |||
| psch | right. and simply carrying the right JClass instance around is probably quite a bit harder than it would seem from here i suppose | 18:15 | |
| ...although that's kind of what the moar fix does, isn't it | |||
| nine | Yes, I just pass the nqp::hash through %adverbs to the MASTCompiler's constructor instead of having the ctor create it | 18:16 | |
| psch | but the jvm Compiler isn't instantiated | ||
| it's just class methods, which is why we rely on dynvars so much | 18:17 | ||
| (which, i think, btw, might play a noteable role in performance) | |||
| nine | Well method jast creates the JAST::Class and takes the *%adverbs parameter. That's where we could hook into | ||
| psch | yeah, that's where i stuffed my attempt with $*JMETH | 18:18 | |
| nine | So you were very close already :) | 18:19 | |
| Ok, I'm AFK now | |||
| psch | no idea if i really was close... | ||
| everything that compiled failed at least a few nqp tests, and mostly didn't compile rakudo... | 18:20 | ||
| psch also out again | |||
| dalek | ast: 500d994 | usev6++ | S32-array/delete.t: Fudge test for rakudo-j, RT #128320 |
19:49 | |
| bartolin | I wonder if this line sneaked into roast accidentially: github.com/perl6/roast/blob/master...nment.t#L8 (commit c49966e4) | 20:06 | |
| on the other hand the line caused the test file to explode on rakudo-j after Rakudo commit 069b789af5 -- so it's probably worth to make it a separate test | 20:08 | ||
| m: my @a; @a[0 ; 1] = "foo"; say @a # RuntimeException on r-j (No such attribute '$!default' for this object) | 20:10 | ||
| camelia | rakudo-moar 48fe6a: OUTPUT«[[(Any) foo]]» | ||
| MasterDuke_ | jnthn: in MoarVM/src/6model/reprs/P6opaque.h, is there a reason MVM_p6opaque_real_data has 'MVMThreadContext *tc' as the first parameter, but never uses it? | 21:43 | |
| jnthn | MasterDuke_: We pretty much always pass tc along to things. | 21:44 | |
| Nearly every function takes it. Quite often things that start out not needing it can come to do so in the future, and the predictability is rather nice when implementing stuff. | 21:45 | ||
| MasterDuke_ | ahh, so no real benefit to removing it? | ||
| jnthn | Not really. | ||
| I mean, it's small, so it's probably going to get inlined by the compiler anyway, at which point the unused arg is free. | 21:46 | ||
| And in the JIT we emit the machine code equivalent inlined straight into the JITted output. | |||
| MasterDuke_ | cool. that's kind of what i assumed, but wanted to confirm | 21:48 | |
| dalek | kudo/nom: 986891f | lizmat++ | src/core/Int.pm: Quick fix for RT #128318 |
21:54 |