596865 - Consider doing propcache lookups on PIC misses

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Right now a PIC miss will do a js_GetProperty, which will do the full resolve, etc.  Would it make sense to use the propcache at that point to try to see whether we hit there?  Or are we pretty certain that if we missed the PIC we'll miss the propcache too?

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

It depends on the callsite, and why we're disabling. The property cache isn't compatible with the way we IC some opcodes (PROPINC, NAMEINC etc). Also, sometimes we assume things are monomorphic. Like |.length| on an array or string will disable immediately after generating the stub.

Most of the time though we should be falling back to stubs::GetProp which will use the property cache. It seems likely that if the PIC doesn't do well, the property cache won't either (it's monomorphic), but if you're seeing examples where this isn't true, we should fix it.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Hmm.  I think the calls I've seen have gone through GetProp.  I'll keep an eye on it.

Comment 3

[Brendan Eich [:brendan]]

(In reply to comment #1)
> Most of the time though we should be falling back to stubs::GetProp which will
> use the property cache. It seems likely that if the PIC doesn't do well, the
> property cache won't either (it's monomorphic),

The property cache is not monomorphic. It is a direct-mapped cache from (kpc, kshape) -> ..., so multiple kshapes for the same kpc hash to different entries.

/be

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK, all my recent profiles do show us try to hit the propcache on stubs::GetProp.  I'm sure that didn't use to happen before....

Resolving wfm; will reopen if needed (unlikely).