00:10 LLamaRider joined 01:36 jepeway joined
dalek arVM: 6698db9 | timotimo++ | src/6model/reprs/CStruct.c:
guard against absent "inlined" keys in CStruct composition
01:45
arVM: aab1400 | timotimo++ | src/6model/reprs/CUnion.c:
also guard against absent "inlined" key in CUnion composition
01:47
timotimo these two commits can most probably be reverted when nqp gets its cunion branch merged 01:48
because then it will invariably have the inlined flag set (right?) 01:49
04:23 vendethiel joined 05:07 vendethiel joined
FROGGS[mobile] ohh, had not tested and thought about that 05:11
timotimo++ 05:12
07:02 Ven joined 07:11 zakharyas joined 07:47 FROGGS joined
FROGGS timotimo: I hope you did not lose too much time on the repr compose fix :S 08:02
08:09 Ven joined 08:12 vendethiel joined 09:39 vendethiel joined 10:07 vendethiel joined, lizmat joined 10:14 lizmat_ joined 10:52 Ven joined 12:00 Ven joined 12:04 vendethiel joined 12:53 vendethiel joined 13:31 brrt joined
brrt \o 13:31
jnthn o/ 13:33
brrt \o/ 13:35
i really really should put something on my blog now, shouldnt i 13:36
oh, also
i've taken it on myself to study at least one compiler-related paper each week until I start my project 13:37
jnthn Cool :)
brrt so I was wondering if anyone had any papers left :-)
jnthn I got sick around the weekend, and have been mostly devoting my time to taking care of things I really have needed to do and sleeping.
nwc10 "sleeping" is not by default in the list of "things I really have needed to do"? :-) [or is that :-(] 13:38
brrt sleeping is reducing technical mental debt :-P
apparantly, some people have pretty large mental credits
jnthn It is in the default list, it's more a matter of quantity. :)
(And yeah, I'm a lot better by now, I just need to take good care of myself to make sure I stay that way.) 13:39
brrt yes, that's a pretty good idea 13:41
timotimo FROGGS: only like ten minutes 13:49
before i fell asleep i was thinking about the profiler and how it logs allocations
and i thought perhaps the logging instruction is keeping allocating instructions alive simply by wanting to mark the allocation
so i'll investigate that today 13:50
JimmyZ brrt: : maybe wiki.luajit.org/Home#LuaJIT-Internals ? 13:55
brrt yes, i've been looking at that :-) 13:57
13:58 vendethiel joined 14:52 vendethiel joined
timotimo hmm. what's a good piece of code to run to figure out if allocations can be spesh'd out? 14:54
15:06 FROGGS joined 15:15 vendethiel joined
jnthn timotimo: I don't think logging instructions bump usage 15:24
timotimo: Especially as they don't make it into the final code ever
timotimo: And we dont' do any opts needing usage until after we tossed the logging instrs
timotimo logging, no; but prof_allocated yes 15:25
jnthn Also, note that create is marked as :pure, so those allocations that simply go unused get tossed already
Oh...
timotimo :)
jnthn True. :)
That's an interesting composition problem. :)
timotimo agreed
i have no data to back up my theory of "profiling increases allocations", however
i do have a patch already, though. because that was pretty easy to write the first version of 15:26
and i don't really have test code that could show if any problems exist :(
jnthn timotimo: I suspect you may be right about it.
timotimo: An NQP sub that does "sub foo() { my @x; 1 }" should show a create being eliminated
timotimo great
but i'll be AFK for a bit first 15:27
jnthn dinner & 15:33
timotimo um ... in the spesh log i don't see any prof_ ops at all 15:56
even after throwing out my local changes 15:57
the create actually gets thrown out already 15:59
maybe the profiling stuff gets added after a frame has been spesh'd, rather than before? 16:02
16:08 Ven joined 16:51 vendethiel joined 17:18 vendethiel joined
timotimo now i'm out of cool ideas again 17:33
17:43 vendethiel joined
dalek arVM: 6abbb1a | FROGGS++ | src/6model/reprs/CStruct.c:
fix handling of inlined CStructs
18:19
18:25 vendethiel joined
dalek arVM: 3898ac4 | FROGGS++ | src/6model/reprs/CUnion. (2 files):
handle CUnions in CUnions
18:30
timotimo maybe i'll just have a quick no-strings-attached look at deopt mechanisms 18:42
hmm, so the implementations of guard* directly call into deopt_one 18:53
so it's not quite as easy as making them look at an annotation right in front of them or something like that 18:54
maybe i should build a mirrored set of those instructions that branch instead of deopting
i probably don't want to compile a bridge for every guard, so making the guard* just branch and then having a generic deoptone/deoptall instruction isn't a good option IMO 19:02
i'll still want the generic deoptone/deoptall instruction for the end of the bridge, of course 19:03
19:08 zakharyas joined
dalek arVM: 4102a25 | FROGGS++ | src/6model/reprs/CStruct.c:
round CStruct up to a multiple of void*
19:11
19:57 brrt joined
nwc10 jnthn: paste.scsys.co.uk/480880 -- the same backtrace, attempting to get a mutex from within the GC 20:08
problem is that tc->instance->sc_weakhash is locked 20:11
line 15 of sc.c
and agan, attempted at line 93 of SCRef.c
comment at line 22 of sc.c explicitly thinks that this is impossible. 20:12
clearly not quite foolproof
bogosity seems to be this: MVMObject *obj = REPR(type)->allocate(tc, STABLE(type)); 20:15
I assume that that's a pointer to MVM_gc_allocate_object 20:16
and that *that* is ignoring the "use gen2, dammit" flag
brrt uhm, lets see 20:28
nwc10 - do you have a live gdb session 20:30
(i'd pay money for a service that let you share debugging sessions.) 20:31
otherwise i'd ask you questions about it 20:32
if you do have it live, can you give me the output of *tc 20:35
20:38 colomon joined
btyler brrt: tmux on a host you can both shell to? :) 20:45
brrt hmmm 20:46
that would work, but there is probably no such host
btyler nothing in p6 ecosystem space?
some folks have shell accounts for running irssi, I seem to recall 20:47
brrt i don't :-)
btyler ingy actually has some application for precisely this purpose. it fires up a cheap digital ocean or AWS host, imports bash/tmux profiles and ssh keys for both participants 20:49
github.com/ingydotnet/pairup there it is 20:50
and with that I'll stop going offtopic here
japhb screen will work as well as tmux. In fact, I have specifically used screen to do multi-user debugging many times in the past
btyler yes, apologies, no implied "tmux > screen"
japhb (Bloody necessary when you're sharing the serial console of the one hardware dev kit you could get your hands on.) 20:51
btyler: I wasn't taking it that way. I meant "if you can't install tmux somewhere, screen will do for this application, and it's more often already installed"
btyler ah of course 20:52
japhb It's like being an emacs person and knowing you can always fallback to vi, because it's hard to find a *nix machine without it. :-)
brrt yes, that is the great feature of vi 20:53
ok, but the point is 20:55
i don't have to pay money for that
but in about 18 months time
somebody will make a startup out of it
and they'll be valuated at a billion dollars 20:56
if and only if they say they'll kill e-mail
timotimo tmux is way better, btw :) 21:43
lizmat I once had Jesus tell me I should use tmux :-) 21:47
(it's a long story) 21:48
21:49 colomon joined
brrt that i can imagine 21:59
how long
timotimo was i the jesus? 22:25
brrt: what do you think: a complete duplication of all guard instructions + a generic deopt_one and deopt_all instruction? (i'm not sure if we can construct bridges for deopt_inline? but i haven't given it much thought) 22:27
brrt well... 22:28
i think deopt_inline is never called directly 22:29
but wait a minute, because there's something that's been bothering me for some time
and i have to check it
nah, i'm wrong 22:31
deopt is not the problem
but yes, that would be my plan of approach too
timotimo cool 22:37
cat was just about to paste some more text 22:38
brrt :-) 22:44
i'm going to sleep, by the way
timotimo oh 22:51
sleep
a thing i haven't tried in a long time