ChangeLog 997 KB
Newer Older
1
2
3
4
5
6
7
8
9
10
11
12
13
2013-03-26  Mark Hahnenberg  <mhahnenberg@apple.com>

        REGRESSION(r144131): It made fast/js/regress/string-repeat-arith.html assert on 32 bit
        https://bugs.webkit.org/show_bug.cgi?id=112106

        Rubber stamped by Filip Pizlo.

        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32): Get rid of the case for constants because
        we would have done constant folding anyways on a ValueToInt32.
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean): Fixed a random compile error with this flag enabled.

14
15
16
17
18
19
20
21
22
23
24
25
2013-03-26  Filip Pizlo  <fpizlo@apple.com>

        JSC_enableProfiler=true should also cause JSGlobalData to save the profiler output somewhere
        https://bugs.webkit.org/show_bug.cgi?id=113144

        Reviewed by Geoffrey Garen.
        
        Forgot to include Geoff's requested change in the original commit.

        * profiler/ProfilerDatabase.cpp:
        (Profiler):

26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
2013-03-25  Filip Pizlo  <fpizlo@apple.com>

        JSC_enableProfiler=true should also cause JSGlobalData to save the profiler output somewhere
        https://bugs.webkit.org/show_bug.cgi?id=113144

        Reviewed by Geoffrey Garen.
        
        Added the ability to save profiler output with JSC_enableProfiler=true. It will save it
        to the current directory, or JSC_PROFILER_PATH if the latter was specified.
        
        This works by saving the Profiler::Database either when it is destroyed or atexit(),
        whichever happens first.
        
        This allows use of the profiler from any WebKit client.

        * jsc.cpp:
        (jscmain):
        * profiler/ProfilerDatabase.cpp:
        (Profiler):
        (JSC::Profiler::Database::Database):
        (JSC::Profiler::Database::~Database):
        (JSC::Profiler::Database::registerToSaveAtExit):
        (JSC::Profiler::Database::addDatabaseToAtExit):
        (JSC::Profiler::Database::removeDatabaseFromAtExit):
        (JSC::Profiler::Database::performAtExitSave):
        (JSC::Profiler::Database::removeFirstAtExitDatabase):
        (JSC::Profiler::Database::atExitCallback):
        * profiler/ProfilerDatabase.h:
        (JSC::Profiler::Database::databaseID):
        (Database):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):

59
60
61
62
63
64
65
66
67
68
69
70
2013-03-25  Filip Pizlo  <fpizlo@apple.com>

        ArrayMode should not consider SpecOther when refining the base
        https://bugs.webkit.org/show_bug.cgi?id=113271

        Reviewed by Geoffrey Garen.
        
        9% speed-up on Octane/pdfjs.

        * dfg/DFGArrayMode.cpp:
        (JSC::DFG::ArrayMode::refine):

71
72
73
74
75
76
77
78
79
80
81
82
2013-03-26  Csaba Osztrogonác  <ossy@webkit.org>

        Fix unused parameter warnings in JITInlines.h
        https://bugs.webkit.org/show_bug.cgi?id=112560

        Reviewed by Zoltan Herczeg.

        * jit/JITInlines.h:
        (JSC::JIT::beginUninterruptedSequence):
        (JSC::JIT::endUninterruptedSequence):
        (JSC):

83
84
85
86
87
88
89
90
91
92
93
94
95
2013-03-25  Kent Tamura  <tkent@chromium.org>

        Rename ENABLE_INPUT_TYPE_DATETIME
        https://bugs.webkit.org/show_bug.cgi?id=113254

        Reviewed by Kentaro Hara.

        Rename ENABLE_INPUT_TYPE_DATETIME to ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE.
        Actually I'd like to remove the code, but we shouldn't remove it yet
        because we shipped products with it on some platforms.

        * Configurations/FeatureDefines.xcconfig:

96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
2013-03-25  Mark Lam  <mark.lam@apple.com>

        Offlineasm cloop backend compiles op+branch incorrectly.
        https://bugs.webkit.org/show_bug.cgi?id=113146.

        Reviewed by Geoffrey Garen.

        * dfg/DFGRepatch.h:
        (JSC::DFG::dfgResetGetByID):
        (JSC::DFG::dfgResetPutByID):
        - These functions never return when the DFG is dsiabled, not just when
          asserts are enabled. Changing the attribute from NO_RETURN_DUE_TO_ASSERT
          to NO_RETURN.
        * llint/LLIntOfflineAsmConfig.h:
        - Added some #defines needed to get the cloop building again.
        * offlineasm/cloop.rb:
        - Fix cloopEmitOpAndBranchIfOverflow() and cloopEmitOpAndBranch() to
          emit code that unconditionally executes the specified operation before
          doing the conditional branch.

116
117
118
119
120
121
122
123
124
125
2013-03-25  Mark Hahnenberg  <mhahnenberg@apple.com>

        JSObject::enterDictionaryIndexingMode doesn't have a case for ALL_BLANK_INDEXING_TYPES
        https://bugs.webkit.org/show_bug.cgi?id=113236

        Reviewed by Geoffrey Garen.

        * runtime/JSObject.cpp:
        (JSC::JSObject::enterDictionaryIndexingMode): We forgot blank indexing types.

