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 |