github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
00:12 travis-ci joined
travis-ci MoarVM build errored. Jonathan Worthington 'Merge pull request #1283 from MasterDuke17/fix_order_of_calloc_arguments 00:12
travis-ci.org/MoarVM/MoarVM/builds/684062990 github.com/MoarVM/MoarVM/compare/6...917b192b1c
00:12 travis-ci left 00:56 farcas1982regreg joined 01:05 AlexDani` joined 01:07 AlexDaniel left 02:13 Kaeipi left 02:14 Kaeipi joined 06:04 AlexDani` is now known as AlexDaniel, AlexDaniel left, AlexDaniel joined 07:30 MasterDuke joined 07:45 Altai-man_ joined
nwc10 good *, #moarvm 07:57
08:09 zakharyas joined 08:16 sena_kun joined 08:18 Altai-man_ left
jnthn morning o/ 09:29
09:30 MasterDuke left
nwc10 \o 09:32
09:40 AlexDaniel` left 09:57 AlexDaniel` joined 10:15 Altai-man_ joined 10:18 sena_kun left 10:38 farcas1982regreg left 10:48 MasterDuke joined 11:43 farcas1982regreg joined 12:16 sena_kun joined 12:18 Altai-man_ left 12:24 Geth left, Geth joined
Geth MoarVM/new-disp: 82ac00d819 | (Jonathan Worthington)++ | 10 files
Switch boot C code over to new args handling

Since a bunch of these are going to be added in order to implement the boot dispatchers, we may as well write them as they eventually should look rather than having more things to tweak later. This also gives an opportunity to get a few more missing pieces in place with regards to the new args handling: the identity map and support for fetching named ... (6 more lines)
13:28
jnthn hacky hack is hacky 13:30
(Also, temporary)
lizmat
.oO( famous last hack :-)
13:32
[Coke] SHIP IT NOW WHILE HE'S NOT LOOKING 13:34
jnthn So, what's the next layer of yaks... 13:35
nine "Temporary workaround. Very temporary, given it's totally leaky." but...but....doesn't "leaky" mean it's less temporary than it ought to be? 13:50
[Coke] <sensible chuckle.jpg> 13:52
jnthn :P 13:57
Geth MoarVM/new-disp: 9d14d47312 | (Jonathan Worthington)++ | src/core/interp.c
Properly fetch dispatcher ID from bytecode
14:10
MoarVM/new-disp: 02781d56dd | (Jonathan Worthington)++ | 5 files
Implement looking up dispatchers in registry

Plus add GC marking of the dispatcher registry.
14:15 Altai-man_ joined 14:18 sena_kun left
Geth MoarVM/new-disp: e5e8137293 | (Jonathan Worthington)++ | 3 files
Sketch out invoking the dispatch callback