126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
2013-03-23  Mark Hahnenberg  <mhahnenberg@apple.com>

        HandleSet should use HeapBlocks for storing handles
        https://bugs.webkit.org/show_bug.cgi?id=113145

        Reviewed by Geoffrey Garen.

        * GNUmakefile.list.am: Build project changes.
        * JavaScriptCore.gypi: Ditto.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
        * JavaScriptCore.xcodeproj/project.pbxproj: Ditto.
        * heap/BlockAllocator.cpp: Rename the RegionSet to m_fourKBBlockRegionSet because there are 
        too many block types to include them all in the name now.
        (JSC::BlockAllocator::BlockAllocator):
        * heap/BlockAllocator.h:
        (BlockAllocator): Add the appropriate override for regionSetFor.
        (JSC::WeakBlock):
        (JSC::MarkStackSegment):
        (JSC::HandleBlock):
        * heap/HandleBlock.h: Added.
        (HandleBlock): New class for HandleBlocks.
        (JSC::HandleBlock::blockFor): Static method to get the block of the given HandleNode pointer. Allows
        us to quickly figure out which HandleSet the HandleNode belongs to without storing the pointer to it
        in the HandleNode.
        (JSC::HandleBlock::handleSet): Getter.
        * heap/HandleBlockInlines.h: Added.
        (JSC::HandleBlock::create):
        (JSC::HandleBlock::HandleBlock):
        (JSC::HandleBlock::payloadEnd):
        (JSC::HandleBlock::payload):
        (JSC::HandleBlock::nodes):
        (JSC::HandleBlock::nodeAtIndex):
        (JSC::HandleBlock::nodeCapacity):
        * heap/HandleSet.cpp:
        (JSC::HandleSet::~HandleSet): 
        (JSC::HandleSet::grow):
        * heap/HandleSet.h:
        (HandleNode): Move the internal Node class from HandleSet to be its own public class so it can be 
        used by HandleBlock.
        (HandleSet): Add a typedef so that Node refers to the new HandleNode class.
        (JSC::HandleSet::toHandle):
        (JSC::HandleSet::toNode):
        (JSC::HandleSet::allocate):
        (JSC::HandleSet::deallocate):
        (JSC::HandleNode::HandleNode):
        (JSC::HandleNode::slot):
        (JSC::HandleNode::handleSet): Use the new blockFor static function to get the right HandleBlock and lookup 
        the HandleSet.
        (JSC::HandleNode::setPrev):
        (JSC::HandleNode::prev):
        (JSC::HandleNode::setNext):
        (JSC::HandleNode::next):
        (JSC::HandleSet::forEachStrongHandle):
        * heap/Heap.h: Friend HandleSet so that it can access the BlockAllocator when allocating HandleBlocks.

183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
2013-03-22  David Kilzer  <ddkilzer@apple.com>

        BUILD FIX (r145119): Make JSValue* properties default to (assign)
        <rdar://problem/13380794>

        Reviewed by Mark Hahnenberg.

        Fixes the following build failures:

            Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute]
            @property JSValue *onclick;
            ^
            Source/JavaScriptCore/API/tests/testapi.mm:106:1: error: default property attrib ute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute]
            Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: no 'assign', 'retain', or 'copy' attribute is specified - 'assign' is assumed [-Werror,-Wobjc-property-no-attribute]
            @property JSValue *weakOnclick;
            ^
            Source/JavaScriptCore/API/tests/testapi.mm:107:1: error: default property attribute 'assign' not appropriate for non-GC object [-Werror,-Wobjc-property-no-attribute]
            4 errors generated.

        * API/tests/testapi.mm: Default to (assign) for JSValue*
        properties.

205
206
207
208
209
210
211
212
213
214
215
216
217
2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>

        testLeakingPrototypesAcrossContexts added in r146682 doesn't compile on Win and fails on Mac
        https://bugs.webkit.org/show_bug.cgi?id=113125

        Reviewed by Mark Hahnenberg

        Remove the test added in r146682 as it's now failing on Mac.
        This is the test that was causing a compilation failure on Windows.

        * API/tests/testapi.c:
        (main):

218
219
220
221
222
223
224
2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>

        Fix the typo: WIN -> WINDOWS.

        * API/tests/testapi.c:
        (main):

225
226
227
228
229
230
231
232
2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>

        I really can't figure out what's wrong with this one.
        Temporarily disable the test added by r146682 on Windows since it doesn't compile.

        * API/tests/testapi.c:
        (main):

233
234
235
236
237
238
239
2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>

        Another build fix (after r146693) for r146682.

        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:

240
241
242
243
244
245
246
2013-03-22  Roger Fong  <roger_fong@apple.com>

        Unreviewed. AppleWin build fix.

        * JavaScriptCore.vcproj/JavaScriptCore/copy-files.cmd:
        * JavaScriptCore.vcxproj/copy-files.cmd:

247
248
249
250
251
252
253
254
255
256
2013-03-22  Mark Hahnenberg  <mhahnenberg@apple.com>

        -[TinyDOMNode dealloc] should call [super dealloc] when ARC is not enabled
        https://bugs.webkit.org/show_bug.cgi?id=113054

        Reviewed by Geoffrey Garen.

        * API/tests/testapi.mm:
        (-[TinyDOMNode dealloc]):

