Geth MoarVM/nummy-num: 337cf380d7 | (Zoffix Znet)++ | src/strings/parse_num.c
Remove trailing whitespace
 00:09
MoarVM: 7349b428fb | (Timo Paulssen)++ | src/debug/debugserver.c
have to use FSA consistently for this field
 00:46
MoarVM: c6aba84d3a | (Timo Paulssen)++ | src/debug/debugserver.c
don't use %b in format string

in not-so-important debug output
01:56 ilbot3 joined
Geth MoarVM/nummy-num: c6c0bab915 | (Zoffix Znet)++ | src/strings/parse_num.c
Fix denormals and precision issues in num parser

With the original method we had problems with handling denomals
  (so e.g. 5e-324 ended up as 0e0) and had precision issues where
NOT the closest representable num was generated for a given string, which causes value drift in repeated num->str roundtripping.
... (8 more lines)		 02:53
MoarVM: zoffixznet++ created pull request #850:
Nummy num		 03:04
MoarVM: 337cf380d7 | (Zoffix Znet)++ | src/strings/parse_num.c
Remove trailing whitespace
MoarVM: c6c0bab915 | (Zoffix Znet)++ | src/strings/parse_num.c
Fix denormals and precision issues in num parser

With the original method we had problems with handling denomals
  (so e.g. 5e-324 ended up as 0e0) and had precision issues where
NOT the closest representable num was generated for a given string, which causes value drift in repeated num->str roundtripping.
... (8 more lines)
MoarVM: 517e26f045 | (Zoffix Znet)++ (committed using GitHub Web editor) | src/strings/parse_num.c
Merge pull request #850 from MoarVM/nummy-num

Nummy num
MoarVM: Kaiepi++ created pull request #851:
Fix installs having an outdated version		 05:01
06:16 domidumont joined 06:23 domidumont joined 06:44 robertle joined 07:18 lizmat joined 07:37 brrt joined
Geth MoarVM/jit-stack-walker: 5 commits pushed by (Bart Wiegmans)++ 07:42
brrt not actually a rebase, though
07:49 lizmat joined 08:24 zakharyas joined 08:27 zakharyas joined 08:28 brrt joined 08:49 FROGGS joined 08:51 FROGGS joined
jnthn Jit Stackwalker sounds like a character from a VM-internals Star Wars rip-off :) 08:59
Geth MoarVM/jit-stack-walker: 7b1f287ada | (Bart Wiegmans)++ | 2 files
[JIT] Extract finding inline for dynlex to JIT

JIT entry label should not leak out to dynamic lexical lookup.		 09:00
brrt it kind of does, doesn't it
with that in place, lets' try and activate the stack walker... 09:02
it breaks, and it breaks because tc->cur_frame points to a caller while returning, which is not on the stack 09:10
jnthn Caller or callee? 09:11
brrt caller, I think 09:12
jnthn Oh, as in, it's JITted code is not on the stack
brrt correct, not on the C stack, I mean :-) 09:13
jnthn Hmm. 09:15
What do we try and look up during this time?
brrt the proper jit entry label 09:17
well, the current position in the jit frame 09:18
line src/core/frame.c - line 868, we update the tc->cur_frame to its caller;
line src/core/frame.c - line 908, we call the special unwind 09:19
src/6model/6model.c:71 - we try to die 09:20
now, in my branch; src/jit/interface.c:27 if (tc->cur_frame == frame) 09:21
hmm
09:27 brrt joined
FROGGS jnthn: I think I'm going to merge the inlined-shaped-carray branches (moarvm/rakudo) today 10:08
jnthn: and I'll put a lock in setdebugname, or what the op was called 10:09
jnthn FROGGS: Alright...this soon after release sounds like a good time :)
FROGGS aye
:o)
10:34 zakharyas joined 10:35 AlexDaniel joined
Geth MoarVM: 8610b8581b | (Tobias Leich)++ | 2 files
Implement one dimensional inlined shaped CArrays

A C(PP)Struct can now hold an inlined array with a fixed sized shape. There is one issue though. We always assumed that CArray attributes of CStructs will always hold pointers to other things than numeric types. I've changed the default for inlined CArray attributes which have a shape. The memory of the CArray slots will be inlined by default as well. If someone wants the opposite, (s)he can declare a CArray of pointers.		 10:52
MoarVM: 25f165ad70 | (Tobias Leich)++ | 5 files
Add CPPStruct/CUnion-reprs where it was forgotten
 10:53
MoarVM/jit-stack-walker: 2a871f3bae | (Bart Wiegmans)++ | 3 files
[JIT] Activate stack walker for current frame

Look up the current return address based on the stack layout. Only works with -fno-omit-frame-pointer.		 10:54
MoarVM/jit-stack-walker: a575805509 | (Bart Wiegmans)++ | 2 files
[JIT] Remove redundant dynamic label assignments

