IonMonkey: Remove failing boundschecks on GWT linpack benchmark




6 years ago
5 years ago


(Reporter: h4writer, Unassigned)


(Blocks 1 bug)

Firefox Tracking Flags

(Not tracked)




6 years ago
We are bailing on :428 due to boundschecks. This sounds bogus. Haven't found yet why we are failing them, investigating now. Removing the bailouts would increase our performance from 2.03s to 1.82s


6 years ago
Blocks: 870627

Comment 1

6 years ago
Not sure what the solution is. I will have to discuss it with other people.
So this is a small testcase showing the behaviour in linpack GWT. This will bail every time create_array gets called:

function create_array(length){
  var array = new Array(length);             (1)
  for (var i = 0; i < length; ++i) {
    array[i] = 0;                            (2)
  return array;
function test() {
  for (var i = 0; i < 10; i++) {
   var arr = create_array(1001);
   var a = ["&"];
   arr[a[1]] = 1;                            (3)

array->resultTypeSet() =>  object[1] [0xb5830be0]
[0xb5830be0] : <0xb583d010> unknown {} 

As a result of that array typeset:
types->unknownProperties() == true
types->hasObjectFlags(cx, types::OBJECT_FLAG_LENGTH_OVERFLOW) == true
ElementAccessHasExtraIndexedProperty == true
writeOutOfBounds == false

so we use MStoreElement instead of MStoreElementHole
(this last one wouldn't bail, since it supports adding to array)

Here we do a JSOP_SETELEM with a string as index. MonitorAssign get's called and MarkTypeObjectUnknownProperties(cx, obj->type()); So that's the reason we have no type information or unknownProperties. I don't know what the reason is for this and hg annotate and following bugs didn't show me good information ...

So I'm a bit in the dark what we want to change? Do we want to adjust (2) and use MStoreElementHole for unknownProperties? Or is the optimization in 3 maybe not needed anymore?
Assignee: general → nobody
You need to log in before you can comment on or make changes to this bug.