257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
2013-03-22  Mark Hahnenberg  <mhahnenberg@apple.com>

        opaqueJSClassData should be cached on JSGlobalObject, not the JSGlobalData
        https://bugs.webkit.org/show_bug.cgi?id=113086

        Reviewed by Geoffrey Garen.

        opaqueJSClassData stores cached prototypes for JSClassRefs in the C API. It doesn't make sense to 
        share these prototypes within a JSGlobalData across JSGlobalObjects, and in fact doing so will cause 
        a leak of the original JSGlobalObject that these prototypes were created in. Therefore we should move 
        this cache to JSGlobalObject where it belongs and where it won't cause memory leaks.

        * API/JSBase.cpp: Needed to add an extern "C" so that testapi.c can use the super secret GC function.
        * API/JSClassRef.cpp: We now grab the cached context data from the global object rather than the global data.
        (OpaqueJSClass::contextData):
        * API/JSClassRef.h: Remove this header because it's unnecessary and causes circular dependencies.
        * API/tests/testapi.c: Added a new test that makes sure that using the same JSClassRef in two different contexts
        doesn't cause leaks of the original global object.
        (leakFinalize):
        (nestedAllocateObject): This is a hack to bypass the conservative scan of the GC, which was unnecessarily marking
        objects and keeping them alive, ruining the test result.
        (testLeakingPrototypesAcrossContexts):
        (main):
        * API/tests/testapi.mm: extern "C" this so we can continue using it here.
        * runtime/JSGlobalData.cpp: Remove JSClassRef related stuff.
        (JSC::JSGlobalData::~JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        * runtime/JSGlobalObject.h: Add the stuff that JSGlobalData had. We add it to JSGlobalObjectRareData so that 
        clients who don't use the C API don't have to pay the memory cost of this extra HashMap.
        (JSGlobalObject):
        (JSGlobalObjectRareData):
        (JSC::JSGlobalObject::opaqueJSClassData):

291
292
293
294
295
296
297
298
299
300
2013-03-19  Martin Robinson  <mrobinson@igalia.com>

        [GTK] Add support for building the WebCore bindings to the gyp build
        https://bugs.webkit.org/show_bug.cgi?id=112638

        Reviewed by Nico Weber.

        * JavaScriptCore.gyp/JavaScriptCoreGTK.gyp: Export all include directories to direct
        dependents and fix the indentation of the libjavascriptcore target.

301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
2013-03-21  Filip Pizlo  <fpizlo@apple.com>

        Fix some minor issues in the DFG's profiling of heap accesses
        https://bugs.webkit.org/show_bug.cgi?id=113010

        Reviewed by Goeffrey Garen.
        
        1) If a CodeBlock gets jettisoned by GC, we should count the exit sites.

        2) If a CodeBlock clears a structure stub during GC, it should record this, and
        the DFG should prefer to not inline that access (i.e. treat it as if it had an
        exit site).

        3) If a PutById was seen by the baseline JIT, and the JIT attempted to cache it,
        but it chose not to, then assume that it will take slow path.

        4) If we frequently exited because of a structure check on a weak constant,
        don't try to inline that access in the future.

        5) Treat all exits that were counted as being frequent.
        
        81% speed-up on Octane/gbemu. Small speed-ups elsewhere, and no regressions.

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::finalizeUnconditionally):
        (JSC):
        (JSC::CodeBlock::resetStubDuringGCInternal):
        (JSC::CodeBlock::reoptimize):
        (JSC::CodeBlock::jettison):
        (JSC::ProgramCodeBlock::jettisonImpl):
        (JSC::EvalCodeBlock::jettisonImpl):
        (JSC::FunctionCodeBlock::jettisonImpl):
        (JSC::CodeBlock::tallyFrequentExitSites):
        * bytecode/CodeBlock.h:
        (CodeBlock):
        (JSC::CodeBlock::tallyFrequentExitSites):
        (ProgramCodeBlock):
        (EvalCodeBlock):
        (FunctionCodeBlock):
        * bytecode/GetByIdStatus.cpp:
        (JSC::GetByIdStatus::computeFor):
        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):
        * bytecode/StructureStubInfo.h:
        (JSC::StructureStubInfo::StructureStubInfo):
        (StructureStubInfo):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGOSRExit.cpp:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSiteSlow):
        * dfg/DFGOSRExit.h:
        (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
        (OSRExit):
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * runtime/Options.h:
        (JSC):

360
361
362
363
364
365
366
367
368
369
2013-03-22  Filip Pizlo  <fpizlo@apple.com>

        DFG folding of PutById to SimpleReplace should consider the specialized function case
        https://bugs.webkit.org/show_bug.cgi?id=113093

        Reviewed by Geoffrey Garen and Mark Hahnenberg.

        * bytecode/PutByIdStatus.cpp:
        (JSC::PutByIdStatus::computeFor):

370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
2013-03-22  David Kilzer  <ddkilzer@apple.com>

        BUILD FIX (r146558): Build testapi.mm with ARC enabled for armv7s
        <http://webkit.org/b/112608>

        Fixes the following build failure:

            Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls]
            }
            ^
            1 error generated.

        * Configurations/ToolExecutable.xcconfig: Enable ARC for armv7s
        architecture.

385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
2013-03-22  David Kilzer  <ddkilzer@apple.com>

        Revert "BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc]"

        This fixes a build failure introduced by this change:

            Source/JavaScriptCore/API/tests/testapi.mm:206:6: error: ARC forbids explicit message send of 'dealloc'
                [super dealloc];
                 ^     ~~~~~~~
            1 error generated.

        Not sure why this didn't fail locally on my Mac Pro.

        * API/tests/testapi.mm:
        (-[TinyDOMNode dealloc]): Remove call to [super dealloc].

401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
2013-03-22  David Kilzer  <ddkilzer@apple.com>

        BUILD FIX (r146558): Call [super dealloc] from -[TinyDOMNode dealloc]
        <http://webkit.org/b/112608>

        Fixes the following build failure:

            Source/JavaScriptCore/API/tests/testapi.mm:205:1: error: method possibly missing a [super dealloc] call [-Werror,-Wobjc-missing-super-calls]
            }
            ^
            1 error generated.

        * API/tests/testapi.mm:
        (-[TinyDOMNode dealloc]): Call [super dealloc].

