TI: Fix benchmark analysis results




JavaScript Engine
7 years ago
3 years ago


(Reporter: bhackett, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)




7 years ago
With the various inference bugfixes and other changes over the last few months, the precision of the resulting type sets has degraded to 80% monomorphic on SS, 65% on V8, from a previous behavior of 90-95% on both.  For JIT optimizations to work on these benchmarks, the previous behavior needs to be restored.

Comment 1

7 years ago
Use new type objects for calls to 'new' which are immediately assigned to a .prototype.  This catches things like:

 function Super() { ... }
 function Sub1() { ... }
 function Sub2() { ... }

 Sub1.prototype = new Super();
 Sub2.prototype = new Super();

Letting us distinguish properties of the two prototypes (since they have different type objects) and the new objects created with them.  This will be important for v8-deltablue, which has a class hierarchy set up in a similar way to this, and several very hot call sites which could be calling one of a few prototype methods depending on the class.  We will probably want to inline all possible targets, and dispatch on the value of obj->type or obj->type->proto to figure out which to use.


Comment 2

7 years ago
Fix FrameEntrys to remove their TypeSet pointer, and instead maintain the current stack of type sets in the FrameState.  Removes a lot of cruft when pushing values, and also lets us always know the type sets for stack entries (except those which were on the stack at the last join point).


Comment 3

7 years ago
Type check function this/arguments when a JITScript is invoked through invokeEntry (the entry point which does an arity check and assumes it can be called from anywhere).  Previously this/arguments were just marked as unknown if this entry point was ever used, even if inference understood the callsite but the call IC mechanism used the invokeEntry to handle argc mismatches or polymorphism.

This uses a new MIC, one per JITScript, which generates code to do the type checking as necessary (flushed on GC in case referenced type objects are collected).


Comment 4

7 years ago
Keep track of entire type sets when remembering the rhs of monitored setprop/setname and arguments to monitored calls. Previously we only remembered a single type, and if there were multiple possible types for the rhs (object or null, or one of several objects) then the property/arguments ended up getting marked as unknown.



3 years ago
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.