Only for built-in C functions for now. We form the capture and pass it along as an argument to the dispatch. Doing this really properly will depend on upcoming call stack changes.
14:47
jnthn Well, that gets me to a range of possible next adventures... :) 14:51
timotimo whew 15:03
MasterDuke timotimo: any suggestions for next steps trying to figure out the weirdness with the speshing/jitting of that .rotate example? 15:37
16:15 Kaeipi left, Kaeipi joined 16:16 sena_kun joined 16:18 Altai-man_ left 16:20 AlexDaniel left 16:22 AlexDaniel joined, AlexDaniel left, AlexDaniel joined
timotimo can you try breakpointing prof_enter? 16:25
16:28 Kaeipi left 16:29 Kaiepi joined
MasterDuke sure, but what should i do when it hits? 16:33
16:34 Kaiepi left
MasterDuke i already did add some fprintf logging before. i did see the 'push' in question show up 16:36
16:37 Kaiepi joined 16:43 Kaiepi left 16:45 Kaiepi joined
timotimo OK and what does the stack look like when push shows up? 16:46
of course not the first time, it's gotta be speshed first
16:46 patrickb joined
MasterDuke hm, let me add an if and breakpoint in there 17:00
17:01 Kaeipi joined
MasterDuke so mode == MVM_PROFILE_ENTER_SPESH ? 17:04
17:05 Kaiepi left
MasterDuke oh, push never has that mode 17:10
2001172 logs of push with mode MVM_PROFILE_ENTER_NORMAL, 656 logs of mode MVM_PROFILE_ENTER_JIT_INLINE, and 172 logs of mode MVM_PROFILE_ENTER_JIT 17:11
17:14 Kaeipi left
MasterDuke timotimo: i had to add a something to break on, so that's why there's an MVM_dump_backtrace 17:18
gist.github.com/MasterDuke17/4b9a1...a4594f13b9 17:19
17:19 Kaiepi joined 17:20 Kaiepi left
MasterDuke i did `if (strcmp(MVM_string_utf8_encode_C_string(tc, sf->body.name), "push") == 0 && mode != MVM_PROFILE_ENTER_NORMAL) {` 17:20
timotimo: btw, still loving how i get links to the files on github in the gist 17:24
17:30 zakharyas left
timotimo :) :) 18:09
which mode is 3 again?
MasterDuke MVM_PROFILE_ENTER_JIT 18:10
timotimo hm, ok, how best to continue 18:11
maybe going to the "dump node" call when it has the same pointer for the profile log
MasterDuke which pointer? 18:12
timotimo the profile call node where it puts the +1 in for the enter jit call
MasterDuke why is methnotfound_callsite in the backtrace?
timotimo jit fucks up the stack
18:15 Altai-man_ joined 18:18 sena_kun left 19:08 farcas1982regreg left
MasterDuke hm. you don't think it's related to the weirdness? 19:19
so &pcn in MVM_profile_log_enter ? 19:22
nine Do you remember the gcc plugin I wrote to find GC issues, waaaaaaaaay back in April? It has bitrotted 19:54
[Coke] ... wow 19:55
nine It's based on the Python GCC plugin which in theory is compatible with Python 2 and 3, but really only with Python 2 which got removed for good with the latest openSUSE Tumbleweed update
MasterDuke whoops. not even any packages available to install manually? 19:59
or you mean not available to run in the build service?
btw, i set a breakpoint at dump_call_graph_node. now that i'm there, i'm trying to refine it to a specific argument value. but it says 'No symbol "pcn" in current context.'. however, i can print pcn (though it's optimized out) 20:01
nine Well, there are a couple of python2 packages left, but e.g. python2-six isn't there anymore
at least there are community packages 20:02
timotimo MasterDuke: stack traces are always chaos when you're in C code called by the jit 20:03
and more often than not, for some reason, you'll have a callsite resolved as a frame name in there
MasterDuke: possibly the value is only available when your breakpoint is in a very specific spot 20:04
20:13 zakharyas joined 20:16 sena_kun joined 20:18 Altai-man_ left 20:57 [Coke] left 21:28 [Coke] joined 21:45 zakharyas left 21:55 pamplemousse left 21:56 pamplemousse joined 22:00 pamplemousse left
MasterDuke ok, i think i did it 22:11
timotimo: i'm broken right here with pcn == a pcn from when i broke in MVM_profile_log_enter 22:12
github.com/MoarVM/MoarVM/blob/mast...ent.c#L566
22:15 Altai-man_ joined 22:18 sena_kun left
timotimo ok, can you print pcn? 22:30
MasterDuke doh. i just exited 22:31
but it was `(MVMProfileCallNode *) 0x5555582b7d20`
timotimo the content would have been the interesting part :o 22:32
MasterDuke yep
timotimo ;(
sorry for not reacting quicker
MasterDuke no worries
i'm in the middle of writing out a profile-compile of AlexDaniel's coercers example 22:33
but i just realized, your branch hasn't been merged, right? the one that makes big profiles much faster
'cause this is taking a long time 22:34
arg. and i just realized i forgot to make it sql
timotimo fun 22:35
MasterDuke oh well, i'll try getting a breakpoint in dump_node again
timotimo oh, it hasn't been merged, but the release has happened, so it should be good to go
MasterDuke do it! 22:36
timotimo if anyone asks, masterduke did it! 22:37
MasterDuke ok. think i'm stopped in dump_node again 22:40
$4 = {sf = 0x555556f46868, cur_entry_time = 133990233724747, cur_skip_time = 0, entry_mode = 4, pred = 0x5555582bd4a0, succ = 0x5555582be520, num_succ = 2, alloc_succ = 8, alloc = 0x5555582be2e0, num_alloc = 2, alloc_alloc = 8, total_time = 167097526698, total_entries = 2000, specialized_entries = 0, inlined_entries = 81, jit_entries = 94, 22:41
osr_count = 0, deopt_one_count = 0, deopt_all_count = 0, native_target_name = 0x0, first_entry_time = 133823135580909}
timotimo interesting. the spesh log would tell us at what number it decided to spesh that 22:42
MasterDuke huh. 0 spesh, but 94 jit
timotimo yeah, normally we either spesh and jit, or only spesh, but not usually both 22:47
if the same sub is called multiple times from one sub, it could have jit and jit_inlined entries in different numbers, though. unlikely, however 22:48
MasterDuke so a spesh log shows it being speshed. but the profile isn't seeing it 22:49
timotimo no, we don't add spesh if we enter jit 22:50
but we can't have jitted something without speshing it
MasterDuke that's what i don't understand. then how did it happend? 22:51
timotimo i'm sorry, what exactly are we talking about?
MasterDuke the numbers above show 0 spesh, but 94 jit. and you just said we can't have jitted something without speshing it 22:52
timotimo yes, which is why we don't +1 the spesh when we already +1 the jit
MasterDuke so you're saying it was jitted immediately after being speshed? being speshed is how it got jitted at all, but no count for spesh means the jit kicked in right away? 22:55
timotimo when a routine gets speshed and can be jitted, the speshed version is immediately discarded for space saving reasons 22:56
MasterDuke hm. why are there 2m+ calls, but only a couple are jitted? 22:59
timotimo i thought there's only 2k entries?
there's probably more than just this one "push", though? in the whole tree? 23:00
MasterDuke 2001000 calls for that 'push' in total 23:01
timotimo then there must be another pcn with the same sf? 23:02
MasterDuke hm. i can try setting another conditional breakpoint 23:03
$5 = {sf = 0x555556f46868, cur_entry_time = 133990238833753, cur_skip_time = 0, entry_mode = 0, pred = 0x555558380ec0, succ = 0x555558381920, num_succ = 1, alloc_succ = 8, alloc = 0x5555583816e0, num_alloc = 2, alloc_alloc = 8, total_time = 3224224, total_entries = 2000, specialized_entries = 0, inlined_entries = 0, jit_entries = 0, osr_count = 23:06
0, deopt_one_count = 0, deopt_all_count = 0, native_target_name = 0x0, first_entry_time = 133990234453618}
see if there's another? 23:10
timotimo started from the beginning or the same run? 23:11
MasterDuke same run
timotimo so that's later in dump_blah_node_blah
MasterDuke yep
timotimo i wonder how often in total it shows up 23:13
Geth MoarVM/master: 4 commits pushed by (Timo Paulssen)++ 23:14
timotimo i went and did it
MasterDuke $6 = {sf = 0x555556f46868, cur_entry_time = 133992295945947, cur_skip_time = 0, entry_mode = 0, pred = 0x555558439d90, succ = 0x55555843a2f0, num_succ = 1, alloc_succ = 8, alloc = 0x55555843a0b0, num_alloc = 2, alloc_alloc = 8, total_time = 1562357458, total_entries = 1998000, specialized_entries = 0, inlined_entries = 0, jit_entries = 0,
osr_count = 0, deopt_one_count = 0, deopt_all_count = 0, native_target_name = 0x0, first_entry_time = 133990239078273}
timotimo aha, there's all the interesting entries
m: say 133990239078273 - 133990234453618 23:15
camelia 4624655
MasterDuke i had a breakpoint in MVM_profile_log_enter to find the pcn, so the times may not make much sense 23:16
timotimo ah that's ok
well, anyway, this is not being speshed 23:19
MasterDuke yeah. but why... 23:20
23:21 Altai-man_ left
timotimo you can have look at the parent nodes (probably also visible in the C stack frames) and see if that gives any information 23:21
like the CUUID of this node's parent's SF could be correlated to the spesh log
MasterDuke hm, i'm not making a spesh log of this run 23:24
pcn of the parent (which is 'push-all'): $9 = {sf = 0x555556e694a0, cur_entry_time = 133992294169495, cur_skip_time = 0, entry_mode = 3, pred = 0x555558439920, succ = 0x55555843a040, num_succ = 1, alloc_succ = 8, alloc = 0x555558439e50, num_alloc = 1, alloc_alloc = 8, total_time = 1880406329, total_entries = 999, specialized_entries = 0, 23:27
inlined_entries = 0, jit_entries = 999, osr_count = 1, deopt_one_count = 0, deopt_all_count = 0, native_target_name = 0x0, first_entry_time = 133990239076593}
timotimo the cuuids should be stable across runs for everything that's not run-time-evalled
MasterDuke pcn->sf of the parent: $10 = {common = {header = {sc_forward_u = {forwarder = 0x0, sc = {sc_idx = 0, idx = 0}, st = 0x0}, owner = 1, flags = 16, size = 232}, st = 0x5555555c4bd8}, body = {bytecode = 0x555558380fe0 "\217\003\214", cu = 0x5555555edc60, local_types = 0x55555837b820, lexical_types = 0x555558380780, lexical_names = 0x555558380500,
lexical_names_list = 0x555558380710, static_env = 0x555558380de0, static_env_flags = 0x555558380760 "", has_state_vars = 0 '\000', allocate_on_heap = 0 '\000', no_inline = 0 '\000', specializable = 1 '\001', instrumentation_level = 3, spesh = 0x55555824d320, env_size = 72, work_size = 296, num_lexicals = 9, num_annotations = 3, work_initial =
0x555558380e30, bytecode_size = 500, num_locals = 17, handlers = 0x5555583813f0, num_handlers = 3, fully_deserialized = 1 '\001', is_thunk = 0 '\000', has_exit_handler = 0 '\000', cuuid = 0x555556e653b0, name = 0x555556e38400, outer = 0x555556e68f30, static_code = 0x5555571d9f10, annotations_data = 0x7ffff5a98e84 "z", orig_bytecode =
0x7ffff56f0c00 "\214", frame_data_pos = 0x7ffff4d52a5a "\350j\036", frame_static_lex_pos = 0x7ffff4d52b24 "", code_obj_sc_dep_idx = 1, code_obj_sc_idx = 7814, instrumentation = 0x555558381440}}
i see that cuuid in a spesh log i had taken before. and it's for 'push-all' 23:29
anything to look for? 23:30
timotimo hmm
how does the invocation of "push" from there look? 23:31
MasterDuke in the before or after?
timotimo also interesting bits will be the "statistics" for both push-all and push
after will be more interesting, but before could have something, too
MasterDuke should i send you the spesh log?
timotimo hm, OK 23:32
MasterDuke send.firefox.com/download/7ba73d36...dh6wMmnULA 23:33
the push-all cuuid is 1568
i don't remember the difference between the two files 23:37
23:40 pamplemousse joined
MasterDuke oh. rotate.spesh.log was not during a profile but roteate.spesh.log was 23:55
23:57 patrickz joined 23:59 patrickb left