416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
2013-03-22  Ryosuke Niwa  <rniwa@webkit.org>

        Leak bots erroneously report JSC::WatchpointSet as leaking
        https://bugs.webkit.org/show_bug.cgi?id=107781

        Reviewed by Filip Pizlo.

        Since leaks doesn't support tagged pointers, avoid using it by flipping the bit flag to indicate
        the entry is "fat". We set the flag when the entry is NOT fat; i.e. slim.

        Replaced FatFlag by SlimFlag and initialized m_bits with this flag to indicate that the entry is
        initially "slim".

        * runtime/SymbolTable.cpp:
        (JSC::SymbolTableEntry::copySlow): Don't set FatFlag since it has been replaced by SlimFlag.
        (JSC::SymbolTableEntry::inflateSlow): Ditto.

        * runtime/SymbolTable.h:
        (JSC::SymbolTableEntry::Fast::Fast): Set SlimFlag by default.
        (JSC::SymbolTableEntry::Fast::isNull): Ignore SlimFlag.
        (JSC::SymbolTableEntry::Fast::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag
        is not set.

        (JSC::SymbolTableEntry::SymbolTableEntry): Set SlimFlag by default.
        (JSC::SymbolTableEntry::SymbolTableEntry::getFast): Set SlimFlag when creating Fast from a fat entry.
        (JSC::SymbolTableEntry::isNull): Ignore SlimFlag.
        (JSC::SymbolTableEntry::FatEntry::FatEntry): Strip SlimFlag.
        (JSC::SymbolTableEntry::isFat): An entry is fat when m_bits is not entirely zero and SlimFlag is unset.
        (JSC::SymbolTableEntry::fatEntry): Don't strip FatFlag as this flag doesn't exist anymore.
        (JSC::SymbolTableEntry::pack): Preserve SlimFlag.

        (JSC::SymbolTableIndexHashTraits): empty value is no longer zero so don't set emptyValueIsZero true.

449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
2013-03-21  Mark Hahnenberg  <mhahnenberg@apple.com>

        Objective-C API: Need a good way to preserve custom properties on JS wrappers
        https://bugs.webkit.org/show_bug.cgi?id=112608

        Reviewed by Geoffrey Garen.

        Currently, we just use a weak map, which means that garbage collection can cause a wrapper to 
        disappear if it isn't directly exported to JavaScript.

        The most straightforward and safe way (with respect to garbage collection and concurrency) is to have 
        clients add and remove their external references along with their owners. Effectively, the client is 
        recording the structure of the external object graph so that the garbage collector can make sure to 
        mark any wrappers that are reachable through either the JS object graph of the external Obj-C object 
        graph. By keeping these wrappers alive, this has the effect that custom properties on these wrappers 
        will also remain alive.

        The rule for if an object needs to be tracked by the runtime (and therefore whether the client should report it) is as follows:
        For a particular object, its references to its children should be added if:
        1. The child is referenced from JavaScript.
        2. The child contains references to other objects for which (1) or (2) are true.

        * API/JSAPIWrapperObject.mm:
        (JSAPIWrapperObjectHandleOwner::finalize):
        (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots): A wrapper object is kept alive only if its JSGlobalObject
        is marked and its corresponding Objective-C object was added to the set of opaque roots.
        (JSC::JSAPIWrapperObject::visitChildren): We now call out to scanExternalObjectGraph, which handles adding all Objective-C
        objects to the set of opaque roots.
        * API/JSAPIWrapperObject.h:
        (JSAPIWrapperObject):
        * API/JSContext.mm: Moved dealloc to its proper place in the main implementation.
        (-[JSContext dealloc]):
        * API/JSVirtualMachine.h:
        * API/JSVirtualMachine.mm:
        (-[JSVirtualMachine initWithContextGroupRef:]):
        (-[JSVirtualMachine dealloc]):
        (getInternalObjcObject): Helper funciton to get the Objective-C object out of JSManagedValues or JSValues if there is one.
        (-[JSVirtualMachine addManagedReference:withOwner:]): Adds the Objective-C object to the set of objects 
        owned by the owner object in that particular virtual machine.
        (-[JSVirtualMachine removeManagedReference:withOwner:]): Removes the relationship between the two objects.
        (-[JSVirtualMachine externalObjectGraph]):
        (scanExternalObjectGraph): Does a depth-first search of the external object graph in a particular virtual machine starting at
        the specified root. Each new object it encounters it adds to the set of opaque roots. These opaque roots will keep their 
        corresponding wrapper objects alive if they have them. 
        * API/JSManagedReferenceInternal.h: Added.
        * API/JSVirtualMachine.mm: Added the per-JSVirtualMachine map between objects and the objects they own, which is more formally
        known as that virtual machine's external object graph.
        * API/JSWrapperMap.mm:
        (-[JSWrapperMap dealloc]): We were leaking this before :-(
        (-[JSVirtualMachine initWithContextGroupRef:]):
        (-[JSVirtualMachine dealloc]):
        (-[JSVirtualMachine externalObjectGraph]):
        * API/JSVirtualMachineInternal.h:
        * API/tests/testapi.mm: Added two new tests using the TinyDOMNode class. The first tests that a custom property added to a wrapper 
        doesn't vanish after GC, even though that wrapper isn't directly accessible to the JS garbage collector but is accessible through 
        the external Objective-C object graph. The second test makes sure that adding an object to the external object graph with the same 
        owner doesn't cause any sort of problems.
        (+[TinyDOMNode sharedVirtualMachine]):
        (-[TinyDOMNode init]):
        (-[TinyDOMNode dealloc]):
        (-[TinyDOMNode appendChild:]):
        (-[TinyDOMNode numberOfChildren]):
        (-[TinyDOMNode childAtIndex:]):
        (-[TinyDOMNode removeChildAtIndex:]):
        * JavaScriptCore.xcodeproj/project.pbxproj:
        * heap/SlotVisitor.h:
        (SlotVisitor):
        * heap/SlotVisitorInlines.h:
        (JSC::SlotVisitor::containsOpaqueRootTriState): Added a new method to SlotVisitor to allow scanExternalObjectGraph to have a 
        thread-safe view of opaque roots during parallel marking. The set of opaque roots available to any one SlotVisitor isn't guaranteed
        to be 100% correct, but that just results in a small duplication of work in scanExternalObjectGraph. To indicate this change for
        false negatives we return a TriState that's either true or mixed, but never false.

522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
2013-03-21  Mark Lam  <mark.lam@apple.com>

        Fix O(n^2) op_debug bytecode charPosition to column computation.
        https://bugs.webkit.org/show_bug.cgi?id=112957.

        Reviewed by Geoffrey Garen.

        The previous algorithm does a linear reverse scan of the source string
        to find the line start for any given char position. This results in a
        O(n^2) algortithm when the source string has no line breaks.

        The new algorithm computes a line start column table for a
        SourceProvider on first use. This line start table is used to fix up
        op_debug's charPosition operand into a column operand when an
        UnlinkedCodeBlock is linked into a CodeBlock. The initialization of
        the line start table is O(n), and the CodeBlock column fix up is
        O(log(n)).

        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode): 
        (JSC::CodeBlock::CodeBlock): - do column fix up.
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::debug): - no need to do column fixup anymore.
        * interpreter/Interpreter.h:
        * jit/JITStubs.cpp:
        (JSC::DEFINE_STUB_FUNCTION):
        * llint/LLIntSlowPaths.cpp:
        (JSC::LLInt::LLINT_SLOW_PATH_DECL):
        * parser/SourceProvider.cpp:
        (JSC::SourceProvider::lineStarts):
        (JSC::charPositionExtractor):
        (JSC::SourceProvider::charPositionToColumnNumber):
        - initialize line start column table if needed.
        - look up line start for the given char position.
        * parser/SourceProvider.h:

