832364 - IonMonkey: add paths for dense element accesses on native objects

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Brian Hackett [Laid off!]]

For native objects, accesses on 'own' dense elements that are property hits always work the same way.  However, even if we have compile time information that an element access is on a native object, we only compile a fast path for the access if the object is known to be an array with no sparse indexes or indexes in its prototypes.

This might be hurting on several Kraken tests.  Bug 827490 caused regressions in several tests in this suite, and all of the regressing tests use a generic get or set element path at some point.  I don't know whether this is actually the cause, but after bug 832360 it will be an easy fix and might as well do it.

Comment 1

[Brian Hackett [Laid off!]]

Attachment: patch

Comment 2

[Brian Hackett [Laid off!]]

Oh, re: comment 0 this shouldn't help kraken at all (bug 832578 took care of that) but is good for robustness and is necessary for (near) future work on desparsifying arrays.

Comment 3

[Jan de Mooij [:jandem]]

Comment on attachment 705904 [details] [diff] [review]
patch

Review of attachment 705904 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/ion/TypeOracle.cpp
@@ +428,5 @@
>  
>  bool
> +TypeInferenceOracle::elementWriteHasExtraIndexedProperty(UnrootedScript script, jsbytecode *pc)
> +{
> +    StackTypeSet *obj = script->analysis()->poppedTypes(pc, 1);

This should be 2 I think.

::: js/src/jsinfer.cpp
@@ +2065,5 @@
> +            nproto = object->proto.get();
> +        else
> +            continue;
> +
> +        if (i) {

Will testing |i| always work with the |continue| above? Should we check proto != NULL instead?

Comment 4

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e6d6b014a076

Comment 5

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e6d6b014a076