193206 - js_FindProperty and the property cache

Status: VERIFIED INVALID

(Core :: JavaScript Engine, defect, P1)

Description

[David Bradley]

I was trying to profile some code and noticed something odd. js_FindProperty
seems to not always get cache hits like you would expect. Using the following JS
in XPCShell I get 10,003 calls to js_LookupProperty in some runs, while other
runs only call js_LookupProperty 3 times. This is using the exact same JS, with
no code modifications, and using with XPCShell completely restarted. I thought
I'd bring this up since it might be a slight performance issue. I don't know how
often such erroneous misses happen within browser code. Don't know if I'm
missing some nuance of the function or cache system. It's almost like the cache
is affected by uninitalized memory or something. I see about 1 out of 3 runs
using the cache, and the others missing.

for (x = 0; x < 5000; ++x)
{
	y = "55222234234234.0";
	t = new Number(y);
}

Comment 1

[Phil Schwartau]

Reassigning -

Comment 2

[Brendan Eich [:brendan]]

I'll look at this one.

/be

Comment 3

[David Bradley]

One last note, this was an optimized build. Also I can't seem to reproduce this
outside of Quantify. It could be a Quantify anomoly, but that would be pretty
sad if Quantify had such effects. I'll try and verify.

Comment 4

[David Bradley]

I did some quick instrumenting in the PROPERTY_CACHE_TEST macro. What I'm seeing
is that hthe pce_sprop_->id and id alternate. One call pce_sprop_->id=25463352
and id =24959544 and the next it's reversed, and then the next it is back again.
Also what I observed is that the hash id generated. What I also saw is that the
hashIndex for ID was always coming up 802. Obviously we could be getting a
genuine collision for the hash, but I would have expected the behavior to be
consistent.

I went to print out the hashIndex for the fill macro, but then the problem went
away. I wonder if there is a slight compiler bug, that's picking up some noise
from a register, that only under Purify does this noise cause the ID's to
collide. Looks like it's time to take a look at the assembler.

Comment 5

[Brendan Eich [:brendan]]

I blame qfy -- dbradley, you willing to take this for now?  Reassign to me at
the first sign of a bug in the code.  Thanks,

/be

Comment 6

[David Bradley]

Marking INVALID.

Actually I think it's the nature of the hash algorithm. I think it just so
happens that the pointer value of the JSObject used in the hash and the two ID
values that are being used equate to the same hash occasionly when running
Quantify. So I don't think there's anything here to fix. Sorry for the noise.

Comment 7

[Phil Schwartau]

Marking Verified -