In order to improve our tiering strategy, it is a good idea to start
by tiering up functions that will be used the most, as this is done in
most JavaScript engines.
To decide which function requires tiering, we use as a basic strategy
to define its compilation priority to 'func_size * number_of_calls',
this roughly approximates the time we spend in the function.
To handle prioritization, it seemed that using a concurrent
priority queue similar to BigUnits was causing concurrencies issues.
I then decided to use different priority queues for each worker thread.
R=clemensb@chromium.orgCC=thibaudm@chromium.org
Bug: v8:10728
Change-Id: I6f314468549000b2a9b51d3d470f04a0cb997879
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2367859
Commit-Queue: Arnaud Robin <arobin@google.com>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69585}
On desktop systems, we use a very basic tiering strategy: Everything is
initially compiled with Liftoff, and once that is done, the module can
start being used. Concurrently to the execution, we re-compile all code
with TurboFan, and hot-swap each function once TurboFan finishes.
We should start using a more dynamic strategy where each function is
tiered-up when judged necessary. This change will then tier-up each
liftoff function once it has been called 5 times.
I then added a counter in the native module, that is updated directly
from Liftoff code, and a runtime call is then made when the counter
reaches the goal.
R=clemensb@chromium.org
CC=thibaudm@chromium.org
Bug: v8:10728
Change-Id: I8dc2b02fdff8d97781bb1cf496886594b3d7f644
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2306803
Commit-Queue: Arnaud Robin <arobin@google.com>
Reviewed-by: Thibaud Michaud <thibaudm@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68971}
