Make DLLLauncherMain executables dependent on dll
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-08-27  Alex Christensen  <achristensen@webkit.org>
2
3         Make DLLLauncherMain executables dependent on dll
4         https://bugs.webkit.org/show_bug.cgi?id=148548
5
6         Reviewed by Brent Fulgham.
7
8         * shell/CMakeLists.txt:
9         * shell/PlatformWin.cmake:
10
11 2015-08-27  Filip Pizlo  <fpizlo@apple.com>
12
13         DFG::StrCat isn't really effectful
14         https://bugs.webkit.org/show_bug.cgi?id=148443
15
16         Reviewed by Geoffrey Garen.
17
18         I previously made the DFG StrCat node effectful because it is implemented by calling a
19         DFGOperations function that could cause arbitrary effects. But, the node is only generated from the
20         op_strcat bytecode operation, and that operation is only used when we first ensure that its
21         operands are primitives. Primitive operands to StrCat cannot cause arbitrary side-effects. The
22         reason why I didn't immediately mark StrCat as pure was because there was nothing in DFG IR that
23         guaranteed that StrCat's children were primitives.
24
25         This change adds a KnownPrimitiveUse use kind, and applies it to StrCat. This allows us to mark
26         StrCat as being pure. This should be a speed-up because we can CSE StrCat and because it means that
27         we can OSR exit after a StrCat (a pure node doesn't clobber exit state), so we can convert more
28         of a large string concatenation into MakeRope's.
29
30         * dfg/DFGAbstractInterpreterInlines.h:
31         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
32         * dfg/DFGClobberize.h:
33         (JSC::DFG::clobberize):
34         * dfg/DFGFixupPhase.cpp:
35         (JSC::DFG::FixupPhase::fixupNode):
36         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
37         * dfg/DFGOperations.cpp:
38         * dfg/DFGSafeToExecute.h:
39         (JSC::DFG::SafeToExecuteEdge::operator()):
40         * dfg/DFGSpeculativeJIT.cpp:
41         (JSC::DFG::SpeculativeJIT::speculate):
42         * dfg/DFGSpeculativeJIT32_64.cpp:
43         (JSC::DFG::SpeculativeJIT::compile):
44         * dfg/DFGSpeculativeJIT64.cpp:
45         (JSC::DFG::SpeculativeJIT::compile):
46         * dfg/DFGUseKind.cpp:
47         (WTF::printInternal):
48         * dfg/DFGUseKind.h:
49         (JSC::DFG::typeFilterFor):
50         (JSC::DFG::shouldNotHaveTypeCheck):
51         * ftl/FTLCapabilities.cpp:
52         (JSC::FTL::canCompile):
53         * ftl/FTLLowerDFGToLLVM.cpp:
54         (JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
55         (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
56
57 2015-08-27  Brent Fulgham  <bfulgham@apple.com>
58
59         [Win] Unreviewed build fix after r189064.
60
61         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
62         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
63
64 2015-08-27  Yusuke Suzuki  <utatane.tea@gmail.com>
65
66         Add module loader "resolve" hook for local file system to test the loader in JSC shell
67         https://bugs.webkit.org/show_bug.cgi?id=148543
68
69         Reviewed by Filip Pizlo.
70
71         Add the module loader "resolve" hook to the JSC shell.
72         It takes the module name and the referrer module key and resolves the name to the unique module key.
73
74         resolve(ModuleName moduleName, ModuleKey referrer) -> Promise<ModuleKey>
75
76         In the JSC shell, since we load the module from the local file system, we treat an absolute file path
77         as a module key. So, in this patch, we implement the "resolve" hook that resolves the module name to
78         the absolute file path.
79
80         This local file system "resolve" functionality makes JSC shell easy to test the module loader.
81
82         * jsc.cpp:
83         (GlobalObject::finishCreation):
84         (GlobalObject::moduleLoaderFetch):
85         (pathSeparator):
86         (extractDirectoryName):
87         (currentWorkingDirectory):
88         (resolvePath):
89         (GlobalObject::moduleLoaderResolve):
90         (functionDrainMicrotasks):
91         * runtime/JSInternalPromiseDeferred.cpp:
92         (JSC::JSInternalPromiseDeferred::resolve):
93         (JSC::JSInternalPromiseDeferred::reject):
94         * runtime/JSInternalPromiseDeferred.h:
95         * tests/stress/pathname-resolve.js: Added.
96         (shouldBe):
97         (shouldThrow):
98
99 2015-08-27  Filip Pizlo  <fpizlo@apple.com>
100
101         Unreviewed, fix some FIXMEs and add some new ones, based on things we've learned from some
102         recent OSR exit work.
103
104         * dfg/DFGLICMPhase.cpp:
105         (JSC::DFG::LICMPhase::run):
106         (JSC::DFG::LICMPhase::attemptHoist):
107         * dfg/DFGMayExit.cpp:
108         * dfg/DFGMayExit.h:
109
110 2015-08-27  Keith Miller  <keith_miller@apple.com>
111
112         [ES6] Add TypedArray.prototype functionality.
113         https://bugs.webkit.org/show_bug.cgi?id=148035
114
115         Reviewed by Geoffrey Garen.
116
117         This patch should add most of the functionality for
118         the prototype properties of TypedArray objects in ES6.
119         There are a few exceptions to this, which will be added
120         in upcoming patches:
121
122         1) First we do not use the species constructor for some
123         of the TypedArray prototype functions (namely: map, filter,
124         slice, and subarray). That will need to be added when
125         species constructors are finished.
126
127         2) TypedArrays still have a length, byteOffset, byteLength,
128         and buffer are still attached to the TypedArray instance (in
129         the spec they are on the TypedArray.prototype instance object)
130         since the JIT currently assumes those properties are fixed.
131
132         3) The TypedArray.constructor property is not added yet
133         as it should point to the TypedArray instance object,
134         which will be added in a future patch.
135
136         * CMakeLists.txt:
137         * JavaScriptCore.xcodeproj/project.pbxproj:
138         * builtins/TypedArray.prototype.js: Added.
139         (every):
140         (find):
141         (findIndex):
142         (forEach):
143         (some):
144         (sort.min):
145         (sort.merge):
146         (sort.mergeSort):
147         (sort):
148         (reduce):
149         (reduceRight):
150         (map):
151         (filter):
152         (toLocaleString):
153         * runtime/ArrayPrototype.cpp:
154         * runtime/ArrayPrototype.h:
155         * runtime/CommonIdentifiers.h:
156         * runtime/JSGenericTypedArrayView.h:
157         (JSC::sortFloat):
158         (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
159         (JSC::JSGenericTypedArrayView::setRangeToValue):
160         (JSC::JSGenericTypedArrayView::sort):
161         * runtime/JSGenericTypedArrayViewInlines.h:
162         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
163         (JSC::argumentClampedIndexFromStartOrEnd):
164         (JSC::genericTypedArrayViewProtoFuncSet):
165         (JSC::genericTypedArrayViewProtoFuncEntries):
166         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
167         (JSC::genericTypedArrayViewProtoFuncFill):
168         (JSC::genericTypedArrayViewProtoFuncIndexOf):
169         (JSC::genericTypedArrayViewProtoFuncJoin):
170         (JSC::genericTypedArrayViewProtoFuncKeys):
171         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
172         (JSC::genericTypedArrayViewProtoGetterFuncLength):
173         (JSC::genericTypedArrayViewProtoGetterFuncByteLength):
174         (JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
175         (JSC::genericTypedArrayViewProtoFuncReverse):
176         (JSC::genericTypedArrayViewPrivateFuncSort):
177         (JSC::genericTypedArrayViewProtoFuncSlice):
178         (JSC::genericTypedArrayViewProtoFuncSubarray):
179         (JSC::typedArrayViewProtoFuncValues):
180         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
181         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
182         (JSC::genericTypedArrayViewProtoFuncSet): Deleted.
183         (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
184         * runtime/JSGlobalObject.cpp:
185         (JSC::JSGlobalObject::init):
186         * runtime/JSObject.h:
187         * runtime/JSTypedArrayPrototypes.cpp:
188         * runtime/JSTypedArrayPrototypes.h:
189         * runtime/JSTypedArrayViewPrototype.cpp: Added.
190         (JSC::typedArrayViewPrivateFuncLength):
191         (JSC::typedArrayViewPrivateFuncSort):
192         (JSC::typedArrayViewProtoFuncSet):
193         (JSC::typedArrayViewProtoFuncEntries):
194         (JSC::typedArrayViewProtoFuncCopyWithin):
195         (JSC::typedArrayViewProtoFuncFill):
196         (JSC::typedArrayViewProtoFuncLastIndexOf):
197         (JSC::typedArrayViewProtoFuncIndexOf):
198         (JSC::typedArrayViewProtoFuncJoin):
199         (JSC::typedArrayViewProtoFuncKeys):
200         (JSC::typedArrayViewProtoGetterFuncLength):
201         (JSC::typedArrayViewProtoGetterFuncByteLength):
202         (JSC::typedArrayViewProtoGetterFuncByteOffset):
203         (JSC::typedArrayViewProtoFuncReverse):
204         (JSC::typedArrayViewProtoFuncSubarray):
205         (JSC::typedArrayViewProtoFuncSlice):
206         (JSC::typedArrayViewProtoFuncValues):
207         (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
208         (JSC::JSTypedArrayViewPrototype::finishCreation):
209         (JSC::JSTypedArrayViewPrototype::create):
210         (JSC::JSTypedArrayViewPrototype::createStructure):
211         * runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
212
213 2015-08-27  Alex Christensen  <achristensen@webkit.org>
214
215         Isolate Source directories in CMake build
216         https://bugs.webkit.org/show_bug.cgi?id=148389
217
218         Reviewed by Brent Fulgham.
219
220         * PlatformWin.cmake:
221         Include ../include/private to find WTF headers in internal build.
222         Don't use a script to generate forwarding headers.
223         * shell/PlatformWin.cmake:
224         Copy inspector scripts to the forwarding headers directory to be used by WebCore.
225
226 2015-08-27  Alex Christensen  <achristensen@webkit.org>
227
228         [Win CMake] Fix incremental build after r188673
229         https://bugs.webkit.org/show_bug.cgi?id=148539
230
231         Reviewed by Brent Fulgham.
232
233         * PlatformWin.cmake:
234         Use xcopy as a build step instead of file(COPY ...) to copy updated headers.
235
236 2015-08-27  Jon Davis  <jond@apple.com>
237
238         Include ES6 Generators and Proxy object status to feature status page.
239         https://bugs.webkit.org/show_bug.cgi?id=148095
240
241         Reviewed by Timothy Hatcher.
242
243         * features.json:
244
245 2015-08-27  Filip Pizlo  <fpizlo@apple.com>
246
247         Unreviewed, add a comment to describe something I learned about a confusingly-named function.
248
249         * dfg/DFGUseKind.h:
250         (JSC::DFG::isCell):
251
252 2015-08-27  Basile Clement  <basile_clement@apple.com>
253
254         REGRESSION(r184779): Possible read-after-free in JavaScriptCore/dfg/DFGClobberize.h
255         https://bugs.webkit.org/show_bug.cgi?id=148411
256
257         Reviewed by Geoffrey Garen and Filip Pizlo.
258
259         * dfg/DFGClobberize.h:
260         (JSC::DFG::clobberize):
261
262 2015-08-27  Brian Burg  <bburg@apple.com>
263
264         Web Inspector: FrontendChannel should know its own connection type
265         https://bugs.webkit.org/show_bug.cgi?id=148482
266
267         Reviewed by Joseph Pecoraro.
268
269         * inspector/InspectorFrontendChannel.h: Add connectionType().
270         * inspector/remote/RemoteInspectorDebuggableConnection.h:
271
272 2015-08-26  Filip Pizlo  <fpizlo@apple.com>
273
274         Node::origin should always be set, and the dead zone due to SSA Phis can just use exitOK=false
275         https://bugs.webkit.org/show_bug.cgi?id=148462
276
277         Reviewed by Saam Barati.
278
279         The need to label nodes that absolutely cannot exit was first observed when we introduced SSA form.
280         We indicated this by not setting the CodeOrigin.
281
282         But just recently (http://trac.webkit.org/changeset/188979), we added a more comprehensive "exitOK"
283         bit in NodeOrigin. After that change, there were two ways of indicating that you cannot exit:
284         !exitOK and an unset NodeOrigin. An unset NodeOrigin implied !exitOK.
285
286         Now, this change is about removing the old way so that we only use !exitOK. From now on, all nodes
287         must have their NodeOrigin set, and the IR validation will check this. This means that I could
288         remove various pieces of cruft for dealing with unset NodeOrigins, but I did have to add some new
289         cruft to ensure that all nodes we create have a NodeOrigin.
290
291         This change simplifies our IR by having a simpler rule about when NodeOrigin is set: it's always
292         set.
293
294         * dfg/DFGBasicBlock.cpp:
295         (JSC::DFG::BasicBlock::isInBlock):
296         (JSC::DFG::BasicBlock::removePredecessor):
297         (JSC::DFG::BasicBlock::firstOriginNode): Deleted.
298         (JSC::DFG::BasicBlock::firstOrigin): Deleted.
299         * dfg/DFGBasicBlock.h:
300         (JSC::DFG::BasicBlock::begin):
301         (JSC::DFG::BasicBlock::end):
302         (JSC::DFG::BasicBlock::numSuccessors):
303         (JSC::DFG::BasicBlock::successor):
304         * dfg/DFGCombinedLiveness.cpp:
305         (JSC::DFG::liveNodesAtHead):
306         * dfg/DFGConstantHoistingPhase.cpp:
307         * dfg/DFGCriticalEdgeBreakingPhase.cpp:
308         (JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
309         * dfg/DFGForAllKills.h:
310         (JSC::DFG::forAllKilledOperands):
311         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
312         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
313         (JSC::DFG::createPreHeader):
314         (JSC::DFG::LoopPreHeaderCreationPhase::run):
315         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
316         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
317         * dfg/DFGObjectAllocationSinkingPhase.cpp:
318         * dfg/DFGPutStackSinkingPhase.cpp:
319         * dfg/DFGSSAConversionPhase.cpp:
320         (JSC::DFG::SSAConversionPhase::run):
321         * dfg/DFGValidate.cpp:
322         (JSC::DFG::Validate::validate):
323         (JSC::DFG::Validate::validateSSA):
324
325 2015-08-26  Saam barati  <sbarati@apple.com>
326
327         MarkedBlock::allocateBlock will have the wrong allocation size when (sizeof(MarkedBlock) + bytes) is divisible by WTF::pageSize()
328         https://bugs.webkit.org/show_bug.cgi?id=148500
329
330         Reviewed by Mark Lam.
331
332         Consider the following scenario:
333         - On OS X, WTF::pageSize() is 4*1024 bytes.
334         - JSEnvironmentRecord::allocationSizeForScopeSize(6621) == 53000
335         - sizeof(MarkedBlock) == 248
336         - (248 + 53000) is a multiple of 4*1024.
337         - (248 + 53000)/(4*1024) == 13
338
339         We will allocate a chunk of memory of size 53248 bytes that looks like this:
340         0            248       256                       53248       53256
341         [Marked Block | 8 bytes |  payload     ......      ]  8 bytes  |
342                                 ^                                      ^
343                            Our Environment record starts here.         ^
344                                                                        ^
345                                                                  Our last JSValue in the environment record will go from byte 53248 to 53256. But, we don't own this memory.
346
347         We need to ensure that we round up sizeof(MarkedBlock) to an
348         atomSize boundary. We need to do this because the first atom
349         inside the MarkedBlock will start at the rounded up multiple
350         of atomSize past MarkedBlock. If we end up with an allocation
351         that is perfectly aligned to the page size, then we will be short
352         8 bytes (in the current implementation where atomSize is 16 bytes,
353         and MarkedBlock is 248 bytes).
354
355         * heap/MarkedAllocator.cpp:
356         (JSC::MarkedAllocator::allocateBlock):
357         * tests/stress/heap-allocator-allocates-incorrect-size-for-activation.js: Added.
358         (use):
359         (makeFunction):
360
361 2015-08-26  Mark Lam  <mark.lam@apple.com>
362
363         watchdog m_didFire state erroneously retained.
364         https://bugs.webkit.org/show_bug.cgi?id=131082
365
366         Reviewed by Geoffrey Garen.
367
368         The watchdog can fire for 2 reasons:
369         1. an external controlling entity (i.e. another thread) has scheduled termination
370            of the script thread via watchdog::terminateSoon().
371         2. the allowed CPU time has expired.
372
373         For case 1, we're doing away with the m_didFire flag.  Watchdog::terminateSoon() 
374         will set the timer deadlines and m_timeLimit to 0, and m_timerDidFire to true.
375         This will get the script thread to check Watchdog::didFire() and terminate
376         execution.
377
378         Note: the watchdog only guarantees that script execution will terminate as soon
379         as possible due to a time limit of 0.  Once we've exited the VM, the client of the
380         VM is responsible from keeping a flag to prevent new script execution.
381
382         In a race condition, if terminateSoon() is called just after execution has gotten
383         past the client's reentry check and the client is in the process of re-entering,
384         the worst that can happen is that we will schedule the watchdog timer to fire
385         after a period of 0.  This will terminate script execution quickly, and thereafter
386         the client's check should be able to prevent further entry into the VM.
387
388         The correctness (i.e. has no race condition) of this type of termination relies
389         on the termination state being sticky.  Once the script thread is terminated this
390         way, the VM will continue to terminate scripts quickly until the client sets the
391         time limit to a non-zero value (or clears it which sets the time limit to
392         noTimeLimit).
393
394         For case 2, the watchdog does not alter m_timeLimit.  If the CPU deadline has
395         been reached, the script thread will terminate execution and exit the VM.
396
397         If the client of the VM starts new script execution, the watchdog will allow
398         execution for the specified m_timeLimit.  In this case, since m_timeLimit is not
399         0, the script gets a fresh allowance of CPU time to execute.  Hence, terminations
400         due to watchdog time outs are no longer sticky.
401
402         * API/JSContextRef.cpp:
403         (JSContextGroupSetExecutionTimeLimit):
404         (JSContextGroupClearExecutionTimeLimit):
405         * API/tests/ExecutionTimeLimitTest.cpp:
406         - Add test scenarios to verify that the watchdog is automatically reset by the VM
407           upon throwing the TerminatedExecutionException.
408
409         (testResetAfterTimeout):
410         (testExecutionTimeLimit):
411         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
412         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
413         * JavaScriptCore.xcodeproj/project.pbxproj:
414         * dfg/DFGByteCodeParser.cpp:
415         (JSC::DFG::ByteCodeParser::parseBlock):
416         * interpreter/Interpreter.cpp:
417         (JSC::Interpreter::execute):
418         (JSC::Interpreter::executeCall):
419         (JSC::Interpreter::executeConstruct):
420         * jit/JITOpcodes.cpp:
421         (JSC::JIT::emit_op_loop_hint):
422         (JSC::JIT::emitSlow_op_loop_hint):
423         * jit/JITOperations.cpp:
424         * llint/LLIntSlowPaths.cpp:
425         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
426         * runtime/VM.cpp:
427         (JSC::VM::VM):
428         (JSC::VM::ensureWatchdog):
429         * runtime/VM.h:
430         * runtime/VMInlines.h: Added.
431         (JSC::VM::shouldTriggerTermination):
432         * runtime/Watchdog.cpp:
433         (JSC::Watchdog::Watchdog):
434         (JSC::Watchdog::setTimeLimit):
435         (JSC::Watchdog::terminateSoon):
436         (JSC::Watchdog::didFireSlow):
437         (JSC::Watchdog::hasTimeLimit):
438         (JSC::Watchdog::enteredVM):
439         (JSC::Watchdog::exitedVM):
440         (JSC::Watchdog::startTimer):
441         (JSC::Watchdog::stopTimer):
442         (JSC::Watchdog::hasStartedTimer): Deleted.
443         (JSC::Watchdog::fire): Deleted.
444         * runtime/Watchdog.h:
445         (JSC::Watchdog::didFire):
446         (JSC::Watchdog::timerDidFireAddress):
447
448 2015-08-26  Joseph Pecoraro  <pecoraro@apple.com>
449
450         Web Inspector: Implement tracking of active stylesheets in the frontend
451         https://bugs.webkit.org/show_bug.cgi?id=105828
452
453         Reviewed by Timothy Hatcher.
454
455         * inspector/protocol/CSS.json:
456         Add new events for when a StyleSheet is added or removed.
457
458 2015-08-26  Chris Dumez  <cdumez@apple.com>
459
460         Distinguish Web IDL callback interfaces from Web IDL callback functions
461         https://bugs.webkit.org/show_bug.cgi?id=148434
462
463         Reviewed by Geoffrey Garen.
464
465         Add isNull() convenience method on PropertyName.
466
467         * runtime/PropertyName.h:
468         (JSC::PropertyName::isNull):
469
470 2015-08-26  Filip Pizlo  <fpizlo@apple.com>
471
472         Node::origin should be able to tell you if it's OK to exit
473         https://bugs.webkit.org/show_bug.cgi?id=145204
474
475         Reviewed by Geoffrey Garen.
476
477         This is a major change to DFG IR, that makes it easier to reason about where nodes with
478         speculations can be soundly hoisted.
479
480         A program in DFG IR is a sequence of operations that compute the values of SSA variables,
481         perform effects on the heap or stack, and perform updates to the OSR exit state. Because
482         effects and OSR exit updates are interleaved, there are points in execution where exiting
483         simply won't work. For example, we may have some bytecode operation:
484
485             [  24] op_foo loc42 // does something, and puts a value in loc42.
486
487         that gets compiled down to a sequence of DFG IR nodes like:
488
489             a: Foo(W:Heap, R:World, bc#24) // writes heap, reads world - i.e. an observable effect.
490             b: MovHint(@a, loc42, bc#24)
491             c: SetLocal(Check:Int32:@a, loc42, bc#24, exit: bc#26)
492
493         Note that we can OSR exit at @a because we haven't yet performed any effects for bc#24 yet and
494         we have performed all effects for prior bytecode operations. That's what the origin.forExit
495         being set to "bc#24" guarantees. So, an OSR exit at @a would transfer execution to bc#24 and
496         this would not be observable. But at @b, if we try to exit to bc#24 as indicated by forExit, we
497         would end up causing the side effect of bc#24 to execute a second time. This would be
498         observable, so we cannot do it. And we cannot exit to the next instruction - bc#26 - either,
499         because @b is responsible for updating the OSR state to indicate that the result of @a should
500         be put into loc42. It's not until we get to @c that we can exit again.
501
502         This is a confusing, but useful, property of DFG IR. It's useful because it allows us to use IR
503         to spell out how we would have affected the bytecode state, and we use this to implement hard
504         things like object allocation elimination, where we use IR instructions to indicate what object
505         allocation and mutation operations we would have performed, and which bytecode variables would
506         have pointed to those objects. So long as IR allows us to describe how OSR exit state is
507         updated, there will be points in execution where that state is invalid - especially if the IR
508         to update exit state is separate from the IR to perform actual effects.
509
510         But this property is super confusing! It's difficult to explain that somehow magically, @b is a
511         bad place to put OSR exits, and that magically we will only have OSR exits at @a. Of course, it
512         all kind of makes sense - we insert OSR exit checks in phases that *know* where it's safe to
513         exit - but it's just too opaque. This also gets in the way of more sophisticated
514         transformations. For example, LICM barely works - it magically knows that loop pre-headers are
515         good places to exit from, but it has no way of determining if that is actually true. It would
516         be odd to introduce a restriction that anytime some block qualifies as a pre-header according
517         to our loop calculator, it must end with a terminal at which it is OK to exit. So, our choices
518         are to either leave LICM in a magical state and exercise extreme caution when introducing new
519         optimizations that hoist checks, or to do something to make the "can I exit here" property more
520         explicit in IR.
521
522         We have already, in a separate change, added a NodeOrigin::exitOK property, though it didn't do
523         anything yet. This change puts exitOK to work, and makes it an integral part of IR. The key
524         intuition behind this change is that if we know which nodes clobber exit state - i.e. after the
525         node, it's no longer possible to OSR exit until the exit state is fixed up - then we can figure
526         out where it's fine to exit. This change mostly adopts the already implicit rule that it's
527         always safe to exit right at the boundary of exit origins (in between two nodes where
528         origin.forExit differs), and adds a new node, called ExitOK, which is a kind of declaration
529         that exit state is good again. When making this change, I struggled with the question of
530         whether to make origin.exitOK be explicit, or something that we can compute with an analysis.
531         Of course if we are armed with a clobbersExitState(Node*) function, we can find the places
532         where it's fine to exit. But this kind of computation could get quite sophisticated if the
533         nodes belonging to an exit origin are lowered to a control-flow construct. It would also be
534         harder to see what the original intent was, if we found an error: is the bug that we shouldn't
535         be clobbering exit state, or that we shouldn't be exiting? This change opts to make exitOK be
536         an explicit property of IR, so that DFG IR validation will reject any program where exitOK is
537         true after a node that clobbersExitState(), or if exitOK is true after a node has exitOK set to
538         false - unless the latter node has a different exit origin or is an ExitOK node. It will also
539         reject any program where a node mayExit() with !exitOK.
540
541         It turns out that this revealed a lot of sloppiness and what almost looked like an outright
542         bug: the callee property of an inline closure call frame was being set up "as if" by the
543         callee's op_enter. If we did hoist a check per the old rule - to the boundary of exit origins -
544         then we would crash because the callee is unknown. It also revealed that LICM could *almost*
545         get hosed by having a pre-header where there are effects before the jump. I wasn't able to
546         construct a test case that would crash trunk, but I also couldn't quite prove why such a
547         program couldn't be constructed. I did fix the issue in loop pre-header creation, and the
548         validater does catch the issue because of its exitOK assertions.
549
550         This doesn't yet add any other safeguards to LICM - that phase still expects that pre-headers
551         are in place and that they were created in such a way that their terminal origins have exitOK.
552         It also still keeps the old way of saying "not OK to exit" - having a clear NodeOrigin. In a
553         later patch I'll remove that and use !exitOK everywhere. Note that I did consider using clear
554         NodeOrigins to signify that it's not OK to exit, but that would make DFGForAllKills a lot more
555         expensive - it would have to sometimes search to find nearby forExit origins if the current
556         node doesn't have it set - and that's a critical phase for DFG compilation performance.
557         Requiring that forExit is usually set to *something* and that properly shadows the original
558         bytecode is cheap and easy, so it seemed like a good trade-off.
559
560         This change has no performance effect. Its only effect is that it makes the compiler easier to
561         understand by turning a previously magical concept into an explicit one.
562
563         * CMakeLists.txt:
564         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
565         * JavaScriptCore.xcodeproj/project.pbxproj:
566         * dfg/DFGAbstractHeap.h:
567         * dfg/DFGAbstractInterpreterInlines.h:
568         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
569         * dfg/DFGArgumentsEliminationPhase.cpp:
570         * dfg/DFGByteCodeParser.cpp:
571         (JSC::DFG::ByteCodeParser::setDirect):
572         (JSC::DFG::ByteCodeParser::currentNodeOrigin):
573         (JSC::DFG::ByteCodeParser::branchData):
574         (JSC::DFG::ByteCodeParser::addToGraph):
575         (JSC::DFG::ByteCodeParser::handleCall):
576         (JSC::DFG::ByteCodeParser::inlineCall):
577         (JSC::DFG::ByteCodeParser::handleInlining):
578         (JSC::DFG::ByteCodeParser::handleGetById):
579         (JSC::DFG::ByteCodeParser::handlePutById):
580         (JSC::DFG::ByteCodeParser::parseBlock):
581         * dfg/DFGCFGSimplificationPhase.cpp:
582         (JSC::DFG::CFGSimplificationPhase::run):
583         * dfg/DFGClobberize.h:
584         (JSC::DFG::clobberize):
585         * dfg/DFGClobbersExitState.cpp: Added.
586         (JSC::DFG::clobbersExitState):
587         * dfg/DFGClobbersExitState.h: Added.
588         * dfg/DFGConstantFoldingPhase.cpp:
589         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
590         * dfg/DFGDoesGC.cpp:
591         (JSC::DFG::doesGC):
592         * dfg/DFGFixupPhase.cpp:
593         (JSC::DFG::FixupPhase::fixupNode):
594         (JSC::DFG::FixupPhase::convertStringAddUse):
595         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
596         (JSC::DFG::FixupPhase::fixupGetAndSetLocalsInBlock):
597         (JSC::DFG::FixupPhase::fixupChecksInBlock):
598         * dfg/DFGFlushFormat.h:
599         (JSC::DFG::useKindFor):
600         (JSC::DFG::uncheckedUseKindFor):
601         (JSC::DFG::typeFilterFor):
602         * dfg/DFGGraph.cpp:
603         (JSC::DFG::printWhiteSpace):
604         (JSC::DFG::Graph::dumpCodeOrigin):
605         (JSC::DFG::Graph::dump):
606         * dfg/DFGGraph.h:
607         (JSC::DFG::Graph::addSpeculationMode):
608         * dfg/DFGInsertionSet.cpp:
609         (JSC::DFG::InsertionSet::insertSlow):
610         (JSC::DFG::InsertionSet::execute):
611         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
612         (JSC::DFG::LoopPreHeaderCreationPhase::run):
613         * dfg/DFGMayExit.cpp:
614         (JSC::DFG::mayExit):
615         (WTF::printInternal):
616         * dfg/DFGMayExit.h:
617         * dfg/DFGMovHintRemovalPhase.cpp:
618         * dfg/DFGNodeOrigin.cpp: Added.
619         (JSC::DFG::NodeOrigin::dump):
620         * dfg/DFGNodeOrigin.h:
621         (JSC::DFG::NodeOrigin::NodeOrigin):
622         (JSC::DFG::NodeOrigin::isSet):
623         (JSC::DFG::NodeOrigin::withSemantic):
624         (JSC::DFG::NodeOrigin::withExitOK):
625         (JSC::DFG::NodeOrigin::withInvalidExit):
626         (JSC::DFG::NodeOrigin::takeValidExit):
627         (JSC::DFG::NodeOrigin::forInsertingAfter):
628         (JSC::DFG::NodeOrigin::operator==):
629         (JSC::DFG::NodeOrigin::operator!=):
630         * dfg/DFGNodeType.h:
631         * dfg/DFGOSREntrypointCreationPhase.cpp:
632         (JSC::DFG::OSREntrypointCreationPhase::run):
633         * dfg/DFGOSRExit.cpp:
634         (JSC::DFG::OSRExit::OSRExit):
635         (JSC::DFG::OSRExit::setPatchableCodeOffset):
636         * dfg/DFGOSRExitBase.h:
637         * dfg/DFGObjectAllocationSinkingPhase.cpp:
638         * dfg/DFGPhantomInsertionPhase.cpp:
639         * dfg/DFGPhase.cpp:
640         (JSC::DFG::Phase::validate):
641         (JSC::DFG::Phase::beginPhase):
642         (JSC::DFG::Phase::endPhase):
643         * dfg/DFGPhase.h:
644         (JSC::DFG::Phase::vm):
645         (JSC::DFG::Phase::codeBlock):
646         (JSC::DFG::Phase::profiledBlock):
647         * dfg/DFGPredictionPropagationPhase.cpp:
648         (JSC::DFG::PredictionPropagationPhase::propagate):
649         * dfg/DFGPutStackSinkingPhase.cpp:
650         * dfg/DFGSSAConversionPhase.cpp:
651         (JSC::DFG::SSAConversionPhase::run):
652         * dfg/DFGSafeToExecute.h:
653         (JSC::DFG::safeToExecute):
654         * dfg/DFGSpeculativeJIT.cpp:
655         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
656         (JSC::DFG::SpeculativeJIT::speculationCheck):
657         (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
658         (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
659         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
660         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
661         (JSC::DFG::SpeculativeJIT::compile):
662         * dfg/DFGSpeculativeJIT.h:
663         * dfg/DFGSpeculativeJIT32_64.cpp:
664         (JSC::DFG::SpeculativeJIT::compile):
665         * dfg/DFGSpeculativeJIT64.cpp:
666         (JSC::DFG::SpeculativeJIT::compile):
667         * dfg/DFGStoreBarrierInsertionPhase.cpp:
668         * dfg/DFGTypeCheckHoistingPhase.cpp:
669         (JSC::DFG::TypeCheckHoistingPhase::run):
670         * dfg/DFGValidate.cpp:
671         (JSC::DFG::Validate::validate):
672         * ftl/FTLCapabilities.cpp:
673         (JSC::FTL::canCompile):
674         * ftl/FTLLowerDFGToLLVM.cpp:
675         (JSC::FTL::DFG::LowerDFGToLLVM::lower):
676         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
677         (JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon):
678         (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
679         (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
680
681 2015-08-26  Andreas Kling  <akling@apple.com>
682
683         [JSC] StructureTransitionTable should eagerly deallocate single-transition WeakImpls.
684         <https://webkit.org/b/148478>
685
686         Reviewed by Geoffrey Garen.
687
688         Use a WeakHandleOwner to eagerly deallocate StructureTransitionTable's Weak pointers
689         when it's using the single-transition optimization and the Structure it transitioned
690         to has been GC'd.
691
692         This prevents Structures from keeping WeakBlocks alive longer than necessary when
693         they've been transitioned away from but are still in use themselves.
694
695         * runtime/Structure.cpp:
696         (JSC::singleSlotTransitionWeakOwner):
697         (JSC::StructureTransitionTable::singleTransition):
698         (JSC::StructureTransitionTable::setSingleTransition):
699         (JSC::StructureTransitionTable::add):
700         * runtime/StructureTransitionTable.h:
701         (JSC::StructureTransitionTable::singleTransition): Deleted.
702         (JSC::StructureTransitionTable::setSingleTransition): Deleted.
703
704 2015-08-26  Brian Burg  <bburg@apple.com>
705
706         Web Inspector: REGRESSION(r188965): BackendDispatcher loses request ids when called re-entrantly
707         https://bugs.webkit.org/show_bug.cgi?id=148480
708
709         Reviewed by Joseph Pecoraro.
710
711         I added an assertion that m_currentRequestId is Nullopt when dispatch() is called, but this should
712         not hold if dispatching a backend command while debugger is paused. I will remove the assertion
713         and add proper scoping for all dispatch() branches.
714
715         No new tests, this wrong assert caused inspector/dom-debugger/node-removed.html to crash reliably.
716
717         * inspector/InspectorBackendDispatcher.cpp:
718         (Inspector::BackendDispatcher::dispatch): Cover each exit with an appropriate TemporaryChange scope.
719
720 2015-08-26  Sukolsak Sakshuwong  <sukolsak@gmail.com>
721
722         Remove the unused *Executable::unlinkCalls() and CodeBlock::unlinkCalls()
723         https://bugs.webkit.org/show_bug.cgi?id=148469
724
725         Reviewed by Geoffrey Garen.
726
727         We use CodeBlock::unlinkIncomingCalls() to unlink calls.
728         (...)Executable::unlinkCalls() and CodeBlock::unlinkCalls() are no longer used.
729
730         * bytecode/CodeBlock.cpp:
731         (JSC::CodeBlock::unlinkCalls): Deleted.
732         * bytecode/CodeBlock.h:
733         * runtime/Executable.cpp:
734         (JSC::EvalExecutable::unlinkCalls): Deleted.
735         (JSC::ProgramExecutable::unlinkCalls): Deleted.
736         (JSC::FunctionExecutable::unlinkCalls): Deleted.
737         * runtime/Executable.h:
738         (JSC::ScriptExecutable::unlinkCalls): Deleted.
739
740 2015-08-25  Brian Burg  <bburg@apple.com>
741
742         Web Inspector: no need to allocate protocolErrors array for every dispatched backend command
743         https://bugs.webkit.org/show_bug.cgi?id=146466
744
745         Reviewed by Joseph Pecoraro.
746
747         Clean up some of the backend dispatcher code, with a focus on eliminating useless allocations
748         of objects in the common case when no protocol errors happen. This is done by saving the
749         current id of each request as it is being processed by the backend dispatcher, and tagging any
750         subsequent errors with that id. This also means we don't have to thread the requestId except
751         in the async command code path.
752
753         This patch also lifts some common code shared between all generated backend command
754         implementatations into the per-domain dispatch method instead. This reduces generated code size.
755
756         To be consistent, this patch standardizes on calling the id of a backend message its 'requestId'.
757         Requests can be handled synchronously or asynchronously (triggered via the 'async' property).
758
759         No new tests, covered by existing protocol tests.
760
761         * inspector/InspectorBackendDispatcher.cpp:
762         (Inspector::BackendDispatcher::CallbackBase::CallbackBase): Split the two code paths for reporting
763         success and failure.
764
765         (Inspector::BackendDispatcher::CallbackBase::sendFailure):
766         (Inspector::BackendDispatcher::CallbackBase::sendSuccess): Renamed from sendIfActive.
767         (Inspector::BackendDispatcher::dispatch): Reset counters and current requestId before dispatching.
768         No need to manually thread the requestId to all reportProtocolError calls.
769
770         (Inspector::BackendDispatcher::hasProtocolErrors): Added.
771         (Inspector::BackendDispatcher::sendResponse):
772         (Inspector::BackendDispatcher::sendPendingErrors): Send any saved protocol errors to the frontend.
773         Always send a 'data' member with all of the errors, even if there's just one. We might want to add
774         more information about errors later.
775
776         (Inspector::BackendDispatcher::reportProtocolError): Enqueue a protocol error to be sent later.
777         (Inspector::BackendDispatcher::getPropertyValue): Remove useless type parameters and nuke most of
778         the type conversion methods. Use std::function types instead of function pointer types.
779
780         (Inspector::castToInteger): Added.
781         (Inspector::castToNumber): Added.
782         (Inspector::BackendDispatcher::getInteger):
783         (Inspector::BackendDispatcher::getDouble):
784         (Inspector::BackendDispatcher::getString):
785         (Inspector::BackendDispatcher::getBoolean):
786         (Inspector::BackendDispatcher::getObject):
787         (Inspector::BackendDispatcher::getArray):
788         (Inspector::BackendDispatcher::getValue):
789         (Inspector::getPropertyValue): Deleted.
790         (Inspector::AsMethodBridges::asInteger): Deleted.
791         (Inspector::AsMethodBridges::asDouble): Deleted.
792         (Inspector::AsMethodBridges::asString): Deleted.
793         (Inspector::AsMethodBridges::asBoolean): Deleted.
794         (Inspector::AsMethodBridges::asObject): Deleted.
795         (Inspector::AsMethodBridges::asArray): Deleted.
796         (Inspector::AsMethodBridges::asValue): Deleted.
797         * inspector/InspectorBackendDispatcher.h:
798         * inspector/scripts/codegen/cpp_generator_templates.py: Extract 'params' object in domain dispatch method.
799         Omit requestIds where possible. Convert dispatch tables to use NeverDestroyed. Check the protocol error count
800         to decide whether to abort the dispatch or not, rather than allocating our own errors array.
801
802         * inspector/scripts/codegen/cpp_generator_templates.py:
803         (void):
804         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: Revert to passing RefPtr<InspectorObject>
805         since parameters are now being passed rather than the message object. Some commands do not require parameters.
806         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
807         (CppBackendDispatcherImplementationGenerator.generate_output):
808         (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
809         (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
810         * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
811         (ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declaration_for_command):
812         * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
813         (ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_command):
814         (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
815         * inspector/scripts/codegen/objc_generator_templates.py:
816
817         Rebaseline some protocol generator tests.
818         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
819         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
820         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
821         * inspector/scripts/tests/expected/enum-values.json-result:
822         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
823         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
824         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
825         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
826         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
827         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
828         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
829         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
830         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
831
832 2015-08-25  Saam barati  <sbarati@apple.com>
833
834         Lets rename codeOriginIndex to callSiteIndex and get rid of CallFrame::Location.
835         https://bugs.webkit.org/show_bug.cgi?id=148213
836
837         Reviewed by Filip Pizlo.
838
839         This patch introduces a struct called CallSiteIndex which is
840         used as a wrapper for a 32-bit int to place things in the tag for ArgumentCount 
841         in the call frame. On 32-bit we place Instruction* into this slot for LLInt and Basline.
842         For 32-bit DFG we place a an index into the code origin table in this slot.
843         On 64-bit we place a bytecode offset into this slot for LLInt and Baseline.
844         On 64-bit we place the index into the code origin table in this slot in the
845         DFG/FTL.
846
847         This patch also gets rid of the encoding scheme that describes if something is a
848         bytecode index or a code origin table index. This information can always
849         be determined based on the CodeBlock's' JITType.
850
851         StructureStubInfo now also has a CallSiteIndex which it stores to
852         the call frame when making a call.
853
854         * bytecode/CodeBlock.h:
855         (JSC::CodeBlock::hasCodeOrigins):
856         (JSC::CodeBlock::canGetCodeOrigin):
857         (JSC::CodeBlock::codeOrigin):
858         (JSC::CodeBlock::addFrequentExitSite):
859         * bytecode/StructureStubInfo.h:
860         (JSC::StructureStubInfo::StructureStubInfo):
861         * dfg/DFGCommonData.cpp:
862         (JSC::DFG::CommonData::notifyCompilingStructureTransition):
863         (JSC::DFG::CommonData::addCodeOrigin):
864         (JSC::DFG::CommonData::shrinkToFit):
865         * dfg/DFGCommonData.h:
866         (JSC::DFG::CommonData::CommonData):
867         * dfg/DFGJITCompiler.h:
868         (JSC::DFG::JITCompiler::setEndOfCode):
869         (JSC::DFG::JITCompiler::addCallSite):
870         (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
871         * dfg/DFGOSRExitCompilerCommon.cpp:
872         (JSC::DFG::reifyInlinedCallFrames):
873         * dfg/DFGSpeculativeJIT.cpp:
874         (JSC::DFG::SpeculativeJIT::compileIn):
875         * dfg/DFGSpeculativeJIT32_64.cpp:
876         (JSC::DFG::SpeculativeJIT::cachedGetById):
877         (JSC::DFG::SpeculativeJIT::cachedPutById):
878         * dfg/DFGSpeculativeJIT64.cpp:
879         (JSC::DFG::SpeculativeJIT::cachedGetById):
880         (JSC::DFG::SpeculativeJIT::cachedPutById):
881         * ftl/FTLCompile.cpp:
882         (JSC::FTL::mmAllocateDataSection):
883         * ftl/FTLInlineCacheDescriptor.h:
884         (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
885         (JSC::FTL::InlineCacheDescriptor::stackmapID):
886         (JSC::FTL::InlineCacheDescriptor::callSiteIndex):
887         (JSC::FTL::InlineCacheDescriptor::uid):
888         (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
889         (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
890         (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
891         (JSC::FTL::InlineCacheDescriptor::codeOrigin): Deleted.
892         * ftl/FTLLink.cpp:
893         (JSC::FTL::link):
894         * ftl/FTLLowerDFGToLLVM.cpp:
895         (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
896         (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
897         (JSC::FTL::DFG::LowerDFGToLLVM::getById):
898         (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
899         * ftl/FTLSlowPathCall.cpp:
900         (JSC::FTL::storeCodeOrigin):
901         * interpreter/CallFrame.cpp:
902         (JSC::CallFrame::currentVPC):
903         (JSC::CallFrame::setCurrentVPC):
904         (JSC::CallFrame::callSiteBitsAsBytecodeOffset):
905         (JSC::CallFrame::bytecodeOffset):
906         (JSC::CallFrame::codeOrigin):
907         (JSC::CallFrame::topOfFrameInternal):
908         (JSC::CallFrame::locationAsBytecodeOffset): Deleted.
909         (JSC::CallFrame::setLocationAsBytecodeOffset): Deleted.
910         (JSC::CallFrame::bytecodeOffsetFromCodeOriginIndex): Deleted.
911         * interpreter/CallFrame.h:
912         (JSC::CallSiteIndex::CallSiteIndex):
913         (JSC::CallSiteIndex::bits):
914         (JSC::ExecState::returnPCOffset):
915         (JSC::ExecState::abstractReturnPC):
916         (JSC::ExecState::topOfFrame):
917         (JSC::ExecState::setCallerFrame):
918         (JSC::ExecState::setScope):
919         (JSC::ExecState::currentVPC): Deleted.
920         (JSC::ExecState::setCurrentVPC): Deleted.
921         * interpreter/CallFrameInlines.h:
922         (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
923         (JSC::CallFrame::callSiteBitsAreCodeOriginIndex):
924         (JSC::CallFrame::callSiteAsRawBits):
925         (JSC::CallFrame::callSiteIndex):
926         (JSC::CallFrame::hasActivation):
927         (JSC::CallFrame::Location::encode): Deleted.
928         (JSC::CallFrame::Location::decode): Deleted.
929         (JSC::CallFrame::Location::encodeAsBytecodeOffset): Deleted.
930         (JSC::CallFrame::Location::encodeAsBytecodeInstruction): Deleted.
931         (JSC::CallFrame::Location::encodeAsCodeOriginIndex): Deleted.
932         (JSC::CallFrame::Location::isBytecodeLocation): Deleted.
933         (JSC::CallFrame::Location::isCodeOriginIndex): Deleted.
934         (JSC::CallFrame::hasLocationAsBytecodeOffset): Deleted.
935         (JSC::CallFrame::hasLocationAsCodeOriginIndex): Deleted.
936         (JSC::CallFrame::locationAsRawBits): Deleted.
937         (JSC::CallFrame::setLocationAsRawBits): Deleted.
938         (JSC::CallFrame::locationAsBytecodeOffset): Deleted.
939         (JSC::CallFrame::setLocationAsBytecodeOffset): Deleted.
940         (JSC::CallFrame::locationAsCodeOriginIndex): Deleted.
941         * interpreter/StackVisitor.cpp:
942         (JSC::StackVisitor::readFrame):
943         (JSC::StackVisitor::readNonInlinedFrame):
944         (JSC::StackVisitor::Frame::print):
945         * jit/JITCall.cpp:
946         (JSC::JIT::compileOpCall):
947         * jit/JITCall32_64.cpp:
948         (JSC::JIT::compileOpCall):
949         * jit/JITInlineCacheGenerator.cpp:
950         (JSC::garbageStubInfo):
951         (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
952         (JSC::JITByIdGenerator::JITByIdGenerator):
953         (JSC::JITByIdGenerator::generateFastPathChecks):
954         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
955         (JSC::JITGetByIdGenerator::generateFastPath):
956         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
957         * jit/JITInlineCacheGenerator.h:
958         (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
959         (JSC::JITInlineCacheGenerator::stubInfo):
960         (JSC::JITByIdGenerator::JITByIdGenerator):
961         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
962         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
963         * jit/JITInlines.h:
964         (JSC::JIT::updateTopCallFrame):
965         * jit/JITOperations.cpp:
966         (JSC::getByVal):
967         (JSC::tryGetByValOptimize):
968         * jit/JITPropertyAccess.cpp:
969         (JSC::JIT::emitGetByValWithCachedId):
970         (JSC::JIT::emitPutByValWithCachedId):
971         (JSC::JIT::emit_op_get_by_id):
972         (JSC::JIT::emit_op_put_by_id):
973         * jit/JITPropertyAccess32_64.cpp:
974         (JSC::JIT::emitGetByValWithCachedId):
975         (JSC::JIT::emitPutByValWithCachedId):
976         (JSC::JIT::emit_op_get_by_id):
977         (JSC::JIT::emit_op_put_by_id):
978         * jit/Repatch.cpp:
979         (JSC::generateByIdStub):
980
981 2015-08-25 Aleksandr Skachkov   <gskachkov@gmail.com>
982
983         Function.prototype.toString is incorrect for ArrowFunction
984         https://bugs.webkit.org/show_bug.cgi?id=148148
985
986         Reviewed by Saam Barati.
987         
988         Added correct support of toString() method for arrow function.
989
990         * parser/ASTBuilder.h:
991         (JSC::ASTBuilder::createFunctionMetadata):
992         (JSC::ASTBuilder::createArrowFunctionExpr):
993         * parser/Nodes.cpp:
994         (JSC::FunctionMetadataNode::FunctionMetadataNode):
995         * parser/Nodes.h:
996         * parser/Parser.cpp:
997         (JSC::Parser<LexerType>::parseFunctionBody):
998         (JSC::Parser<LexerType>::parseFunctionInfo):
999         * parser/SyntaxChecker.h:
1000         (JSC::SyntaxChecker::createFunctionMetadata):
1001         * runtime/FunctionPrototype.cpp:
1002         (JSC::functionProtoFuncToString):
1003         * tests/stress/arrowfunction-tostring.js: Added.
1004
1005 2015-08-25  Saam barati  <sbarati@apple.com>
1006
1007         Callee can be incorrectly overridden when it's captured
1008         https://bugs.webkit.org/show_bug.cgi?id=148400
1009
1010         Reviewed by Filip Pizlo.
1011
1012         We now resort to always creating the function name scope
1013         when the function name is in scope. Because the bytecode
1014         generator now has a notion of local lexical scoping,
1015         this incurs no runtime penalty for function expression names
1016         that aren't heap allocated. If they are heap allocated,
1017         this means we may now have one more scope on the runtime
1018         scope stack than before. This modification simplifies the
1019         callee initialization code and uses the lexical scoping constructs
1020         to implement this. This implementation also ensures
1021         that everything Just Works for function's with default
1022         parameter values. Before this patch, IIFE functions
1023         with default parameter values and a captured function
1024         name would crash JSC.
1025
1026         * bytecompiler/BytecodeGenerator.cpp:
1027         (JSC::BytecodeGenerator::BytecodeGenerator):
1028         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
1029         (JSC::BytecodeGenerator::popLexicalScopeInternal):
1030         (JSC::BytecodeGenerator::variable):
1031         (JSC::BytecodeGenerator::resolveType):
1032         (JSC::BytecodeGenerator::emitThrowTypeError):
1033         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
1034         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
1035         * bytecompiler/BytecodeGenerator.h:
1036         (JSC::Variable::isReadOnly):
1037         (JSC::Variable::isSpecial):
1038         (JSC::Variable::isConst):
1039         (JSC::Variable::setIsReadOnly):
1040         * bytecompiler/NodesCodegen.cpp:
1041         (JSC::PostfixNode::emitResolve):
1042         (JSC::PrefixNode::emitResolve):
1043         (JSC::ReadModifyResolveNode::emitBytecode):
1044         (JSC::AssignResolveNode::emitBytecode):
1045         (JSC::BindingNode::bindValue):
1046         * tests/stress/IIFE-es6-default-parameters.js: Added.
1047         (assert):
1048         (.):
1049         * tests/stress/IIFE-function-name-captured.js: Added.
1050         (assert):
1051         (.):
1052
1053 2015-08-24  Brian Burg  <bburg@apple.com>
1054
1055         Web Inspector: add protocol test for existing error handling performed by the backend
1056         https://bugs.webkit.org/show_bug.cgi?id=147097
1057
1058         Reviewed by Joseph Pecoraro.
1059
1060         A new test revealed that the protocol "method" parameter was being parsed in a naive way.
1061         Rewrite it to use String::split and improve error checking to avoid failing later.
1062
1063         * inspector/InspectorBackendDispatcher.cpp:
1064         (Inspector::BackendDispatcher::dispatch):
1065
1066 2015-08-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1067
1068         [ES6] Return JSInternalPromise as result of evaluateModule
1069         https://bugs.webkit.org/show_bug.cgi?id=148173
1070
1071         Reviewed by Saam Barati.
1072
1073         Now evaluateModule returns JSInternalPromise* as its result value.
1074         When an error occurs while loading or executing the modules,
1075         this promise is rejected by that error. By leveraging this, we implemented
1076         asynchronous error reporting when executing the modules in JSC shell.
1077
1078         And this patch also changes the evaluateModule signature to accept the entry
1079         point by the moduleName. By using it, JSC shell can start executing the modules
1080         with the entry point module name.
1081
1082         * builtins/ModuleLoaderObject.js:
1083         (loadModule):
1084         * jsc.cpp:
1085         (dumpException):
1086         (runWithScripts):
1087         * runtime/Completion.cpp:
1088         (JSC::evaluateModule):
1089         * runtime/Completion.h:
1090         * runtime/JSInternalPromise.cpp:
1091         (JSC::JSInternalPromise::then):
1092         * runtime/JSInternalPromise.h:
1093         * runtime/ModuleLoaderObject.cpp:
1094         (JSC::ModuleLoaderObject::requestInstantiateAll):
1095         (JSC::ModuleLoaderObject::loadModule):
1096         (JSC::ModuleLoaderObject::resolve):
1097         (JSC::ModuleLoaderObject::fetch):
1098         (JSC::ModuleLoaderObject::translate):
1099         (JSC::ModuleLoaderObject::instantiate):
1100         (JSC::moduleLoaderObjectParseModule):
1101         * runtime/ModuleLoaderObject.h:
1102
1103 2015-08-24  Basile Clement  <basile_clement@apple.com>
1104
1105         REPTACH is not a word
1106         https://bugs.webkit.org/show_bug.cgi?id=148401
1107
1108         Reviewed by Saam Barati.
1109
1110         * assembler/MacroAssemblerX86_64.h:
1111         (JSC::MacroAssemblerX86_64::callWithSlowPathReturnType):
1112         (JSC::MacroAssemblerX86_64::call):
1113         (JSC::MacroAssemblerX86_64::tailRecursiveCall):
1114         (JSC::MacroAssemblerX86_64::makeTailRecursiveCall):
1115         (JSC::MacroAssemblerX86_64::readCallTarget):
1116         (JSC::MacroAssemblerX86_64::linkCall):
1117         (JSC::MacroAssemblerX86_64::repatchCall):
1118
1119 2015-08-24  Mark Lam  <mark.lam@apple.com>
1120
1121         Add support for setting JSC options from a file.
1122         https://bugs.webkit.org/show_bug.cgi?id=148394
1123
1124         Reviewed by Saam Barati.
1125
1126         This is needed for environments where the JSC executable does not have access to
1127         environmental variables.  This is only needed for debugging, and is currently
1128         guarded under a #define USE_OPTIONS_FILE in Options.cpp, and is disabled by
1129         default.
1130
1131         Also fixed Options::setOptions() to be allow for whitespace that is not a single
1132         ' '.  This makes setOptions() much more flexible and friendlier to use for loading
1133         options in general.
1134
1135         For example, this current use case of loading options from a file may have '\n's
1136         in the character stream, and this feature is easier to implement if setOptions()
1137         just support more than 1 whitespace char between options, and recognize whitespace
1138         characters other than ' '.
1139
1140         * runtime/Options.cpp:
1141         (JSC::parse):
1142         (JSC::Options::initialize):
1143         (JSC::Options::setOptions):
1144
1145 2015-08-24  Filip Pizlo  <fpizlo@apple.com>
1146
1147         DFG::FixupPhase should use the lambda form of m_graph.doToChildren() rather than the old macro
1148         https://bugs.webkit.org/show_bug.cgi?id=148397
1149
1150         Reviewed by Geoffrey Garen.
1151
1152         We used to iterate the edges of a node by using the DFG_NODE_DO_TO_CHILDREN macro. We
1153         don't need to do that anymore since we have the lambda-based m_graph.doToChildren(). This
1154         allows us to get rid of a bunch of helper methods in DFG::FixupPhase.
1155
1156         I also took the opportunity to give the injectTypeConversionsInBlock() method a more
1157         generic name, since after https://bugs.webkit.org/show_bug.cgi?id=145204 it will be used
1158         for fix-up of checks more broadly.
1159
1160         * dfg/DFGFixupPhase.cpp:
1161         (JSC::DFG::FixupPhase::run):
1162         (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
1163         (JSC::DFG::FixupPhase::fixupChecksInBlock):
1164         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock): Deleted.
1165         (JSC::DFG::FixupPhase::tryToRelaxRepresentation): Deleted.
1166         (JSC::DFG::FixupPhase::fixEdgeRepresentation): Deleted.
1167         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge): Deleted.
1168
1169 2015-08-24  Geoffrey Garen  <ggaren@apple.com>
1170
1171         Some renaming to clarify CodeBlock and UnlinkedCodeBlock
1172         https://bugs.webkit.org/show_bug.cgi?id=148391
1173
1174         Reviewed by Saam Barati.
1175
1176         * bytecode/UnlinkedFunctionExecutable.cpp:
1177         (JSC::generateUnlinkedFunctionCodeBlock):
1178         (JSC::UnlinkedFunctionExecutable::visitChildren):
1179         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
1180         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
1181         (JSC::generateFunctionCodeBlock): Deleted.
1182         (JSC::UnlinkedFunctionExecutable::codeBlockFor): Deleted.
1183         * bytecode/UnlinkedFunctionExecutable.h: Call our CodeBlocks "unlinked"
1184         in the name for clarity, since we are unlinked. 
1185
1186         * heap/Heap.cpp:
1187         (JSC::Heap::objectTypeCounts):
1188         (JSC::Heap::deleteAllCodeBlocks):
1189         (JSC::Heap::deleteAllUnlinkedCodeBlocks):
1190         (JSC::Heap::clearUnmarkedExecutables):
1191         (JSC::Heap::deleteOldCode):
1192         (JSC::Heap::FinalizerOwner::finalize):
1193         (JSC::Heap::addExecutable):
1194         (JSC::Heap::collectAllGarbageIfNotDoneRecently):
1195         (JSC::Heap::deleteAllCompiledCode): Deleted.
1196         (JSC::Heap::deleteAllUnlinkedFunctionCode): Deleted.
1197         (JSC::Heap::addCompiledCode): Deleted.
1198         * heap/Heap.h:
1199         (JSC::Heap::notifyIsSafeToCollect):
1200         (JSC::Heap::isSafeToCollect):
1201         (JSC::Heap::sizeBeforeLastFullCollection):
1202         (JSC::Heap::sizeAfterLastFullCollection):
1203         (JSC::Heap::compiledCode): Deleted.
1204
1205             deleteAllCompiledCode => deleteAllCodeBlocks because "compiled"
1206             is a broad phrase these days.
1207
1208             m_compiledCode => m_executables for the same reason.
1209
1210             addCompiledCode => addExecutable for the same reason.
1211
1212             deleteAllUnlinkedFunctionCode => deleteAllUnlinkedCodeBlocks
1213             for consistency.
1214
1215         * jsc.cpp:
1216         (functionDeleteAllCompiledCode):
1217
1218         * runtime/Executable.cpp:
1219         (JSC::ScriptExecutable::newCodeBlockFor): codeBlockFor => unlinkedCodeBlockFor
1220
1221         (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation): Deleted.
1222         It was strange to put this function on executable, since its name implied
1223         that it only changed the executable, but it actually changed all cached
1224         code. Now, a client that wants to change cached code must do so explicitly.
1225
1226         * runtime/Executable.h:
1227         (JSC::ScriptExecutable::finishCreation):
1228         * runtime/VM.cpp:
1229         (JSC::VM::deleteAllCode):
1230         * runtime/VMEntryScope.cpp:
1231         (JSC::VMEntryScope::VMEntryScope): Updated for renames above.
1232
1233 2015-08-22  Filip Pizlo  <fpizlo@apple.com>
1234
1235         DFG::InsertionSet should be tolerant of occasional out-of-order insertions
1236         https://bugs.webkit.org/show_bug.cgi?id=148367
1237
1238         Reviewed by Geoffrey Garen and Saam Barati.
1239
1240         Since forever, the DFG::InsertionSet has been the way we insert nodes into DFG IR, and it
1241         requires that you walk a block in order and perform insertions in order: you can't insert
1242         something at index J, then at index I where I < J, except if you do a second pass.
1243
1244         This restriction makes sense, because it enables a very fast algorithm. And it's very
1245         rare that a phase would need to insert things out of order.
1246
1247         But sometimes - rarely - we need to insert things slightly out-of-order. For example we
1248         may want to insert a node at index J, but to insert a check associated with that node, we
1249         may need to use index I where I < J. This will come up from the work on
1250         https://bugs.webkit.org/show_bug.cgi?id=145204. And it has already come up in the past.
1251         It seems like it would be best to just lift this restriction.
1252
1253         * CMakeLists.txt:
1254         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1255         * JavaScriptCore.xcodeproj/project.pbxproj:
1256         * dfg/DFGInsertionSet.cpp: Added.
1257         (JSC::DFG::InsertionSet::insertSlow):
1258         * dfg/DFGInsertionSet.h:
1259         (JSC::DFG::InsertionSet::InsertionSet):
1260         (JSC::DFG::InsertionSet::graph):
1261         (JSC::DFG::InsertionSet::insert):
1262         (JSC::DFG::InsertionSet::execute):
1263
1264 2015-08-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1265
1266         Create ById IC for ByVal operation only when the specific Id comes more than once
1267         https://bugs.webkit.org/show_bug.cgi?id=148288
1268
1269         Reviewed by Geoffrey Garen.
1270
1271         After introducing byId ICs into byVal ops, byVal ops creates much ICs than before.
1272         The failure fixed in r188767 figures out these ICs are created even if this op is executed only once.
1273
1274         The situation is the following;
1275         In the current code, when byVal op is executed with the Id, we immediately set up the byId IC for that byVal op.
1276         But setting up JITGetByIdGenerator generates the fast path IC code and consumes executable memory.
1277         As a result, if we call eval("contains byVal ops") with the different strings repeatedly under no-llint environment, each eval call creates byId IC for byVal and consumes executable memory.
1278
1279         To solve it, we will add "seen" flag to ByValInfo.
1280         And we will create the IC on the second byVal op call with the same Id.
1281
1282         * bytecode/ByValInfo.h:
1283         (JSC::ByValInfo::ByValInfo):
1284         * jit/JITOperations.cpp:
1285         (JSC::tryGetByValOptimize):
1286         * jit/JITPropertyAccess.cpp:
1287         (JSC::JIT::privateCompileGetByValWithCachedId): Deleted.
1288         (JSC::JIT::privateCompilePutByValWithCachedId): Deleted.
1289
1290 2015-08-23  Benjamin Poulain  <bpoulain@apple.com>
1291
1292         [JSC] Get rid of NodePointerTraits
1293         https://bugs.webkit.org/show_bug.cgi?id=148340
1294
1295         Reviewed by Anders Carlsson.
1296
1297         NodePointerTraits does exactly the same thing has the default trait.
1298
1299         * dfg/DFGBasicBlock.h:
1300         * dfg/DFGCommon.h:
1301         (JSC::DFG::NodePointerTraits::defaultValue): Deleted.
1302         (JSC::DFG::NodePointerTraits::isEmptyForDump): Deleted.
1303
1304 2015-08-23  Benjamin Poulain  <bpoulain@apple.com>
1305
1306         [JSC] Reduce the memory usage of BytecodeLivenessAnalysis
1307         https://bugs.webkit.org/show_bug.cgi?id=148353
1308
1309         Reviewed by Darin Adler.
1310
1311         BytecodeLivenessAnalysis easily takes kilobytes of memory for
1312         non trivial blocks and that memory sticks around because
1313         it stored on CodeBlock.
1314
1315         This patch reduces that memory use a bit.
1316
1317         Most of the memory is in the array of BytecodeBasicBlock.
1318         BytecodeBasicBlock is shrunk by:
1319         -Making it not ref-counted.
1320         -Removing m_predecessors, it was only used for debugging and
1321          is usually big.
1322         -Added a shrinkToFit() phase to shrink the vectors once we are
1323          done building the BytecodeBasicBlock.
1324
1325         There are more things we should do in the future:
1326         -Store all the BytecodeBasicBlock direclty in the array.
1327          We know the size ahead of time, this would be a pure win.
1328          The only tricky part is changing m_successors to have the
1329          index of the successor instead of a pointer.
1330         -Stop putting duplicates in m_successors.
1331
1332         * bytecode/BytecodeBasicBlock.cpp:
1333         (JSC::computeBytecodeBasicBlocks):
1334         (JSC::BytecodeBasicBlock::shrinkToFit): Deleted.
1335         (JSC::linkBlocks): Deleted.
1336         * bytecode/BytecodeBasicBlock.h:
1337         (JSC::BytecodeBasicBlock::addSuccessor):
1338         (JSC::BytecodeBasicBlock::addPredecessor): Deleted.
1339         (JSC::BytecodeBasicBlock::predecessors): Deleted.
1340         * bytecode/BytecodeLivenessAnalysis.cpp:
1341         (JSC::getLeaderOffsetForBasicBlock):
1342         (JSC::findBasicBlockWithLeaderOffset):
1343         (JSC::findBasicBlockForBytecodeOffset):
1344         (JSC::stepOverInstruction):
1345         (JSC::computeLocalLivenessForBytecodeOffset):
1346         (JSC::computeLocalLivenessForBlock):
1347         (JSC::BytecodeLivenessAnalysis::dumpResults): Deleted.
1348         * bytecode/BytecodeLivenessAnalysis.h:
1349
1350 2015-08-23  Geoffrey Garen  <ggaren@apple.com>
1351
1352         Unreviewed, rolling back in r188792.
1353         https://bugs.webkit.org/show_bug.cgi?id=148347
1354
1355         Previously reverted changesets:
1356
1357         "Unify code paths for manually deleting all code"
1358         https://bugs.webkit.org/show_bug.cgi?id=148280
1359         http://trac.webkit.org/changeset/188792
1360
1361         The previous patch caused some inspector tests to hang because it
1362         introduced extra calls to sourceParsed, and sourceParsed is
1363         pathologically slow in WK1 debug builds. This patch restores pre-existing
1364         code to limit calls to sourceParsed, excluding code not being debugged
1365         (i.e., inspector code).
1366
1367 2015-08-23  Geoffrey Garen  <ggaren@apple.com>
1368
1369         Unreviewed, rolling back in r188803.
1370
1371         Previously reverted changesets:
1372
1373         "Debugger's VM should never be null"
1374         https://bugs.webkit.org/show_bug.cgi?id=148341
1375         http://trac.webkit.org/changeset/188803
1376
1377         * debugger/Debugger.cpp:
1378         (JSC::Debugger::Debugger):
1379         (JSC::Debugger::attach):
1380         (JSC::Debugger::detach):
1381         (JSC::Debugger::isAttached):
1382         (JSC::Debugger::setSteppingMode):
1383         (JSC::Debugger::registerCodeBlock):
1384         (JSC::Debugger::toggleBreakpoint):
1385         (JSC::Debugger::recompileAllJSFunctions):
1386         (JSC::Debugger::setBreakpoint):
1387         (JSC::Debugger::clearBreakpoints):
1388         (JSC::Debugger::clearDebuggerRequests):
1389         (JSC::Debugger::setBreakpointsActivated):
1390         (JSC::Debugger::breakProgram):
1391         (JSC::Debugger::stepOutOfFunction):
1392         (JSC::Debugger::returnEvent):
1393         (JSC::Debugger::didExecuteProgram):
1394         * debugger/Debugger.h:
1395         * inspector/JSGlobalObjectScriptDebugServer.cpp:
1396         (Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
1397         (Inspector::JSGlobalObjectScriptDebugServer::removeListener):
1398         (Inspector::JSGlobalObjectScriptDebugServer::runEventLoopWhilePaused):
1399         (Inspector::JSGlobalObjectScriptDebugServer::recompileAllJSFunctions): Deleted.
1400         * inspector/JSGlobalObjectScriptDebugServer.h:
1401         * inspector/ScriptDebugServer.cpp:
1402         (Inspector::ScriptDebugServer::ScriptDebugServer):
1403         * inspector/ScriptDebugServer.h:
1404
1405 2015-08-22  Filip Pizlo  <fpizlo@apple.com>
1406
1407         DFG string concatenation shouldn't be playing fast and loose with effects and OSR exit
1408         https://bugs.webkit.org/show_bug.cgi?id=148338
1409
1410         Reviewed by Michael Saboff and Saam Barati.
1411
1412         Prior to this change, DFG string concatenation appeared to have various different ways of
1413         creating an OSR exit right after a side effect. That's bad, because the exit will cause
1414         us to reexecute the side effect. The code appears to have some hacks for avoiding this,
1415         but some cases are basically unavoidable, like the OOM case of string concatenation: in
1416         trunk that could cause two executions of the toString operation.
1417
1418         This changes the string concatenation code to either be speculative or effectful but
1419         never both. It's already the case that when this code needs to be effectful, it also
1420         needs to be slow (it does int->string conversions, calls JS functions, etc). So, this is
1421         a small price to pay for sanity.
1422
1423         The biggest part of this change is the introduction of StrCat, which is like MakeRope but
1424         does toString conversions on its own instead of relying on separate nodes. StrCat can
1425         take either 2 or 3 children. It's the effectful but not speculative version of MakeRope.
1426
1427         * dfg/DFGAbstractInterpreterInlines.h:
1428         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1429         * dfg/DFGBackwardsPropagationPhase.cpp:
1430         (JSC::DFG::BackwardsPropagationPhase::propagate):
1431         * dfg/DFGByteCodeParser.cpp:
1432         (JSC::DFG::ByteCodeParser::parseBlock):
1433         * dfg/DFGClobberize.h:
1434         (JSC::DFG::clobberize):
1435         * dfg/DFGDoesGC.cpp:
1436         (JSC::DFG::doesGC):
1437         * dfg/DFGFixupPhase.cpp:
1438         (JSC::DFG::FixupPhase::fixupNode):
1439         (JSC::DFG::FixupPhase::convertStringAddUse):
1440         (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
1441         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1442         (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
1443         * dfg/DFGNodeType.h:
1444         * dfg/DFGOperations.cpp:
1445         * dfg/DFGOperations.h:
1446         * dfg/DFGPredictionPropagationPhase.cpp:
1447         (JSC::DFG::PredictionPropagationPhase::propagate):
1448         * dfg/DFGSafeToExecute.h:
1449         (JSC::DFG::safeToExecute):
1450         * dfg/DFGSpeculativeJIT.h:
1451         (JSC::DFG::SpeculativeJIT::callOperation):
1452         (JSC::DFG::JSValueOperand::JSValueOperand):
1453         (JSC::DFG::JSValueOperand::~JSValueOperand):
1454         * dfg/DFGSpeculativeJIT32_64.cpp:
1455         (JSC::DFG::SpeculativeJIT::compile):
1456         * dfg/DFGSpeculativeJIT64.cpp:
1457         (JSC::DFG::SpeculativeJIT::compile):
1458         * dfg/DFGValidate.cpp:
1459         (JSC::DFG::Validate::validate):
1460         * ftl/FTLCapabilities.cpp:
1461         (JSC::FTL::canCompile):
1462         * ftl/FTLIntrinsicRepository.h:
1463         * ftl/FTLLowerDFGToLLVM.cpp:
1464         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
1465         (JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
1466         (JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
1467         (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
1468         * jit/JITOperations.h:
1469         * tests/stress/exception-effect-strcat.js: Added. This test previously failed.
1470         * tests/stress/exception-in-strcat-string-overflow.js: Added. An earlier version of this patch made this fail.
1471         * tests/stress/exception-in-strcat.js: Added.
1472
1473 2015-08-22  Andreas Kling  <akling@apple.com>
1474
1475         [JSC] Static hash tables should be 100% compile-time constant.
1476         <https://webkit.org/b/148359>
1477
1478         Reviewed by Michael Saboff.
1479
1480         We were dirtying the memory pages containing static hash tables the
1481         first time they were used, when a dynamically allocated index-to-key
1482         table was built and cached in the HashTable struct.
1483
1484         It turns out that this "optimization" was completely useless, since
1485         we've long since decoupled static hash tables from the JSC::VM and
1486         we can get the key for an index via HashTable::values[index].m_key!
1487
1488         We also get rid of VM::keywords which was a little wrapper around
1489         a VM-specific copy of JSC::mainTable. There was nothing VM-specific
1490         about it at all, so clients now use JSC::mainTable directly.
1491
1492         After this change all fooHashTable structs end up in __DATA __const
1493         and no runtime initialization/allocation takes place.
1494
1495         * create_hash_table:
1496         * jsc.cpp:
1497         * parser/Lexer.cpp:
1498         (JSC::isLexerKeyword):
1499         (JSC::Lexer<LChar>::parseIdentifier):
1500         (JSC::Lexer<UChar>::parseIdentifier):
1501         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
1502         (JSC::Keywords::Keywords): Deleted.
1503         * parser/Lexer.h:
1504         (JSC::Keywords::isKeyword): Deleted.
1505         (JSC::Keywords::getKeyword): Deleted.
1506         (JSC::Keywords::~Keywords): Deleted.
1507         * runtime/LiteralParser.cpp:
1508         (JSC::LiteralParser<CharType>::tryJSONPParse):
1509         * runtime/Lookup.cpp:
1510         (JSC::HashTable::createTable): Deleted.
1511         (JSC::HashTable::deleteTable): Deleted.
1512         * runtime/Lookup.h:
1513         (JSC::HashTable::entry):
1514         (JSC::HashTable::ConstIterator::key):
1515         (JSC::HashTable::ConstIterator::skipInvalidKeys):
1516         (JSC::HashTable::copy): Deleted.
1517         (JSC::HashTable::initializeIfNeeded): Deleted.
1518         (JSC::HashTable::begin): Deleted.
1519         (JSC::HashTable::end): Deleted.
1520         * runtime/VM.cpp:
1521         (JSC::VM::VM): Deleted.
1522         * runtime/VM.h:
1523         * testRegExp.cpp:
1524
1525 2015-08-21  Commit Queue  <commit-queue@webkit.org>
1526
1527         Unreviewed, rolling out r188792 and r188803.
1528         https://bugs.webkit.org/show_bug.cgi?id=148347
1529
1530         broke lots of tests, ggaren is going to investigate and reland
1531         (Requested by thorton on #webkit).
1532
1533         Reverted changesets:
1534
1535         "Unify code paths for manually deleting all code"
1536         https://bugs.webkit.org/show_bug.cgi?id=148280
1537         http://trac.webkit.org/changeset/188792
1538
1539         "Debugger's VM should never be null"
1540         https://bugs.webkit.org/show_bug.cgi?id=148341
1541         http://trac.webkit.org/changeset/188803
1542
1543 2015-08-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1544
1545         Parse control flow statements in WebAssembly
1546         https://bugs.webkit.org/show_bug.cgi?id=148333
1547
1548         Reviewed by Geoffrey Garen.
1549
1550         Parse control flow statements in WebAssembly files generated by pack-asmjs
1551         <https://github.com/WebAssembly/polyfill-prototype-1>.
1552
1553         * wasm/WASMConstants.h:
1554         * wasm/WASMFunctionParser.cpp:
1555         (JSC::WASMFunctionParser::parseStatement):
1556         (JSC::WASMFunctionParser::parseIfStatement):
1557         (JSC::WASMFunctionParser::parseIfElseStatement):
1558         (JSC::WASMFunctionParser::parseWhileStatement):
1559         (JSC::WASMFunctionParser::parseDoStatement):
1560         (JSC::WASMFunctionParser::parseLabelStatement):
1561         (JSC::WASMFunctionParser::parseBreakStatement):
1562         (JSC::WASMFunctionParser::parseBreakLabelStatement):
1563         (JSC::WASMFunctionParser::parseContinueStatement):
1564         (JSC::WASMFunctionParser::parseContinueLabelStatement):
1565         (JSC::WASMFunctionParser::parseSwitchStatement):
1566         * wasm/WASMFunctionParser.h:
1567         (JSC::WASMFunctionParser::WASMFunctionParser):
1568         * wasm/WASMReader.cpp:
1569         (JSC::WASMReader::readCompactInt32):
1570         (JSC::WASMReader::readSwitchCase):
1571         * wasm/WASMReader.h:
1572
1573 2015-08-21  Geoffrey Garen  <ggaren@apple.com>
1574
1575         Debugger's VM should never be null
1576         https://bugs.webkit.org/show_bug.cgi?id=148341
1577
1578         Reviewed by Joseph Pecoraro.
1579
1580         It doesn't make sense for a Debugger's VM to be null, and code related
1581         to maintaining that illusion just caused the Web Inspector to crash on
1582         launch (https://bugs.webkit.org/show_bug.cgi?id=148312). So, let's stop
1583         doing that.
1584
1585         Now, Debugger requires its subclass to provide a never-null VM&.
1586
1587         Also took the opportunity, based on review feedback, to remove some
1588         confusion in the virtual recompileAllJSFunctions hierarchy, by eliminating
1589         the pure virtual in ScriptDebugServer and the unnecessary override in
1590         JSGlobalObjectScriptDebugServer.
1591
1592         * debugger/Debugger.cpp:
1593         (JSC::Debugger::Debugger):
1594         (JSC::Debugger::attach):
1595         (JSC::Debugger::detach):
1596         (JSC::Debugger::isAttached):
1597         (JSC::Debugger::setSteppingMode):
1598         (JSC::Debugger::registerCodeBlock):
1599         (JSC::Debugger::toggleBreakpoint):
1600         (JSC::Debugger::recompileAllJSFunctions):
1601         (JSC::Debugger::setBreakpoint):
1602         (JSC::Debugger::clearBreakpoints):
1603         (JSC::Debugger::clearDebuggerRequests):
1604         (JSC::Debugger::setBreakpointsActivated):
1605         (JSC::Debugger::breakProgram):
1606         (JSC::Debugger::stepOutOfFunction):
1607         (JSC::Debugger::returnEvent):
1608         (JSC::Debugger::didExecuteProgram):
1609         * debugger/Debugger.h:
1610         * inspector/JSGlobalObjectScriptDebugServer.cpp:
1611         (Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
1612         (Inspector::JSGlobalObjectScriptDebugServer::recompileAllJSFunctions):
1613         (Inspector::JSGlobalObjectScriptDebugServer::runEventLoopWhilePaused):
1614         * inspector/ScriptDebugServer.cpp:
1615         (Inspector::ScriptDebugServer::ScriptDebugServer):
1616         * inspector/ScriptDebugServer.h:
1617
1618 2015-08-21  Basile Clement  <basile_clement@apple.com>
1619
1620         Remove unused code relative to allocation sinking
1621         https://bugs.webkit.org/show_bug.cgi?id=148342
1622
1623         Reviewed by Mark Lam.
1624
1625         This removes two things:
1626
1627          - The DFGPromoteHeapAccess.h file which is a relic of the old sinking
1628            phase and is no longer used (it has been subsumed by
1629            ObjectAllocationSinking::promoteLocalHeap)
1630
1631          - Code in the allocation sinking phase for sinking
1632            MaterializeCreateActivation and MaterializeNewObject. Handling those
1633            is no longer necessary since the phase no longer runs in a fixpoint
1634            and thus will never see those nodes, since no other phase creates
1635            them.
1636
1637         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1638         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1639         * JavaScriptCore.xcodeproj/project.pbxproj:
1640         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1641         * dfg/DFGPromoteHeapAccess.h: Removed.
1642
1643 2015-08-21  Geoffrey Garen  <ggaren@apple.com>
1644
1645         Unify code paths for manually deleting all code
1646         https://bugs.webkit.org/show_bug.cgi?id=148280
1647
1648         Reviewed by Saam Barati.
1649
1650         We used to have three paths for manually deleting all code. Now we have
1651         one shared path.
1652
1653         * debugger/Debugger.cpp:
1654         (JSC::Debugger::attach): Notify the debugger of all previous code when
1655         it attaches. We used to do this when recompiling, which was only correct
1656         by accident.
1657
1658         (JSC::Debugger::recompileAllJSFunctions): Switch to the shared path.
1659
1660         * heap/Heap.h:
1661         (JSC::Heap::compiledCode):
1662
1663         * inspector/agents/InspectorRuntimeAgent.cpp:
1664         (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
1665         (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
1666         (Inspector::InspectorRuntimeAgent::setTypeProfilerEnabledState):
1667         (Inspector::InspectorRuntimeAgent::getBasicBlocks):
1668         (Inspector::TypeRecompiler::visit): Deleted.
1669         (Inspector::TypeRecompiler::operator()): Deleted.
1670         (Inspector::recompileAllJSFunctionsForTypeProfiling): Deleted. Switch
1671         to the shared path.
1672
1673         * runtime/VM.cpp:
1674         (JSC::VM::afterVMExit): Added a helper for scheduling an activity after
1675         VM exit. We can't delete code while it's on the stack, and we can't
1676         delete auxiliary profiling data while profiling code is on the stack,
1677         so in those cases, we schedule the deletion for the next time we exit.
1678
1679         (JSC::VM::deleteAllCode): Use afterVMExit because we might have code
1680         on the stack when debugger, profiler, or watchdog state changes.
1681
1682         * runtime/VM.h:
1683
1684         * runtime/VMEntryScope.cpp:
1685         (JSC::VMEntryScope::VMEntryScope):
1686         (JSC::VMEntryScope::addDidPopListener):
1687         (JSC::VMEntryScope::~VMEntryScope):
1688         (JSC::VMEntryScope::setEntryScopeDidPopListener): Deleted.
1689         * runtime/VMEntryScope.h:
1690         (JSC::VMEntryScope::globalObject): Removed the uniquing feature from
1691         the scope pop listener list because we don't have a client that wants
1692         it, and it's not convenient to use correctly since you can't take
1693         the address of a member function, a lambda, or an std::function. We can
1694         add this feature back if we discover that we want it.
1695
1696 2015-08-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1697
1698         Implement WebAssembly function parser
1699         https://bugs.webkit.org/show_bug.cgi?id=147738
1700
1701         Reviewed by Filip Pizlo.
1702
1703         Implement WebAssembly function parser for WebAssembly files produced by pack-asmjs
1704         <https://github.com/WebAssembly/polyfill-prototype-1>. This patch parses only
1705         some instructions on statements and int32 expressions. Parsing of the rest
1706         will be implemented in subsequent patches. The instruction lists in WASMConstants.h
1707         are slightly modified from
1708         <https://github.com/WebAssembly/polyfill-prototype-1/blob/master/src/shared.h>.
1709
1710         * CMakeLists.txt:
1711         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1712         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1713         * JavaScriptCore.xcodeproj/project.pbxproj:
1714         * wasm/WASMConstants.h: Added.
1715         * wasm/WASMFormat.h:
1716         * wasm/WASMFunctionParser.cpp: Added.
1717         (JSC::WASMFunctionParser::checkSyntax):
1718         (JSC::WASMFunctionParser::parseFunction):
1719         (JSC::WASMFunctionParser::parseLocalVariables):
1720         (JSC::WASMFunctionParser::parseStatement):
1721         (JSC::WASMFunctionParser::parseSetLocalStatement):
1722         (JSC::WASMFunctionParser::parseReturnStatement):
1723         (JSC::WASMFunctionParser::parseBlockStatement):
1724         (JSC::WASMFunctionParser::parseExpression):
1725         (JSC::WASMFunctionParser::parseExpressionI32):
1726         (JSC::WASMFunctionParser::parseImmediateExpressionI32):
1727         * wasm/WASMFunctionParser.h: Added.
1728         (JSC::WASMFunctionParser::WASMFunctionParser):
1729         * wasm/WASMFunctionSyntaxChecker.h: Renamed from Source/JavaScriptCore/wasm/WASMMagicNumber.h.
1730         * wasm/WASMModuleParser.cpp:
1731         (JSC::WASMModuleParser::WASMModuleParser):
1732         (JSC::WASMModuleParser::parseFunctionDefinitionSection):
1733         (JSC::WASMModuleParser::parseFunctionDefinition):
1734         * wasm/WASMModuleParser.h:
1735         * wasm/WASMReader.cpp:
1736         (JSC::WASMReader::readType):
1737         (JSC::WASMReader::readExpressionType):
1738         (JSC::WASMReader::readExportFormat):
1739         (JSC::WASMReader::readOpStatement):
1740         (JSC::WASMReader::readOpExpressionI32):
1741         (JSC::WASMReader::readVariableTypes):
1742         (JSC::WASMReader::readOp):
1743         * wasm/WASMReader.h:
1744         (JSC::WASMReader::offset):
1745         (JSC::WASMReader::setOffset):
1746
1747 2015-08-21  Filip Pizlo  <fpizlo@apple.com>
1748
1749         DFG::PutStackSinkingPhase doesn't need to emit KillStack nodes
1750         https://bugs.webkit.org/show_bug.cgi?id=148331
1751
1752         Reviewed by Geoffrey Garen.
1753
1754         PutStackSinkingPhase previously emitted a KillStack node when it sank a PutStack. This
1755         isn't necessary because KillStack is only interesting for OSR exit, and PutStack nodes
1756         that are relevant to OSR will already be preceded by a KillStack/MovHint pair.
1757
1758         * dfg/DFGPutStackSinkingPhase.cpp:
1759
1760 2015-08-21  Filip Pizlo  <fpizlo@apple.com>
1761
1762         DFG::NodeOrigin should have a flag determining if exiting is OK right now
1763         https://bugs.webkit.org/show_bug.cgi?id=148323
1764
1765         Reviewed by Saam Barati.
1766
1767         * dfg/DFGByteCodeParser.cpp:
1768         (JSC::DFG::ByteCodeParser::currentNodeOrigin):
1769         (JSC::DFG::ByteCodeParser::branchData):
1770         * dfg/DFGInsertionSet.h:
1771         (JSC::DFG::InsertionSet::insertConstant):
1772         (JSC::DFG::InsertionSet::insertConstantForUse):
1773         (JSC::DFG::InsertionSet::insertBottomConstantForUse):
1774         * dfg/DFGIntegerCheckCombiningPhase.cpp:
1775         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
1776         * dfg/DFGLICMPhase.cpp:
1777         (JSC::DFG::LICMPhase::attemptHoist):
1778         * dfg/DFGNodeOrigin.h:
1779         (JSC::DFG::NodeOrigin::NodeOrigin):
1780         (JSC::DFG::NodeOrigin::isSet):
1781         (JSC::DFG::NodeOrigin::withSemantic):
1782         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1783
1784 2015-08-21  Saam barati  <sbarati@apple.com>
1785
1786         DFG callOperations should not implicitly emit an exception check. At callOperation call sites, we should explicitly emit exception checks
1787         https://bugs.webkit.org/show_bug.cgi?id=147988
1788
1789         Reviewed by Geoffrey Garen.
1790
1791         This is in preparation for the DFG being able to handle exceptions. 
1792         To do this, we need more control over when we emit exception checks.
1793         Specifically, we want to be able to silentFill before emitting an exception check.
1794         This patch does that. This patch also allows us to easily see which
1795         operations do and do not emit exception checks. Finding this information
1796         out before was a pain.
1797
1798         * assembler/AbortReason.h:
1799         * dfg/DFGArrayifySlowPathGenerator.h:
1800         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
1801         * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
1802         * dfg/DFGJITCompiler.h:
1803         (JSC::DFG::JITCompiler::appendCall):
1804         (JSC::DFG::JITCompiler::exceptionCheck):
1805         * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
1806         * dfg/DFGSlowPathGenerator.h:
1807         (JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
1808         (JSC::DFG::CallSlowPathGenerator::tearDown):
1809         (JSC::DFG::CallResultAndNoArgumentsSlowPathGenerator::CallResultAndNoArgumentsSlowPathGenerator):
1810         (JSC::DFG::CallResultAndOneArgumentSlowPathGenerator::CallResultAndOneArgumentSlowPathGenerator):
1811         (JSC::DFG::CallResultAndTwoArgumentsSlowPathGenerator::CallResultAndTwoArgumentsSlowPathGenerator):
1812         (JSC::DFG::CallResultAndThreeArgumentsSlowPathGenerator::CallResultAndThreeArgumentsSlowPathGenerator):
1813         (JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::CallResultAndFourArgumentsSlowPathGenerator):
1814         (JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::CallResultAndFiveArgumentsSlowPathGenerator):
1815         (JSC::DFG::slowPathCall):
1816         * dfg/DFGSpeculativeJIT.cpp:
1817         (JSC::DFG::SpeculativeJIT::compileIn):
1818         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1819         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
1820         (JSC::DFG::SpeculativeJIT::compileArithRound):
1821         (JSC::DFG::SpeculativeJIT::compileNewFunction):
1822         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
1823         (JSC::DFG::SpeculativeJIT::compileCreateScopedArguments):
1824         (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
1825         (JSC::DFG::SpeculativeJIT::compileNotifyWrite):
1826         (JSC::DFG::SpeculativeJIT::compileRegExpExec):
1827         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
1828         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
1829         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
1830         (JSC::DFG::SpeculativeJIT::emitSwitchImm):
1831         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
1832         * dfg/DFGSpeculativeJIT.h:
1833         (JSC::DFG::SpeculativeJIT::callOperation):
1834         (JSC::DFG::SpeculativeJIT::callOperationWithCallFrameRollbackOnException):
1835         (JSC::DFG::SpeculativeJIT::prepareForExternalCall):
1836         (JSC::DFG::SpeculativeJIT::appendCall):
1837         (JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnException):
1838         (JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnExceptionSetResult):
1839         (JSC::DFG::SpeculativeJIT::appendCallSetResult):
1840         (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck): Deleted.
1841         (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult): Deleted.
1842         * dfg/DFGSpeculativeJIT32_64.cpp:
1843         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1844         (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
1845         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
1846         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1847         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1848         (JSC::DFG::SpeculativeJIT::emitCall):
1849         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
1850         (JSC::DFG::SpeculativeJIT::compile):
1851         * dfg/DFGSpeculativeJIT64.cpp:
1852         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1853         (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
1854         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
1855         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1856         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1857         (JSC::DFG::SpeculativeJIT::emitCall):
1858         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
1859         (JSC::DFG::SpeculativeJIT::compile):
1860         * ftl/FTLIntrinsicRepository.h:
1861         * ftl/FTLLowerDFGToLLVM.cpp:
1862         (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
1863         * jit/AssemblyHelpers.cpp:
1864         (JSC::AssemblyHelpers::jitAssertArgumentCountSane):
1865         (JSC::AssemblyHelpers::jitAssertNoException):
1866         (JSC::AssemblyHelpers::callExceptionFuzz):
1867         (JSC::AssemblyHelpers::emitExceptionCheck):
1868         * jit/AssemblyHelpers.h:
1869         (JSC::AssemblyHelpers::jitAssertIsInt32):
1870         (JSC::AssemblyHelpers::jitAssertIsJSInt32):
1871         (JSC::AssemblyHelpers::jitAssertIsNull):
1872         (JSC::AssemblyHelpers::jitAssertTagsInPlace):
1873         (JSC::AssemblyHelpers::jitAssertArgumentCountSane):
1874         (JSC::AssemblyHelpers::jitAssertNoException):
1875         * jit/JITOperations.cpp:
1876         * jit/JITOperations.h:
1877         * runtime/VM.h:
1878         (JSC::VM::scratchBufferForSize):
1879         (JSC::VM::exceptionFuzzingBuffer):
1880
1881 2015-08-21  Geoffrey Garen  <ggaren@apple.com>
1882
1883         REGRESSION (r188714): RELEASE_ASSERT in JSC::Heap::incrementDeferralDepth() opening Web Inspector on daringfireball.net
1884         https://bugs.webkit.org/show_bug.cgi?id=148312
1885
1886         Reviewed by Mark Lam.
1887
1888         * debugger/Debugger.cpp:
1889         (JSC::Debugger::recompileAllJSFunctions): Use our vm argument instead of
1890         m_vm because sometimes they are different and m_vm is null. (This behavior
1891         is very strange, and we should probably eliminate it -- but we need a 
1892         fix for this serious regression right now.)
1893
1894 2015-08-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1895
1896         [ES6] prototyping module loader in JSC shell
1897         https://bugs.webkit.org/show_bug.cgi?id=147876
1898
1899         Reviewed by Saam Barati.
1900
1901         This patch implements ES6 Module Loader part. The implementation is based on
1902         the latest draft[1, 2]. The naive implementation poses several problems.
1903         This patch attempts to solve the spec issues and proposes the fix[3, 4, 5].
1904
1905         We construct the JSC internal module loader based on the ES6 Promises.
1906         The chain of the promises represents the dependency graph of the modules and
1907         it automatically enables asynchronous module fetching.
1908         To leverage the Promises internally, we use the InternalPromise landed in r188681.
1909
1910         The loader has several platform-dependent hooks. The platform can implement
1911         these hooks to provide the functionality missing in the module loaders, like
1912         "how to fetch the resources". The method table of the JSGlobalObject is extended
1913         to accept these hooks from the platform.
1914
1915         This patch focus on the loading part. So we don't create the module environment
1916         and don't link the modules yet.
1917
1918         To test the current module progress easily, we add the `-m` option to the JSC shell.
1919         When this option is specified, we load the given script as the module. And to use
1920         the module loading inside the JSC shell, we added the simple loader hook for fetching.
1921         It fetches the module content from the file system.
1922
1923         And to use the ES6 Map in the Loader implementation, we added @get and @set methods to the Map.
1924         But it conflicts with the existing `getPrivateName` method. Rename it to `lookUpPrivateName`.
1925
1926         [1]: https://whatwg.github.io/loader/
1927         [2]: https://github.com/whatwg/loader/commit/214c7a6625b445bdf411c39984f36f01139a24be
1928         [3]: https://github.com/whatwg/loader/pull/66
1929         [4]: https://github.com/whatwg/loader/pull/67
1930         [5]: https://github.com/whatwg/loader/issues/68
1931         [6]: https://bugs.webkit.org/show_bug.cgi?id=148136
1932
1933         * CMakeLists.txt:
1934         * DerivedSources.make:
1935         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1936         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1937         * JavaScriptCore.xcodeproj/project.pbxproj:
1938         * builtins/BuiltinNames.h:
1939         (JSC::BuiltinNames::lookUpPrivateName):
1940         (JSC::BuiltinNames::lookUpPublicName):
1941         (JSC::BuiltinNames::getPrivateName): Deleted.
1942         (JSC::BuiltinNames::getPublicName): Deleted.
1943         * builtins/ModuleLoaderObject.js: Added.
1944         (setStateToMax):
1945         (newRegistryEntry):
1946         (forceFulfillPromise):
1947         (fulfillFetch):
1948         (fulfillTranslate):
1949         (fulfillInstantiate):
1950         (instantiation):
1951         (requestFetch):
1952         (requestTranslate):
1953         (requestInstantiate):
1954         (requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then.):
1955         (requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then):
1956         (requestResolveDependencies):
1957         (requestInstantiateAll):
1958         (provide):
1959         * jsc.cpp:
1960         (stringFromUTF):
1961         (jscSource):
1962         (GlobalObject::moduleLoaderFetch):
1963         (functionCheckModuleSyntax):
1964         (dumpException):
1965         (runWithScripts):
1966         (printUsageStatement):
1967         (CommandLine::parseArguments):
1968         (jscmain):
1969         (CommandLine::CommandLine): Deleted.
1970         * parser/Lexer.cpp:
1971         (JSC::Lexer<LChar>::parseIdentifier):
1972         (JSC::Lexer<UChar>::parseIdentifier):
1973         * parser/ModuleAnalyzer.cpp:
1974         (JSC::ModuleAnalyzer::ModuleAnalyzer):
1975         (JSC::ModuleAnalyzer::exportVariable):
1976         (JSC::ModuleAnalyzer::analyze):
1977         * parser/ModuleAnalyzer.h:
1978         (JSC::ModuleAnalyzer::moduleRecord):
1979         * parser/ModuleRecord.cpp:
1980         (JSC::printableName): Deleted.
1981         (JSC::ModuleRecord::dump): Deleted.
1982         * parser/ModuleRecord.h:
1983         (JSC::ModuleRecord::ImportEntry::isNamespace): Deleted.
1984         (JSC::ModuleRecord::create): Deleted.
1985         (JSC::ModuleRecord::appendRequestedModule): Deleted.
1986         (JSC::ModuleRecord::addImportEntry): Deleted.
1987         (JSC::ModuleRecord::addExportEntry): Deleted.
1988         (JSC::ModuleRecord::addStarExportEntry): Deleted.
1989         * parser/Nodes.h:
1990         * parser/NodesAnalyzeModule.cpp:
1991         (JSC::ImportDeclarationNode::analyzeModule):
1992         (JSC::ExportAllDeclarationNode::analyzeModule):
1993         (JSC::ExportNamedDeclarationNode::analyzeModule):
1994         * runtime/CommonIdentifiers.cpp:
1995         (JSC::CommonIdentifiers::lookUpPrivateName):
1996         (JSC::CommonIdentifiers::lookUpPublicName):
1997         (JSC::CommonIdentifiers::getPrivateName): Deleted.
1998         (JSC::CommonIdentifiers::getPublicName): Deleted.
1999         * runtime/CommonIdentifiers.h:
2000         * runtime/Completion.cpp:
2001         (JSC::checkModuleSyntax):
2002         (JSC::evaluateModule):
2003         * runtime/Completion.h:
2004         * runtime/ExceptionHelpers.cpp:
2005         (JSC::createUndefinedVariableError):
2006         * runtime/Identifier.h:
2007         * runtime/JSGlobalObject.cpp:
2008         (JSC::JSGlobalObject::init):
2009         (JSC::JSGlobalObject::visitChildren):
2010         * runtime/JSGlobalObject.h:
2011         (JSC::JSGlobalObject::moduleLoader):
2012         (JSC::JSGlobalObject::moduleRecordStructure):
2013         * runtime/JSModuleRecord.cpp: Renamed from Source/JavaScriptCore/parser/ModuleRecord.cpp.
2014         (JSC::JSModuleRecord::destroy):
2015         (JSC::JSModuleRecord::finishCreation):
2016         (JSC::printableName):
2017         (JSC::JSModuleRecord::dump):
2018         * runtime/JSModuleRecord.h: Renamed from Source/JavaScriptCore/parser/ModuleRecord.h.
2019         (JSC::JSModuleRecord::ImportEntry::isNamespace):
2020         (JSC::JSModuleRecord::createStructure):
2021         (JSC::JSModuleRecord::create):
2022         (JSC::JSModuleRecord::requestedModules):
2023         (JSC::JSModuleRecord::JSModuleRecord):
2024         (JSC::JSModuleRecord::appendRequestedModule):
2025         (JSC::JSModuleRecord::addImportEntry):
2026         (JSC::JSModuleRecord::addExportEntry):
2027         (JSC::JSModuleRecord::addStarExportEntry):
2028         * runtime/MapPrototype.cpp:
2029         (JSC::MapPrototype::finishCreation):
2030         * runtime/ModuleLoaderObject.cpp: Added.
2031         (JSC::ModuleLoaderObject::ModuleLoaderObject):
2032         (JSC::ModuleLoaderObject::finishCreation):
2033         (JSC::ModuleLoaderObject::getOwnPropertySlot):
2034         (JSC::printableModuleKey):
2035         (JSC::ModuleLoaderObject::provide):
2036         (JSC::ModuleLoaderObject::requestInstantiateAll):
2037         (JSC::ModuleLoaderObject::resolve):
2038         (JSC::ModuleLoaderObject::fetch):
2039         (JSC::ModuleLoaderObject::translate):
2040         (JSC::ModuleLoaderObject::instantiate):
2041         (JSC::moduleLoaderObjectParseModule):
2042         (JSC::moduleLoaderObjectRequestedModules):
2043         (JSC::moduleLoaderObjectResolve):
2044         (JSC::moduleLoaderObjectFetch):
2045         (JSC::moduleLoaderObjectTranslate):
2046         (JSC::moduleLoaderObjectInstantiate):
2047         * runtime/ModuleLoaderObject.h: Added.
2048         (JSC::ModuleLoaderObject::create):
2049         (JSC::ModuleLoaderObject::createStructure):
2050         * runtime/Options.h:
2051
2052 2015-08-20  Filip Pizlo  <fpizlo@apple.com>
2053
2054         DFG should have a KnownBooleanUse for cases where we are required to know that the child is a boolean and it's not OK to speculate
2055         https://bugs.webkit.org/show_bug.cgi?id=148286
2056
2057         Reviewed by Benjamin Poulain.
2058
2059         This enables us to ensure that the Branch or LogicalNot after an effectful CompareXYZ can
2060         be marked as !mayExit(). I need that for https://bugs.webkit.org/show_bug.cgi?id=145204.
2061
2062         * dfg/DFGFixupPhase.cpp:
2063         (JSC::DFG::FixupPhase::fixupNode):
2064         (JSC::DFG::FixupPhase::observeUseKindOnNode):
2065         * dfg/DFGSafeToExecute.h:
2066         (JSC::DFG::SafeToExecuteEdge::operator()):
2067         * dfg/DFGSpeculativeJIT.cpp:
2068         (JSC::DFG::SpeculativeJIT::speculate):
2069         * dfg/DFGSpeculativeJIT.h:
2070         (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand):
2071         * dfg/DFGSpeculativeJIT32_64.cpp:
2072         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2073         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2074         (JSC::DFG::SpeculativeJIT::emitBranch):
2075         * dfg/DFGSpeculativeJIT64.cpp:
2076         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2077         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2078         (JSC::DFG::SpeculativeJIT::emitBranch):
2079         * dfg/DFGUseKind.cpp:
2080         (WTF::printInternal):
2081         * dfg/DFGUseKind.h:
2082         (JSC::DFG::typeFilterFor):
2083         (JSC::DFG::shouldNotHaveTypeCheck):
2084         * ftl/FTLCapabilities.cpp:
2085         (JSC::FTL::canCompile):
2086         * ftl/FTLLowerDFGToLLVM.cpp:
2087         (JSC::FTL::DFG::LowerDFGToLLVM::boolify):
2088         (JSC::FTL::DFG::LowerDFGToLLVM::lowBoolean):
2089
2090 2015-08-20  Filip Pizlo  <fpizlo@apple.com>
2091
2092         Overflow check elimination fails for a simple test case
2093         https://bugs.webkit.org/show_bug.cgi?id=147387
2094
2095         Reviewed by Benjamin Poulain.
2096
2097         Overflow check elimination was having issues when things got constant-folded, because whereas an
2098         Add or LessThan operation teaches us about relationships between the things being added or
2099         compared, we don't do that when we see a JSConstant. We don't create a relationship between every
2100         JSConstant and every other JSConstant. So, if we constant-fold an Add, we forget the relationships
2101         that it would have had with its inputs.
2102
2103         One solution would be to have every JSConstant create a relationship with every other JSConstant.
2104         This is dangerous, since it would create O(n^2) explosion of relationships.
2105
2106         Instead, this patch teaches filtration and merging how to behave "as if" there were inter-constant
2107         relationships. Normally those operations only work on two relationships involving the same node
2108         pair. But now, if we have @x op @c and @x op @d, where @c and @d are different nodes but both are
2109         constants, we will do merging or filtering by grokking the constant values.
2110
2111         This speeds up lots of tests in JSRegress, because it enables overflow check elimination on things
2112         like:
2113
2114         for (var i = 0; i < 100; ++i)
2115
2116         Previously, the fact that this was all constants would throw off the analysis because the analysis
2117         wouldn't "know" that 0 < 100.
2118
2119         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2120
2121 2015-08-20  Geoffrey Garen  <ggaren@apple.com>
2122
2123         forEachCodeBlock should wait for all CodeBlocks automatically
2124         https://bugs.webkit.org/show_bug.cgi?id=148255
2125
2126         Add back a line of code I deleted by accident in my last patch due to
2127         incorrect merge.
2128
2129         Unreviewed.
2130
2131         * runtime/VM.cpp:
2132         (JSC::VM::deleteAllCode):
2133
2134 2015-08-20  Geoffrey Garen  <ggaren@apple.com>
2135
2136         forEachCodeBlock should wait for all CodeBlocks automatically
2137         https://bugs.webkit.org/show_bug.cgi?id=148255
2138
2139         Reviewed by Saam Barati.
2140
2141         Previously, all clients needed to wait manually before calling
2142         forEachCodeBlock. That's easy to get wrong, and at least one place
2143         got it wrong. Let's do this automatically instead.
2144
2145         * debugger/Debugger.cpp:
2146         (JSC::Debugger::Debugger):
2147         (JSC::Debugger::setSteppingMode):
2148         (JSC::Debugger::toggleBreakpoint): No need to wait manually;
2149         forEachCodeBlock will do it automatically now.
2150
2151         (JSC::Debugger::recompileAllJSFunctions): We still need to wait manually
2152         here because this is an iteration of the heap, which does not wait
2153         automatically. Use the new helper function for waiting.
2154
2155         (JSC::Debugger::clearBreakpoints):
2156         (JSC::Debugger::clearDebuggerRequests):
2157         (JSC::Debugger::setBreakpointsActivated):
2158         (JSC::Debugger::forEachCodeBlock): Deleted. No need to wait manually.
2159
2160         * debugger/Debugger.h:
2161
2162         * dfg/DFGWorklist.cpp:
2163         (JSC::DFG::completeAllPlansForVM):
2164         * dfg/DFGWorklist.h:
2165         (JSC::DFG::completeAllPlansForVM): Added a helper function that replaces
2166         vm.prepareToDeleteCode. This new function is clearer because we need
2167         to call it sometimes even if we are not going to delete code.
2168
2169         * heap/HeapInlines.h:
2170         (JSC::Heap::forEachCodeBlock): Moved.
2171
2172         * inspector/agents/InspectorRuntimeAgent.cpp:
2173         (Inspector::recompileAllJSFunctionsForTypeProfiling): Use the new helper
2174         function.
2175
2176         * runtime/JSCInlines.h:
2177         (JSC::Heap::forEachCodeBlock): Do the waiting automatically.
2178
2179         * runtime/VM.cpp:
2180         (JSC::VM::stopSampling):
2181         (JSC::VM::deleteAllCode):
2182         (JSC::VM::setEnabledProfiler):
2183         (JSC::VM::prepareToDeleteCode): Deleted.
2184         * runtime/VM.h: No need to wait manually.
2185
2186 2015-08-20  Commit Queue  <commit-queue@webkit.org>
2187
2188         Unreviewed, rolling out r188675.
2189         https://bugs.webkit.org/show_bug.cgi?id=148244
2190
2191         "caused a 17% Mac PLT regression" (Requested by ggaren on
2192         #webkit).
2193
2194         Reverted changeset:
2195
2196         "clearCode() should clear code"
2197         https://bugs.webkit.org/show_bug.cgi?id=148203
2198         http://trac.webkit.org/changeset/188675
2199
2200 2015-08-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2201
2202         Introduce put_by_id like IC into put_by_val when the given name is String or Symbol
2203         https://bugs.webkit.org/show_bug.cgi?id=147760
2204
2205         Reviewed by Filip Pizlo.
2206
2207         This patch adds put_by_id IC to put_by_val by caching the one candidate id,
2208         it is the same thing to the get_by_val IC extension.
2209         It will encourage the use of ES6 Symbols and ES6 computed properties in the object literals.
2210
2211         In this patch, we leverage the existing CheckIdent and PutById / PutByVal in DFG,
2212         so this patch does not change FTL because the above operations are already supported in FTL.
2213
2214         And this patch also includes refactoring to leverage byValInfo->slowPathCount in the cached Id path.
2215
2216         Performance results report there's no regression in the existing tests. And in the synthetic
2217         benchmarks created by modifying put-by-id to put-by-val, we can see significant performance
2218         improvements up to 13.9x.
2219
2220         * bytecode/PutByIdStatus.cpp:
2221         (JSC::PutByIdStatus::computeForStubInfo):
2222         * bytecode/PutByIdStatus.h:
2223         * dfg/DFGByteCodeParser.cpp:
2224         (JSC::DFG::ByteCodeParser::parseBlock):
2225         * jit/JIT.h:
2226         (JSC::JIT::compilePutByValWithCachedId):
2227         * jit/JITOperations.cpp:
2228         (JSC::getByVal):
2229         (JSC::tryGetByValOptimize):
2230         * jit/JITOperations.h:
2231         * jit/JITPropertyAccess.cpp:
2232         (JSC::JIT::emitGetByValWithCachedId):
2233         (JSC::JIT::emit_op_put_by_val):
2234         (JSC::JIT::emitPutByValWithCachedId):
2235         (JSC::JIT::emitSlow_op_put_by_val):
2236         (JSC::JIT::emitIdentifierCheck):
2237         (JSC::JIT::privateCompilePutByValWithCachedId):
2238         * jit/JITPropertyAccess32_64.cpp:
2239         (JSC::JIT::emitGetByValWithCachedId):
2240         (JSC::JIT::emit_op_put_by_val):
2241         (JSC::JIT::emitPutByValWithCachedId):
2242         (JSC::JIT::emitSlow_op_put_by_val):
2243         * tests/stress/put-by-val-with-string-break.js: Added.
2244         (shouldBe):
2245         (assign):
2246         * tests/stress/put-by-val-with-string-generated.js: Added.
2247         (shouldBe):
2248         (gen1):
2249         (gen2):
2250         (assign):
2251         * tests/stress/put-by-val-with-string-generic.js: Added.
2252         (shouldBe):
2253         (assign):
2254         * tests/stress/put-by-val-with-symbol-break.js: Added.
2255         (shouldBe):
2256         (assign):
2257         * tests/stress/put-by-val-with-symbol-generic.js: Added.
2258         (shouldBe):
2259         (assign):
2260
2261 2015-08-20  Alex Christensen  <achristensen@webkit.org>
2262
2263         Clean up CMake build after r188673
2264         https://bugs.webkit.org/show_bug.cgi?id=148234
2265
2266         Reviewed by Tim Horton.
2267
2268         * shell/PlatformWin.cmake:
2269         Define WIN_CAIRO so the WinCairo jsc.exe can find the correct dlls.
2270
2271 2015-08-20  Mark Lam  <mark.lam@apple.com>
2272
2273         A watchdog tests is failing on Windows.
2274         https://bugs.webkit.org/show_bug.cgi?id=148228
2275
2276         Reviewed by Brent Fulgham.
2277
2278         The test just needed a little more time because Windows' timer resolution is low.
2279         After increasing the test deadlines, the test started passing.
2280
2281         * API/tests/ExecutionTimeLimitTest.cpp:
2282         (testExecutionTimeLimit):
2283
2284 2015-08-20  Mark Lam  <mark.lam@apple.com>
2285
2286         Fixed some warnings on Windows.
2287         https://bugs.webkit.org/show_bug.cgi?id=148224
2288
2289         Reviewed by Brent Fulgham.
2290
2291         The Windows build was complaining that function params were hiding a global variable.
2292         Since the function params were unused, I resolved this by removing the param names.
2293
2294         * API/tests/ExecutionTimeLimitTest.cpp:
2295         (currentCPUTimeAsJSFunctionCallback):
2296         (shouldTerminateCallback):
2297         (cancelTerminateCallback):
2298         (extendTerminateCallback):
2299
2300 2015-08-19  Yusuke Suzuki  <utatane.tea@gmail.com>
2301
2302         Add InternalPromise to use Promises safely in the internals
2303         https://bugs.webkit.org/show_bug.cgi?id=148136
2304
2305         Reviewed by Saam Barati.
2306
2307         This patch implements InternalPromise.
2308         It is completely different instance set (constructor, prototype, instance)
2309         but it has the same feature to the Promise.
2310
2311         In the Promise operations, when resolving the promise with the returned promise
2312         from the fulfill handler, we need to look up "then" method.
2313
2314         e.g.
2315             var p3 = p1.then(function handler(...) {
2316                 return p2;
2317             });
2318
2319         When handler is executed, we retrieve the returned `p2` promise. And to resolve
2320         the returned promise by "then" method (that is `p3`), we construct the chain by executing
2321         `p2.then(resolving function for p3)`. So if the user modify the Promise.prototype.then,
2322         we can observe the internal operations.
2323
2324         By using InternalPromise, we completely hide InternalPromise.prototype from the users.
2325         It allows JSC to use Promises internally; even if the user modify / override
2326         the Promise.prototype.then function, it does not effect on InternalPromise.
2327
2328         One limitation is that the implementation need to take care not to leak the InternalPromise instance
2329         to the user space.
2330
2331         * CMakeLists.txt:
2332         * DerivedSources.make:
2333         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2334         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2335         * JavaScriptCore.xcodeproj/project.pbxproj:
2336         * builtins/InternalPromiseConstructor.js: Added.
2337         (internalAll.newResolveElement):
2338         (internalAll):
2339         * builtins/Operations.Promise.js:
2340         (newPromiseDeferred): Deleted.
2341         * builtins/PromiseConstructor.js:
2342         (privateAll.newResolveElement): Deleted.
2343         (privateAll): Deleted.
2344         * runtime/CommonIdentifiers.h:
2345         * runtime/JSGlobalObject.cpp:
2346         (JSC::JSGlobalObject::init):
2347         (JSC::JSGlobalObject::visitChildren):
2348         * runtime/JSGlobalObject.h:
2349         (JSC::JSGlobalObject::promiseConstructor):
2350         (JSC::JSGlobalObject::internalPromiseConstructor):
2351         (JSC::JSGlobalObject::newPromiseCapabilityFunction):
2352         (JSC::JSGlobalObject::newPromiseDeferredFunction): Deleted.
2353         * runtime/JSInternalPromise.cpp: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.h.
2354         (JSC::JSInternalPromise::create):
2355         (JSC::JSInternalPromise::createStructure):
2356         (JSC::JSInternalPromise::JSInternalPromise):
2357         * runtime/JSInternalPromise.h: Copied from Source/JavaScriptCore/runtime/JSPromise.h.
2358         * runtime/JSInternalPromiseConstructor.cpp: Added.
2359         (JSC::JSInternalPromiseConstructor::create):
2360         (JSC::JSInternalPromiseConstructor::createStructure):
2361         (JSC::JSInternalPromiseConstructor::JSInternalPromiseConstructor):
2362         (JSC::constructPromise):
2363         (JSC::JSInternalPromiseConstructor::getConstructData):
2364         (JSC::JSInternalPromiseConstructor::getCallData):
2365         (JSC::JSInternalPromiseConstructor::getOwnPropertySlot):
2366         * runtime/JSInternalPromiseConstructor.h: Copied from Source/JavaScriptCore/runtime/JSPromiseConstructor.h.
2367         * runtime/JSInternalPromiseDeferred.cpp: Added.
2368         (JSC::JSInternalPromiseDeferred::create):
2369         (JSC::JSInternalPromiseDeferred::JSInternalPromiseDeferred):
2370         (JSC::JSInternalPromiseDeferred::promise):
2371         * runtime/JSInternalPromiseDeferred.h: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.h.
2372         * runtime/JSInternalPromisePrototype.cpp: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.cpp.
2373         (JSC::JSInternalPromisePrototype::create):
2374         (JSC::JSInternalPromisePrototype::createStructure):
2375         (JSC::JSInternalPromisePrototype::JSInternalPromisePrototype):
2376         * runtime/JSInternalPromisePrototype.h: Copied from Source/JavaScriptCore/runtime/JSPromise.h.
2377         * runtime/JSPromise.cpp:
2378         (JSC::JSPromise::create):
2379         (JSC::JSPromise::JSPromise):
2380         (JSC::JSPromise::initialize):
2381         * runtime/JSPromise.h:
2382         * runtime/JSPromiseConstructor.cpp:
2383         (JSC::JSPromiseConstructor::JSPromiseConstructor):
2384         (JSC::constructPromise):
2385         (JSC::JSPromiseConstructor::getOwnPropertySlot):
2386         (JSC::JSPromiseConstructor::finishCreation): Deleted.
2387         * runtime/JSPromiseConstructor.h:
2388         * runtime/JSPromiseDeferred.cpp:
2389         (JSC::newPromiseCapability):
2390         (JSC::JSPromiseDeferred::create):
2391         (JSC::JSPromiseDeferred::JSPromiseDeferred):
2392         * runtime/JSPromiseDeferred.h:
2393         * runtime/JSPromisePrototype.cpp:
2394         (JSC::JSPromisePrototype::getOwnPropertySlot):
2395         * runtime/JSPromisePrototype.h:
2396         * runtime/VM.cpp:
2397         (JSC::VM::VM):
2398         * runtime/VM.h:
2399
2400 2015-08-19  Filip Pizlo  <fpizlo@apple.com>
2401
2402         Remove WTF::SpinLock
2403         https://bugs.webkit.org/show_bug.cgi?id=148208
2404
2405         Reviewed by Geoffrey Garen.
2406
2407         Remove the one remaining use of SpinLock.
2408
2409         * API/JSValue.mm:
2410         (handerForStructTag):
2411
2412 2015-08-19  Geoffrey Garen  <ggaren@apple.com>
2413
2414         clearCode() should clear code
2415         https://bugs.webkit.org/show_bug.cgi?id=148203
2416
2417         Reviewed by Saam Barati.
2418
2419         Clearing code used to require two steps: clearCode() and
2420         clearUnlinkedCodeForRecompilation(). Unsurprisingly, clients sometimes
2421         did one or the other or both without much rhyme or reason.
2422
2423         This patch simplifies things by merging both functions into clearCode().
2424
2425         * bytecode/UnlinkedFunctionExecutable.h:
2426         * debugger/Debugger.cpp:
2427         * heap/Heap.cpp:
2428         (JSC::Heap::deleteAllCompiledCode):
2429         (JSC::Heap::clearUnmarkedExecutables):
2430         (JSC::Heap::deleteAllUnlinkedFunctionCode): Deleted. No need for this
2431         function anymore since it was only used by clients who already called
2432         clearCode() (and it would be terribly wrong to use without doing both.)
2433
2434         * heap/Heap.h:
2435         (JSC::Heap::sizeAfterLastFullCollection):
2436         * inspector/agents/InspectorRuntimeAgent.cpp:
2437         (Inspector::TypeRecompiler::visit):
2438         (Inspector::TypeRecompiler::operator()):
2439         * runtime/Executable.cpp:
2440         (JSC::FunctionExecutable::visitChildren):
2441         (JSC::FunctionExecutable::clearCode):
2442         (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation): Deleted.
2443         * runtime/Executable.h:
2444         * runtime/VM.cpp:
2445         (JSC::VM::deleteAllCode):
2446
2447 2015-08-19  Alex Christensen  <achristensen@webkit.org>
2448
2449         CMake Windows build should not include files directly from other Source directories
2450         https://bugs.webkit.org/show_bug.cgi?id=148198
2451
2452         Reviewed by Brent Fulgham.
2453
2454         * CMakeLists.txt:
2455         JavaScriptCore_FORWARDING_HEADERS_FILES is no longer necessary because all the headers
2456         that used to be in it are now in JavaScriptCore_FORWARDING_HEADERS_DIRECTORIES
2457         * PlatformEfl.cmake:
2458         * PlatformGTK.cmake:
2459         * PlatformMac.cmake:
2460         * PlatformWin.cmake:
2461
2462 2015-08-19  Eric Carlson  <eric.carlson@apple.com>
2463
2464         Remove ENABLE_WEBVTT_REGIONS
2465         https://bugs.webkit.org/show_bug.cgi?id=148184
2466
2467         Reviewed by Jer Noble.
2468
2469         * Configurations/FeatureDefines.xcconfig: Remove ENABLE_WEBVTT_REGIONS.
2470
2471 2015-08-19  Joseph Pecoraro  <pecoraro@apple.com>
2472
2473         Web Inspector: Unexpected node preview format for an element with newlines in className attribute
2474         https://bugs.webkit.org/show_bug.cgi?id=148192
2475
2476         Reviewed by Brian Burg.
2477
2478         * inspector/InjectedScriptSource.js:
2479         (InjectedScript.prototype._nodePreview):
2480         Replace whitespace blocks with single spaces to produce a simpler class string for previews.
2481
2482 2015-08-19  Mark Lam  <mark.lam@apple.com>
2483
2484         Add support for CheckWatchdogTimer as slow path in DFG and FTL.
2485         https://bugs.webkit.org/show_bug.cgi?id=147968
2486
2487         Reviewed by Michael Saboff.
2488
2489         Re-implement the DFG's CheckWatchdogTimer as a slow path instead of a speculation
2490         check.  Since the watchdog timer can fire spuriously, this allows the code to
2491         stay optimized if all we have are spurious fires.
2492
2493         Implement the equivalent slow path for CheckWatchdogTimer in the FTL. 
2494
2495         The watchdog tests in ExecutionTimeLimitTest.cpp has already been updated in
2496         https://bugs.webkit.org/show_bug.cgi?id=148125 to test for the FTL's watchdog
2497         implementation.
2498
2499         * dfg/DFGSpeculativeJIT32_64.cpp:
2500         (JSC::DFG::SpeculativeJIT::compile):
2501         * dfg/DFGSpeculativeJIT64.cpp:
2502         (JSC::DFG::SpeculativeJIT::compile):
2503         * ftl/FTLCapabilities.cpp:
2504         (JSC::FTL::canCompile):
2505         * ftl/FTLLowerDFGToLLVM.cpp:
2506         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
2507         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation):
2508         (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckWatchdogTimer):
2509         (JSC::FTL::DFG::LowerDFGToLLVM::isInlinableSize):
2510
2511         * jit/JIT.h:
2512         * jit/JITInlines.h:
2513         (JSC::JIT::callOperation):
2514         * jit/JITOperations.cpp:
2515         * jit/JITOperations.h:
2516         - Changed operationHandleWatchdogTimer() to return an unused nullptr.  This
2517           allows me to reuse the existing DFG slow path generator mechanism.  I didn't
2518           think that operationHandleWatchdogTimer() was worth introducing a whole new set
2519           of machinery just so we can have a slow path that returns void.
2520
2521 2015-08-19  Mark Lam  <mark.lam@apple.com>
2522
2523         Add ability to save and restore JSC options.
2524         https://bugs.webkit.org/show_bug.cgi?id=148125
2525
2526         Reviewed by Saam Barati.
2527
2528         * API/tests/ExecutionTimeLimitTest.cpp:
2529         (testExecutionTimeLimit):
2530         - Employ the new options getter/setter to run watchdog tests for each of the
2531           execution engine tiers.
2532         - Also altered the test scripts to be in a function instead of global code.
2533           This is one of 2 changes needed to give them an opportunity to be FTL compiled.
2534           The other is to add support for compiling CheckWatchdogTimer in the FTL (which
2535           will be addressed in a separate patch).
2536
2537         * jsc.cpp:
2538         (CommandLine::parseArguments):
2539         * runtime/Options.cpp:
2540         (JSC::parse):
2541         - Add the ability to clear a string option with a nullptr value.
2542           This is needed to restore a default string option value which may be null.
2543
2544         (JSC::OptionRange::init):
2545         - Add the ability to clear a range option with a null value.
2546           This is needed to restore a default range option value which may be null.
2547
2548         (JSC::Options::initialize):
2549         (JSC::Options::dumpOptionsIfNeeded):
2550         - Factor code to dump options out to dumpOptionsIfNeeded() since we will need
2551           that logic elsewhere.
2552
2553         (JSC::Options::setOptions):
2554         - Parse an options string and set each of the specified options.
2555
2556         (JSC::Options::dumpAllOptions):
2557         (JSC::Options::dumpAllOptionsInALine):
2558         (JSC::Options::dumpOption):
2559         (JSC::Option::dump):
2560         - Refactored so that the underlying dumper dumps to a StringBuilder instead of
2561           stderr.  This lets us reuse this code to serialize all the options into a
2562           single string for dumpAllOptionsInALine().
2563
2564         * runtime/Options.h:
2565         (JSC::OptionRange::rangeString):
2566
2567 2015-08-18  Filip Pizlo  <fpizlo@apple.com>
2568
2569         Replace all uses of std::mutex/std::condition_variable with WTF::Lock/WTF::Condition
2570         https://bugs.webkit.org/show_bug.cgi?id=148140
2571
2572         Reviewed by Geoffrey Garen.
2573
2574         * inspector/remote/RemoteInspector.h:
2575         * inspector/remote/RemoteInspector.mm:
2576         (Inspector::RemoteInspector::registerDebuggable):
2577         (Inspector::RemoteInspector::unregisterDebuggable):
2578         (Inspector::RemoteInspector::updateDebuggable):
2579         (Inspector::RemoteInspector::updateDebuggableAutomaticInspectCandidate):
2580         (Inspector::RemoteInspector::sendMessageToRemoteFrontend):
2581         (Inspector::RemoteInspector::setupFailed):
2582         (Inspector::RemoteInspector::setupCompleted):
2583         (Inspector::RemoteInspector::start):
2584         (Inspector::RemoteInspector::stop):
2585         (Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
2586         (Inspector::RemoteInspector::setParentProcessInformation):
2587         (Inspector::RemoteInspector::xpcConnectionReceivedMessage):
2588         (Inspector::RemoteInspector::xpcConnectionFailed):
2589         (Inspector::RemoteInspector::pushListingSoon):
2590         (Inspector::RemoteInspector::receivedIndicateMessage):
2591         (Inspector::RemoteInspector::receivedProxyApplicationSetupMessage):
2592         * inspector/remote/RemoteInspectorXPCConnection.h:
2593         * inspector/remote/RemoteInspectorXPCConnection.mm:
2594         (Inspector::RemoteInspectorXPCConnection::close):
2595         (Inspector::RemoteInspectorXPCConnection::closeFromMessage):
2596         (Inspector::RemoteInspectorXPCConnection::deserializeMessage):
2597         (Inspector::RemoteInspectorXPCConnection::handleEvent):
2598
2599 2015-08-18  Joseph Pecoraro  <pecoraro@apple.com>
2600
2601         Web Inspector: Links for rules in <style> are incorrect, do not account for <style> offset in the document
2602         https://bugs.webkit.org/show_bug.cgi?id=148141
2603
2604         Reviewed by Brian Burg.
2605
2606         * inspector/protocol/CSS.json:
2607         Extend StyleSheetHeader to include start offset information and a bit
2608         for whether or not this was an inline style tag created by the parser.
2609         These match additions to Blink's protocol.
2610
2611 2015-08-18  Benjamin Poulain  <bpoulain@apple.com>
2612
2613         [JSC] Optimize more cases of something-compared-to-null/undefined
2614         https://bugs.webkit.org/show_bug.cgi?id=148157
2615
2616         Reviewed by Geoffrey Garen and Filip Pizlo.
2617
2618         CompareEq is fairly trivial if you assert one of the operands is either
2619         null or undefined. Under those conditions, the only way to have "true"
2620         is to have the other operand be null/undefined or have an object
2621         that masquerades to undefined.
2622
2623         JSC already had a fast path in CompareEqConstant.
2624         With this patch, I generalize this fast path to more cases and try
2625         to eliminate the checks whenever possible.
2626
2627         CompareEq now does the job of CompareEqConstant. If any operand can
2628         be proved to be undefined/other, its edge is set to OtherUse. Whenever
2629         any edge is OtherUse, we generate the fast code we had for CompareEqConstant.
2630
2631         The AbstractInterpreter has additional checks to reduce the node to a constant
2632         whenever possible.
2633
2634         There are two additional changes in this patch:
2635         -The Fixup Phase tries to set edges to OtherUse early. This is done correctly
2636          in ConstantFoldingPhase but setting it up early helps the phases relying
2637          on Clobberize.
2638         -The codegen for CompareEqConstant was improved. The reason is the comparison
2639          for ObjectOrOther could be faster just because the codegen was better.
2640
2641         * dfg/DFGAbstractInterpreterInlines.h:
2642         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2643         * dfg/DFGByteCodeParser.cpp:
2644         (JSC::DFG::ByteCodeParser::parseBlock):
2645         * dfg/DFGClobberize.h:
2646         (JSC::DFG::clobberize): Deleted.
2647         * dfg/DFGConstantFoldingPhase.cpp:
2648         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2649         * dfg/DFGDoesGC.cpp:
2650         (JSC::DFG::doesGC): Deleted.
2651         * dfg/DFGFixupPhase.cpp:
2652         (JSC::DFG::FixupPhase::fixupNode):
2653         * dfg/DFGNode.h:
2654         (JSC::DFG::Node::isUndefinedOrNullConstant):
2655         * dfg/DFGNodeType.h:
2656         * dfg/DFGPredictionPropagationPhase.cpp:
2657         (JSC::DFG::PredictionPropagationPhase::propagate): Deleted.
2658         * dfg/DFGSafeToExecute.h:
2659         (JSC::DFG::safeToExecute): Deleted.
2660         * dfg/DFGSpeculativeJIT.cpp:
2661         (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
2662         (JSC::DFG::SpeculativeJIT::compare):
2663         * dfg/DFGSpeculativeJIT.h:
2664         (JSC::DFG::SpeculativeJIT::isKnownNotOther):
2665         * dfg/DFGSpeculativeJIT32_64.cpp:
2666         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
2667         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
2668         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): Deleted.
2669         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): Deleted.
2670         (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull): Deleted.
2671         (JSC::DFG::SpeculativeJIT::compile): Deleted.
2672         * dfg/DFGSpeculativeJIT64.cpp:
2673         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNullOrUndefined):
2674         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNullOrUndefined):
2675         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull): Deleted.
2676         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull): Deleted.
2677         (JSC::DFG::SpeculativeJIT::nonSpeculativeCompareNull): Deleted.
2678         (JSC::DFG::SpeculativeJIT::compile): Deleted.
2679         * dfg/DFGValidate.cpp:
2680         (JSC::DFG::Validate::validate): Deleted.
2681         * dfg/DFGWatchpointCollectionPhase.cpp:
2682         (JSC::DFG::WatchpointCollectionPhase::handle):
2683         * ftl/FTLCapabilities.cpp:
2684         (JSC::FTL::canCompile):
2685         * ftl/FTLLowerDFGToLLVM.cpp:
2686         (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEq):
2687         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode): Deleted.
2688         (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEqConstant): Deleted.
2689         * tests/stress/compare-eq-on-null-and-undefined-non-peephole.js: Added.
2690         (string_appeared_here.useForMath):
2691         (testUseForMath):
2692         * tests/stress/compare-eq-on-null-and-undefined-optimized-in-constant-folding.js: Added.
2693         (string_appeared_here.unreachableCodeTest):
2694         (inlinedCompareToNull):
2695         (inlinedComparedToUndefined):
2696         (warmupInlineFunctions):
2697         (testInlineFunctions):
2698         * tests/stress/compare-eq-on-null-and-undefined.js: Added.
2699         (string_appeared_here.compareConstants):
2700         (opaqueNull):
2701         (opaqueUndefined):
2702         (compareConstantsAndDynamicValues):
2703         (compareDynamicValues):
2704         (compareDynamicValueToItself):
2705         (arrayTesting):
2706         (opaqueCompare1):
2707         (testNullComparatorUpdate):
2708         (opaqueCompare2):
2709         (testUndefinedComparatorUpdate):
2710         (opaqueCompare3):
2711         (testNullAndUndefinedComparatorUpdate):
2712
2713 2015-08-18  Yusuke Suzuki  <utatane.tea@gmail.com>
2714
2715         Introduce non-user-observable Promise functions to use Promises internally
2716         https://bugs.webkit.org/show_bug.cgi?id=148118
2717
2718         Reviewed by Saam Barati.
2719
2720         To leverage the Promises internally (like ES6 Module Loaders), we add
2721         the several non-user-observable private methods, like @then, @all. And
2722         refactor the existing Promises implementation to make it easy to use
2723         internally.
2724
2725         But still the trappable part remains. When resolving the promise with
2726         the returned value, we look up the "then" function. So users can trap
2727         by replacing "then" function of the Promise's prototype.
2728         To avoid this situation, we'll introduce completely differnt promise
2729         instances called InternalPromise in the subsequent patch[1].
2730
2731         No behavior change.
2732
2733         [1]: https://bugs.webkit.org/show_bug.cgi?id=148136
2734
2735         * builtins/PromiseConstructor.js:
2736         (privateAll.newResolveElement):
2737         (privateAll):
2738         * runtime/JSGlobalObject.cpp:
2739         (JSC::JSGlobalObject::init):
2740         (JSC::JSGlobalObject::visitChildren): Deleted.
2741         * runtime/JSGlobalObject.h:
2742         (JSC::JSGlobalObject::promiseConstructor): Deleted.
2743         (JSC::JSGlobalObject::promisePrototype): Deleted.
2744         (JSC::JSGlobalObject::promiseStructure): Deleted.
2745         * runtime/JSPromiseConstructor.cpp:
2746         (JSC::JSPromiseConstructor::finishCreation):
2747         * runtime/JSPromiseDeferred.cpp:
2748         (JSC::callFunction):
2749         (JSC::JSPromiseDeferred::resolve):
2750         (JSC::JSPromiseDeferred::reject):
2751         * runtime/JSPromiseDeferred.h:
2752         * runtime/JSPromisePrototype.cpp:
2753         (JSC::JSPromisePrototype::create):
2754         (JSC::JSPromisePrototype::JSPromisePrototype):
2755         * runtime/JSPromisePrototype.h:
2756
2757 2015-08-18  Geoffrey Garen  <ggaren@apple.com>
2758
2759         Try to fix the CLOOP build.
2760
2761         Unreviewed.
2762
2763         * bytecode/CodeBlock.cpp:
2764
2765 2015-08-18  Geoffrey Garen  <ggaren@apple.com>
2766
2767         Split InlineCallFrame into its own file
2768         https://bugs.webkit.org/show_bug.cgi?id=148131
2769
2770         Reviewed by Saam Barati.
2771
2772         * CMakeLists.txt:
2773         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2774         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2775         * JavaScriptCore.xcodeproj/project.pbxproj:
2776         * bytecode/CallLinkStatus.cpp:
2777         * bytecode/CodeBlock.h:
2778         (JSC::ExecState::r):
2779         (JSC::baselineCodeBlockForInlineCallFrame): Deleted.
2780         (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock): Deleted.
2781         * bytecode/CodeOrigin.cpp:
2782         (JSC::CodeOrigin::inlineStack):
2783         (JSC::CodeOrigin::codeOriginOwner):
2784         (JSC::CodeOrigin::stackOffset):
2785         (JSC::CodeOrigin::dump):
2786         (JSC::CodeOrigin::dumpInContext):
2787         (JSC::InlineCallFrame::calleeConstant): Deleted.
2788         (JSC::InlineCallFrame::visitAggregate): Deleted.
2789         (JSC::InlineCallFrame::calleeForCallFrame): Deleted.
2790         (JSC::InlineCallFrame::hash): Deleted.
2791         (JSC::InlineCallFrame::hashAsStringIfPossible): Deleted.
2792         (JSC::InlineCallFrame::inferredName): Deleted.
2793         (JSC::InlineCallFrame::baselineCodeBlock): Deleted.
2794         (JSC::InlineCallFrame::dumpBriefFunctionInformation): Deleted.
2795         (JSC::InlineCallFrame::dumpInContext): Deleted.
2796         (JSC::InlineCallFrame::dump): Deleted.
2797         (WTF::printInternal): Deleted.
2798         * bytecode/CodeOrigin.h:
2799         (JSC::CodeOrigin::deletedMarker):
2800         (JSC::CodeOrigin::hash):
2801         (JSC::CodeOrigin::operator==):
2802         (JSC::CodeOriginHash::hash):
2803         (JSC::CodeOriginHash::equal):
2804         (JSC::InlineCallFrame::kindFor): Deleted.
2805         (JSC::InlineCallFrame::varargsKindFor): Deleted.
2806         (JSC::InlineCallFrame::specializationKindFor): Deleted.
2807         (JSC::InlineCallFrame::isVarargs): Deleted.
2808         (JSC::InlineCallFrame::InlineCallFrame): Deleted.
2809         (JSC::InlineCallFrame::specializationKind): Deleted.
2810         (JSC::InlineCallFrame::setStackOffset): Deleted.
2811         (JSC::InlineCallFrame::callerFrameOffset): Deleted.
2812         (JSC::InlineCallFrame::returnPCOffset): Deleted.
2813         (JSC::CodeOrigin::stackOffset): Deleted.
2814         (JSC::CodeOrigin::codeOriginOwner): Deleted.
2815         * bytecode/InlineCallFrame.cpp: Copied from Source/JavaScriptCore/bytecode/CodeOrigin.cpp.
2816         (JSC::InlineCallFrame::calleeConstant):
2817         (JSC::CodeOrigin::inlineDepthForCallFrame): Deleted.
2818         (JSC::CodeOrigin::inlineDepth): Deleted.
2819         (JSC::CodeOrigin::isApproximatelyEqualTo): Deleted.
2820         (JSC::CodeOrigin::approximateHash): Deleted.
2821         (JSC::CodeOrigin::inlineStack): Deleted.
2822         (JSC::CodeOrigin::dump): Deleted.
2823         (JSC::CodeOrigin::dumpInContext): Deleted.
2824         * bytecode/InlineCallFrame.h: Copied from Source/JavaScriptCore/bytecode/CodeOrigin.h.
2825         (JSC::InlineCallFrame::isVarargs):
2826         (JSC::InlineCallFrame::InlineCallFrame):
2827         (JSC::InlineCallFrame::specializationKind):
2828         (JSC::baselineCodeBlockForInlineCallFrame):
2829         (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
2830         (JSC::CodeOrigin::CodeOrigin): Deleted.
2831         (JSC::CodeOrigin::isSet): Deleted.
2832         (JSC::CodeOrigin::operator!): Deleted.
2833         (JSC::CodeOrigin::isHashTableDeletedValue): Deleted.
2834         (JSC::CodeOrigin::operator!=): Deleted.
2835         (JSC::CodeOrigin::deletedMarker): Deleted.
2836         (JSC::CodeOrigin::stackOffset): Deleted.
2837         (JSC::CodeOrigin::hash): Deleted.
2838         (JSC::CodeOrigin::operator==): Deleted.
2839         (JSC::CodeOrigin::codeOriginOwner): Deleted.
2840         (JSC::CodeOriginHash::hash): Deleted.
2841         (JSC::CodeOriginHash::equal): Deleted.
2842         (JSC::CodeOriginApproximateHash::hash): Deleted.
2843         (JSC::CodeOriginApproximateHash::equal): Deleted.
2844         * bytecode/InlineCallFrameSet.cpp:
2845         * dfg/DFGCommonData.cpp:
2846         * dfg/DFGOSRExitBase.cpp:
2847         * dfg/DFGVariableEventStream.cpp:
2848         * ftl/FTLOperations.cpp:
2849         * interpreter/CallFrame.cpp:
2850         * interpreter/StackVisitor.cpp:
2851         * jit/AssemblyHelpers.h:
2852         * profiler/ProfilerOriginStack.cpp:
2853         * runtime/ClonedArguments.cpp:
2854
2855 2015-08-18  Mark Lam  <mark.lam@apple.com>
2856
2857         Removed an unused param in Interpreter::initialize().
2858         https://bugs.webkit.org/show_bug.cgi?id=148129
2859
2860         Reviewed by Michael Saboff.
2861
2862         * interpreter/Interpreter.cpp:
2863         (JSC::Interpreter::~Interpreter):
2864         (JSC::Interpreter::initialize):
2865         * interpreter/Interpreter.h:
2866         (JSC::Interpreter::stack):
2867         * runtime/VM.cpp:
2868         (JSC::VM::VM):
2869
2870 2015-08-17  Alex Christensen  <achristensen@webkit.org>
2871
2872         Add const to content extension parser
2873         https://bugs.webkit.org/show_bug.cgi?id=148044
2874
2875         Reviewed by Benjamin Poulain.
2876
2877         * runtime/JSObject.h:
2878         (JSC::JSObject::getIndexQuickly):
2879         (JSC::JSObject::tryGetIndexQuickly):
2880         (JSC::JSObject::getDirectIndex):
2881         (JSC::JSObject::getIndex):
2882         Added a few const keywords.
2883
2884 2015-08-17  Alex Christensen  <achristensen@webkit.org>
2885
2886         Build Debug Suffix on Windows with CMake
2887         https://bugs.webkit.org/show_bug.cgi?id=148083
2888
2889         Reviewed by Brent Fulgham.
2890
2891         * CMakeLists.txt:
2892         * PlatformWin.cmake:
2893         * shell/CMakeLists.txt:
2894         * shell/PlatformWin.cmake:
2895         Add DEBUG_SUFFIX
2896
2897 2015-08-17  Saam barati  <sbarati@apple.com>
2898
2899         Web Inspector: Type profiler return types aren't showing up
2900         https://bugs.webkit.org/show_bug.cgi?id=147348
2901
2902         Reviewed by Brian Burg.
2903
2904         Bug #145995 changed the starting offset of a function to 
2905         be the open parenthesis of the function's parameter list.
2906         This broke JSC's type profiler protocol of communicating 
2907         return types of a function to the web inspector. This
2908         is now fixed. The text offset used in the protocol is now
2909         the first letter of the function/get/set/method name.
2910         So "f" in "function a() {}", "s" in "set foo(){}", etc.
2911
2912         * bytecode/CodeBlock.cpp:
2913         (JSC::CodeBlock::CodeBlock):
2914         * jsc.cpp:
2915         (functionReturnTypeFor):
2916
2917 2015-08-17 Aleksandr Skachkov   <gskachkov@gmail.com>
2918
2919         [ES6] Implement ES6 arrow function syntax. Arrow function specific features. Lexical bind of this
2920         https://bugs.webkit.org/show_bug.cgi?id=144956
2921
2922         Reviewed by Saam Barati.
2923
2924         Added support of ES6 arrow function specific feature, lexical bind of this and no constructor. http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax
2925         In patch were implemented the following cases:
2926            this - variable |this| is point to the |this| of the function where arrow function is declared. Lexical bind of |this|
2927            constructor - the using of the command |new| for arrow function leads to runtime error
2928            call(), apply(), bind()  - methods can only pass in arguments, but has no effect on |this| 
2929
2930
2931         * CMakeLists.txt:
2932         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2933         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2934         * JavaScriptCore.xcodeproj/project.pbxproj:
2935         * bytecode/BytecodeList.json:
2936         * bytecode/BytecodeUseDef.h:
2937         (JSC::computeUsesForBytecodeOffset):
2938         (JSC::computeDefsForBytecodeOffset):
2939         * bytecode/CodeBlock.cpp:
2940         (JSC::CodeBlock::dumpBytecode):
2941         * bytecode/ExecutableInfo.h:
2942         (JSC::ExecutableInfo::ExecutableInfo):
2943         (JSC::ExecutableInfo::isArrowFunction):
2944         * bytecode/UnlinkedCodeBlock.cpp:
2945         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2946         * bytecode/UnlinkedCodeBlock.h:
2947         (JSC::UnlinkedCodeBlock::isArrowFunction):
2948         * bytecode/UnlinkedFunctionExecutable.cpp:
2949         (JSC::generateFunctionCodeBlock):
2950         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2951         (JSC::UnlinkedFunctionExecutable::codeBlockFor):
2952         * bytecode/UnlinkedFunctionExecutable.h:
2953         * bytecompiler/BytecodeGenerator.cpp:
2954         (JSC::BytecodeGenerator::BytecodeGenerator):
2955         (JSC::BytecodeGenerator::emitNewFunctionCommon):
2956         (JSC::BytecodeGenerator::emitNewFunctionExpression):
2957         (JSC::BytecodeGenerator::emitNewArrowFunctionExpression):
2958         (JSC::BytecodeGenerator::emitLoadArrowFunctionThis):
2959         * bytecompiler/BytecodeGenerator.h:
2960         * bytecompiler/NodesCodegen.cpp:
2961         (JSC::ArrowFuncExprNode::emitBytecode):
2962         * dfg/DFGAbstractInterpreterInlines.h:
2963         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2964         * dfg/DFGByteCodeParser.cpp:
2965         (JSC::DFG::ByteCodeParser::parseBlock):
2966         * dfg/DFGCapabilities.cpp:
2967         (JSC::DFG::capabilityLevel):
2968         * dfg/DFGClobberize.h:
2969         (JSC::DFG::clobberize):
2970         * dfg/DFGDoesGC.cpp:
2971         (JSC::DFG::doesGC):
2972         * dfg/DFGFixupPhase.cpp:
2973         (JSC::DFG::FixupPhase::fixupNode):
2974         * dfg/DFGNode.h:
2975         (JSC::DFG::Node::convertToPhantomNewFunction):
2976         (JSC::DFG::Node::hasCellOperand):
2977         (JSC::DFG::Node::isFunctionAllocation):
2978         * dfg/DFGNodeType.h:
2979         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2980         * dfg/DFGPredictionPropagationPhase.cpp:
2981         (JSC::DFG::PredictionPropagationPhase::propagate):
2982         * dfg/DFGPromotedHeapLocation.cpp:
2983         (WTF::printInternal):
2984         * dfg/DFGPromotedHeapLocation.h:
2985         * dfg/DFGSafeToExecute.h:
2986         (JSC::DFG::safeToExecute):
2987         * dfg/DFGSpeculativeJIT.cpp:
2988         (JSC::DFG::SpeculativeJIT::compileLoadArrowFunctionThis):
2989         (JSC::DFG::SpeculativeJIT::compileNewFunctionCommon):
2990         (JSC::DFG::SpeculativeJIT::compileNewFunction):
2991         * dfg/DFGSpeculativeJIT.h:
2992         (JSC::DFG::SpeculativeJIT::callOperation):
2993         * dfg/DFGSpeculativeJIT32_64.cpp:
2994         (JSC::DFG::SpeculativeJIT::compile):
2995         * dfg/DFGSpeculativeJIT64.cpp:
2996         (JSC::DFG::SpeculativeJIT::compile):
2997         * dfg/DFGStoreBarrierInsertionPhase.cpp:
2998         * dfg/DFGStructureRegistrationPhase.cpp:
2999         (JSC::DFG::StructureRegistrationPhase::run):
3000         * ftl/FTLAbstractHeapRepository.cpp:
3001         * ftl/FTLAbstractHeapRepository.h:
3002         * ftl/FTLCapabilities.cpp:
3003         (JSC::FTL::canCompile):
3004         * ftl/FTLIntrinsicRepository.h:
3005         * ftl/FTLLowerDFGToLLVM.cpp:
3006         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
3007         (JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
3008         (JSC::FTL::DFG::LowerDFGToLLVM::compileLoadArrowFunctionThis):
3009         * ftl/FTLOperations.cpp:
3010         (JSC::FTL::operationMaterializeObjectInOSR):
3011         * interpreter/Interpreter.cpp:
3012         * interpreter/Interpreter.h:
3013         * jit/CCallHelpers.h:
3014         (JSC::CCallHelpers::setupArgumentsWithExecState): Added 3 arguments version for windows build.
3015         * jit/JIT.cpp:
3016         (JSC::JIT::privateCompileMainPass):
3017         * jit/JIT.h:
3018         * jit/JITInlines.h:
3019         (JSC::JIT::callOperation):
3020         * jit/JITOpcodes.cpp:
3021         (JSC::JIT::emit_op_load_arrowfunction_this):
3022         (JSC::JIT::emit_op_new_func_exp):
3023         (JSC::JIT::emitNewFuncExprCommon):
3024         (JSC::JIT::emit_op_new_arrow_func_exp):
3025         * jit/JITOpcodes32_64.cpp:
3026         (JSC::JIT::emit_op_load_arrowfunction_this):
3027         * jit/JITOperations.cpp:
3028         * jit/JITOperations.h:
3029         * llint/LLIntOffsetsExtractor.cpp:
3030         * llint/LLIntSlowPaths.cpp:
3031         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3032         (JSC::LLInt::setUpCall):
3033         * llint/LLIntSlowPaths.h:
3034         * llint/LowLevelInterpreter.asm:
3035         * llint/LowLevelInterpreter32_64.asm:
3036         * llint/LowLevelInterpreter64.asm:
3037         * parser/ASTBuilder.h:
3038         (JSC::ASTBuilder::createFunctionMetadata):
3039         (JSC::ASTBuilder::createArrowFunctionExpr):
3040         * parser/NodeConstructors.h:
3041         (JSC::BaseFuncExprNode::BaseFuncExprNode):
3042         (JSC::FuncExprNode::FuncExprNode):
3043         (JSC::ArrowFuncExprNode::ArrowFuncExprNode):
3044         * parser/Nodes.cpp:
3045         (JSC::FunctionMetadataNode::FunctionMetadataNode):
3046         * parser/Nodes.h:
3047         (JSC::ExpressionNode::isArrowFuncExprNode):
3048         * parser/Parser.cpp:
3049         (JSC::Parser<LexerType>::parseFunctionBody):
3050         (JSC::Parser<LexerType>::parseFunctionInfo):
3051         * parser/SyntaxChecker.h:
3052         (JSC::SyntaxChecker::createFunctionMetadata):
3053         * runtime/Executable.cpp:
3054         (JSC::ScriptExecutable::newCodeBlockFor):
3055         * runtime/Executable.h:
3056         * runtime/JSArrowFunction.cpp: Added.
3057         (JSC::JSArrowFunction::destroy):
3058         (JSC::JSArrowFunction::create):
3059         (JSC::JSArrowFunction::JSArrowFunction):
3060         (JSC::JSArrowFunction::createWithInvalidatedReallocationWatchpoint):
3061         (JSC::JSArrowFunction::visitChildren):
3062         (JSC::JSArrowFunction::getConstructData):
3063         * runtime/JSArrowFunction.h: Added.
3064         (JSC::JSArrowFunction::allocationSize):
3065         (JSC::JSArrowFunction::createImpl):
3066         (JSC::JSArrowFunction::boundThis):
3067         (JSC::JSArrowFunction::createStructure):
3068         (JSC::JSArrowFunction::offsetOfThisValue):
3069         * runtime/JSFunction.h:
3070         * runtime/JSFunctionInlines.h:
3071         (JSC::JSFunction::JSFunction):
3072         * runtime/JSGlobalObject.cpp:
3073         (JSC::JSGlobalObject::init):
3074         (JSC::JSGlobalObject::visitChildren):
3075         * runtime/JSGlobalObject.h:
3076         (JSC::JSGlobalObject::arrowFunctionStructure):
3077         * tests/stress/arrowfunction-activation-sink-osrexit-default-value-tdz-error.js: Added.
3078         * tests/stress/arrowfunction-activation-sink-osrexit-default-value.js: Added.
3079         * tests/stress/arrowfunction-activation-sink-osrexit.js: Added.
3080         * tests/stress/arrowfunction-activation-sink.js: Added.
3081         * tests/stress/arrowfunction-bound.js: Added.
3082         * tests/stress/arrowfunction-call.js: Added.
3083         * tests/stress/arrowfunction-constructor.js: Added.
3084         * tests/stress/arrowfunction-lexical-bind-this-1.js: Added.
3085         * tests/stress/arrowfunction-lexical-bind-this-2.js: Added.
3086         * tests/stress/arrowfunction-lexical-bind-this-3.js: Added.
3087         * tests/stress/arrowfunction-lexical-bind-this-4.js: Added.
3088         * tests/stress/arrowfunction-lexical-bind-this-5.js: Added.
3089         * tests/stress/arrowfunction-lexical-bind-this-6.js: Added.
3090         * tests/stress/arrowfunction-lexical-this-activation-sink-osrexit.js: Added.
3091         * tests/stress/arrowfunction-lexical-this-activation-sink.js: Added.
3092         * tests/stress/arrowfunction-lexical-this-sinking-no-double-allocate.js: Added.
3093         * tests/stress/arrowfunction-lexical-this-sinking-osrexit.js: Added.
3094         * tests/stress/arrowfunction-lexical-this-sinking-put.js: Added.
3095         * tests/stress/arrowfunction-others.js: Added.
3096         * tests/stress/arrowfunction-run-10-1.js: Added.
3097         * tests/stress/arrowfunction-run-10-2.js: Added.
3098         * tests/stress/arrowfunction-run-10000-1.js: Added.
3099         * tests/stress/arrowfunction-run-10000-2.js: Added.
3100         * tests/stress/arrowfunction-sinking-no-double-allocate.js: Added.
3101         * tests/stress/arrowfunction-sinking-osrexit.js: Added.
3102         * tests/stress/arrowfunction-sinking-put.js: Added.
3103         * tests/stress/arrowfunction-tdz.js: Added.
3104         * tests/stress/arrowfunction-typeof.js: Added.
3105
3106 2015-07-28  Sam Weinig  <sam@webkit.org>
3107
3108         Cleanup the builtin JavaScript files
3109         https://bugs.webkit.org/show_bug.cgi?id=147382
3110
3111         Reviewed by Geoffrey Garen.
3112
3113         * builtins/Array.prototype.js:
3114         * builtins/ArrayConstructor.js:
3115         * builtins/ArrayIterator.prototype.js:
3116         * builtins/Function.prototype.js:
3117         * builtins/Iterator.prototype.js:
3118         * builtins/ObjectConstructor.js:
3119         * builtins/StringConstructor.js:
3120         * builtins/StringIterator.prototype.js:
3121         Unify the style of the built JavaScript files.
3122
3123 2015-08-17  Alex Christensen  <achristensen@webkit.org>
3124
3125         Move some commands from ./CMakeLists.txt to Source/cmake
3126         https://bugs.webkit.org/show_bug.cgi?id=148003
3127
3128         Reviewed by Brent Fulgham.
3129
3130         * CMakeLists.txt:
3131         Added commands needed to build JSC by itself.
3132
3133 2015-08-17  Yusuke Suzuki  <utatane.tea@gmail.com>
3134
3135         [ES6] Implement Reflect.get
3136         https://bugs.webkit.org/show_bug.cgi?id=147925
3137
3138         Reviewed by Geoffrey Garen.
3139
3140         This patch implements Reflect.get API.
3141         It can take the receiver object as the third argument.
3142         When the receiver is specified and there's a getter for the given property name,
3143         we call the getter with the receiver as the |this| value.
3144
3145         * runtime/ReflectObject.cpp:
3146         (JSC::reflectObjectGet):
3147         * runtime/SparseArrayValueMap.cpp:
3148         (JSC::SparseArrayEntry::get): Deleted.
3149         * runtime/SparseArrayValueMap.h:
3150         * tests/stress/reflect-get.js: Added.
3151         (shouldBe):
3152         (shouldThrow):
3153         (.get shouldThrow):
3154         (.get var):
3155         (get var.object.get hello):
3156         (.get shouldBe):
3157         (get var.object.set hello):
3158
3159 2015-08-17  Simon Fraser  <simon.fraser@apple.com>
3160
3161         will-change should sometimes trigger compositing
3162         https://bugs.webkit.org/show_bug.cgi?id=148072
3163
3164         Reviewed by Tim Horton.
3165         
3166         Include will-change as a reason for compositing.
3167
3168         * inspector/protocol/LayerTree.json:
3169
3170 2015-08-17  Yusuke Suzuki  <utatane.tea@gmail.com>
3171
3172         [ES6] Implement Reflect.getOwnPropertyDescriptor
3173         https://bugs.webkit.org/show_bug.cgi?id=147929
3174
3175         Reviewed by Geoffrey Garen.
3176
3177         Implement Reflect.getOwnPropertyDescriptor.
3178         The difference from the Object.getOwnPropertyDescriptor is
3179         Reflect.getOwnPropertyDescriptor does not perform ToObject onto
3180         the first argument. If the first argument is not an Object, it
3181         immediately raises the TypeError.
3182
3183         * runtime/ObjectConstructor.cpp:
3184         (JSC::objectConstructorGetOwnPropertyDescriptor):
3185         * runtime/ObjectConstructor.h:
3186         * runtime/ReflectObject.cpp:
3187         (JSC::reflectObjectGetOwnPropertyDescriptor):
3188         * tests/stress/reflect-get-own-property.js: Added.
3189         (shouldBe):
3190         (shouldThrow):
3191
3192 2015-08-16  Benjamin Poulain  <bpoulain@apple.com>
3193
3194         [JSC] Use (x + x) instead of (x * 2) when possible
3195         https://bugs.webkit.org/show_bug.cgi?id=148051
3196
3197         Reviewed by Michael Saboff.
3198
3199         When multiplying a number by 2, JSC was loading a constant "2"
3200         in register and multiplying it with the first number:
3201
3202             mov $0x4000000000000000, %rcx
3203             movd %rcx, %xmm0
3204             mulsd %xmm0, %xmm1
3205
3206         This is a problem for a few reasons.
3207         1) "movd %rcx, %xmm0" only set half of XMM0. This instruction
3208            has to wait for any preceding instruction on XMM0 to finish
3209            before executing.
3210         2) The load and transform itself is large and unecessary.
3211
3212         To fix that, I added a StrengthReductionPhase to transform
3213         multiplications by 2 into a addition.
3214
3215         Unfortunately, that turned the code into:
3216             movsd %xmm0 %xmm1
3217             mulsd %xmm1 %xmm0
3218
3219         The reason is GenerationInfo::canReuse() was not accounting
3220         for nodes using other nodes multiple times.
3221
3222         After fixing that too, we now have the multiplications by 2
3223         done as:
3224             addsd %xmm0 %xmm0
3225
3226         * dfg/DFGGenerationInfo.h:
3227         (JSC::DFG::GenerationInfo::useCount):
3228         (JSC::DFG::GenerationInfo::canReuse): Deleted.
3229         * dfg/DFGSpeculativeJIT.cpp:
3230         (JSC::DFG::FPRTemporary::FPRTemporary):
3231         * dfg/DFGSpeculativeJIT.h:
3232         (JSC::DFG::SpeculativeJIT::canReuse):
3233         (JSC::DFG::GPRTemporary::GPRTemporary):
3234         * dfg/DFGStrengthReductionPhase.cpp:
3235         (JSC::DFG::StrengthReductionPhase::handleNode):
3236
3237 2015-08-14  Basile Clement  <basile_clement@apple.com>
3238
3239         Occasional failure in v8-v6/v8-raytrace.js.ftl-eager
3240         https://bugs.webkit.org/show_bug.cgi?id=147165
3241
3242         Reviewed by Saam Barati.
3243
3244         The object allocation sinking phase was not properly checking that a
3245         MultiGetByOffset was safe to lower before lowering it.
3246         This makes it so that we only lower MultiGetByOffset if it only loads
3247         from direct properties of the object, and considers it as an escape in
3248         any other case (e.g. a load from the prototype).
3249
3250         It also ensure proper conversion of MultiGetByOffset into
3251         CheckStructureImmediate when needed.
3252
3253         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3254         * ftl/FTLLowerDFGToLLVM.cpp:
3255         (JSC::FTL::DFG::LowerDFGToLLVM::checkStructure):
3256             We were not compiling properly CheckStructure and
3257             CheckStructureImmediate nodes with an empty StructureSet.
3258         * tests/stress/sink-multigetbyoffset.js: Regression test.
3259
3260 2015-08-14  Filip Pizlo  <fpizlo@apple.com>
3261
3262         Use WTF::Lock and WTF::Condition instead of WTF::Mutex, WTF::ThreadCondition, std::mutex, and std::condition_variable
3263         https://bugs.webkit.org/show_bug.cgi?id=147999
3264
3265         Reviewed by Geoffrey Garen.
3266
3267         * API/JSVirtualMachine.mm:
3268         (initWrapperCache):
3269         (+[JSVMWrapperCache addWrapper:forJSContextGroupRef:]):
3270         (+[JSVMWrapperCache wrapperForJSContextGroupRef:]):
3271         (wrapperCacheMutex): Deleted.
3272         * bytecode/SamplingTool.cpp:
3273         (JSC::SamplingTool::doRun):
3274         (JSC::SamplingTool::notifyOfScope):
3275         * bytecode/SamplingTool.h:
3276         * dfg/DFGThreadData.h:
3277         * dfg/DFGWorklist.cpp:
3278         (JSC::DFG::Worklist::~Worklist):
3279         (JSC::DFG::Worklist::isActiveForVM):
3280         (JSC::DFG::Worklist::enqueue):
3281         (JSC::DFG::Worklist::compilationState):
3282         (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
3283         (JSC::DFG::Worklist::removeAllReadyPlansForVM):
3284         (JSC::DFG::Worklist::completeAllReadyPlansForVM):
3285         (JSC::DFG::Worklist::visitWeakReferences):
3286         (JSC::DFG::Worklist::removeDeadPlans):
3287         (JSC::DFG::Worklist::queueLength):
3288         (JSC::DFG::Worklist::dump):
3289         (JSC::DFG::Worklist::runThread):
3290         * dfg/DFGWorklist.h:
3291         * disassembler/Disassembler.cpp:
3292         * heap/CopiedSpace.cpp:
3293         (JSC::CopiedSpace::doneFillingBlock):
3294         (JSC::CopiedSpace::doneCopying):
3295         * heap/CopiedSpace.h:
3296         * heap/CopiedSpaceInlines.h:
3297         (JSC::CopiedSpace::recycleBorrowedBlock):
3298         (JSC::CopiedSpace::allocateBlockForCopyingPhase):
3299         * heap/GCThread.cpp:
3300         (JSC::GCThread::waitForNextPhase):
3301         (JSC::GCThread::gcThreadMain):
3302         * heap/GCThreadSharedData.cpp:
3303         (JSC::GCThreadSharedData::GCThreadSharedData):
3304         (JSC::GCThreadSharedData::~GCThreadSharedData):
3305         (JSC::GCThreadSharedData::startNextPhase):
3306         (JSC::GCThreadSharedData::endCurrentPhase):
3307         (JSC::GCThreadSharedData::didStartMarking):
3308         (JSC::GCThreadSharedData::didFinishMarking):
3309         * heap/GCThreadSharedData.h:
3310         * heap/HeapTimer.h:
3311         * heap/MachineStackMarker.cpp:
3312         (JSC::ActiveMachineThreadsManager::Locker::Locker):
3313         (JSC::ActiveMachineThreadsManager::add):
3314         (JSC::ActiveMachineThreadsManager::remove):
3315         (JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
3316         (JSC::MachineThreads::~MachineThreads):
3317         (JSC::MachineThreads::addCurrentThread):
3318         (JSC::MachineThreads::removeThreadIfFound):
3319         (JSC::MachineThreads::tryCopyOtherThreadStack):
3320         (JSC::MachineThreads::tryCopyOtherThreadStacks):
3321         (JSC::MachineThreads::gatherConservativeRoots):
3322         * heap/MachineStackMarker.h:
3323         * heap/SlotVisitor.cpp:
3324         (JSC::SlotVisitor::donateKnownParallel):
3325         (JSC::SlotVisitor::drain):
3326         (JSC::SlotVisitor::drainFromShared):
3327         (JSC::SlotVisitor::mergeOpaqueRoots):