Closed Bug 1494504 Opened Last year Closed Last year

IonSetPropertyIC stubs transition to Generic too quickly on GDocs

Categories

(Core :: JavaScript Engine: JIT, defect, P1)

defect

Tracking

()

RESOLVED DUPLICATE of bug 1494537
Tracking Status
firefox64 --- affected

People

(Reporter: bas.schouten, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [qf:p1:64])

From what Kannan has been telling me this is bad, it shouldn't be hit that much in hot code. What I'm actually seeing is it's being called 20k+ times per key stroke.. I'm attempting to understand why because this seems bad.
This is happening because the ICState's mode for the relevant stubs is in 'generic' I'm trying to add instrumentation to discover why.
I made an attempt in my instrumentation to locate the point of the transition to generic, one place I found my instrumentation outputted the following:

Cannot attach stub.
Calling IonSetPropertyIC::update count: 1089001
Cannot attach stub.
Calling IonSetPropertyIC::update count: 1089002
Cannot attach stub.
Calling IonSetPropertyIC::update count: 1089003
Cannot attach stub.
Calling IonSetPropertyIC::update count: 1089004
Cannot attach stub.
Calling IonSetPropertyIC::update count: 1089005
Cannot attach stub.
Calling IonSetPropertyIC::update count: 1089006
Calling IonSetPropertyIC::update count: 1089007
Calling IonSetPropertyIC::update count: 1089008
Calling IonSetPropertyIC::update count: 1089009
Calling IonSetPropertyIC::update count: 1089010
Calling IonSetPropertyIC::update count: 1089011
Discarding stubs
Discarding stubs
Calling IonSetPropertyIC::update count: 1089012
Discarding stubs
Discarding stubs
Transitioning state to generic!
Discarding stubs
Calling IonSetPropertyIC::update count: 1089013


This is a little off, it's attaching 6 stubs succesfully, then it discards them (presumably this was a transition to megamorphic which I am not tracking in this build), then it attaches one more stub and right away transitions to generic, as if the stub count was never reset, however as far as I can tell the stub count should be reset in IonIC::discardStubs because of trackUnlinkedAllStubs being called.
So the above log has some sad mixup of different objects. Further instrumentation shows that the vast majority of these 20k+ update calls are coming from a single IonSetPropertyIC object, that at some point early in its life experiences a large amount of failures attaching the stub, causing the state object to transaition into generic mode and everything is screwed from there on.
So the reason these stubs are failing to attach is because inside SetPropIRGenerator::tryAttachAddSlotStub the check for nameOrSymbol fails.
Depends on: 1494531
Depends on: 1494537
Whiteboard: [qf:p1:64]
I'm re-summarying this bug because we have a family that are very hard to tell apart at a glance. 

I'd like to use this bug to track and investigate the fact that our stubs are transitioning to generic mode too quickly, meaning that future potential attachments never happen. 

(Bas Schouten (:bas.schouten) from comment #2)
> 
> This is a little off, it's attaching 6 stubs succesfully, then it discards
> them (presumably this was a transition to megamorphic which I am not
> tracking in this build), then it attaches one more stub and right away
> transitions to generic, as if the stub count was never reset, however as far
> as I can tell the stub count should be reset in IonIC::discardStubs because
> of trackUnlinkedAllStubs being called.
Summary: IonSetPropertyIC::update seems to be hit excessively on GDocs → IonSetPropertyIC stubs transition to Generic too quickly on GDocs
Matthew, are you going to take this bug to get it fixed for Firefox 64 or do you know if someone else might be able to?
Flags: needinfo?(mgaudet)
Priority: -- → P1
Bug 1494537 should fix this, but we'll need to verify.
As Ted says, this will likely get fixed as a side effect of Bug 1494537. However, I think there's also some relevance to Bug 1495519.
Flags: needinfo?(mgaudet)
Closing this as a dup of 1494537, because the specific case this arises out of has been addressed for the use case that prompted this investigation.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → DUPLICATE
Duplicate of bug: 1494537
You need to log in before you can comment on or make changes to this bug.