github.com/moarvm/moarvm | IRC logs at colabti.org/irclogger/irclogger_logs/moarvm
Set by AlexDaniel on 12 June 2018.
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
nwc10 good *, #moarvm 07:57
jnthn morning o/ 09:29
nwc10 \o 09:32
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.
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
timotimo can you try breakpointing prof_enter? 16:25
MasterDuke sure, but what should i do when it hits? 16:33
MasterDuke i already did add some fprintf logging before. i did see the 'push' in question show up 16:36
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
MasterDuke hm, let me add an if and breakpoint in there 17:00
MasterDuke so mode == MVM_PROFILE_ENTER_SPESH ? 17:04
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
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
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
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
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
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
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
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
MasterDuke oh. rotate.spesh.log was not during a profile but roteate.spesh.log was 23:55

Powered by Cro and the Raku® Programming Language.

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

Thank you!