If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

JM: With fatvals+tracing, specialize unboxing numbers from getelem when it helps

RESOLVED WONTFIX

Status

()

Core
JavaScript Engine
RESOLVED WONTFIX
7 years ago
6 years ago

People

(Reporter: dmandelin, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
See bug 572029 for background. Even after the fix for that bug, we can still get another 15-20ms win on crypto and fannkuch if we are smart about doing specialized unboxing from getelem. The key is being able to predict when specializing for int or double is a good idea. Ideas we've come up with:

1. Start by fully specializing. Keep a bit per trace tree (or maybe script) that indicates if we've misspeculated after a getelem. Once it is set, use the common number path instead. This limits the damage to 1 per tree (or script).

2. Try to predict by looking ahead in the bytecode stream. If we can find the consumer of the result of the getelem, we can make a good guess. If the consumer is a setelem, we should use the common path, because that enables the box-after-unbox optimization. If the consumer is a bitop and the value is an int, we can guess that that is stable. Further empirical observation would tell us what to do for other cases.

3. Wait for type-specialized arrays, which may just make this problem go away.
(In reply to comment #0)
> 
> 3. Wait for type-specialized arrays, which may just make this problem go away.

Yeah, I was about to pipe up and suggest that... :)
Obsolete with the removal of tracejit.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.