|
github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm Set by AlexDaniel on 12 June 2018. |
|||
|
00:02
patrickz left
00:09
patrickb left
00:25
leont left
01:51
squashable6 left,
squashable6 joined
07:21
sena_kun joined
07:36
zakharyas joined,
MasterDuke joined
07:51
leont joined
09:00
patrickb joined
09:22
Altai-man_ joined
09:25
sena_kun left
10:29
squashable6 left
10:32
squashable6 joined
10:58
MasterDuke left
11:12
patrickb left
11:23
sena_kun joined
11:25
Altai-man_ left
11:30
zakharyas left
12:51
zakharyas joined
12:53
Altai-man_ joined
12:55
sena_kun left
12:57
MasterDuke joined
|
|||
| MasterDuke | timotimo: blosc.org/pages/blosc-in-depth/ seems like something you'd find interesting | 13:17 | |
| could we use it to store profile data compressed | 13:20 | ||
| ? | |||
| jnthn is on quite the bug hunt... | 13:33 | ||
| github.com/jnthn/spreadsheet-xlsx/issues/2 segfaults because we try to make a native call but the function pointer is null | |||
| But it only does it when specialized | 13:34 | ||
| Disabling all <jit inline osr> doesn't fix it | |||
| lizmat | yuk | ||
| good that it's reproducible :-) | |||
| jnthn | It's not stable as you start spesh limiting it to try and bissect what busts it, even with hash randomization turned off | 13:35 | |
| timotimo | this is where i'd rr and watch-point the function pointer address | 13:36 | |
| may have to switch the address around once or twice as it may move / be moved | |||
| jnthn | Until I put in a NULL check in our native call logic it managed to be in such a broken state that it was almost impossible to examine the program much under gdb, 'cus evaluations caused an error that was too unrecoverable and GDB is just like "oh, the process went away", which is odd :) | ||
| I mighta seen that happen before, but not often. | 13:37 | ||
| timotimo | if it was in combination with jit, i could imagine the "surprising stack layout" to combine with an invalid function pointer bein ginvoked to turn into a big ol' mess | 13:39 | |
| jnthn | No, I had JIT disabled | 13:42 | |
| timotimo | that makes it quite a bit more interesting :) | 13:44 | |
| MasterDuke | releasable6: status | 13:51 | |
| releasable6 | MasterDuke, Next release in ā9 days and ā5 hours. There are no known blockers. 143 out of 274 commits logged (ā 4 warnings) | ||
| MasterDuke, Details: gist.github.com/6c12cebc517cee3085...272f921017 | |||
| MasterDuke | anyone object if i merge github.com/MoarVM/MoarVM/pull/1291 so it gets some time for testing before the release? | 13:52 | |
| [Coke] | it says it's a gcc plugin but is modifying source also? (just checking) | 13:55 | |
| MasterDuke | yep. fixing the things the plugin found | 13:56 | |
| dogbert11 | What should we do with github.com/MoarVM/MoarVM/pull/1302 | 14:03 | |
| MasterDuke | merge it too | 14:04 | |
| hopefully Altai-man_ can do a Blin run this weekend | |||
| Altai-man_ | Sure thing. | 14:06 | |
| timotimo | i have no clue if blosc can do very much for the heap snapshot profiler; that page seems to focus on speed, and better compression rates would be reached by a good selection of filters for different parts of the data i guess? | 14:17 | |
| MasterDuke | i guess i'm thinking reducing memory use. if it's fast enough, compress/decompress collected data on the fly | 14:24 | |
| jnthn | OK, so...the require at github.com/libxml-raku/LibXML-raku...kumod#L692 reposseses the native call, thus wiping out its body | 14:35 | |
| But bizzarely, that only happens when spesh is enabled... | 14:38 | ||
| nine | jnthn: that.....I was gonna suggest repossession as that's bitten me in that way too many times. I even had typed in the message and then deleted it again because how could that be a reason when it's about spesh? | 14:39 | |
| jnthn | Or more to the point, MVM_nativecall_restore_library only gets called when the specializer is on, which implies the library only got wiped out in that case | 14:40 | |
| Well, spesh doesn't really enforce repossession barriers... | |||
| Or rather, the specialized code doesn't | 14:41 | ||
| But not sure why that'd be the issue | 14:42 | ||
|
14:55
sena_kun joined
14:56
Altai-man_ left
|
|||
| jnthn | nine: How exactly do the frames with nativecallinvoke come to exist? Is there any reason that doing a fastinvoke of one could go very wrong? | 15:04 | |
| 'cus it seems to be the optimization of the invoke to that which is breaking | 15:05 | ||
| nine | They're not that special github.com/rakudo/rakudo/blob/mast...kumod#L441 | 15:10 | |
| nativecallinvoke means that it's not even a JIT compiled native call | |||
| Oh, of course, since you disabled the jit | |||
| jnthn | Yeah, just looking at that now. Hmmm. | 15:11 | |
| nine | No, can't find anything. This is really the most mundane part of it all | 15:20 | |
| jnthn | If I disable rewriting to fastinvoke the bug goes away | 15:31 | |
| oops | 15:32 | ||
| If I disable optimizing invoke_o at all the bug goes away | |||
| If I only disable rewriting to fastinvoke then it stays | |||
| This is really odd | |||
| gah, I found it | 15:41 | ||
| spesh didn't check if there was an invocation handler...which there is | |||
| grmbl, a whole afternoon for a tiny patch to fix something that I'm ripping out as a result of dispatch | 15:42 | ||
| At least it'll get into the next release... | |||
| How on earth didn't we hit this before, though... | 15:44 | ||
| Geth | MoarVM: 63051257b5 | (Jonathan Worthington)++ | src/spesh/optimize.c Don't specialize invokes with invocation handlers These don't actually wish to be directly invoked, but rather to have their invocation handler invoked. This applies to anything with a CALL-ME. Fixes github.com/jnthn/spreadsheet-xlsx/issues/2 (although the code fixed here will end up going away as part of the dispatch work). |
16:02 | |
| [Coke] | jnthn++ | 16:17 | |
| nine++ | |||
|
16:36
leont left
16:45
leont joined
16:46
dogbert11 left
16:54
Altai-man_ joined
16:56
sena_kun left
|
|||
| timotimo | d'oh | 16:57 | |
|
17:49
zakharyas left
18:55
sena_kun joined
18:57
Altai-man_ left
19:07
zakharyas joined
20:51
zakharyas left
|
|||
| timotimo | jnthn: how can we deal with bringing my changes to the moar heapanalyzer back to your upstream repo? | 20:52 | |
|
20:54
Altai-man_ joined
20:56
sena_kun left
|
|||
| timotimo | it's not ... pretty :X | 20:59 | |
| jnthn | What in particular ins't pretty? | 21:12 | |
| *isn't | |||
| timotimo | only the code inside it. i should probably get rid of all usage of nqp:: ops | ||
| which i put in mostly for performance reasons | |||
| i'm also thinking moar could perhaps get a commandline flag that at the very least reads out the "highscores" and summary data for snaps inside a mvmheap file | 21:13 | ||
| (since moar already has zstd support for writing the heap snapshots anyway) | |||
| oh, hmm, if moar gets something that does low-level heap snapshot file access, perhaps there's no more need for a zstd library binding (though then rakudo-js and rakudo-jvm wouldn't be able to stand-alone read a file like that) | 21:16 | ||
| aha it's not even that many nqp ops | 21:20 | ||
| github.com/timo/p6-app-moarvm-heap...r.pm6#L221 these three blocks use nqp to shovel integers of different sizes from a big buffer into a native int array of the given entrysize | 21:22 | ||
| github.com/timo/p6-app-moarvm-heap...r.pm6#L352 - and here it's grabbing its value from an array with atpos_i | 21:23 | ||
| jnthn | I'd prefer it be free of nqp:: ops, in so far as I like to set a good example | 21:50 | |
| timotimo | yeah | 21:57 | |
|
22:02
dogbert11 joined
22:55
sena_kun joined
22:56
Altai-man_ left
|
|||