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