558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
2013-03-21  Filip Pizlo  <fpizlo@apple.com>

        JSC profiler should have an at-a-glance report of the success of DFG optimization
        https://bugs.webkit.org/show_bug.cgi?id=112988

        Reviewed by Geoffrey Garen.

        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::handleCall):
        (JSC::DFG::ByteCodeParser::handleGetById):
        (JSC::DFG::ByteCodeParser::parseBlock):
        * profiler/ProfilerCompilation.cpp:
        (JSC::Profiler::Compilation::Compilation):
        (JSC::Profiler::Compilation::toJS):
        * profiler/ProfilerCompilation.h:
        (JSC::Profiler::Compilation::noticeInlinedGetById):
        (JSC::Profiler::Compilation::noticeInlinedPutById):
        (JSC::Profiler::Compilation::noticeInlinedCall):
        (Compilation):
        * runtime/CommonIdentifiers.h:

579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
2013-03-21  Mark Lam  <mark.lam@apple.com>

        Fix lexer charPosition computation when "rewind"ing the lexer.
        https://bugs.webkit.org/show_bug.cgi?id=112952.

        Reviewed by Michael Saboff.

        Changed the Lexer to no longer keep a m_charPosition. Instead, we compute
        currentCharPosition() from m_code and m_codeStartPlusOffset, where
        m_codeStartPlusOffset is the SourceProvider m_codeStart + the SourceCode
        start offset. This ensures that the charPosition is always in sync with
        m_code.

        * parser/Lexer.cpp:
        (JSC::::setCode):
        (JSC::::internalShift):
        (JSC::::shift):
        (JSC::::lex):
        * parser/Lexer.h:
        (JSC::Lexer::currentCharPosition):
        (JSC::::lexExpectIdentifier):

601
602
603
604
605
606
607
608
609
610
611
612
2013-03-21  Alberto Garcia  <agarcia@igalia.com>

        [BlackBerry] GCActivityCallback: replace JSLock with JSLockHolder
        https://bugs.webkit.org/show_bug.cgi?id=112448

        Reviewed by Xan Lopez.

        This changed in r121381.

        * runtime/GCActivityCallbackBlackBerry.cpp:
        (JSC::DefaultGCActivityCallback::doWork):

613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
2013-03-21  Mark Hahnenberg  <mhahnenberg@apple.com>

        Objective-C API: wrapperClass holds a static JSClassRef, which causes JSGlobalObjects to leak
        https://bugs.webkit.org/show_bug.cgi?id=112856

        Reviewed by Geoffrey Garen.

        Through a very convoluted path that involves the caching of prototypes on the JSClassRef, we can leak 
        JSGlobalObjects when inserting an Objective-C object into multiple independent JSContexts.

        * API/JSAPIWrapperObject.cpp: Removed.
        * API/JSAPIWrapperObject.h:
        (JSAPIWrapperObject):
        * API/JSAPIWrapperObject.mm: Copied from Source/JavaScriptCore/API/JSAPIWrapperObject.cpp. Made this an
        Objective-C++ file so that we can call release on the wrappedObject. Also added a WeakHandleOwner for 
        JSAPIWrapperObjects. This will also be used in a future patch for https://bugs.webkit.org/show_bug.cgi?id=112608.
        (JSAPIWrapperObjectHandleOwner):
        (jsAPIWrapperObjectHandleOwner):
        (JSAPIWrapperObjectHandleOwner::finalize): This finalize replaces the old finalize that was done through
        the C API.
        (JSC::JSAPIWrapperObject::finishCreation): Allocate the WeakImpl. Balanced in finalize.
        (JSC::JSAPIWrapperObject::setWrappedObject): We now do the retain of the wrappedObject here rather than in random
        places scattered around JSWrapperMap.mm
        * API/JSObjectRef.cpp: Added some ifdefs for platforms that don't support the Obj-C API.
        (JSObjectGetPrivate): Ditto.
        (JSObjectSetPrivate): Ditto.
        (JSObjectGetPrivateProperty): Ditto.
        (JSObjectSetPrivateProperty): Ditto.
        (JSObjectDeletePrivateProperty): Ditto.
        * API/JSValueRef.cpp: Ditto.
        (JSValueIsObjectOfClass): Ditto.
        * API/JSWrapperMap.mm: Remove wrapperClass().
        (objectWithCustomBrand): Change to no longer use a parent class, which was only used to give the ability to 
        finalize wrapper objects.
        (-[JSObjCClassInfo initWithContext:forClass:superClassInfo:]): Change to no longer use wrapperClass(). 
        (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): Ditto.
        (tryUnwrapObjcObject): We now check if the object inherits from JSAPIWrapperObject.
        * API/tests/testapi.mm: Added a test that exports an Objective-C object to two different JSContexts and makes 
        sure that the first one is collected properly by using a weak JSManagedValue for the wrapper in the first JSContext.
        * CMakeLists.txt: Build file modifications.
        * GNUmakefile.list.am: Ditto.
        * JavaScriptCore.gypi: Ditto.
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCore.vcproj: Ditto.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj: Ditto.
        * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters: Ditto.
        * JavaScriptCore.xcodeproj/project.pbxproj: Ditto.
        * runtime/JSGlobalObject.cpp: More ifdefs for unsupported platforms.
        (JSC::JSGlobalObject::reset): Ditto.
        (JSC::JSGlobalObject::visitChildren): Ditto.
        * runtime/JSGlobalObject.h: Ditto.
        (JSGlobalObject): Ditto.
        (JSC::JSGlobalObject::objcCallbackFunctionStructure): Ditto.

