Bug 24447 - REGRESSION (r41508): Google Maps does not complete initialization
Summary: REGRESSION (r41508): Google Maps does not complete initialization
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P1 Major
Assignee: Oliver Hunt
URL: http://maps.google.com/
Keywords: InRadar, NeedsReduction, Regression
: 24466 24471 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-03-07 15:04 PST by mitz
Modified: 2009-03-10 03:52 PDT (History)
2 users (show)

See Also:


Attachments
Fix dirtying of the register cache at branch targets (4.79 KB, patch)
2009-03-09 06:10 PDT, Oliver Hunt
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description mitz 2009-03-07 15:04:36 PST
Google Maps does finish loading and the map cannot be dragged. The Web Inspector console says
TypeError: Result of expression '(d.getScript||YY.xFa)' [0] is not a function.
Comment 1 mitz 2009-03-07 15:05:04 PST
<rdar://problem/6657774>
Comment 2 mitz 2009-03-07 15:07:46 PST
(In reply to comment #0)
> Google Maps does finish loading

does not*
Comment 3 Oliver Hunt 2009-03-07 17:17:48 PST
Trying to work out what/why this broke
Comment 4 Oliver Hunt 2009-03-09 06:10:03 PDT
Created attachment 28412 [details]
Fix dirtying of the register cache at branch targets

From Radar:
3/7/09 8:13 PM Oliver Hunt:
(This is an underlying bug exposes by r41508, not caused by it)

3/8/09 6:57 AM Oliver Hunt:
Reduced to 
(print||q.c)()

3/8/09 7:04 AM Oliver Hunt:
or 
(print?1:q.c)()

This is very suckful, apparently we aren't checking for an instruction being a branch target -- i'm 90% sure we can get buy only tracking forward branches, although it will suck to do so, it should not be too difficult

3/8/09 4:00 PM Oliver Hunt:
The basic cause of the issue is demonstrated thus:
[   1] resolve_global	 r4, [object global], print(@id0) // cachedResultRegister = r4
[   7] jfalse		 r4, 6(->15) // cachedResultRegister = <nothing>

    [  10] mov		 r3, r0 // no change
    [  13] jmp		 15(->29) // no change
    [  15] resolve_global	 r4, [object global], q(@id1) // cachedResultRegister = r4
    [  21] get_by_id	 r3, r4, c(@id2) // cachedResultRegister = r3
// At this point we believe  r4 is cached in eax, but if we come from
[  29] mov		 r4, r1
[  32] call		 r3, r3, 1, 13

This patch ensures that the jit will correctly clobber the cache register when it hits the target of a forward branch.  I have not yet determined whether it is possible to create code that can be hit by a loop that does not clobber the register cache.

Currently have not test case written, and haven't been able to get stable perf numbers, so will finish this at work.
Comment 5 Oliver Hunt 2009-03-09 14:42:07 PDT
*** Bug 24466 has been marked as a duplicate of this bug. ***
Comment 6 Oliver Hunt 2009-03-09 18:10:07 PDT
Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	JavaScriptCore/ChangeLog
	M	JavaScriptCore/assembler/AbstractMacroAssembler.h
	M	JavaScriptCore/assembler/X86Assembler.h
	M	JavaScriptCore/jit/JIT.cpp
	M	LayoutTests/ChangeLog
	A	LayoutTests/fast/js/registerCachingAcrossBranchTargets-expected.txt
	A	LayoutTests/fast/js/registerCachingAcrossBranchTargets.html
	A	LayoutTests/fast/js/resources/registerCachingAcrossBranchTargets.js
Committed r41544
Comment 7 Cameron Zwarich (cpst) 2009-03-10 03:52:12 PDT
*** Bug 24471 has been marked as a duplicate of this bug. ***