01:48 ilbot3 joined 06:18 TimToady joined 07:38 domidumont joined 07:41 brrt joined 07:43 domidumont joined
brrt okay, here's a new idea 07:55
whenever we allocate something, we need to flush all object values into memory 07:56
nwc10 "why?" 07:59
(I'm trying to be a bit more useful than a teddy bear, but I can't work out where you're coming from/where this is going) 08:00
oh, that's where :-/ 08:02
08:05 brrt joined
brrt they can be moved by the garbage collector 08:05
so, lets suppose i keep a pointer to an object in a register 08:07
nwc10 (I think I see where you're going now) 08:09
brrt okay :-) cool
the second part of the idea was (aside from setting an 'allocates' flag on the op), to maintain both the node and the root for the last definition of a local 08:10
nwc10 more pedantically, it's "just before we do anything that potentially might allocate, we need to flush all object values to memory (in case the GC runs)" ? 08:11
brrt why? so if we decide we have to flush them, we can figure out which pointer to update as well
yes
that's basically what i was trying to say
nwc10 it feels like maintaing correctness here is going to be expensive. (this feels like a flippant statement too - of course correctness is what really matters.) 08:12
brrt well, yes, it is
that's why moving generational collectors are not super-awesome from the perspective of JIT compilation 08:13
nwc10 this follows now that you make the reason clear, but I wouldn't have reached this conclusion alone
(although I might if I'd been studing them hard and trying to implement one) 08:14
brrt the flushing-bit isn't all *that* expensive, though, because spilling values from memory arround a function call is what you'd have to do anyway 08:15
so the difference is mostly that you spill them to an 'approved' location where the GC can update them 08:16
jnthn Functions that really need calling might call into the allocator, and indeed we have to handle them with such spills. 09:46
yoleaux 01:20Z <Zoffix> jnthn: did your encoding rework affect precomp stuff? I'm getting file-rename errors on Win10, and I had no build issues on 2017.05 release, so it's something new: rt.perl.org/Ticket/Display.html?id=131378
jnthn The situation for sp_fastcreate and even create need not be so dire, however. 09:47
We allocate in the nursery, which is a bump-the-pointer allocator. The allocation will only trigger GC if the bump takes us over the end of the buffer. 09:48
So the allocation process is just a bit of arithmetic in the common case, which could be emitted directly inline in the JITted code as it's probably small enough 09:49
Now of course, the occasional allocation could fail, in which case, yes, we'd want to fall back to the function
So we could conditionally spill/restore in that slow-path case
If the spill/call/restore was emitted at the end of the JITted code and branched to, then we get a predictable (very rare) branch and the rarely executed code will typically not take up I-cache lines 'cus it won't be needed much. 09:51
09:51 robertle joined
jnthn A mechanism for sticking "oh, dammit" paths at the end of the JITted output is probably generally worthwhile for that reason; deopt handlers could also be pushed down there. 09:55
.tell Zoffix Hm, I can reproduce it also, though I have no idea at all what could have caused it. As nine++ mentioned on the RT, it's pretty much always about a missing .close 10:02
yoleaux jnthn: I'll pass your message to Zoffix.
10:29 domidumont joined 10:37 brrt joined
brrt .tell jnthn that is a pretty good idea, i think; we could use a separate section for that 10:39
yoleaux brrt: I'll pass your message to jnthn.
brrt ('bad path' code, i mean) 10:45
would keep the 'good path' code a bit shorter 10:47
jnthn Aye 10:53
brrt hmm 10:54
i don't really have a good hypothesis for my breakage of sp_fastcreate 10:55
it breaks by a segv on elems on.. something, not sure what
i've created just two objects by then
jnthn What's the template/assembly look like? 10:56
brrt but i think it also breaks if i create just the first object
gist.github.com/bdw/62320648e0fe0b...8f4f51b8d5
the first is the one that is expr-jitted, which breaks, the second is the one which is 'original', which works 10:57
they look functionally pretty much identical to me 10:58
jnthn Is the STable pointer sensible immediately after sp_fastcreate? 11:05
mov rcx,0x88 mov QWORD PTR [rbx+0xd8],rcx 11:06
Hm, it spills a constant? :) 11:07
But yeah, I agree they look functionally identical 11:10
11:47 AlexDani` joined 12:50 brrt joined
brrt yes, that needs optimization 12:51
13:49 dogbert17 joined 15:22 domidumont joined 15:25 committable6 joined, bisectable6 joined 16:31 zakharyas joined 16:45 brrt joined 17:09 brrt joined 17:25 brrt joined 18:10 brrt joined 18:54 zakharyas joined 19:15 brrt joined
samcv good * 21:05
yoleaux 14:08Z <Zoffix> samcv: would you have an idea about the bug in this ticket? The bug behaviour feels a lot like that case-insensitive regex match issue we had: rt.perl.org/Ticket/Display.html?id=131383
samcv on it Zoffix 21:06
22:55 Zoffix joined 23:00 benchable6 joined, quotable6 joined, bloatable6 joined, evalable6 joined, committable6 joined 23:01 bisectable6 joined 23:29 greppable6 joined, unicodable6 joined, statisfiable6 joined