666
667
668
669
670
671
672
673
674
675
2013-03-21  Anton Muhin  <antonm@chromium.org>

        Unreviewed, rolling out r146483.
        http://trac.webkit.org/changeset/146483
        https://bugs.webkit.org/show_bug.cgi?id=111695

        Breaks debug builds.

        * bytecode/GlobalResolveInfo.h: Removed property svn:mergeinfo.

676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
2013-03-21  Gabor Rapcsanyi  <rgabor@webkit.org>

        Implement LLInt for CPU(ARM_TRADITIONAL)
        https://bugs.webkit.org/show_bug.cgi?id=97589

        Reviewed by Zoltan Herczeg.

        Enable LLInt for ARMv5 and ARMv7 traditional as well.

        * llint/LLIntOfflineAsmConfig.h:
        * llint/LowLevelInterpreter.asm:
        * llint/LowLevelInterpreter32_64.asm:
        * offlineasm/arm.rb:
        * offlineasm/backends.rb:
        * offlineasm/instructions.rb:

692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
2013-03-20  Cosmin Truta  <ctruta@blackberry.com>

        [QNX][ARM] REGRESSION(r135330): Various failures in Octane
        https://bugs.webkit.org/show_bug.cgi?id=112863

        Reviewed by Yong Li.

        This was fixed in http://trac.webkit.org/changeset/146396 on Linux only.
        Enable this fix on QNX.

        * assembler/ARMv7Assembler.h:
        (ARMv7Assembler):
        (JSC::ARMv7Assembler::replaceWithJump):
        (JSC::ARMv7Assembler::maxJumpReplacementSize):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):

709
710
711
712
713
714
715
716
2013-03-20  Filip Pizlo  <fpizlo@apple.com>

        Fix indentation of JSString.h

        Rubber stamped by Mark Hahnenberg.

        * runtime/JSString.h:

717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
2013-03-20  Filip Pizlo  <fpizlo@apple.com>

        "" + x where x is not a string should be optimized by the DFG to some manner of ToString conversion
        https://bugs.webkit.org/show_bug.cgi?id=112845

        Reviewed by Mark Hahnenberg.
        
        I like to do "" + x. So I decided to make DFG recognize it, and related idioms.

        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::fixupToPrimitive):
        (FixupPhase):
        (JSC::DFG::FixupPhase::fixupToString):
        (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::resultOfToPrimitive):
        (DFG):
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGPredictionPropagationPhase.h:
        (DFG):

739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
2013-03-20  Zoltan Herczeg  <zherczeg@webkit.org>

        ARMv7 replaceWithJump ASSERT failure after r135330.
        https://bugs.webkit.org/show_bug.cgi?id=103146

        Reviewed by Filip Pizlo.

        On Linux, the 24 bit distance range of jumps sometimes does not
        enough to cover all targets addresses. This patch supports jumps
        outside of this range using a mov/movt/bx 10 byte long sequence.

        * assembler/ARMv7Assembler.h:
        (ARMv7Assembler):
        (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2):
        (JSC::ARMv7Assembler::nopw):
        (JSC::ARMv7Assembler::label):
        (JSC::ARMv7Assembler::replaceWithJump):
        (JSC::ARMv7Assembler::maxJumpReplacementSize):
        * assembler/MacroAssemblerARMv7.h:
        (JSC::MacroAssemblerARMv7::revertJumpReplacementToBranchPtrWithPatch):

760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
2013-03-20  Mark Hahnenberg  <mhahnenberg@apple.com>

        Objective-C API: Fix over-releasing in allocateConstructorAndPrototypeWithSuperClassInfo:
        https://bugs.webkit.org/show_bug.cgi?id=112832

        Reviewed by Geoffrey Garen.

        If either the m_constructor or m_prototype (but not both) is collected, we will call 
        allocateConstructorAndPrototypeWithSuperClassInfo, which will create a new object to replace the one 
        that was collected, but at the end of the method we call release on both of them. 
        This is incorrect since we autorelease the JSValue in the case that the object doesn't need to be 
        reallocated. Thus we'll end up overreleasing later during the drain of the autorelease pool.

        * API/JSWrapperMap.mm:
        (objectWithCustomBrand): We no longer alloc here. We instead call the JSValue valueWithValue class method,
        which autoreleases for us.
        (-[JSObjCClassInfo allocateConstructorAndPrototypeWithSuperClassInfo:]): We no longer call release on the 
        constructor or prototype JSValues.
        * API/tests/testapi.mm: Added a new test that crashes on ToT due to over-releasing.

