mozilla :: #ionmonkey

11 Sep 2017
11:28nbpjandem: Do we garbage collect BaselineScripts at all, except when turning on the Debugger?
11:29jandemnbp: there are some heuristics to discard baseline scripts on GC
11:29jandemonly script that are not active on the stack
11:54nbpjandem: would it make sense to keep them slightly longer, unless this is a shrinking GC?
11:54jandemnbp: we already keep them if the Zone has frames on the stack
11:54jandemnbp: i looked at this a while ago and always keeping them didn't affect speedometer much
11:55jandembut we could consider changing it maybe
11:56nbpjandem: I saying so, because I recently noticed (Bug 1394761), that we could run code coverage - instrumented interpreter after having baseline compiled a script.
11:57nbpjandem: That should be an easy fix, what makes me wonder is why did we return in Baseline.
11:58nbpjandem: I wonder if this is the hack from the facebook devs, to delazify every functions by executing them a few times. (so I heard)
11:58jandemnbp: so is the problem that we run in the interpreter after baseline compiling?
11:59nbpjandem: yes.
11:59nbpjandem: GC-ing them would be an explanation.
11:59jandemnbp: that can also happen with recursive calls
11:59jandemwe enter baseline while the script is on the stack in the interpreter
11:59nbpwouldn't we OSR on loop headers?
12:00nbpjandem: I would not expect that to be frequent enough to appear in profiles.
12:00nbpor maybe once in a profile, but not in every profile.
12:01jandemwe should OSR at some point yes
12:27evilpienbp: jandem: how much % of ember bench are we running in jit?
12:28nbpI have no idea
12:34evilpiemostly baseline?
12:42anbaevilpie: I'd need to remeasure the calls to js::array_push and then compare to the previous numbers in bug 1386001
13:32nbpevilpie: array.push(a,b,c) is optimized in Ion. I have not seen above-the-noise variations in any speedometer benchmarks after landing it.
13:33nbpevilpie: There is certainly room for improvement in js::array_push builtin, as unrolling the loop in Ion was still twice as fast, while not being optimal.
15:06nbpIt is fun to see other engines catching up:
16:17nbplth: are you going to replace --no-threads by --no-cpu ? :D
16:17lthnbp: ooh, good idea :)
16:18lthI guess that's another nail in the coffin for --thread-count, in that it is not actually related to --no-threads
16:18lth--no-threads means, no background helper threads
16:19lthcompletely unrelated!
16:20* lth 's head explodes
12 Sep 2017
No messages
Last message: 10 days and 1 hour ago