Bug 96891 – Array profiling has convergence issues

• Component: JavaScriptCore
• Status: RESOLVED FIXED

[Filip Pizlo]

Consider the following code:

function foo() {
    var o = {};
    o.length = 5;
    for (var i = 0; i < o.length; ++i)
        o[i] = i;
}

Currently, array profiling will always say that 'o' is NonArrayWithArrayStorage, even though on the first iteration it's a NonArray (as in it has no array storage).

We could catch this corner case in one of two ways: (1) OSR exit profiling or (2) more precise baseline profiling.  I prefer (2) because we usually only like to rely on (1) in pathological cases.  The above does not feel like a pathological case - it seems rather sensible to write a program that has a loop, where the first iteration of that loop does special things.

Of course, we could also kill off this pathology, at least in most cases, by relying on loop peeling.  But for now, I think having a more precise array profiler just feels like a nicer solution

[Filip Pizlo]

Created attachment 164328 [details]
the patch

[Build Bot]

Comment on attachment 164328 [details]
the patch

Attachment 164328 [details] did not pass win-ews (win):
Output: http://queues.webkit.org/results/13873232

[Filip Pizlo]

Created attachment 164330 [details]
the patch

Fix non-DFG builds.

[Filip Pizlo]

Landed in http://trac.webkit.org/changeset/128790

[Csaba Osztrogonác]

(In reply to comment #4)
> Landed in http://trac.webkit.org/changeset/128790

It broke the Qt ARM build - https://bugs.webkit.org/show_bug.cgi?id=96968

Could you check it, please?

[Filip Pizlo]

(In reply to comment #5)
> (In reply to comment #4)
> > Landed in http://trac.webkit.org/changeset/128790
> 
> It broke the Qt ARM build - https://bugs.webkit.org/show_bug.cgi?id=96968
> 
> Could you check it, please?

It broke your build because I introduced new assembler functionality.

It's up to you guys to implement assembler functionality on your platforms.