780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
2013-03-19  Filip Pizlo  <fpizlo@apple.com>

        It's called "Hash Consing" not "Hash Consting"
        https://bugs.webkit.org/show_bug.cgi?id=112768

        Rubber stamped by Mark Hahnenberg.
        
        See http://en.wikipedia.org/wiki/Hash_consing

        * heap/GCThreadSharedData.cpp:
        (JSC::GCThreadSharedData::GCThreadSharedData):
        (JSC::GCThreadSharedData::reset):
        * heap/GCThreadSharedData.h:
        (GCThreadSharedData):
        * heap/SlotVisitor.cpp:
        (JSC::SlotVisitor::SlotVisitor):
        (JSC::SlotVisitor::setup):
        (JSC::SlotVisitor::reset):
        (JSC::JSString::tryHashConsLock):
        (JSC::JSString::releaseHashConsLock):
        (JSC::JSString::shouldTryHashCons):
        (JSC::SlotVisitor::internalAppend):
        * heap/SlotVisitor.h:
        (SlotVisitor):
        * runtime/JSGlobalData.cpp:
        (JSC::JSGlobalData::JSGlobalData):
        * runtime/JSGlobalData.h:
        (JSGlobalData):
        (JSC::JSGlobalData::haveEnoughNewStringsToHashCons):
        (JSC::JSGlobalData::resetNewStringsSinceLastHashCons):
        * runtime/JSString.h:
        (JSC::JSString::finishCreation):
        (JSString):
        (JSC::JSString::isHashConsSingleton):
        (JSC::JSString::clearHashConsSingleton):
        (JSC::JSString::setHashConsSingleton):

