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