js_FindProperty and the property cache

VERIFIED INVALID

Status

()

Core
JavaScript Engine
P1
normal
VERIFIED INVALID
15 years ago
15 years ago

People

(Reporter: David Bradley, Assigned: David Bradley)

Tracking

({js1.5})

Trunk
mozilla1.4alpha
x86
Windows XP
js1.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

15 years ago
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

15 years ago
Reassigning -
Assignee: rogerl → khanson
I'll look at this one.

/be
Assignee: khanson → brendan
Priority: -- → P1
Target Milestone: --- → mozilla1.4alpha

Updated

15 years ago
Status: NEW → ASSIGNED
Keywords: js1.5
(Assignee)

Comment 3

15 years ago
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.
(Assignee)

Comment 4

15 years ago
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.
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
Assignee: brendan → dbradley
Status: ASSIGNED → NEW
(Assignee)

Comment 6

15 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → INVALID

Comment 7

15 years ago
Marking Verified -
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.