817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
2013-03-20  Filip Pizlo  <fpizlo@apple.com>

        DFG implementation of op_strcat should inline rope allocations
        https://bugs.webkit.org/show_bug.cgi?id=112780

        Reviewed by Oliver Hunt.
        
        This gets rid of the StrCat node and adds a MakeRope node. The MakeRope node can
        take either two or three operands, and allocates a rope string with either two or
        three fibers. (The magic choice of three children for non-VarArg nodes happens to
        match exactly with the magic choice of three fibers for rope strings.)
        
        ValueAdd on KnownString is replaced with MakeRope with two children.
        
        StrCat gets replaced by an appropriate sequence of MakeRope's.
        
        MakeRope does not do the dynamic check to see if its children are empty strings.
        This is replaced by a static check, instead. The downside is that we may use more
        memory if the strings passed to MakeRope turn out to dynamically be empty. The
        upside is that we do fewer checks in the cases where either the strings are not
        empty, or where the strings are statically known to be empty. I suspect both of
        those cases are more common, than the case where the string is dynamically empty.
        
        This also results in some badness for X86. MakeRope needs six registers if it is
        allocating a three-rope. We don't have six registers to spare on X86. Currently,
        the code side-steps this problem by just never usign three-ropes in optimized
        code on X86. All other architectures, including X86_64, don't have this problem.
        
        This is a shocking speed-up. 9% progressions on both V8/splay and
        SunSpider/date-format-xparb. 1% progression on V8v7 overall, and ~0.5% progression
        on SunSpider. 2x speed-up on microbenchmarks that test op_strcat.

        * dfg/DFGAbstractState.cpp:
        (JSC::DFG::AbstractState::executeEffects):
        * dfg/DFGAdjacencyList.h:
        (AdjacencyList):
        (JSC::DFG::AdjacencyList::removeEdge):
        * dfg/DFGArgumentsSimplificationPhase.cpp:
        (JSC::DFG::ArgumentsSimplificationPhase::removeArgumentsReferencingPhantomChild):
        * dfg/DFGBackwardsPropagationPhase.cpp:
        (JSC::DFG::BackwardsPropagationPhase::propagate):
        * dfg/DFGByteCodeParser.cpp:
        (JSC::DFG::ByteCodeParser::parseBlock):
        * dfg/DFGCSEPhase.cpp:
        (JSC::DFG::CSEPhase::putStructureStoreElimination):
        (JSC::DFG::CSEPhase::eliminateIrrelevantPhantomChildren):
        (JSC::DFG::CSEPhase::performNodeCSE):
        * dfg/DFGDCEPhase.cpp:
        (JSC::DFG::DCEPhase::eliminateIrrelevantPhantomChildren):
        * dfg/DFGFixupPhase.cpp:
        (JSC::DFG::FixupPhase::fixupNode):
        (JSC::DFG::FixupPhase::createToString):
        (JSC::DFG::FixupPhase::attemptToForceStringArrayModeByToStringConversion):
        (JSC::DFG::FixupPhase::convertStringAddUse):
        (FixupPhase):
        (JSC::DFG::FixupPhase::convertToMakeRope):
        (JSC::DFG::FixupPhase::fixupMakeRope):
        (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
        * dfg/DFGNodeType.h:
        (DFG):
        * dfg/DFGOperations.cpp:
        * dfg/DFGOperations.h:
        * dfg/DFGPredictionPropagationPhase.cpp:
        (JSC::DFG::PredictionPropagationPhase::propagate):
        * dfg/DFGSpeculativeJIT.cpp:
        (JSC::DFG::SpeculativeJIT::compileAdd):
        (JSC::DFG::SpeculativeJIT::compileMakeRope):
        (DFG):
        * dfg/DFGSpeculativeJIT.h:
        (JSC::DFG::SpeculativeJIT::callOperation):
        (SpeculativeJIT):
        (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
        (JSC::DFG::SpeculateCellOperand::~SpeculateCellOperand):
        (JSC::DFG::SpeculateCellOperand::gpr):
        (JSC::DFG::SpeculateCellOperand::use):
        * dfg/DFGSpeculativeJIT32_64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * dfg/DFGSpeculativeJIT64.cpp:
        (JSC::DFG::SpeculativeJIT::compile):
        * runtime/JSString.h:
        (JSRopeString):

899
900
901
902
903
904
905
906
907
908
909
2013-03-20  Peter Gal  <galpeter@inf.u-szeged.hu>

        Implement and32 on MIPS platform
        https://bugs.webkit.org/show_bug.cgi?id=112665

        Reviewed by Zoltan Herczeg.

        * assembler/MacroAssemblerMIPS.h:
        (JSC::MacroAssemblerMIPS::and32): Added missing method.
        (MacroAssemblerMIPS):

910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
2013-03-20  Mark Lam  <mark.lam@apple.com>

        Fix incorrect debugger column number value.
        https://bugs.webkit.org/show_bug.cgi?id=112741.

        Reviewed by Oliver Hunt.

        1. In lexer, parser, and debugger code, renamed column to charPosition.
        2. Convert the charPosition to the equivalent column number before
           passing it to the debugger.
        3. Changed ScopeNodes to take both a startLocation and an endLocation.
           This allows FunctionBodyNodes, ProgramNodes, and EvalNodess to emit
           correct debug hooks with correct starting line and column numbers.
        4. Fixed the Lexer to not reset the charPosition (previously
           columnNumber) in Lexer::lex().

        * JavaScriptCore.order:
        * JavaScriptCore.vcproj/JavaScriptCore/JavaScriptCoreExports.def:
        * JavaScriptCore.vcxproj/JavaScriptCoreExportGenerator/JavaScriptCoreExports.def.in:
        * bytecode/CodeBlock.cpp:
        (JSC::CodeBlock::dumpBytecode):
        * bytecompiler/BytecodeGenerator.cpp:
        (JSC::BytecodeGenerator::emitDebugHook):
        * bytecompiler/BytecodeGenerator.h:
        (JSC::BytecodeGenerator::emitExpressionInfo):
        * bytecompiler/NodesCodegen.cpp:
        (JSC::ArrayNode::toArgumentList):
        (JSC::ConstStatementNode::emitBytecode):
        (JSC::EmptyStatementNode::emitBytecode):
        (JSC::DebuggerStatementNode::emitBytecode):
        (JSC::ExprStatementNode::emitBytecode):
        (JSC::VarStatementNode::emitBytecode):
        (JSC::IfNode::emitBytecode):
        (JSC::IfElseNode::emitBytecode):
        (JSC::DoWhileNode::emitBytecode):
        (JSC::WhileNode::emitBytecode):
        (JSC::ForNode::emitBytecode):
        (JSC::ForInNode::emitBytecode):
        (JSC::ContinueNode::emitBytecode):
        (JSC::BreakNode::emitBytecode):
        (JSC::ReturnNode::emitBytecode):
        (JSC::WithNode::emitBytecode):
        (JSC::SwitchNode::emitBytecode):
        (JSC::LabelNode::emitBytecode):
        (JSC::ThrowNode::emitBytecode):
        (JSC::TryNode::emitBytecode):
        (JSC::ProgramNode::emitBytecode):
        (JSC::EvalNode::emitBytecode):
        (JSC::FunctionBodyNode::emitBytecode):
        * interpreter/Interpreter.cpp:
        (JSC::Interpreter::debug):
        - convert charPosition to column for the debugger.
        * interpreter/Interpreter.h:
        * jit/JITStubs.cpp:
        (DEFINE_STUB_FUNCTION(void, op_debug)):
        * llint/LLIntSlowPaths.cpp:
        (LLINT_SLOW_PATH_DECL(slow_op_debug)):
        * parser/ASTBuilder.h:
        (JSC::ASTBuilder::createFunctionExpr):
        (JSC::ASTBuilder::createFunctionBody):
        (JSC::ASTBuilder::createGetterOrSetterProperty):
        (JSC::ASTBuilder::createFuncDeclStatement):
        (JSC::ASTBuilder::createBlockStatement):
        (JSC::ASTBuilder::createExprStatement):
        (JSC::ASTBuilder::createIfStatement):
        (JSC::ASTBuilder::createForLoop):
        (JSC::ASTBuilder::createForInLoop):
        (JSC::ASTBuilder::createVarStatement):
        (JSC::ASTBuilder::createReturnStatement):
        (JSC::ASTBuilder::createBreakStatement):
        (JSC::ASTBuilder::createContinueStatement):
        (JSC::ASTBuilder::createTryStatement):
        (JSC::ASTBuilder::createSwitchStatement):
        (JSC::ASTBuilder::createWhileStatement):
        (JSC::ASTBuilder::createDoWhileStatement):
        (JSC::ASTBuilder::createWithStatement):
        (JSC::ASTBuilder::createThrowStatement):
        (JSC::ASTBuilder::createDebugger):
        (JSC::ASTBuilder::createConstStatement):
        * parser/Lexer.cpp:
        (JSC::::setCode):
        (JSC::::internalShift):
        (JSC::::shift):
        (JSC::::lex):
        * parser/Lexer.h:
        (JSC::Lexer::currentCharPosition):
        (Lexer):
        (JSC::::lexExpectIdentifier):
        * parser/NodeConstructors.h:
        (JSC::Node::Node):
        * parser/Nodes.cpp: