1828115 - Change inlining rules based on tenuring information?

Status: ASSIGNED

(Core :: JavaScript Engine, task, P1)

Description

[Nicolas B. Pierron [:nbp]]

IonMonkey is capable of doing wonders when provided full contextual information on the life time of object it manipulates, such as doing Scalar Replacement of the object allocation, and removing the computation of some fields that are unused. The problem is knowing this information ahead of the compilation.

The Garbage Collector is already dealing with lifetime information, by moving objects out of the nursery if they are still reachable. When the nursery is collected, by iterating over the store buffer and moving object to the tenured space is one way to get the information whether allocated objects are escaping.

Objects which are infrequently moved to the tenured space might still be assigned to properties of objects which are not exiting the nursery. This case should be supported by Scalar Replacement as long as there is no cycle.

Thus, can we use the tenured statistics as a way to approximate the potential for Scalar Replacement opportunities? And would we gain any performance benefit out of it?

Comment 1

[Nicolas B. Pierron [:nbp]]

Attachment: Bug 1828115 - Exfiltrate tenuredStats information each time a call is made with an IC. r=

This patch extract tenuredStats information from nursery allocation which are
used either as returned value or as arguments.

For the returned value, the JitScript is annotated with the tenuredStats
information corresponding to its result.

For arguments, a new field is added as part of the CallIC to collect the
escapeStats information, extracted from each argument given at every function
calls.

The TrialInlining is then modified to extract these information and apply
different inlining rules based on JIT_OPTION_* variables, defined in the
running environment.

Comment 2

[Nicolas B. Pierron [:nbp]]

Attachment: Bug 1828115 - Add AllocSite hints to CallScriptedFunction CacheIR.

When creating a CallScriptedFunction CacheIR, we also optionally annotate it
with the scripted AllocSite of its arguments. The intent is to carry information
captured during the IC creation as a hint for inlining calls which are dealing
with infrequently tenured objects.

Comment 3

[Nicolas B. Pierron [:nbp]]

Attachment: Bug 1828115 - Change inlining rules to favor short-lived objects.

This patch updates the inlining rules to use the information collected by
nursery collection.

When the nursery is collected, the garbage collector is tracking whether an
object should be preferably allocated in the nursery or preferrably tenured by
default.

When attaching call ICs, we record the AllocSite, where the nursery collection
record the number of tenured allocations, and use it as a hint to update our
inlining rules in favor of weaker constraints to in hope to give more contextual
information to scalar replacement.

Comment 4

[Nicolas B. Pierron [:nbp]]

These patches are an interesting area of investigation, but despite some interesting results with the dirty prototype, this yield some speedometer 3 results which are mitigated by having both improvements and regressions depending on the sub-benchmarks.

The overall results is also mitigated … as it yields a score which is 0.04% better and a total time which is 0.34% worse.

I suspect one can tune the parameters to please the benchmarks …

Comment 5

[Nicolas B. Pierron [:nbp]]

Doug, you were looking for data points regarding changes of inlining rules and the consequences of it. I think this might be of interest for you if you want to investigate further.

Denis, any idea whether the focus is on the score or on the total time?

Comment 6

[Alex Thayer [:alexical] (she/her)]

Can you do a run where we collect all the needed information but don't use it to make a different inlining decision, so we can try to isolate the overhead of the decision from the performance impact of the decision itself?

Comment 7

[Iain Ireland [:iain]]

Markus and Jeff and I are talking about this. The comparison report tool is currently built on hardware profiles, which don't know about inline frames, so we can't use the tool directly to figure out why Vue doesn't like this change, but Markus thinks that he might be able to tweak his tool to compare profiles taken by the Firefox profiler, which already knows about inline frames.