Now that we can look up the current position in the JIT frame via stack walking, it is no longer required to load the jit entry label on the start and end of frame handlers and at the start of every basic block.
As basic block entry is quite a bit more frequent than looking up dynamic lexicals or throwing exceptions, I hope this should provide a nice speedup.
brrt these ^ are the scariest two commits i have done for some time
oh, and i've already found a bug 10:56
11:19 brrt joined
Geth MoarVM/jit-stack-walker: 960dd4af48 | (Bart Wiegmans)++ | src/core/exceptions.c
[JIT] Also extract selecting active lexical handlers

Forgotten this bit. Not sure if correct though.		 11:20
11:27 zakharyas joined 11:59 domidumont joined 12:34 domidumont1 joined 12:47 domidumont joined
Geth MoarVM/jit-stack-walker: 9 commits pushed by (Bart Wiegmans)++ 13:14
brrt surprisingly enough, this works. I now encourage all of you to test and benchmark this against master 13:16
jnthn brrt++ 13:46
Will give it a go later
brrt if you're on windows, it might well not work 13:48
because I expect microsft's assemlber to disagree (if it is configured at all)
jnthn Primarily on Linux these days 13:49
brrt i'm probably going to have to setup a VM anyway 13:51
14:27 domidumont1 joined 15:01 TimToady joined 15:51 robertle joined 16:22 domidumont joined
Geth MoarVM/pluggable-spesh: e963b0500c | (Jonathan Worthington)++ | src/mast/compiler.c
Implement bytecode assembly for speshresolve
 16:42
dogbert17 WARNING: unhandled amd64-linux syscall: 1000318 # haven't seen valgrind say this before 16:52
jnthn Me either :) 16:54
ooh, actually I do see it 16:55
Hmm
cooking & 16:57
robertle I have some more data on the mips failures in R#1711, mostly that it still happens with MVM_SPESH_DISABLE and that it is still intermittent with MVM_SPESH_NODELAY. I tried changing the "Bytecode validation error" macro to get better messages, but might have gotten that wrong. any pointers on what else to try very welcome... 16:59
synopsebot R#1711 [open]: github.com/rakudo/rakudo/issues/1711 [severe] intermittent "Bytecode validation error at offset 0, instruction 0" on s390x/mips
nine .tell brrt csv-ip5xs.pl performance is well within noise. 17:55
yoleaux nine: I'll pass your message to brrt.
robertle there is a lot that I do not understand about src/core/validate.c, but doesn't the malloc+memset in the #ifdef MVM_BIGENDIAN in MVM_validate_static_frame mean that we are not actually validating anything? did I get that right? also, why doesn't this leak memory like a sieve? 18:52
timotimo we only do that once per chunk of bytecode, no? 18:55
that's a limited amount of things 18:56
robertle ok, not really worried about the leak... but what is it with the memset? 19:00
why does that not wreck the static_frame we pass in? and why does this ever validate, shouldn't all opcodes be DBDB afterwards? which would be a rather large opcode... 19:01
timotimo validation when endian switching is on will copy from the original code and switch bytes afterwards 19:04
the memset is potentially there so we know when we forgot to do something? 19:05
robertle ah! so ensure_bytes overwrites the stuff we did memset from src_cur_op... 19:08
timotimo right
robertle would it help if I made it hexdump the whole bytecode body in these error conditions?
timotimo i guess? does this ever trigger? 19:09
robertle yes, but only about 1 in every 100 runs on the most trigger happy test cases
I get the "invalid extension opcode %u - should be less than %u" case 19:10
timotimo oh, ah
does rr run on that system?
robertle what's rr? 19:11
timotimo mozilla's time-travelling debugger extension for gdb 19:12
robertle ah that 19:13
I had trouble even getting plain gdb to work in these cases, but perhaps the time travelling would help 19:14
but when I get into these cases, I don't seem to have a valid stack anymore
timotimo right
if jit is turned on, stacks are never there, but your arch doesn't have a jit for it, so ...?
robertle so perhaps something unrelated has wrecked the stack, and this validation error is just the result of that. note that this seems to happen only in the presence of threads 19:16
timotimo possible, but our bytecode isn't on the stack, and neither is the "current operation" pointer i think? 19:17
robertle hmm, not sure about the current op pointer: it's part of the Validator struct which is set up as Validator val[1]; 19:21
timotimo oh, it's dieing inside the validator 19:22
silly me
sorry, i'm not all present
robertle I am still working on the non-presentness... *klink* 19:23
19:23 Kaiepi joined
dogbert17 jnthn, samcv: I believe that the mysterious valgrind msg started to appear with github.com/MoarVM/MoarVM/commit/b0...aeed01791c 19:24
19:51 Kaiepi joined 20:07 Kaiepi joined 20:25 Kaiepi joined
jnthn github.com/MoarVM/MoarVM/commit/b0...986d960R95 :) 20:26
I think it's genuinely that valgrind perhaps doesn't know that syscall :)
If the syscall didn't work, I think we'd know about it. :)
21:27 MasterDuke joined
MasterDuke .tell brrt i didn't see any noticeable difference running Tux's test-t and test-t --race scripts on the jit-stack-walker branch 23:31
yoleaux MasterDuke: I'll pass your message to brrt.
23:51 mtj_ joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!