eca9b652c88d674e052d25ee4d425b04c96aa52d
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2
3         [DOMJIT] DOMJIT::Patchpoint should have a way to receive constant folded arguments
4         https://bugs.webkit.org/show_bug.cgi?id=163224
5
6         Reviewed by Filip Pizlo.
7
8         We use the GetGlobalObject DFG node to retrieve a global object from a DOM node.
9         This global object is necessary to check whether the world is normal before entering
10         the fast path of looking up the DOM wrapper cache.
11         We can sometimes constant-fold this GetGlobalObject. For example, if we performed
12         CheckStructure, the structure can offer the information about the possible result
13         of GetGlobalObject. By using this constant-folded global object, we can drop some
14         checks.
15
16         This patch introduces the way to tell the constant-folded values to DOMJIT::Patchpoint.
17         We pass DOMJIT::Value instead of DOMJIT::Reg as a parameter of DOMJIT::PatchpointParams.
18         This DOMJIT::Value is a pair of DOMJIT::Reg and JSValue. If the given parameter has a
19         constant value, this JSValue is filled with it.
20
21         * JavaScriptCore.xcodeproj/project.pbxproj:
22         * dfg/DFGDOMJITPatchpointParams.h:
23         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
24         * dfg/DFGSpeculativeJIT.cpp:
25         (JSC::DFG::SpeculativeJIT::compileCallDOM):
26         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
27         * domjit/DOMJITPatchpointParams.h:
28         (JSC::DOMJIT::PatchpointParams::at):
29         (JSC::DOMJIT::PatchpointParams::operator[]):
30         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
31         * domjit/DOMJITValue.h: Copied from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h.
32         (JSC::DOMJIT::Value::Value):
33         (JSC::DOMJIT::Value::isGPR):
34         (JSC::DOMJIT::Value::isFPR):
35         (JSC::DOMJIT::Value::isJSValueRegs):
36         (JSC::DOMJIT::Value::gpr):
37         (JSC::DOMJIT::Value::fpr):
38         (JSC::DOMJIT::Value::jsValueRegs):
39         (JSC::DOMJIT::Value::reg):
40         (JSC::DOMJIT::Value::value):
41         * ftl/FTLDOMJITPatchpointParams.h:
42         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
43         * ftl/FTLLowerDFGToB3.cpp:
44         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
45         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
46
47 2016-10-10  Filip Pizlo  <fpizlo@apple.com>
48
49         Air should be able to replace constant materializations with adds
50         https://bugs.webkit.org/show_bug.cgi?id=162749
51
52         Reviewed by Yusuke Suzuki.
53         
54         We have a lot of defenses against emitting code that materializes huge contants. But if we do
55         end up with such code in the backend, it's better to convert those materializations into add
56         instructions by checking if other registers are known to contain nearby constants. That's
57         what this patch does.
58
59         * b3/air/AirFixObviousSpills.cpp:
60         * b3/testb3.cpp:
61
62 2016-10-11  Filip Pizlo  <fpizlo@apple.com>
63
64         B3->Air lowering needs the same defenses in effectiveAddr() that it has in tryAppendLea()
65         https://bugs.webkit.org/show_bug.cgi?id=163264
66
67         Reviewed by Mark Lam.
68         
69         When writing the lea patch (r207039), I was very careful about how I convert a Shl into a
70         BaseIndex scale. But I forgot to check if the older code for creating BaseIndexes for
71         effectiveAddr() got this right. It turns out that the older code missed the <<32 corner
72         case.
73         
74         It's sad that the two paths can't share all of their code, but it's somewhat inevitable due
75         to how matching an address and matching a lea have to do very different things. Matching a
76         lea means creating an instruction that is distinct from other instructions to do multiple
77         math operations at once. Matching an address means making some instruction do extra work
78         for free. Also, address matching can take advantage of the fact that the offset is already
79         associated with the memory operation by strength reduction - lea matching can't do this; it
80         has to figure out Add(@value, $const) on its own. This change makes the situation slightly
81         more sane by adding a scaleForShl() helper that handles this weird case. It's based on the
82         new Shl handling from r207039, and exposes it as an API for effectiveAddr() to use.
83         
84         The testLoadBaseIndexShift32() used to crash. I don't think that this case affects JS
85         content, since <<32 is such a bizarre outlier. I don't think we even have a path along
86         which the FTL would emit a 64-bit <<32. It probably won't even affect WebAssembly since
87         that uses 32-bit pointers, so we won't see 64-bit <<32 in effectiveAddr() there.
88
89         * b3/B3LowerToAir.cpp:
90         (JSC::B3::Air::LowerToAir::scaleForShl):
91         (JSC::B3::Air::LowerToAir::effectiveAddr):
92         (JSC::B3::Air::LowerToAir::tryAppendLea):
93         (JSC::B3::Air::LowerToAir::crossesInterference): Deleted.
94         * b3/testb3.cpp:
95         (JSC::B3::testLoadBaseIndexShift2):
96         (JSC::B3::testLoadBaseIndexShift32):
97         (JSC::B3::run):
98
99 2016-10-11  Saam Barati  <sbarati@apple.com>
100
101         ValueAdd should be constant folded if the operands are constant String,Primitive or Primitive,String
102         https://bugs.webkit.org/show_bug.cgi?id=163182
103
104         Reviewed by Filip Pizlo.
105
106         This code pattern shows up in Dromaeo, so it's worth optimizing for.
107         This might also show up in real world JS code due to inlining and other
108         types of constant folding.
109
110         * dfg/DFGByteCodeParser.cpp:
111         (JSC::DFG::ByteCodeParser::parseBlock):
112         * dfg/DFGLazyJSValue.cpp:
113         (JSC::DFG::LazyJSValue::getValue):
114         * dfg/DFGStrengthReductionPhase.cpp:
115         (JSC::DFG::StrengthReductionPhase::handleNode):
116
117 2016-10-10  Zan Dobersek  <zdobersek@igalia.com>
118
119         Add ENABLE_ENCRYPTED_MEDIA configuration option
120         https://bugs.webkit.org/show_bug.cgi?id=163219
121
122         Reviewed by Darin Adler.
123
124         * Configurations/FeatureDefines.xcconfig:
125         Add the ENABLE_ENCRYPTED_MEDIA configuration option. It will be used
126         to enable or disable the new EME implementation at build-time.
127
128 2016-10-10  Filip Pizlo  <fpizlo@apple.com>
129
130         B3->Air lowering should be able to emit complex leas on x86
131         https://bugs.webkit.org/show_bug.cgi?id=163234
132
133         Reviewed by Saam Barati.
134         
135         This adds comprehensive support for emitting lea on x86.
136         
137         When adding this, I found that it was useful to also finally add more reassociation. That
138         reduces the amount of patterns that the instruction selector has to deal with.
139
140         * assembler/MacroAssembler.h:
141         (JSC::MacroAssembler::lea32):
142         (JSC::MacroAssembler::lea64):
143         (JSC::MacroAssembler::lea): Deleted.
144         * b3/B3LowerToAir.cpp:
145         (JSC::B3::Air::LowerToAir::commitInternal):
146         (JSC::B3::Air::LowerToAir::tryAppendLea):
147         (JSC::B3::Air::LowerToAir::lower):
148         (JSC::B3::Air::LowerToAir::createSelect): Deleted.
149         * b3/B3ReduceStrength.cpp:
150         * b3/B3Value.h:
151         * b3/B3ValueInlines.h:
152         (JSC::B3::Value::isRepresentableAs):
153         (JSC::B3::Value::representableAs): Deleted.
154         * b3/air/AirOpcode.opcodes:
155         * b3/testb3.cpp: Lots of tests for lea and reassociation.
156
157 2016-10-10  Mark Lam  <mark.lam@apple.com>
158
159         Change ArrayPrototype.cpp's putLength() and setLength() to take a VM& so that we can use vm.propertyNames.
160         https://bugs.webkit.org/show_bug.cgi?id=163260
161
162         Reviewed by Saam Barati.
163
164         In all cases where we call these, we already have the VM& anyway.
165
166         * runtime/ArrayPrototype.cpp:
167         (JSC::putLength):
168         (JSC::setLength):
169         (JSC::arrayProtoFuncPop):
170         (JSC::arrayProtoFuncPush):
171         (JSC::arrayProtoFuncShift):
172         (JSC::arrayProtoFuncSlice):
173         (JSC::arrayProtoFuncSplice):
174         (JSC::arrayProtoFuncUnShift):
175
176 2016-10-10  Mark Lam  <mark.lam@apple.com>
177
178         Rename the StrictModeReadonlyPropertyWriteError string to ReadonlyPropertyWriteError.
179         https://bugs.webkit.org/show_bug.cgi?id=163239
180
181         Reviewed by Filip Pizlo.
182
183         This string is also used for reporting the same error in cases which have nothing
184         to do with strict mode.
185
186         * bytecompiler/BytecodeGenerator.cpp:
187         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
188         * runtime/CommonSlowPaths.cpp:
189         (JSC::SLOW_PATH_DECL):
190         * runtime/GetterSetter.cpp:
191         (JSC::callSetter):
192         * runtime/JSArray.cpp:
193         (JSC::JSArray::setLengthWithArrayStorage):
194         (JSC::JSArray::pop):
195         * runtime/JSCJSValue.cpp:
196         (JSC::JSValue::putToPrimitive):
197         (JSC::JSValue::putToPrimitiveByIndex):
198         * runtime/JSFunction.cpp:
199         (JSC::JSFunction::put):
200         * runtime/JSModuleEnvironment.cpp:
201         (JSC::JSModuleEnvironment::put):
202         * runtime/JSModuleNamespaceObject.cpp:
203         (JSC::JSModuleNamespaceObject::put):
204         (JSC::JSModuleNamespaceObject::putByIndex):
205         * runtime/JSObject.cpp:
206         (JSC::ordinarySetSlow):
207         (JSC::JSObject::putInlineSlow):
208         (JSC::JSObject::setPrototypeWithCycleCheck):
209         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
210         (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
211         * runtime/JSObject.h:
212         * runtime/JSObjectInlines.h:
213         (JSC::JSObject::putInline):
214         * runtime/JSSymbolTableObject.h:
215         (JSC::symbolTablePut):
216         * runtime/Lookup.h:
217         (JSC::putEntry):
218         * runtime/RegExpObject.h:
219         (JSC::RegExpObject::setLastIndex):
220         * runtime/SparseArrayValueMap.cpp:
221         (JSC::SparseArrayValueMap::putEntry):
222         (JSC::SparseArrayEntry::put):
223         * runtime/StringObject.cpp:
224         (JSC::StringObject::put):
225         (JSC::StringObject::putByIndex):
226
227 2016-10-10  Saam Barati  <sbarati@apple.com>
228
229         compileCheckStringIdent in the FTL is wrong
230         https://bugs.webkit.org/show_bug.cgi?id=163215
231
232         Reviewed by Mark Lam and Filip Pizlo.
233
234         lowStringIdent() returns the StringImpl pointer. The compileCheckStringIdent()
235         was treating its return value as the actual JSString. This is wrong.
236
237         * ftl/FTLLowerDFGToB3.cpp:
238         (JSC::FTL::DFG::LowerDFGToB3::compileCheckStringIdent):
239
240 2016-10-10  Yusuke Suzuki  <utatane.tea@gmail.com>
241
242         [DOMJIT] Implement Node accessors in DOMJIT
243         https://bugs.webkit.org/show_bug.cgi?id=163005
244
245         Reviewed by Filip Pizlo.
246
247         Add some helper methods and offsetOfXXX for JSC::Weak since it is used
248         for DOM wrapper caching.
249
250         And make DOMJIT::Patchpoint in FTL closer to one in DFG. We add resultConstraint
251         to avoid the situation that the same register is allocated to child and result.
252
253         We also extend DOMJIT::Patchpoint to tell useTagTypeNumberRegister / useTagMaskRegister.
254
255         * dfg/DFGSpeculativeJIT.h:
256         (JSC::DFG::SpeculativeJIT::callOperation):
257         * domjit/DOMJITSlowPathCalls.h:
258         * ftl/FTLLowerDFGToB3.cpp:
259         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
260         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
261         * heap/WeakImpl.h:
262         (JSC::WeakImpl::offsetOfJSValue):
263         (JSC::WeakImpl::offsetOfWeakHandleOwner):
264         * jit/AssemblyHelpers.h:
265         (JSC::AssemblyHelpers::boxCell):
266         (JSC::AssemblyHelpers::boxInt32): Deleted.
267         * jit/JITOperations.h:
268
269 2016-10-09  Filip Pizlo  <fpizlo@apple.com>
270
271         Air should expose API for pinning registers
272         https://bugs.webkit.org/show_bug.cgi?id=163175
273
274         Reviewed by Keith Miller.
275         
276         You can now call Procedure::pinRegister(), or Code::pinRegister(), and it will make this
277         register behave as follows:
278         
279         - B3 and Air will emit no code that modifies the value in this register, except if that
280           happens via a Patchpoint or stackmap constraint (i.e. the user explicitly asked for it).
281         - B3 and Air will allow others to modify the register. For example, if the register is not
282           callee-save, then the compiler knows that the register's value will be trashed by any
283           C-style call.
284         - Air will be happy to emit code that reads from this register, including coalescing tmps
285           with it, so longer as there is no interference (i.e. no chance of the register's value
286           changing). For example, if we went back to having pinned tag registers, we would tell B3
287           to use them by (1) excluding them from any clobber set (easy, since they're callee save)
288           and (2) emitting ArgumentReg to grab their value. There's a test that does this.
289         
290         This is accomplished by taking regsInPriorityOrder() and making it a method of Code. Air 
291         already used this API when choosing registers in register allocation. Code now also vends a
292         mutableRegs() set, which is derived from regsInPriorityOrder(), that can quickly tell you if
293         a register can be mutated. Doing it this way means that most of this is a purely mechanical
294         change. The calls to mutableRegs() are the places where we had to change logic:
295         
296         - The register allocators needs to know that coalescing with a precolored pinned tmp is free.
297         - The callee-save handler needs to know that we're not supposed to save/restore pinned
298           registers.
299         
300         Note that in this scheme, pinned registers are simply registers that do not appear in
301         regsInPriorityOrder(). This means, for example, that we will now say that FP is pinned. So,
302         this means that you can also pin registers by calling setRegsInPriorityOrder() and passing a
303         vector that excludes some registers. More generally, this means that clients can now tweak
304         the register allocator's register preferences, since the ordering in that list reflects the
305         order in which the allocator will try registers.
306
307         * CMakeLists.txt:
308         * JavaScriptCore.xcodeproj/project.pbxproj:
309         * b3/B3Procedure.cpp:
310         (JSC::B3::Procedure::pinRegister):
311         * b3/B3Procedure.h:
312         * b3/air/AirCode.cpp:
313         (JSC::B3::Air::Code::Code):
314         (JSC::B3::Air::Code::setRegsInPriorityOrder):
315         (JSC::B3::Air::Code::pinRegister):
316         * b3/air/AirCode.h:
317         (JSC::B3::Air::Code::regsInPriorityOrder):
318         (JSC::B3::Air::Code::mutableRegs):
319         (JSC::B3::Air::Code::isPinned):
320         (JSC::B3::Air::Code::regsInPriorityOrderImpl):
321         (JSC::B3::Air::Code::proc): Deleted.
322         * b3/air/AirEmitShuffle.cpp:
323         (JSC::B3::Air::emitShuffle):
324         * b3/air/AirEmitShuffle.h:
325         * b3/air/AirHandleCalleeSaves.cpp:
326         (JSC::B3::Air::handleCalleeSaves):
327         * b3/air/AirIteratedRegisterCoalescing.cpp:
328         * b3/air/AirLowerAfterRegAlloc.cpp:
329         (JSC::B3::Air::lowerAfterRegAlloc):
330         * b3/air/AirRegisterPriority.cpp: Removed.
331         * b3/air/AirRegisterPriority.h: Removed.
332         * b3/air/AirSpillEverything.cpp:
333         (JSC::B3::Air::spillEverything):
334         * b3/air/testair.cpp:
335         (JSC::B3::Air::testShuffleBroadcastAllRegs):
336         (JSC::B3::Air::testShuffleShiftAllRegs):
337         (JSC::B3::Air::testShuffleRotateAllRegs):
338         (JSC::B3::Air::testShuffleShiftMemoryAllRegs):
339         (JSC::B3::Air::testShuffleShiftMemoryAllRegs64):
340         (JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth):
341         (JSC::B3::Air::testShuffleRotateMemoryAllRegs64):
342         (JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth):
343         * b3/testb3.cpp:
344         (JSC::B3::testPinRegisters):
345         (JSC::B3::run):
346         * jit/RegisterSet.h:
347
348 2016-10-08  Filip Pizlo  <fpizlo@apple.com>
349
350         B3 should know about mutable pinned registers
351         https://bugs.webkit.org/show_bug.cgi?id=163172
352
353         Reviewed by Keith Miller.
354         
355         If we have mutable pinned registers then we need to know which operations mutate them. At
356         first I considered making this into a heap range thing, but I think that this would be very
357         confusing. Also, in the future, we might want to make Effects track register sets of
358         clobbered registers (see bug 163173).
359
360         * b3/B3Effects.cpp:
361         (JSC::B3::Effects::interferes):
362         (JSC::B3::Effects::operator==):
363         (JSC::B3::Effects::dump):
364         * b3/B3Effects.h:
365         (JSC::B3::Effects::forCall):
366         (JSC::B3::Effects::mustExecute):
367
368 2016-10-08  Saam Barati  <sbarati@apple.com>
369
370         HasIndexedProperty clobberize rule is wrong for Array::ForceOSRExit
371         https://bugs.webkit.org/show_bug.cgi?id=159942
372         <rdar://problem/27328836>
373
374         Reviewed by Filip Pizlo.
375
376         When HasIndexedProperty has a ForceOSRExit array mode, it should
377         report to write to side state, like the ForceOSRExit node, and the
378         other nodes with ForceOSRExit array mode.
379
380         * dfg/DFGClobberize.h:
381         (JSC::DFG::clobberize):
382
383 2016-10-07  Mark Lam  <mark.lam@apple.com>
384
385         Object.freeze() and seal() should throw if [[PreventExtensions]]() fails.
386         https://bugs.webkit.org/show_bug.cgi?id=163160
387
388         Reviewed by Saam Barati.
389
390         See https://tc39.github.io/ecma262/#sec-object.freeze,
391         https://tc39.github.io/ecma262/#sec-object.seal, and
392         https://tc39.github.io/ecma262/#sec-setintegritylevel.  We need to call
393         preventExtensions first before proceeding to freeze / seal the object.  If
394         preventExtensions fails, we should throw a TypeError.
395
396         * runtime/ObjectConstructor.cpp:
397         (JSC::setIntegrityLevel):
398         (JSC::objectConstructorSeal):
399         (JSC::objectConstructorFreeze):
400
401 2016-10-06  Yusuke Suzuki  <utatane.tea@gmail.com>
402
403         [DOMJIT] Support slow path call
404         https://bugs.webkit.org/show_bug.cgi?id=162978
405
406         Reviewed by Saam Barati.
407
408         One of the most important features required in DOMJIT::Patchpoint is slow path calls.
409         DOM operation typically returns DOMWrapper object. At that time, if wrapper cache hits, we can go
410         to the fast path. However, if we cannot use the cache, we need to go to the slow path to call toJS function.
411         At that time, slow path call functionality is necessary.
412
413         This patch expose DOMJIT::PatchpointParams::addSlowPathCall. We can request slow path call code generation
414         through this interface. DOMJIT::PatchpointParams automatically leverages appropriate slow path call systems
415         in each tier. In DFG, we use slow path call system. In FTL, we implement slow path call by using addLatePath
416         to construct slow path call. But these details are completely hidden by DOMJIT::PatchpointParams. Users can
417         just use addSlowPathCall.
418
419         Since DFG and FTL slow path call systems are implemented in variadic templates, directly using this means
420         that we need to expose core part of DFG and FTL. For example, DFG::SpeculativeJIT need to be exposed in
421         such a design. That is too bad. Instead, we use magical macro in DOMJITSlowPathCalls.h. We can list up the
422         call signatures in DOMJIT_SLOW_PATH_CALLS. DOMJIT uses these signatures to generate an interface to request
423         slow path calls inside DFG and FTL instead of exposing everything.
424
425         * CMakeLists.txt:
426         * JavaScriptCore.xcodeproj/project.pbxproj:
427         * dfg/DFGCommon.h:
428         * dfg/DFGDOMJITPatchpointParams.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
429         (JSC::DFG::dispatch):
430         * dfg/DFGDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
431         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
432         * dfg/DFGSpeculativeJIT.cpp:
433         (JSC::DFG::SpeculativeJIT::compileCallDOM):
434         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
435         * dfg/DFGSpeculativeJIT.h:
436         (JSC::DFG::extractResult): Deleted.
437         * domjit/DOMJITPatchpointParams.h:
438         (JSC::DOMJIT::PatchpointParams::addSlowPathCall):
439         * domjit/DOMJITSlowPathCalls.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
440         * ftl/FTLDOMJITPatchpointParams.cpp: Added.
441         (JSC::FTL::dispatch):
442         * ftl/FTLDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
443         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
444         * ftl/FTLLowerDFGToB3.cpp:
445         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
446         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
447         * jit/GPRInfo.h:
448         (JSC::extractResult):
449         * jsc.cpp:
450
451 2016-10-06  Saam Barati  <sbarati@apple.com>
452
453         HasOwnPropertyCache flattening dictionaries is causing insane memory usage with the uBlock Safari extension
454         https://bugs.webkit.org/show_bug.cgi?id=163091
455
456         Reviewed by Mark Lam.
457
458         I'm investigating a real fix for this in:
459         https://bugs.webkit.org/show_bug.cgi?id=163092
460         However, it's best to get this out of trunk for now.
461
462         * runtime/HasOwnPropertyCache.h:
463         (JSC::HasOwnPropertyCache::tryAdd):
464
465 2016-10-06  Keith Miller  <keith_miller@apple.com>
466
467         getInternalObjcObject should validate the JSManagedObject's value.
468         https://bugs.webkit.org/show_bug.cgi?id=162985
469
470         Reviewed by Geoffrey Garen.
471
472         Previously, if, for instance, the JSManagedObject's weak value had been
473         cleared we would call tryUnwrapObjcObject with a nil context and value.
474         This triggered assertions failures as those functions expect their inputs
475         to be valid.
476
477         * API/JSVirtualMachine.mm:
478         (getInternalObjcObject):
479
480 2016-10-06  Brian Burg  <bburg@apple.com>
481
482         Web Inspector: RemoteInspector should cache client capabilities for off-main thread usage
483         https://bugs.webkit.org/show_bug.cgi?id=163039
484         <rdar://problem/28571460>
485
486         Reviewed by Timothy Hatcher.
487
488         The fix in r206797 was incorrect because listings are always pushed out on the XPC connection queue.
489         Instead of delaying the listing needlessly, RemoteInspector should cache the capabilities of its
490         client while on the main thread, then use the cached struct data on the XPC connection queue rather
491         than directly accessing m_client. This is similar to how RemoteConnectionToTarget marshalls listing
492         information from arbitrary queues into m_targetListingMap, which can then be read from any queue.
493
494         * inspector/remote/RemoteInspector.h:
495         * inspector/remote/RemoteInspector.mm:
496         (Inspector::RemoteInspector::updateClientCapabilities): Cache the capabilities.
497         (Inspector::RemoteInspector::setRemoteInspectorClient):
498         Re-cache the capabilities. Scope the lock to avoid reentrant locking.
499
500         (Inspector::RemoteInspector::clientCapabilitiesDidChange): Cache the capabilities.
501         (Inspector::RemoteInspector::pushListingsNow): Use cached client capabilities.
502         (Inspector::RemoteInspector::receivedGetListingMessage): Revert the change in r206797.
503         (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
504
505 2016-10-06  Yusuke Suzuki  <utatane.tea@gmail.com>
506
507         [WebCore][JSC] Use new @throwTypeError and @throwRangeError intrinsics
508         https://bugs.webkit.org/show_bug.cgi?id=163001
509
510         Reviewed by Keith Miller.
511
512         Previously, the argument of @throwXXXError intrinsics must be string literal.
513         But it is error-prone restriction. This patch relaxes the restriction to accept
514         arbitrary values. To keep emitted bytecode small, if the argument is string literal,
515         we generate the same bytecode as before. If the argument is not string literal,
516         we evaluate it and perform to_string before passing to throw_static_error.
517
518         * bytecompiler/BytecodeGenerator.cpp:
519         (JSC::BytecodeGenerator::emitThrowStaticError):
520         * bytecompiler/BytecodeGenerator.h:
521         * bytecompiler/NodesCodegen.cpp:
522         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
523         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
524         * dfg/DFGByteCodeParser.cpp:
525         (JSC::DFG::ByteCodeParser::parseBlock):
526
527 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
528
529         [JSC] Add @throwXXXError bytecode intrinsic
530         https://bugs.webkit.org/show_bug.cgi?id=162995
531
532         Reviewed by Saam Barati.
533
534         Builtin JS code need to check arguments carefully since it is somewhat standard library for JS.
535         So bunch of `throw new @TypeError("...")` exists while usual code does not have so many.
536         However the above code bloats 32 instructions per site, enlarges the size of bytecodes of builtins,
537         and prevent us from inlining. We should have a way to reduce this size.
538
539         Fortunately, we already have such a opcode: op_throw_static_error. In this patch,
540         1. We extends op_throw_static_error to throw arbitrary errors. Previously, only TypeError and ReferenceError are allowed.
541            We can embed ErrorType enum in op_throw_static_error to throw any types of errors.
542         2. We introduce several new bytecode intrinsics, `@throwTypeError("...")`, `@throwRangeError("...")`,
543            and `@throwOutOfMemoryError()`. And use it inside builtin JS instead of `throw new @TypeError("...")` thingy.
544         3. DFG Node for throw_static_error is incorrectly named as "ThrowReferenceError". This patch renames it to "ThrowStaticError".
545
546         * builtins/ArrayConstructor.js:
547         * builtins/ArrayIteratorPrototype.js:
548         (next):
549         * builtins/ArrayPrototype.js:
550         (values):
551         (keys):
552         (entries):
553         (reduce):
554         (reduceRight):
555         (every):
556         (forEach):
557         (filter):
558         (map):
559         (some):
560         (fill):
561         (find):
562         (findIndex):
563         (includes):
564         (sort):
565         (concatSlowPath):
566         (copyWithin):
567         * builtins/DatePrototype.js:
568         (toLocaleString.toDateTimeOptionsAnyAll):
569         (toLocaleString):
570         (toLocaleDateString.toDateTimeOptionsDateDate):
571         (toLocaleDateString):
572         (toLocaleTimeString.toDateTimeOptionsTimeTime):
573         (toLocaleTimeString):
574         * builtins/FunctionPrototype.js:
575         (bind):
576         * builtins/GeneratorPrototype.js:
577         (globalPrivate.generatorResume):
578         * builtins/GlobalOperations.js:
579         (globalPrivate.speciesConstructor):
580         * builtins/MapPrototype.js:
581         (forEach):
582         * builtins/ModuleLoaderPrototype.js:
583         (provide):
584         * builtins/ObjectConstructor.js:
585         (values):
586         (entries):
587         (assign):
588         * builtins/PromiseConstructor.js:
589         (race):
590         (reject):
591         (resolve):
592         * builtins/PromiseOperations.js:
593         (globalPrivate.newPromiseCapability.executor):
594         (globalPrivate.newPromiseCapability):
595         (globalPrivate.initializePromise):
596         * builtins/PromisePrototype.js:
597         * builtins/ReflectObject.js:
598         (apply):
599         (deleteProperty):
600         (has):
601         * builtins/RegExpPrototype.js:
602         (globalPrivate.regExpExec):
603         (match):
604         (replace):
605         (search):
606         (split):
607         (intrinsic.RegExpTestIntrinsic.test):
608         * builtins/SetPrototype.js:
609         (forEach):
610         * builtins/StringConstructor.js:
611         (raw):
612         * builtins/StringIteratorPrototype.js:
613         (next):
614         * builtins/StringPrototype.js:
615         (match):
616         (globalPrivate.repeatSlowPath):
617         (repeat):
618         (padStart):
619         (padEnd):
620         (intrinsic.StringPrototypeReplaceIntrinsic.replace):
621         (localeCompare):
622         (search):
623         (split):
624         * builtins/TypedArrayConstructor.js:
625         (of):
626         (from):
627         * builtins/TypedArrayPrototype.js:
628         (globalPrivate.typedArraySpeciesConstructor):
629         (every):
630         (find):
631         (findIndex):
632         (forEach):
633         (some):
634         (subarray):
635         (reduce):
636         (reduceRight):
637         (map):
638         (filter):
639         * bytecode/BytecodeIntrinsicRegistry.h:
640         * bytecode/CodeBlock.cpp:
641         (JSC::CodeBlock::dumpBytecode):
642         * bytecompiler/BytecodeGenerator.cpp:
643         (JSC::BytecodeGenerator::emitThrowStaticError):
644         (JSC::BytecodeGenerator::emitThrowReferenceError):
645         (JSC::BytecodeGenerator::emitThrowTypeError):
646         (JSC::BytecodeGenerator::emitThrowRangeError):
647         (JSC::BytecodeGenerator::emitThrowOutOfMemoryError):
648         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
649         * bytecompiler/BytecodeGenerator.h:
650         * bytecompiler/NodesCodegen.cpp:
651         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
652         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
653         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwOutOfMemoryError):
654         * dfg/DFGAbstractInterpreterInlines.h:
655         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
656         * dfg/DFGByteCodeParser.cpp:
657         (JSC::DFG::ByteCodeParser::parseBlock):
658         * dfg/DFGClobberize.h:
659         (JSC::DFG::clobberize):
660         * dfg/DFGDoesGC.cpp:
661         (JSC::DFG::doesGC):
662         * dfg/DFGFixupPhase.cpp:
663         (JSC::DFG::FixupPhase::fixupNode):
664         * dfg/DFGNodeType.h:
665         * dfg/DFGPredictionPropagationPhase.cpp:
666         * dfg/DFGSafeToExecute.h:
667         (JSC::DFG::safeToExecute):
668         * dfg/DFGSpeculativeJIT32_64.cpp:
669         (JSC::DFG::SpeculativeJIT::compile):
670         * dfg/DFGSpeculativeJIT64.cpp:
671         (JSC::DFG::SpeculativeJIT::compile):
672         * ftl/FTLCapabilities.cpp:
673         (JSC::FTL::canCompile):
674         * ftl/FTLLowerDFGToB3.cpp:
675         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
676         * jit/JITOpcodes.cpp:
677         (JSC::JIT::emit_op_throw_static_error):
678         * jit/JITOpcodes32_64.cpp:
679         (JSC::JIT::emit_op_throw_static_error): Deleted.
680         * jit/JITOperations.cpp:
681         * jit/JITOperations.h:
682         * llint/LLIntSlowPaths.cpp:
683         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
684         * llint/LLIntSlowPaths.h:
685         * llint/LowLevelInterpreter.asm:
686         * runtime/CommonSlowPaths.cpp:
687         (JSC::SLOW_PATH_DECL):
688         * runtime/CommonSlowPaths.h:
689         * runtime/Error.cpp:
690         (JSC::createError):
691         (WTF::printInternal):
692         * runtime/Error.h:
693
694 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
695
696         Unreviewed, attempt to fix CLoop build after r206846
697         https://bugs.webkit.org/show_bug.cgi?id=162941
698
699         Attempt to fix CLoop build part 2. r206847 was not valid.
700
701         * jsc.cpp:
702
703 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
704
705         Unreviewed, build fix after r206846
706         https://bugs.webkit.org/show_bug.cgi?id=162941
707
708         DOMJIT::Patchpoint part should be guarded by ENABLE(JIT).
709
710         * jsc.cpp:
711
712 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
713
714         [DOMJIT] Add initial CheckDOM and CallDOM implementations
715         https://bugs.webkit.org/show_bug.cgi?id=162941
716
717         Reviewed by Filip Pizlo.
718
719         This patch implements a prototype of DOMJIT accelerated getter.
720         We add two new DFG nodes, CheckDOM and CallDOM.
721
722         CheckDOM is used to filter inappropriate |this| object for DOM getter. Its functionality
723         is equivalent to jsDynamicCast's Check. You can use like "CheckDOM, @1, JSNode::info()",
724         and this CheckDOM incurs a BadType exit if the class of the given @1 is not a subclass of
725         JSNode::info().
726
727         CallDOM is used to emit actual DOM operations. It takes GlobalObject and checked DOM
728         object. And it returns JSValue as its result.
729
730         Both CheckDOM and CallDOM can take a DOMJIT::Patchpoint. This is somewhat code snippet
731         generator, and is injectable to DFG and FTL. DFG and FTL set up registers correctly
732         according to DOMJIT::Patchpoint's requirement and invoke this patchpoint generator to emit code.
733         While CallDOM always requires a patchpoint, ideally CheckDOM does not require it since
734         isSubclassOf check can be implemented in DFG / FTL side. However, some classes have a
735         faster way to query isSubclassOf. For example, JSNode in WebCore introduces a special
736         JSType to optimize this query. CheckDOM's patchpoint gives us a chance to emit special
737         faster code for such a case.
738
739         By leveraging above nodes, we can construct DOMJIT accelerated getter. When DFG recognizes the
740         given getter call is CustomGetter and it has DOMJIT::GetterSetter information, DFG emits the above nodes.
741         We implemented a prototype in jsc.cpp shell as DOMJITGetter to test the functionality.
742
743         Notes about the future extensions.
744
745         1. Currently, we do not allow CallDOM to emit any function calls. This will be extended by
746            adding `addSlowPathCall` functionality to DOMJIT::Patchpoint later. Interesting thing is that
747            we need to create an abstraction over DFG slow path call and FTL slow path call!
748
749         2. CheckDOM is not handled in DFGTypeCheckHoistingPhase yet. And we have a chance to merge several CheckDOM into one.
750            For example, given CheckDOM A and CheckDOM B to the same target. If A is subclass of B, we can merge them to CheckDOM A.
751
752         * JavaScriptCore.xcodeproj/project.pbxproj:
753         * b3/B3Effects.h:
754         (JSC::B3::Effects::forCheck):
755         * b3/B3Value.cpp:
756         (JSC::B3::Value::effects):
757         * bytecode/GetByIdStatus.cpp:
758         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
759         (JSC::GetByIdStatus::makesCalls):
760         (JSC::GetByIdStatus::dump):
761         * bytecode/GetByIdStatus.h:
762         (JSC::GetByIdStatus::GetByIdStatus):
763         (JSC::GetByIdStatus::isCustom):
764         (JSC::GetByIdStatus::takesSlowPath):
765         (JSC::GetByIdStatus::isSimple): Deleted.
766         * bytecode/SpeculatedType.cpp:
767         (JSC::speculationFromClassInfo):
768         * dfg/DFGAbstractInterpreter.h:
769         (JSC::DFG::AbstractInterpreter::filterClassInfo):
770         * dfg/DFGAbstractInterpreterInlines.h:
771         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
772         (JSC::DFG::AbstractInterpreter<AbstractStateType>::filterClassInfo):
773         * dfg/DFGAbstractValue.cpp:
774         (JSC::DFG::AbstractValue::filterClassInfo):
775         * dfg/DFGAbstractValue.h:
776         * dfg/DFGByteCodeParser.cpp:
777         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
778         (JSC::DFG::ByteCodeParser::handleGetById):
779         * dfg/DFGClobberize.h:
780         (JSC::DFG::clobberize):
781         * dfg/DFGConstantFoldingPhase.cpp:
782         (JSC::DFG::ConstantFoldingPhase::foldConstants):
783         * dfg/DFGDoesGC.cpp:
784         (JSC::DFG::doesGC):
785         * dfg/DFGFixupPhase.cpp:
786         (JSC::DFG::FixupPhase::fixupNode):
787         * dfg/DFGNode.h:
788         (JSC::DFG::Node::hasHeapPrediction):
789         (JSC::DFG::Node::hasDOMJIT):
790         (JSC::DFG::Node::domJIT):
791         (JSC::DFG::Node::hasClassInfo):
792         (JSC::DFG::Node::classInfo):
793         (JSC::DFG::Node::OpInfoWrapper::OpInfoWrapper):
794         (JSC::DFG::Node::OpInfoWrapper::operator=):
795         * dfg/DFGNodeType.h:
796         * dfg/DFGOpInfo.h:
797         (JSC::DFG::OpInfo::OpInfo):
798         * dfg/DFGPredictionPropagationPhase.cpp:
799         * dfg/DFGSafeToExecute.h:
800         (JSC::DFG::safeToExecute):
801         * dfg/DFGSpeculativeJIT.cpp:
802         (JSC::DFG::allocateTemporaryRegistersForPatchpoint):
803         (JSC::DFG::SpeculativeJIT::compileCallDOM):
804         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
805         * dfg/DFGSpeculativeJIT.h:
806         * dfg/DFGSpeculativeJIT32_64.cpp:
807         (JSC::DFG::SpeculativeJIT::compile):
808         * dfg/DFGSpeculativeJIT64.cpp:
809         (JSC::DFG::SpeculativeJIT::compile):
810         * dfg/DFGStructureAbstractValue.cpp:
811         (JSC::DFG::StructureAbstractValue::filterClassInfoSlow):
812         (JSC::DFG::StructureAbstractValue::isSubClassOf):
813         * dfg/DFGStructureAbstractValue.h:
814         (JSC::DFG::StructureAbstractValue::filterClassInfo):
815         (JSC::DFG::StructureAbstractValue::filter): Deleted.
816         * domjit/DOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/dfg/DFGOpInfo.h.
817         (JSC::DOMJIT::PatchpointParams::~PatchpointParams):
818         (JSC::DOMJIT::PatchpointParams::size):
819         (JSC::DOMJIT::PatchpointParams::at):
820         (JSC::DOMJIT::PatchpointParams::operator[]):
821         (JSC::DOMJIT::PatchpointParams::gpScratch):
822         (JSC::DOMJIT::PatchpointParams::fpScratch):
823         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
824         * domjit/DOMJITReg.h: Added.
825         (JSC::DOMJIT::Reg::Reg):
826         (JSC::DOMJIT::Reg::isGPR):
827         (JSC::DOMJIT::Reg::isFPR):
828         (JSC::DOMJIT::Reg::isJSValueRegs):
829         (JSC::DOMJIT::Reg::gpr):
830         (JSC::DOMJIT::Reg::fpr):
831         (JSC::DOMJIT::Reg::jsValueRegs):
832         * ftl/FTLCapabilities.cpp:
833         (JSC::FTL::canCompile):
834         * ftl/FTLLowerDFGToB3.cpp:
835         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
836         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
837         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
838         (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable): Deleted.
839         * jit/AssemblyHelpers.h:
840         * jsc.cpp:
841         (WTF::DOMJITNode::DOMJITNode):
842         (WTF::DOMJITNode::createStructure):
843         (WTF::DOMJITNode::create):
844         (WTF::DOMJITNode::value):
845         (WTF::DOMJITNode::offsetOfValue):
846         (WTF::DOMJITGetter::DOMJITGetter):
847         (WTF::DOMJITGetter::createStructure):
848         (WTF::DOMJITGetter::create):
849         (WTF::DOMJITGetter::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
850         (WTF::DOMJITGetter::domJITNodeGetterSetter):
851         (WTF::DOMJITGetter::finishCreation):
852         (WTF::DOMJITGetter::customGetter):
853         (GlobalObject::finishCreation):
854         (functionCreateDOMJITNodeObject):
855         (functionCreateDOMJITGetterObject):
856
857 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
858
859         [JSC] Do not construct Simple GetByIdStatus against self-custom-accessor case
860         https://bugs.webkit.org/show_bug.cgi?id=162993
861
862         Reviewed by Filip Pizlo.
863
864         We accidentally created a Simple GetByIdStatus against self-custom-accessor case: the object has own custom accessor property and get_by_id hits.
865         If we returned such a result, the GetById will be turned to GetByOffset and it looks up incorrect thing like CustomGetterSetter object.
866         We do not hit this bug before since maybe there is no object that has own custom-accessor and this custom-accessor does not raise an error.
867         For example, "Node.prototype" has "firstChild" custom accessor. But since "Node.prototype" itself does not have Node::info(), "Node.prototype.firstChild"
868         access always raises an error. I guess all the custom accessors follow this pattern. This bug is uncovered when testing DOMJIT (This bug causes crash and
869         it can occur even if we disabled DOMJIT).
870
871         But such a assumption is not guaranteed. In this patch, we fix this by not returning Simple GetById.
872
873         * bytecode/GetByIdStatus.cpp:
874         (JSC::GetByIdStatus::computeFromLLInt):
875         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
876         (JSC::GetByIdStatus::computeFor):
877
878 2016-10-05  Saam Barati  <sbarati@apple.com>
879
880         PCToCodeOriginMap builder should use labelIgnoringWatchpoints() inside the DFG
881         https://bugs.webkit.org/show_bug.cgi?id=162936
882
883         Reviewed by Michael Saboff.
884
885         label() may insert nops because of an InvalidationPoint. It does that
886         because we don't want code that comes after an InvalidationPoint that isn't
887         effected by the invalidation point to be overwritten if we fire the
888         InvalidationPoint. PCToCodeOriginMap just grabs labels to build
889         a mapping, it never emits code that actually jumps to those labels.
890         Therefore, it should never cause us to emit nops.
891
892         * dfg/DFGJITCompiler.cpp:
893         (JSC::DFG::JITCompiler::compile):
894         (JSC::DFG::JITCompiler::compileFunction):
895         * dfg/DFGSpeculativeJIT.cpp:
896         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
897         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
898
899 2016-10-05  Myles C. Maxfield  <mmaxfield@apple.com>
900
901         Put variation fonts work behind a compile-time flag
902         https://bugs.webkit.org/show_bug.cgi?id=162949
903
904         Reviewed by Simon Fraser.
905
906         * Configurations/FeatureDefines.xcconfig:
907
908 2016-10-05  Andy VanWagoner  <thetalecrafter@gmail.com>
909
910         [INTL] Implement Intl.getCanonicalLocales
911         https://bugs.webkit.org/show_bug.cgi?id=162768
912
913         Reviewed by Benjamin Poulain.
914
915         Implement Intl.getCanonicalLocales from ECMA 402 (3rd edition)
916         http://ecma-international.org/ecma-402/3.0/index.html#sec-intl.getcanonicallocales
917
918         Reuse canonicalizeLocaleList and copy the results into a new JSArray.
919
920         * runtime/IntlObject.cpp:
921         (JSC::IntlObject::finishCreation):
922         (JSC::intlObjectFuncGetCanonicalLocales):
923
924 2016-10-05  Michael Saboff  <msaboff@apple.com>
925
926         Bad ASSERT in ClonedArguments::createByCopyingFrom()
927         https://bugs.webkit.org/show_bug.cgi?id=162988
928
929         Reviewed by Keith Miller.
930
931         Removed bogus assert.
932
933         * runtime/ClonedArguments.cpp:
934         (JSC::ClonedArguments::createByCopyingFrom):
935
936 2016-10-05  Zan Dobersek  <zdobersek@igalia.com>
937
938         Rename ENABLE_ENCRYPTED_MEDIA_V2 to ENABLE_LEGACY_ENCRYPTED_MEDIA
939         https://bugs.webkit.org/show_bug.cgi?id=162903
940
941         Reviewed by Alex Christensen.
942
943         Rename build guards for the remaining implementation of the legacy EME API
944         to ENABLE_LEGACY_ENCRYPTED_MEDIA. This will allow for the future implementation
945         of the near-finished API to be guarded with the simple ENABLE_ENCRYPTED_MEDIA guards.
946
947         * Configurations/FeatureDefines.xcconfig:
948
949 2016-10-05  Csaba Osztrogon√°c  <ossy@webkit.org>
950
951         ARM EABI buildfix after r206778
952         https://bugs.webkit.org/show_bug.cgi?id=162964
953
954         Unreviewed trivial fix.
955
956         * jit/CCallHelpers.h:
957         (JSC::CCallHelpers::setupArgumentsWithExecState):
958
959 2016-10-04  Saam Barati  <sbarati@apple.com>
960
961         String.prototype.toLowerCase should be a DFG/FTL intrinsic
962         https://bugs.webkit.org/show_bug.cgi?id=162887
963
964         Reviewed by Filip Pizlo and Yusuke Suzuki.
965
966         This patch makes ToLowerCase an intrinsic in the DFG/FTL. On the fast
967         path, the intrinsic will loop over an 8-bit string ensuring it's already
968         lower case, and simply return the string. In the slow path, it'll call
969         into C code to make a new string.
970
971         This is a 7-8% speedup on ES6SampleBench/Basic.
972
973         * dfg/DFGAbstractInterpreterInlines.h:
974         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
975         * dfg/DFGByteCodeParser.cpp:
976         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
977         * dfg/DFGClobberize.h:
978         (JSC::DFG::clobberize):
979         * dfg/DFGDoesGC.cpp:
980         (JSC::DFG::doesGC):
981         * dfg/DFGFixupPhase.cpp:
982         (JSC::DFG::FixupPhase::fixupNode):
983         * dfg/DFGNodeType.h:
984         * dfg/DFGOperations.cpp:
985         * dfg/DFGOperations.h:
986         * dfg/DFGPredictionPropagationPhase.cpp:
987         * dfg/DFGSafeToExecute.h:
988         (JSC::DFG::safeToExecute):
989         * dfg/DFGSpeculativeJIT.cpp:
990         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
991         * dfg/DFGSpeculativeJIT.h:
992         (JSC::DFG::SpeculativeJIT::callOperation):
993         * dfg/DFGSpeculativeJIT32_64.cpp:
994         (JSC::DFG::SpeculativeJIT::compile):
995         * dfg/DFGSpeculativeJIT64.cpp:
996         (JSC::DFG::SpeculativeJIT::compile):
997         * ftl/FTLAbstractHeapRepository.h:
998         * ftl/FTLCapabilities.cpp:
999         (JSC::FTL::canCompile):
1000         * ftl/FTLLowerDFGToB3.cpp:
1001         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1002         (JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
1003         * jit/JITOperations.h:
1004         * runtime/Intrinsic.h:
1005         * runtime/StringPrototype.cpp:
1006         (JSC::StringPrototype::finishCreation):
1007
1008 2016-10-04  Brian Burg  <bburg@apple.com>
1009
1010         Web Inspector: don't synchronously send a listing message if we might need to query _WKAutomationDelegate
1011         https://bugs.webkit.org/show_bug.cgi?id=162810
1012         <rdar://problem/28571460>
1013
1014         Reviewed by Timothy Hatcher.
1015
1016         We shouldn't ever access the _WKAutomationDelegate through RemoteInspector::Client methods
1017         off of the main thread, because it could cause problems. This happens when we pushListingsNow()
1018         in response to a WIRApplicationGetListingMessage XPC message. In this case, just use
1019         pushListingsSoon() since it dispatches on the correct (main) queue to gather listing information.
1020
1021         This may induce a slight update delay when first connecting to the UIProcess through RemoteInspector,
1022         but this is at most 200ms and will coalesce with other updates that happen when UIProcess gets set up.
1023
1024         There are no other code paths through RemoteInspector (for UIProcess) that could cause a call
1025         to pushListingsNow(), so this only needs to be changed in the XPC message handler.
1026
1027         * inspector/remote/RemoteInspector.mm:
1028         (Inspector::RemoteInspector::receivedGetListingMessage):
1029
1030 2016-10-04  JF Bastien  <jfbastien@apple.com>
1031
1032         WebAssembly: handle a few corner cases
1033         https://bugs.webkit.org/show_bug.cgi?id=162884
1034
1035         Reviewed by Keith Miller.
1036
1037         * wasm/JSWASMModule.cpp: missing include broke cmake build
1038         * wasm/WASMFunctionParser.h:
1039         (JSC::WASM::FunctionParser<Context>::parseBlock): check op is valid
1040         (JSC::WASM::FunctionParser<Context>::parseExpression): switch covers all cases
1041         * wasm/WASMOps.h:
1042         (JSC::WASM::isValidOpType): op is valid
1043         * wasm/WASMParser.h:
1044         (JSC::WASM::Parser::consumeString): avoid str[i] being one-past-the-end
1045         (JSC::WASM::Parser::parseUInt32): shift math around to avoid overflow
1046
1047 2016-10-04  Yusuke Suzuki  <utatane.tea@gmail.com>
1048
1049         REGRESSION (r206778): Release JSC test ChakraCore.yaml/ChakraCore/test/Error/validate_line_column.js.default failing
1050         https://bugs.webkit.org/show_bug.cgi?id=162937
1051
1052         Reviewed by Saam Barati.
1053
1054         We dropped expression info accidentally at r206777.
1055
1056         * bytecompiler/BytecodeGenerator.cpp:
1057         (JSC::BytecodeGenerator::emitCallDefineProperty):
1058         * bytecompiler/BytecodeGenerator.h:
1059         * bytecompiler/NodesCodegen.cpp:
1060         (JSC::PropertyListNode::emitPutConstantProperty):
1061         (JSC::ClassExprNode::emitBytecode):
1062
1063 2016-10-04  Yusuke Suzuki  <utatane.tea@gmail.com>
1064
1065         [DOMJIT] Introduce DOMJIT::GetterSetter to tell JIT information
1066         https://bugs.webkit.org/show_bug.cgi?id=162916
1067
1068         Reviewed by Filip Pizlo.
1069
1070         In this patch, we introduce DOMJIT::GetterSetter.
1071         This class maintains information required to emit JIT code in DFG and FTL.
1072         DOMJIT::GetterSetter has 2 virtual functions: checkDOM and callDOM.
1073         These functions can return a DOMJIT::Patchpoint that allows us to inject
1074         appropriate machine code during DFG and FTL phases. DFG and FTL will invoke
1075         these functions to get a patchpoint. And this patchpoint will be used to
1076         emit code corresponding to CheckDOM and CallDOM DFG nodes, which will be added
1077         in subsqeunt patch.
1078
1079         We propagate DOMJIT::GetterSetter through PropertySlot, AccessCase, GetByIdVariant,
1080         and GetByIdStatus along with CustomGetter to teach DFG that this custom access
1081         code has a chance to be inlined with this DOMJIT::GetterSetter information.
1082         Instead of propagating CustomGetterSetter holding DOMJIT::GetterSetter and CustomGetter,
1083         we propagate CustomGetter and DOMJIT::GetterSetter. This is because of the current
1084         CustomGetterSetter design that we reify CustomGetterSetters only when we need to reify
1085         all the properties. This design allows us to avoid frequent CustomGetterSetter allocations
1086         and structure transitions.
1087
1088         Currently, domJIT field is always nullptr since there is no DOMJITAttribute user.
1089         When we add this, we will add code handling this DOMJIT::GetterSetter in DFG::ByteCodeParser.
1090
1091         * CMakeLists.txt:
1092         * JavaScriptCore.xcodeproj/project.pbxproj:
1093         * bytecode/GetByIdStatus.cpp:
1094         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
1095         * bytecode/GetByIdVariant.cpp:
1096         (JSC::GetByIdVariant::GetByIdVariant):
1097         (JSC::GetByIdVariant::operator=):
1098         (JSC::GetByIdVariant::attemptToMerge):
1099         (JSC::GetByIdVariant::dumpInContext):
1100         * bytecode/GetByIdVariant.h:
1101         (JSC::GetByIdVariant::domJIT):
1102         (JSC::GetByIdVariant::intrinsic): Deleted.
1103         * bytecode/PolymorphicAccess.cpp:
1104         (JSC::AccessCase::get):
1105         (JSC::AccessCase::clone):
1106         * bytecode/PolymorphicAccess.h:
1107         (JSC::AccessCase::domJIT):
1108         (JSC::AccessCase::RareData::RareData):
1109         * dfg/DFGNode.h:
1110         * domjit/DOMJITGetterSetter.h: Added.
1111         (JSC::DOMJIT::GetterSetter::GetterSetter):
1112         (JSC::DOMJIT::GetterSetter::~GetterSetter):
1113         (JSC::DOMJIT::GetterSetter::getter):
1114         (JSC::DOMJIT::GetterSetter::setter):
1115         (JSC::DOMJIT::GetterSetter::thisClassInfo):
1116         * domjit/DOMJITPatchpoint.h: Added.
1117         (JSC::DOMJIT::Patchpoint::create):
1118         (JSC::DOMJIT::Patchpoint::setGenerator):
1119         (JSC::DOMJIT::Patchpoint::generator):
1120         * jit/Repatch.cpp:
1121         (JSC::tryCacheGetByID):
1122         * runtime/CustomGetterSetter.h:
1123         * runtime/JSObject.h:
1124         (JSC::JSObject::fillCustomGetterPropertySlot):
1125         * runtime/Lookup.h:
1126         (JSC::HashTableValue::domJIT):
1127         (JSC::getStaticPropertySlotFromTable):
1128         (JSC::putEntry):
1129         (JSC::reifyStaticProperty):
1130         * runtime/PropertySlot.h:
1131         (JSC::PropertySlot::domJIT):
1132         (JSC::PropertySlot::setCacheableCustom):
1133
1134 2016-09-27  Yusuke Suzuki  <utatane.tea@gmail.com>
1135
1136         [JSC] Add a new byte code op_define_property instead of calling defineProperty
1137         https://bugs.webkit.org/show_bug.cgi?id=162108
1138
1139         Reviewed by Saam Barati.
1140
1141         To construct ES6 class, we emitted bytecode that performs the following operations.
1142
1143             1. construct a new object
1144             2. put "configurable", "enumerable" etc. fields
1145             3. call "defineProperty" function
1146
1147         However, this approach has problems. Every time we define a class method, we need to create
1148         a new object to represent property descriptor. This can be removed if we can introduce
1149         a special bytecode or special function.
1150
1151         This patch introduces new bytecodes, op_define_data_property and op_define_accessor_property.
1152         Instead of taking an object, they takes several registers to avoid object allocations.
1153         We're planning to use this bytecode to implement Object.defineProperty in builtin JS next.
1154         This allows us to leverage object allocation sinking. And it also gives us a chance to use
1155         faster ::get and ::hasProperty in JS.
1156
1157         Originally, I attempted to create one bytecode, op_define_property. However, it takes too many
1158         children in DFG and uses so many registers in DFG. This leads tricky program in 32bit platforms.
1159         Furthermore, it does not fit to the number of x64 argument registers. So instead, we introduce
1160         two bytecodes.
1161
1162         And for op_define_accessor_property, we perform CellUse edge filter to getter and setter children.
1163         This edge filter makes us possible to use SpeculateCellOperand and reduce the number of used registers
1164         in comparison with JSValueOperand. To make children Cells even if we do not specify some accessors (for
1165         example, { get: func, set: null } case), we fill registers with special throwTypeErrorFunction.
1166         The attributes bitset keep information like "This property descriptor only has getter slot".
1167
1168         In these two bytecodes, we take attributes (configurable, enumerable, writable, hasGetter etc.) as
1169         register instead of embedding constant int value because we will use these bytecodes to implement
1170         Object.defineProperty next. In Object.defineProperty case, an attributes are not statically defined
1171         at bytecode compiling time.
1172
1173         Run ES6SampleBench/Air 20 times. The result shows ~2% performance improvement.
1174
1175         Baseline:
1176             firstIteration:     84.05 ms +- 4.37 ms
1177             averageWorstCase:   40.54 ms +- 2.81 ms
1178             steadyState:        3317.49 ms +- 48.25 ms
1179             summary:            223.51 ms +- 5.07 ms
1180
1181         Patched:
1182             firstIteration:     84.46 ms +- 4.22 ms
1183             averageWorstCase:   41.48 ms +- 2.33 ms
1184             steadyState:        3253.48 ms +- 29.31 ms
1185             summary:            224.40 ms +- 4.72 ms
1186
1187         * JavaScriptCore.xcodeproj/project.pbxproj:
1188         * bytecode/BytecodeList.json:
1189         * bytecode/BytecodeUseDef.h:
1190         (JSC::computeUsesForBytecodeOffset):
1191         (JSC::computeDefsForBytecodeOffset):
1192         * bytecode/CodeBlock.cpp:
1193         (JSC::CodeBlock::dumpBytecode):
1194         * bytecode/SpecialPointer.h:
1195         * bytecompiler/BytecodeGenerator.cpp:
1196         (JSC::BytecodeGenerator::emitMoveLinkTimeConstant):
1197         (JSC::BytecodeGenerator::emitCallDefineProperty):
1198         * bytecompiler/BytecodeGenerator.h:
1199         * bytecompiler/NodesCodegen.cpp:
1200         (JSC::PropertyListNode::emitPutConstantProperty):
1201         (JSC::BitwiseNotNode::emitBytecode):
1202         (JSC::ClassExprNode::emitBytecode):
1203         (JSC::ObjectPatternNode::bindValue):
1204         * dfg/DFGAbstractInterpreterInlines.h:
1205         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1206         * dfg/DFGByteCodeParser.cpp:
1207         (JSC::DFG::ByteCodeParser::parseBlock):
1208         * dfg/DFGCapabilities.cpp:
1209         (JSC::DFG::capabilityLevel):
1210         * dfg/DFGClobberize.h:
1211         (JSC::DFG::clobberize):
1212         * dfg/DFGDoesGC.cpp:
1213         (JSC::DFG::doesGC):
1214         * dfg/DFGFixupPhase.cpp:
1215         (JSC::DFG::FixupPhase::fixupNode):
1216         * dfg/DFGNodeType.h:
1217         * dfg/DFGOperations.cpp:
1218         * dfg/DFGOperations.h:
1219         * dfg/DFGPredictionPropagationPhase.cpp:
1220         * dfg/DFGSafeToExecute.h:
1221         (JSC::DFG::safeToExecute):
1222         * dfg/DFGSpeculativeJIT.cpp:
1223         (JSC::DFG::SpeculativeJIT::compileDefineDataProperty):
1224         (JSC::DFG::SpeculativeJIT::compileDefineAccessorProperty):
1225         * dfg/DFGSpeculativeJIT.h:
1226         (JSC::DFG::SpeculativeJIT::callOperation):
1227         * dfg/DFGSpeculativeJIT32_64.cpp:
1228         (JSC::DFG::SpeculativeJIT::compile):
1229         * dfg/DFGSpeculativeJIT64.cpp:
1230         (JSC::DFG::SpeculativeJIT::compile):
1231         * ftl/FTLCapabilities.cpp:
1232         (JSC::FTL::canCompile):
1233         * ftl/FTLLowerDFGToB3.cpp:
1234         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1235         (JSC::FTL::DFG::LowerDFGToB3::compileDefineDataProperty):
1236         (JSC::FTL::DFG::LowerDFGToB3::compileDefineAccessorProperty):
1237         (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis): Deleted.
1238         * jit/CCallHelpers.cpp:
1239         (JSC::CCallHelpers::setupFourStubArgsGPR): Deleted.
1240         * jit/CCallHelpers.h:
1241         (JSC::CCallHelpers::setupFourStubArgsGPR):
1242         (JSC::CCallHelpers::setupFiveStubArgsGPR):
1243         (JSC::CCallHelpers::setupArgumentsWithExecState):
1244         (JSC::CCallHelpers::setupStubArgsGPR):
1245         (JSC::CCallHelpers::prepareForTailCallSlow): Deleted.
1246         * jit/JIT.cpp:
1247         (JSC::JIT::privateCompileMainPass):
1248         * jit/JIT.h:
1249         * jit/JITOperations.h:
1250         * jit/JITPropertyAccess.cpp:
1251         (JSC::JIT::emit_op_define_data_property):
1252         (JSC::JIT::emit_op_define_accessor_property):
1253         * llint/LowLevelInterpreter.asm:
1254         * runtime/CommonSlowPaths.cpp:
1255         (JSC::SLOW_PATH_DECL):
1256         * runtime/CommonSlowPaths.h:
1257         * runtime/DefinePropertyAttributes.h: Added.
1258         (JSC::DefinePropertyAttributes::DefinePropertyAttributes):
1259         (JSC::DefinePropertyAttributes::rawRepresentation):
1260         (JSC::DefinePropertyAttributes::hasValue):
1261         (JSC::DefinePropertyAttributes::setValue):
1262         (JSC::DefinePropertyAttributes::hasGet):
1263         (JSC::DefinePropertyAttributes::setGet):
1264         (JSC::DefinePropertyAttributes::hasSet):
1265         (JSC::DefinePropertyAttributes::setSet):
1266         (JSC::DefinePropertyAttributes::writable):
1267         (JSC::DefinePropertyAttributes::configurable):
1268         (JSC::DefinePropertyAttributes::enumerable):
1269         (JSC::DefinePropertyAttributes::setWritable):
1270         (JSC::DefinePropertyAttributes::setConfigurable):
1271         (JSC::DefinePropertyAttributes::setEnumerable):
1272         (JSC::DefinePropertyAttributes::fillWithTriState):
1273         (JSC::DefinePropertyAttributes::extractTriState):
1274         * runtime/JSGlobalObject.cpp:
1275         (JSC::JSGlobalObject::init):
1276         (JSC::JSGlobalObject::visitChildren):
1277         * runtime/JSGlobalObject.h:
1278         (JSC::JSGlobalObject::throwTypeErrorFunction):
1279         (JSC::JSGlobalObject::definePropertyFunction): Deleted.
1280         * runtime/ObjectConstructor.cpp:
1281         (JSC::ObjectConstructor::addDefineProperty): Deleted.
1282         * runtime/ObjectConstructor.h:
1283         * runtime/PropertyDescriptor.h:
1284         (JSC::toPropertyDescriptor):
1285
1286 2016-10-04  Saam Barati  <sbarati@apple.com>
1287
1288         Follow up fix to GetMapBucket and MapHash speculating on child node types.
1289         To fix this, on 32-bit platforms, we do not speculate on the child
1290         type since we just call into C code for these nodes.
1291
1292         * dfg/DFGFixupPhase.cpp:
1293         (JSC::DFG::FixupPhase::fixupNode):
1294
1295 2016-10-03  Saam Barati  <sbarati@apple.com>
1296
1297         GetMapBucket node should speculate on the type of its 'key' child
1298         https://bugs.webkit.org/show_bug.cgi?id=161638
1299
1300         Reviewed by Filip Pizlo.
1301
1302         This eliminates type-check branches when we've already
1303         proven the type of the incoming key. Also, it reduces
1304         the branches we emit when type checking the bucket's key.
1305
1306         This is a 2-3% speedup on ES6SampleBench/Basic.
1307
1308         * dfg/DFGFixupPhase.cpp:
1309         (JSC::DFG::FixupPhase::fixupNode):
1310         * dfg/DFGSpeculativeJIT64.cpp:
1311         (JSC::DFG::SpeculativeJIT::compile):
1312         * ftl/FTLLowerDFGToB3.cpp:
1313         (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
1314
1315 2016-10-03  Christopher Reid  <Christopher.Reid@am.sony.com>
1316
1317         Offline asm should not output masm assembly when using a x86_64 asm backend
1318         https://bugs.webkit.org/show_bug.cgi?id=162705
1319
1320         When cross compiling on windows to Clang, masm was being generated simply because
1321         the os was windows. This change adds a command line parameter --assembler=MASM
1322         to set the output assembly to masm.
1323         The functions isGCC and isCompilingToWindows were removed as they are no longer called.
1324
1325         Reviewed by Mark Lam.
1326
1327         * CMakeLists.txt:
1328         * offlineasm/asm.rb:
1329         * offlineasm/x86.rb:
1330
1331 2016-10-03  JF Bastien  <jfbastien@apple.com>
1332
1333         Auto-generate WASMOps.h, share with testing JSON file
1334         https://bugs.webkit.org/show_bug.cgi?id=162870
1335
1336         Reviewed by Keith Miller.
1337
1338         Add a few new opcodes, but keep this mostly as-is for now. I want
1339         to generate smarter code but will do so in a later update to
1340         reduce disruption.
1341
1342         * wasm/WASMOps.h: auto-generated from ./JSTests/stress/wasm/to-c++.js
1343
1344 2016-10-03  Michael Saboff  <msaboff@apple.com>
1345
1346         Creating pcToOriginMap in FTL shouldn't insert unnecessary NOPs
1347         https://bugs.webkit.org/show_bug.cgi?id=162879
1348
1349         Reviewed by Filip Pizlo.
1350
1351         If there is a recent watchpoint label, using MacroAssembler::label() will pad
1352         the instruction stream with NOPs to provide space for a jump.  This changes
1353         Air::generate() to use labelIgnoringWatchpoints() to create pcToOriginMap
1354         entries to eliminate unneccesary NOPs.
1355         
1356         * b3/air/AirGenerate.cpp:
1357         (JSC::B3::Air::generate):
1358         * b3/testb3.cpp:
1359         (JSC::B3::testPCOriginMapDoesntInsertNops): New test.
1360         (JSC::B3::run):
1361
1362 2016-10-03  Saam Barati  <sbarati@apple.com>
1363
1364         MapHash should speculate on the type of its child node
1365         https://bugs.webkit.org/show_bug.cgi?id=161922
1366
1367         Reviewed by Filip Pizlo.
1368
1369         This allows us to remove runtime type checks when we've already
1370         proven the type of the incoming value.
1371
1372         This is a 2-3% speedup on ES6SampleBench/Basic.
1373
1374         * dfg/DFGFixupPhase.cpp:
1375         (JSC::DFG::FixupPhase::fixupNode):
1376         * dfg/DFGSpeculativeJIT64.cpp:
1377         (JSC::DFG::SpeculativeJIT::compile):
1378         * ftl/FTLLowerDFGToB3.cpp:
1379         (JSC::FTL::DFG::LowerDFGToB3::wangsInt64Hash):
1380         (JSC::FTL::DFG::LowerDFGToB3::mapHashString):
1381         (JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
1382
1383 2016-10-03  Filip Pizlo  <fpizlo@apple.com>
1384
1385         B3 trapping memory accesses should be documented
1386         https://bugs.webkit.org/show_bug.cgi?id=162845
1387
1388         Reviewed by Geoffrey Garen.
1389         
1390         While writing some documentation, I found some small holes in the code.
1391
1392         * b3/B3Effects.cpp:
1393         (JSC::B3::Effects::operator==): Need this to write tests.
1394         (JSC::B3::Effects::operator!=): Need this to write tests.
1395         * b3/B3Effects.h:
1396         * b3/B3HeapRange.h:
1397         * b3/B3MemoryValue.cpp:
1398         (JSC::B3::MemoryValue::dumpMeta): Sometimes the heap range dump won't show you the memory value's actual range. This makes the dump show you the actual range in that case.
1399         * b3/B3Value.cpp:
1400         (JSC::B3::Value::effects): While documenting this, I remembered that trapping also has to imply reading top. I fixed this.
1401         * b3/testb3.cpp:
1402         (JSC::B3::testTrappingLoad): Added checks for the effects of trapping loads.
1403         (JSC::B3::testTrappingStore): Added checks for the effects of trapping stores.
1404         (JSC::B3::testMoveConstants): Made this not crash with validation.
1405
1406 2016-10-03  Yusuke Suzuki  <utatane.tea@gmail.com>
1407
1408         [ES6] GeneratorFunction (a.k.a. GeneratorWrapperFunction)'s prototype object does not have constructor property
1409         https://bugs.webkit.org/show_bug.cgi?id=162849
1410
1411         Reviewed by Geoffrey Garen.
1412
1413         Since GeneratorFunction is not constructible, GeneratorFunction.prototype does not have "constructor" property.
1414
1415             function* generatorFunction() { }
1416             generatorFunction.prototype.constructor // undefined
1417
1418         * runtime/JSFunction.cpp:
1419         (JSC::JSFunction::getOwnPropertySlot):
1420
1421 2016-10-03  Nicolas Breidinger  <Nicolas.Breidinger@sony.com>
1422
1423         JSStringRef should define JSChar without platform checks
1424         https://bugs.webkit.org/show_bug.cgi?id=162808
1425
1426         Reviewed by Mark Lam.
1427
1428         * API/JSStringRef.h:
1429
1430 2016-10-01  Yusuke Suzuki  <utatane.tea@gmail.com>
1431
1432         [ES6] Align attributes of Generator related properties to spec
1433         https://bugs.webkit.org/show_bug.cgi?id=162839
1434
1435         Reviewed by Saam Barati.
1436
1437         This patch fixes attributes of Generator related properties.
1438         These fixes are covered by test262.
1439
1440         * runtime/GeneratorFunctionConstructor.cpp:
1441         (JSC::GeneratorFunctionConstructor::finishCreation):
1442         * runtime/GeneratorFunctionConstructor.h:
1443         * runtime/GeneratorFunctionPrototype.cpp:
1444         (JSC::GeneratorFunctionPrototype::finishCreation):
1445         * runtime/GeneratorFunctionPrototype.h:
1446         * runtime/GeneratorPrototype.h:
1447         * runtime/JSGlobalObject.cpp:
1448         (JSC::JSGlobalObject::init):
1449
1450 2016-10-01  Yusuke Suzuki  <utatane.tea@gmail.com>
1451
1452         [ES6] GeneratorFunction constructor should instantiate generator function
1453         https://bugs.webkit.org/show_bug.cgi?id=162838
1454
1455         Reviewed by Saam Barati.
1456
1457         GeneratorFunction's constructor should return an instance of JSGeneratorFunction
1458         instead of JSFunction. In this patch, we fix the following 2 things.
1459
1460         1. GeneratorFunction constructor should use JSGeneratorFunction
1461
1462             Previously, we used JSFunction to construct a result. It's wrong. We use JSGeneratorFunction.
1463
1464         2. Pass newTarget into GeneratorFunction constructor to make it subclassible
1465
1466             We did not leverage newTarget when using GeneratorFunction constructor.
1467             Using it correctly to create the subclass Structure and making GeneratorFunction subclassible.
1468
1469         Test262 test covers (1), but (2) is not covered. We add tests that covers both to stress tests.
1470
1471         * runtime/FunctionConstructor.cpp:
1472         (JSC::constructFunctionSkippingEvalEnabledCheck):
1473         * runtime/GeneratorFunctionConstructor.cpp:
1474         (JSC::constructGeneratorFunctionConstructor):
1475         * runtime/JSGeneratorFunction.cpp:
1476         (JSC::JSGeneratorFunction::JSGeneratorFunction):
1477         (JSC::JSGeneratorFunction::createImpl):
1478         (JSC::JSGeneratorFunction::create):
1479         (JSC::JSGeneratorFunction::createWithInvalidatedReallocationWatchpoint):
1480         * runtime/JSGeneratorFunction.h:
1481
1482 2016-10-01  Filip Pizlo  <fpizlo@apple.com>
1483
1484         Get rid of isMarkedOrNewlyAllocated
1485         https://bugs.webkit.org/show_bug.cgi?id=162842
1486
1487         Reviewed by Dan Bernstein.
1488         
1489         This function has become dead code. This change removes it.
1490
1491         * heap/CellContainer.h:
1492         * heap/CellContainerInlines.h:
1493         (JSC::CellContainer::isMarkedOrNewlyAllocated): Deleted.
1494         * heap/LargeAllocation.h:
1495         (JSC::LargeAllocation::isLive):
1496         (JSC::LargeAllocation::isMarkedOrNewlyAllocated): Deleted.
1497         * heap/MarkedBlock.cpp:
1498         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated): Deleted.
1499         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Deleted.
1500         * heap/MarkedBlock.h:
1501         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated): Deleted.
1502         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Deleted.
1503
1504 2016-10-01  Joseph Pecoraro  <pecoraro@apple.com>
1505
1506         Rename DebugHookID to DebugHookType
1507         https://bugs.webkit.org/show_bug.cgi?id=162820
1508
1509         Reviewed by Alex Christensen.
1510
1511         * bytecode/CodeBlock.cpp:
1512         (JSC::debugHookName):
1513         (JSC::CodeBlock::dumpBytecode):
1514         * bytecompiler/BytecodeGenerator.cpp:
1515         (JSC::BytecodeGenerator::emitDebugHook):
1516         * bytecompiler/BytecodeGenerator.h:
1517         * interpreter/Interpreter.cpp:
1518         (JSC::Interpreter::debug):
1519         * interpreter/Interpreter.h:
1520         * jit/JITOperations.cpp:
1521         * llint/LLIntSlowPaths.cpp:
1522         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1523
1524 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
1525
1526         Web Inspector: Stepping to a line with an autoContinue breakpoint should still pause
1527         https://bugs.webkit.org/show_bug.cgi?id=161712
1528         <rdar://problem/28193970>
1529
1530         Reviewed by Brian Burg.
1531
1532         * debugger/Debugger.cpp:
1533         (JSC::Debugger::pauseIfNeeded):
1534         If we stepped to an auto-continue breakpoint we should continue
1535         stepping, not just continue.
1536
1537 2016-09-30  Filip Pizlo  <fpizlo@apple.com>
1538
1539         B3 should support trapping memory accesses
1540         https://bugs.webkit.org/show_bug.cgi?id=162689
1541
1542         Reviewed by Geoffrey Garen.
1543         
1544         This adds a traps flag to B3::Kind. It also makes B3::Kind work more like Air::Kind, in the
1545         sense that it's a bag of distinct bits - it doesn't need to be a union unless we get enough
1546         things that it would make a difference.
1547         
1548         The only analysis that needs to know about traps is effects. It now knows that traps implies
1549         sideExits, which means that this turns off DCE. The only optimization that needs to know
1550         about traps is eliminateCommonSubexpressions(), which needs to pessimize its store
1551         elimination if the store traps.
1552         
1553         The hard part of this change is teaching the instruction selector to faithfully carry the
1554         traps flag down to Air. I got this to work by making ArgPromise a non-copyable object that
1555         knows whether you've used it in an instruction. It knows when you call consume(). If you do
1556         this then ArgPromise cannot be destructed without first passing your inst through it. This,
1557         along with a few other hacks, means that all of the load-op and load-op-store fusions
1558         correctly carry the trap bit: if any of the B3 loads or stores involved traps then you get
1559         traps in Air.
1560         
1561         This framework also sets us up to do bug 162688, since the ArgPromise::inst() hook is
1562         powerful enough to allow wrapping the instruction with a Patch.
1563         
1564         I added some tests to testb3 that verify that optimizations are appropriately inhibited and
1565         that the traps flag survives until the bitter end of Air.
1566
1567         * b3/B3EliminateCommonSubexpressions.cpp:
1568         * b3/B3Kind.cpp:
1569         (JSC::B3::Kind::dump):
1570         * b3/B3Kind.h:
1571         (JSC::B3::Kind::Kind):
1572         (JSC::B3::Kind::hasExtraBits):
1573         (JSC::B3::Kind::isChill):
1574         (JSC::B3::Kind::setIsChill):
1575         (JSC::B3::Kind::hasTraps):
1576         (JSC::B3::Kind::traps):
1577         (JSC::B3::Kind::setTraps):
1578         (JSC::B3::Kind::operator==):
1579         (JSC::B3::Kind::hash):
1580         (JSC::B3::trapping):
1581         * b3/B3LowerToAir.cpp:
1582         (JSC::B3::Air::LowerToAir::ArgPromise::swap):
1583         (JSC::B3::Air::LowerToAir::ArgPromise::ArgPromise):
1584         (JSC::B3::Air::LowerToAir::ArgPromise::operator=):
1585         (JSC::B3::Air::LowerToAir::ArgPromise::~ArgPromise):
1586         (JSC::B3::Air::LowerToAir::ArgPromise::setTraps):
1587         (JSC::B3::Air::LowerToAir::ArgPromise::consume):
1588         (JSC::B3::Air::LowerToAir::ArgPromise::inst):
1589         (JSC::B3::Air::LowerToAir::trappingInst):
1590         (JSC::B3::Air::LowerToAir::loadPromiseAnyOpcode):
1591         (JSC::B3::Air::LowerToAir::appendUnOp):
1592         (JSC::B3::Air::LowerToAir::appendBinOp):
1593         (JSC::B3::Air::LowerToAir::tryAppendStoreUnOp):
1594         (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
1595         (JSC::B3::Air::LowerToAir::appendStore):
1596         (JSC::B3::Air::LowerToAir::append):
1597         (JSC::B3::Air::LowerToAir::createGenericCompare):
1598         (JSC::B3::Air::LowerToAir::createBranch):
1599         (JSC::B3::Air::LowerToAir::createCompare):
1600         (JSC::B3::Air::LowerToAir::createSelect):
1601         (JSC::B3::Air::LowerToAir::lower):
1602         * b3/B3Validate.cpp:
1603         * b3/B3Value.cpp:
1604         (JSC::B3::Value::effects):
1605         * b3/B3Value.h:
1606         * b3/air/AirCode.h:
1607         * b3/testb3.cpp:
1608         (JSC::B3::testTrappingLoad):
1609         (JSC::B3::testTrappingStore):
1610         (JSC::B3::testTrappingLoadAddStore):
1611         (JSC::B3::testTrappingLoadDCE):
1612         (JSC::B3::testTrappingStoreElimination):
1613         (JSC::B3::run):
1614
1615 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
1616
1617         Web Inspector: Stepping over/out of a function sometimes resumes instead of taking you to caller
1618         https://bugs.webkit.org/show_bug.cgi?id=162802
1619         <rdar://problem/28569982>
1620
1621         Reviewed by Mark Lam.
1622
1623         * debugger/Debugger.cpp:
1624         (JSC::Debugger::stepOverStatement):
1625         (JSC::Debugger::stepOutOfFunction):
1626         Enable stepping mode when we start stepping.
1627
1628 2016-09-30  Filip Pizlo  <fpizlo@apple.com>
1629
1630         B3::moveConstants should be able to edit code to minimize the number of constants
1631         https://bugs.webkit.org/show_bug.cgi?id=162764
1632
1633         Reviewed by Saam Barati.
1634         
1635         There are some interesting cases where we can reduce the number of constant materializations if
1636         we teach moveConstants() how to edit code. The two examples that this patch supports are:
1637         
1638             - Loads and stores from a constant pointer. Since loads and stores get an offset for free
1639               and the instruction selector is really good at handling it, and since we can query Air to
1640               see what kinds of offsets are legal, we can sometimes avoid using a constant pointer that
1641               is specific to the absolute address of that load and instead pick some other constant
1642               that is within offset distance of ours.
1643             
1644             - Add and Sub by a constant (x + c, x - c). Since x + c = x - -c and x - c = x + -c, we can
1645               flip Add to Sub or vice versa if the negated constant is available.
1646         
1647         This change makes moveConstants() pick the most dominant constant that works for an value. In
1648         the case of memory accesses, it uses Air::Arg::isValidAddrForm() to work out what other
1649         constants would work. In the case of Add/Sub, it simply looks for the negated constant. This
1650         should result in something like a minimal number of constants since these rules always pick the
1651         most dominant constant that works - so if an Add's constant is already most dominant then
1652         nothing changes, but if the negated one is more dominant then it becomes a Sub.
1653         
1654         This is a 0.5% speed-up on LongSpider and neutral elsewhere. It's a speed-up because the
1655         absolute address thing reduces the number of address materializations that we have to do, while
1656         the add/sub thing prevents us from having to materialize 0x1000000000000 to box doubles.
1657         However, this may introduce a pathology, which I've filed a bug for: bug 162796.
1658
1659         * b3/B3MoveConstants.cpp:
1660         * b3/B3MoveConstants.h:
1661         * b3/B3UseCounts.h:
1662         * b3/air/AirFixObviousSpills.cpp:
1663         * b3/testb3.cpp:
1664         (JSC::B3::testMoveConstants):
1665         (JSC::B3::run):
1666
1667 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
1668
1669         Fix modules tests after r206653 handle breakpoint locations in import/export statements
1670         https://bugs.webkit.org/show_bug.cgi?id=162807
1671
1672         Reviewed by Mark Lam.
1673
1674         * parser/ASTBuilder.h:
1675         (JSC::ASTBuilder::createExportDefaultDeclaration):
1676         (JSC::ASTBuilder::createExportLocalDeclaration):
1677         Don't record an extra breakpoint location for the statement
1678         within an export statement.
1679
1680         * parser/Parser.cpp:
1681         (JSC::Parser<LexerType>::parseModuleSourceElements):
1682         Record a pause location for import/export statements.
1683
1684 2016-09-30  Mark Lam  <mark.lam@apple.com>
1685
1686         Remove the dumping of the stack back trace in VM::verifyExceptionCheckNeedIsSatisfied().
1687         https://bugs.webkit.org/show_bug.cgi?id=162797
1688
1689         Reviewed by Geoffrey Garen.
1690
1691         This is because the RELEASE_ASSERT() that follows immediately after will also
1692         dump the stack back trace.  Hence, the first dump will be redundant.
1693
1694         Also removed an extra space in the dataLog output.
1695
1696         * runtime/VM.cpp:
1697         (JSC::VM::verifyExceptionCheckNeedIsSatisfied):
1698
1699 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
1700
1701         Web Inspector: Stepping through `a(); b(); c();` it is unclear where we are and what is about to execute
1702         https://bugs.webkit.org/show_bug.cgi?id=161658
1703         <rdar://problem/28181254>
1704
1705         Reviewed by Geoffrey Garen.
1706
1707         * parser/Parser.cpp:
1708         (JSC::Parser<LexerType>::parseAssignmentExpression):
1709         Updated pause location for unary expressions.
1710
1711 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
1712
1713         Breakpoints on blank lines or comments don't break
1714         https://bugs.webkit.org/show_bug.cgi?id=9885
1715         <rdar://problem/6134406>
1716
1717         Reviewed by Mark Lam.
1718
1719         This change introduces a way to perform a Debugger Parse of a script.
1720         This debugger parse gathers a list of breakpoint locations, which
1721         the backend uses to resolve breakpoint locations that came from the
1722         Inspector frontend to the exact location we would actually pause.
1723         We gather this information from the parser so that we can eagerly
1724         get this information without requiring the code to have executed (the
1725         real op_debugs are generated during bytecode generation when code
1726         is actually evaluated).
1727
1728         If an input location was on a line with whitespace or a comment, the
1729         resolved breakpoint location would be before the next statement that
1730         will be executed. That may be the next line, or even later. We also
1731         update our policy when setting breakpoints on and around function
1732         statements to better match user expectations.
1733
1734         For example, when resolving breakpoints in:
1735
1736             1.  // Comment
1737             2.  before;
1738             3.
1739             4.  function foo() {
1740             5.      inside;
1741             6.  }
1742             7.
1743             8.  after;
1744
1745         A breakpoint on line 1, a comment, resolves to line 2 the next
1746         statement that will execute.
1747
1748         A breakpoint on line 3 or 7, empty lines, resolves to line 8 the next
1749         statement that will execute. This skips past the definition of foo,
1750         just like stepping would have done. The creation of foo would have
1751         been hoisted, which would have happened before execution of the
1752         other statements.
1753
1754         A breakpoint on line 4, a function signature, resolves to line 5,
1755         inside the function. Users would expect to pause inside of a function
1756         when setting a breakpoint on that function's name or opening brace.
1757
1758         A breakpoint on line 6, a function's closing brace, resolves to
1759         line 6. The debugger will pause whenever execution leaves foo due to
1760         a return and not an exception. This matches stepping behavior. An
1761         explicit or implicit return (the implicit return undefined) will
1762         pause on the closing brace as we leave the function, giving users
1763         an opportunity to inspect the final state before leaving.
1764
1765         --
1766
1767         At this point, op_debug's are still emitted at custom locations during
1768         bytecode generation of other statements / expressions. In order to
1769         ensure the generated op_debugs correspond to locations the Parser
1770         determined were breakpoint locations, the Parser sets a "needs debug
1771         hook" flag on the nodes it will use for breakpoint locations, and
1772         we assert during bytecode generation that op_debugs are only emitted
1773         for nodes that were marked as needing debug hooks.
1774
1775         This still leaves open the possibility that the Parser will mark
1776         some nodes that get missed during bytecode generation, so we might
1777         fail to emit some op_debugs. The next step will be eliminating the
1778         custom emitDebugHooks spread across StatementNode and ExpressionNode
1779         subclasses, and instead always generating op_debugs whenever we
1780         emit a flagged node.
1781
1782         --
1783
1784         * CMakeLists.txt:
1785         * JavaScriptCore.xcodeproj/project.pbxproj:
1786         New DebuggerParseData files.
1787
1788         * API/JSScriptRef.cpp:
1789         (OpaqueJSScript::OpaqueJSScript):
1790         * jsc.cpp:
1791         (functionCheckModuleSyntax):
1792         * parser/SourceCode.h:
1793         (JSC::makeSource):
1794         * parser/SourceProvider.cpp:
1795         (JSC::SourceProvider::SourceProvider):
1796         * parser/SourceProvider.h:
1797         (JSC::SourceProvider::sourceType):
1798         (JSC::StringSourceProvider::create):
1799         (JSC::StringSourceProvider::StringSourceProvider):
1800         (JSC::WebAssemblySourceProvider::WebAssemblySourceProvider):
1801         (JSC::SourceProvider::startPosition): Deleted.
1802         Add a new type on SourceProvider to distinguish if its script was
1803         intended to be a Script, Module, or WebAssembly. This information
1804         will be needed to know how to best parse this file when the
1805         debugger decides to lazily parse.
1806
1807         * runtime/Executable.cpp:
1808         (JSC::EvalExecutable::EvalExecutable):
1809         (JSC::ProgramExecutable::ProgramExecutable):
1810         (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
1811         (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
1812         * runtime/ModuleLoaderPrototype.cpp:
1813         (JSC::moduleLoaderPrototypeParseModule):
1814         ASSERT the SourceProvider type matches the executable type we are
1815         creating for it.
1816
1817         * parser/ASTBuilder.h:
1818         (JSC::ASTBuilder::breakpointLocation):
1819         * parser/SyntaxChecker.h:
1820         (JSC::SyntaxChecker::operatorStackPop):
1821         When gathering breakpoint positions, get the position from the
1822         current node. In the SyntaxChecker, return an invalid position.
1823
1824         * parser/Nodes.h:
1825         (JSC::ExpressionNode::needsDebugHook):
1826         (JSC::ExpressionNode::setNeedsDebugHook):
1827         (JSC::StatementNode::needsDebugHook):
1828         (JSC::StatementNode::setNeedsDebugHook):
1829         When gathering breakpoint positions, mark the node as needing
1830         a debug hook. For now we assert op_debugs generated must come
1831         from these nodes. Later we should just generate op_debugs for
1832         these nodes.
1833
1834         * parser/Parser.cpp:
1835         (JSC::Parser<LexerType>::Parser):
1836         (JSC::Parser<LexerType>::parseStatementListItem):
1837         (JSC::Parser<LexerType>::parseDoWhileStatement):
1838         (JSC::Parser<LexerType>::parseWhileStatement):
1839         (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
1840         (JSC::Parser<LexerType>::parseForStatement):
1841         (JSC::Parser<LexerType>::parseWithStatement):
1842         (JSC::Parser<LexerType>::parseSwitchStatement):
1843         (JSC::Parser<LexerType>::parseStatement):
1844         (JSC::Parser<LexerType>::parseFunctionBody):
1845         (JSC::Parser<LexerType>::parseFunctionInfo):
1846         (JSC::Parser<LexerType>::parseIfStatement):
1847         (JSC::Parser<LexerType>::parseAssignmentExpression):
1848         * parser/Parser.h:
1849         (JSC::parse):
1850         Add an optional DebuggerParseData struct to the Parser. When available
1851         the Parser will gather debugger data, and parse all functions with the
1852         ASTBuilder instead of SyntaxChecking inner functions.
1853
1854         * debugger/DebuggerParseData.cpp: Added.
1855         (JSC::DebuggerPausePositions::breakpointLocationForLineColumn):
1856         (JSC::DebuggerPausePositions::sort):
1857         (JSC::gatherDebuggerParseData):
1858         (JSC::gatherDebuggerParseDataForSource):
1859         * debugger/DebuggerParseData.h: Copied from Source/JavaScriptCore/debugger/DebuggerPrimitives.h.
1860         (JSC::DebuggerPausePositions::DebuggerPausePositions):
1861         (JSC::DebuggerPausePositions::appendPause):
1862         (JSC::DebuggerPausePositions::appendEntry):
1863         (JSC::DebuggerPausePositions::appendLeave):
1864         The DebuggerParseData struct currently only contains a list of pause positions.
1865         Once populated it can resolve an input location to a pause position.
1866
1867         * bytecompiler/BytecodeGenerator.cpp:
1868         (JSC::BytecodeGenerator::emitCall):
1869         (JSC::BytecodeGenerator::emitCallVarargs):
1870         (JSC::BytecodeGenerator::emitDebugHook):
1871         (JSC::BytecodeGenerator::emitEnumeration):
1872         * bytecompiler/BytecodeGenerator.h:
1873         * bytecompiler/NodesCodegen.cpp:
1874         (JSC::EmptyStatementNode::emitBytecode):
1875         (JSC::DebuggerStatementNode::emitBytecode):
1876         (JSC::ExprStatementNode::emitBytecode):
1877         (JSC::DeclarationStatement::emitBytecode):
1878         (JSC::IfElseNode::emitBytecode):
1879         (JSC::DoWhileNode::emitBytecode):
1880         (JSC::WhileNode::emitBytecode):
1881         (JSC::ForNode::emitBytecode):
1882         (JSC::ForInNode::emitBytecode):
1883         (JSC::ContinueNode::emitBytecode):
1884         (JSC::BreakNode::emitBytecode):
1885         (JSC::ReturnNode::emitBytecode):
1886         (JSC::WithNode::emitBytecode):
1887         (JSC::SwitchNode::emitBytecode):
1888         (JSC::ThrowNode::emitBytecode):
1889         Emit op_debugs for the nodes themselves. Assert when we do that the
1890         Parser had marked them as needing a debug hook.
1891
1892         * debugger/Breakpoint.h:
1893         (JSC::Breakpoint::Breakpoint):
1894         A breakpoint may be resolved or unresolved. Debugger::resolveBreakpoint
1895         must be used to resolve the breakpoint. Most methods now require a
1896         resolved breakpoint.
1897
1898         * debugger/Debugger.h:
1899         * debugger/Debugger.cpp:
1900         (JSC::Debugger::detach):
1901         (JSC::Debugger::toggleBreakpoint):
1902         (JSC::Debugger::debuggerParseData):
1903         (JSC::Debugger::resolveBreakpoint):
1904         (JSC::Debugger::setBreakpoint):
1905         (JSC::Debugger::clearParsedData):
1906         Provide a public method to resolve a breakpoint location in a script.
1907         This will gather debugger parse data for the script if none is available.
1908         Ensure clients have resolved a breakpoint before attempting to set it.
1909         Currently we allow only a single breakpoint at a location. This may
1910         need to change if multiple breakpoints resolve to the same location
1911         but have different actions.
1912
1913         * inspector/ScriptDebugListener.h:
1914         ScriptDebugServer::Script is effectively duplicating most of the data from
1915         a SourceProvider. We should eliminate this and just use SourceProvider.
1916
1917         * inspector/ScriptDebugServer.cpp:
1918         (Inspector::ScriptDebugServer::setBreakpointActions):
1919         (Inspector::ScriptDebugServer::removeBreakpointActions):
1920         (Inspector::ScriptDebugServer::getActionsForBreakpoint):
1921         (Inspector::ScriptDebugServer::clearBreakpointActions):
1922         (Inspector::ScriptDebugServer::evaluateBreakpointAction):
1923         (Inspector::ScriptDebugServer::dispatchDidParseSource):
1924         (Inspector::ScriptDebugServer::handleBreakpointHit):
1925         (Inspector::ScriptDebugServer::setBreakpoint): Deleted.
1926         (Inspector::ScriptDebugServer::removeBreakpoint): Deleted.
1927         (Inspector::ScriptDebugServer::clearBreakpoints): Deleted.
1928         * inspector/ScriptDebugServer.h:
1929         Reduce ScriptDebugServer's involvement in breakpoints to just handling
1930         breakpoint actions. Eventually we should eliminate it alltogether and
1931         fold breakpoint logic into Debugger or DebugAgent.
1932
1933         * inspector/agents/InspectorDebuggerAgent.h:
1934         * inspector/agents/InspectorDebuggerAgent.cpp:
1935         (Inspector::buildDebuggerLocation):
1936         (Inspector::parseLocation):
1937         (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
1938         (Inspector::InspectorDebuggerAgent::setBreakpoint):
1939         (Inspector::InspectorDebuggerAgent::didSetBreakpoint):
1940         (Inspector::InspectorDebuggerAgent::resolveBreakpoint):
1941         (Inspector::InspectorDebuggerAgent::removeBreakpoint):
1942         (Inspector::InspectorDebuggerAgent::continueToLocation):
1943         (Inspector::InspectorDebuggerAgent::didParseSource):
1944         (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
1945         The Inspector can set breakpoints in multiple ways.
1946         Ensure that once we have the Script that we always
1947         resolve the breakpoint location before setting the
1948         breakpoint. The different paths are:
1949         
1950         - setBreakpoint(scriptId, location)
1951           - Here we know the SourceProvider by its SourceID
1952             - resolve and set
1953         
1954         - setBreakpointByURL(url, location)
1955           - Search for existing Scripts that match the URL
1956             - resolve in each and set
1957           - When new Scripts are parsed that match the URL
1958             - resolve and set
1959             
1960
1961 2016-09-30  Joseph Pecoraro  <pecoraro@apple.com>
1962
1963         Web Inspector: Stepping out of a function finishes the line that called it.
1964         https://bugs.webkit.org/show_bug.cgi?id=155325
1965         <rdar://problem/25094578>
1966
1967         Reviewed by Mark Lam.
1968
1969         Also addresses:
1970         <https://webkit.org/b/161721> Web Inspector: Stepping all the way through program should not cause a pause on the next program that executes
1971         <https://webkit.org/b/161716> Web Inspector: Stepping into a function / program should not require stepping to the first statement
1972
1973         This change introduces a new op_debug hook: WillExecuteExpression.
1974         Currently this new hook is only used for pausing at function calls.
1975         We may decide to add it to other places later where pausing with
1976         finer granularity then statements (or lines) if useful.
1977
1978         This updates the location and behavior of some of the existing debug
1979         hooks, to be more consistent and useful if the exact location of the
1980         pause is displayed. For example, in control flow statements like
1981         `if` and `while`, the pause location is the expression itself that
1982         will be evaluated, not the location of the `if` or `while` keyword.
1983         For example:
1984
1985             if (|condition)
1986             while (|condition)
1987
1988         Finally, this change gets rid of some unnecessary / useless pause
1989         locations such as on entering a function and on entering a program.
1990         These pauses are not needed because if there is a statement, we
1991         would pause before the statement and it is equivalent. We continue
1992         to pause when leaving a function via stepping by uniformly jumping
1993         to the closing brace of the function. This gives users a chance
1994         to observe state before leaving the function.
1995
1996         * bytecode/CodeBlock.cpp:
1997         (JSC::debugHookName):
1998         * bytecode/UnlinkedCodeBlock.cpp:
1999         (JSC::dumpLineColumnEntry):
2000         Logging strings for the new debug hook.
2001
2002         * bytecompiler/BytecodeGenerator.h:
2003         * bytecompiler/BytecodeGenerator.cpp:
2004         (JSC::BytecodeGenerator::emitCallInTailPosition):
2005         (JSC::BytecodeGenerator::emitCallEval):
2006         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
2007         (JSC::BytecodeGenerator::emitConstructVarargs):
2008         (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
2009         (JSC::BytecodeGenerator::emitCallDefineProperty):
2010         (JSC::BytecodeGenerator::emitConstruct):
2011         (JSC::BytecodeGenerator::emitGetTemplateObject):
2012         (JSC::BytecodeGenerator::emitIteratorNext):
2013         (JSC::BytecodeGenerator::emitIteratorNextWithValue):
2014         (JSC::BytecodeGenerator::emitIteratorClose):
2015         (JSC::BytecodeGenerator::emitDelegateYield):
2016         All emitCall variants now take an enum to decide whether or not to
2017         emit the WillExecuteExpression debug hook.
2018
2019         (JSC::BytecodeGenerator::emitCall):
2020         (JSC::BytecodeGenerator::emitCallVarargs):
2021         In the two real implementations, actually decide to emit the debug
2022         hook or not based on the parameter.
2023
2024         (JSC::BytecodeGenerator::emitEnumeration):
2025         This is shared looping code used by for..of iteration of iterables.
2026         When used by ForOfNode, we want to emit a pause location during
2027         iteration.
2028
2029         (JSC::BytecodeGenerator::emitWillLeaveCallFrameDebugHook):
2030         This is shared call frame leave code to emit a consistent pause
2031         location when leaving a function.
2032
2033         * bytecompiler/NodesCodegen.cpp:
2034         (JSC::EvalFunctionCallNode::emitBytecode):
2035         (JSC::FunctionCallValueNode::emitBytecode):
2036         (JSC::FunctionCallResolveNode::emitBytecode):
2037         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tailCallForwardArguments):
2038         (JSC::FunctionCallBracketNode::emitBytecode):
2039         (JSC::FunctionCallDotNode::emitBytecode):
2040         (JSC::CallFunctionCallDotNode::emitBytecode):
2041         (JSC::ApplyFunctionCallDotNode::emitBytecode):
2042         (JSC::TaggedTemplateNode::emitBytecode):
2043         (JSC::ArrayPatternNode::bindValue):
2044         All tail position calls are the function calls that we want to emit
2045         debug hooks for. All non-tail call calls appear to be internal
2046         implementation details, and these should not have the debug hook.
2047
2048         (JSC::IfElseNode::emitBytecode):
2049         (JSC::WhileNode::emitBytecode):
2050         (JSC::WithNode::emitBytecode):
2051         (JSC::SwitchNode::emitBytecode):
2052         Make the pause location consistent at the expression.
2053
2054         (JSC::DoWhileNode::emitBytecode):
2055         Make the pause location consistent at the expression.
2056         Remove the errant pause at the do's '}' when entering the do block.
2057
2058         (JSC::ForNode::emitBytecode):
2059         (JSC::ForInNode::emitMultiLoopBytecode):
2060         (JSC::ForOfNode::emitBytecode):
2061         Make the pause location consistent at expressions.
2062         Also allow stepping to the traditional for loop's
2063         update expression, which was previously not possible.
2064
2065         (JSC::ReturnNode::emitBytecode):
2066         (JSC::FunctionNode::emitBytecode):
2067         Make the pause location when leaving a function consistently be the
2068         function's closing brace. The two cases are stepping through a return
2069         statement, or the implicit return undefined at the end of a function.
2070
2071         (JSC::LabelNode::emitBytecode):
2072         (JSC::TryNode::emitBytecode):
2073         Remove unnecessary pauses that add no value, as they contain a
2074         statement and we will then pause at that statement.
2075
2076         * parser/Nodes.h:
2077         (JSC::StatementNode::isFunctionNode):
2078         (JSC::StatementNode::isForOfNode):
2079         (JSC::EnumerationNode::lexpr):
2080         (JSC::ForOfNode::isForOfNode):
2081         New virtual methods to distinguish different nodes.
2082
2083         * debugger/Debugger.h:
2084         Rename m_pauseAtNextStatement to m_pauseAtNextOpportunity.
2085         This is the finest granularity of stepping, and it can be
2086         pausing at a location that is not a statement.
2087         Introduce state to properly handle step out and stepping
2088         when there are multiple expressions in a statement.
2089
2090         * debugger/Debugger.cpp:
2091         (JSC::Debugger::Debugger):
2092         (JSC::Debugger::setPauseOnNextStatement):
2093         (JSC::Debugger::breakProgram):
2094         (JSC::Debugger::continueProgram):
2095         (JSC::Debugger::stepIntoStatement):
2096         (JSC::Debugger::exception):
2097         (JSC::Debugger::didReachBreakpoint):
2098         
2099         Use new variable names, and clarify if we should attempt
2100         to pause or not.
2101
2102         (JSC::Debugger::stepOutOfFunction):
2103         Set a new state to indicate a step out action.
2104
2105         (JSC::Debugger::updateCallFrame):
2106         (JSC::Debugger::updateCallFrameAndPauseIfNeeded): Deleted.
2107         (JSC::Debugger::updateCallFrameInternal):
2108         (JSC::Debugger::pauseIfNeeded):
2109         Allow updateCallFrame to either attempt a pause or not.
2110         
2111         (JSC::Debugger::atStatement):
2112         Attempt pause and reset the at first expression flag.
2113
2114         (JSC::Debugger::atExpression):
2115         Attempt a pause when not stepping over. Also skip
2116         the first expression pause, since that would be
2117         equivalent to when we paused for the expression.
2118
2119         (JSC::Debugger::callEvent):
2120         Do not pause when entering a function.
2121
2122         (JSC::Debugger::returnEvent):
2123         Attempt pause when leaving a function.
2124         If the user did a step-over and is leaving the
2125         function, then behave like step-out.
2126         
2127         (JSC::Debugger::unwindEvent):
2128         Behave like return except don't change any
2129         pausing states. If we needed to pause the
2130         Debugger::exception will have handled it.
2131
2132         (JSC::Debugger::willExecuteProgram):
2133         Do not pause when entering a program.
2134
2135         (JSC::Debugger::didExecuteProgram):
2136         Attempt pause when leaving a program that has a caller.
2137         This can be useful for exiting an eval(...) program.
2138         Otherwise treat this like return, and step-over out
2139         of the program should behave like step-out. We use
2140         pause at next opportunity because there may be extra
2141         callframes we do not know about.
2142         When the program doesn't have a parent, clear all
2143         our state so we don't errantly pause on the next
2144         JavaScript microtask that gets executed.
2145         
2146         (JSC::Debugger::clearNextPauseState):
2147         Helper to clear all of the pause states now that
2148         it happens in a couple places.
2149
2150         * interpreter/Interpreter.cpp:
2151         (JSC::notifyDebuggerOfUnwinding):
2152         Treat unwinding slightly differently from returning.
2153         We will not want to pause when unwinding callframes.
2154
2155         (JSC::Interpreter::debug):
2156         * interpreter/Interpreter.h:
2157         New debug hook.
2158
2159         * inspector/agents/InspectorDebuggerAgent.cpp:
2160         (Inspector::InspectorDebuggerAgent::stepInto):
2161         (Inspector::InspectorDebuggerAgent::didPause):
2162         * inspector/agents/InspectorDebuggerAgent.h:
2163         Remove unnecessary stepInto code notification for listeners.
2164         The listeners are never notified if the debugger resumes,
2165         so whatever state they were setting by this is going to
2166         get out of date.
2167
2168 2016-09-30  Saam Barati  <sbarati@apple.com>
2169
2170         Arrow functions should not allow duplicate parameter names
2171         https://bugs.webkit.org/show_bug.cgi?id=162741
2172
2173         Reviewed by Filip Pizlo.
2174
2175         This patch makes parsing arrow function parameters throw
2176         a syntax error when there are duplicate parameter names.
2177         It also starts to make some syntax errors for arrow functions
2178         better, however, this is trickier than it seems since we need
2179         to choose between two parsing productions when we decide to
2180         throw a syntax error. I'm going to work on this problem
2181         in another patch specifically devoted to making the error
2182         messages better for parsing arrow functions:
2183         https://bugs.webkit.org/show_bug.cgi?id=162794
2184
2185         * parser/Parser.cpp:
2186         (JSC::Parser<LexerType>::isArrowFunctionParameters):
2187         (JSC::Parser<LexerType>::parseFormalParameters):
2188         (JSC::Parser<LexerType>::parseFunctionParameters):
2189         (JSC::Parser<LexerType>::parseAssignmentExpression):
2190         * parser/Parser.h:
2191
2192 2016-09-30  Mark Lam  <mark.lam@apple.com>
2193
2194         Use topVMEntryFrame to determine whether to skip the re-throw of a simulated throw.
2195         https://bugs.webkit.org/show_bug.cgi?id=162793
2196
2197         Reviewed by Saam Barati.
2198
2199         Change the ThrowScope destructor to use topVMEntryFrame (instead of topCallFrame)
2200         in the determination of whether to skip the re-throw of a simulated throw.  This
2201         is needed because the topCallFrame is not updated in operationConstructArityCheck()
2202         (and does not need to be), whereas topVMEntryFrame is always updated properly.
2203         Hence, we should just switch to using the more reliable topVMEntryFrame instead.
2204
2205         This issue was discovered by existing JSC tests when exception check validation
2206         is enabled.
2207
2208         * runtime/ThrowScope.cpp:
2209         (JSC::ThrowScope::~ThrowScope):
2210
2211 2016-09-30  Filip Pizlo  <fpizlo@apple.com>
2212
2213         64-bit LLInt needs to have a concurrency-aware barrier
2214         https://bugs.webkit.org/show_bug.cgi?id=162790
2215
2216         Reviewed by Mark Lam.
2217
2218         In a concurrent GC the barrier definitely has to be after the store, not before it.
2219
2220         * llint/LowLevelInterpreter64.asm:
2221
2222 2016-09-29  Filip Pizlo  <fpizlo@apple.com>
2223
2224         Air should have a way of expressing additional instruction flags
2225         https://bugs.webkit.org/show_bug.cgi?id=162699
2226
2227         Reviewed by Mark Lam.
2228         
2229         This follows a similar change in B3 (r206595) and replaces Air::Opcode with Air::Kind,
2230         which holds onto the opcode and some additional flags. Because Air is an orthogonal ISA
2231         (the opcode tells you what the operation does but each operand is allowed to also contain
2232         effectively instructions for what to do to read or write that operand), the flags are
2233         meant to be orthogonal to opcode. This allows us to say things like Add32<Trap>, which
2234         makes sense if any of the operands to the Add32 are addresses.
2235         
2236         To demonstrate the flags facility this partly adds a trap flag to Air. B3 doesn't use it
2237         yet, but I made sure that Air respects it. Basically that means blocking DCE when the flag
2238         is set, by making it imply hasNonArgNonControlEffects.
2239
2240         * CMakeLists.txt:
2241         * JavaScriptCore.xcodeproj/project.pbxproj:
2242         * b3/B3CheckSpecial.cpp:
2243         (JSC::B3::Air::numB3Args):
2244         (JSC::B3::CheckSpecial::Key::Key):
2245         (JSC::B3::CheckSpecial::Key::dump):
2246         (JSC::B3::CheckSpecial::CheckSpecial):
2247         (JSC::B3::CheckSpecial::hiddenBranch):
2248         (JSC::B3::CheckSpecial::forEachArg):
2249         (JSC::B3::CheckSpecial::generate):
2250         (JSC::B3::CheckSpecial::dumpImpl):
2251         (JSC::B3::CheckSpecial::deepDumpImpl):
2252         * b3/B3CheckSpecial.h:
2253         (JSC::B3::CheckSpecial::Key::Key):
2254         (JSC::B3::CheckSpecial::Key::operator==):
2255         (JSC::B3::CheckSpecial::Key::kind):
2256         (JSC::B3::CheckSpecial::Key::hash):
2257         (JSC::B3::CheckSpecial::Key::opcode): Deleted.
2258         * b3/B3Kind.cpp:
2259         (JSC::B3::Kind::dump):
2260         * b3/air/AirDumpAsJS.cpp:
2261         (JSC::B3::Air::dumpAsJS):
2262         * b3/air/AirFixObviousSpills.cpp:
2263         * b3/air/AirFixPartialRegisterStalls.cpp:
2264         * b3/air/AirGenerate.cpp:
2265         (JSC::B3::Air::generate):
2266         * b3/air/AirHandleCalleeSaves.cpp:
2267         (JSC::B3::Air::handleCalleeSaves):
2268         * b3/air/AirInst.cpp:
2269         (JSC::B3::Air::Inst::jsHash):
2270         (JSC::B3::Air::Inst::dump):
2271         * b3/air/AirInst.h:
2272         (JSC::B3::Air::Inst::Inst):
2273         (JSC::B3::Air::Inst::kind):
2274         (JSC::B3::Air::Inst::operator bool):
2275         (JSC::B3::Air::Inst::opcode): Deleted.
2276         * b3/air/AirInstInlines.h:
2277         (JSC::B3::Air::Inst::extraClobberedRegs):
2278         (JSC::B3::Air::Inst::extraEarlyClobberedRegs):
2279         (JSC::B3::Air::Inst::forEachDefWithExtraClobberedRegs):
2280         (JSC::B3::Air::Inst::reportUsedRegisters):
2281         (JSC::B3::Air::Inst::shouldTryAliasingDef):
2282         * b3/air/AirIteratedRegisterCoalescing.cpp:
2283         * b3/air/AirKind.cpp: Added.
2284         (JSC::B3::Air::Kind::dump):
2285         * b3/air/AirKind.h: Added.
2286         (JSC::B3::Air::Kind::Kind):
2287         (JSC::B3::Air::Kind::operator==):
2288         (JSC::B3::Air::Kind::operator!=):
2289         (JSC::B3::Air::Kind::hash):
2290         (JSC::B3::Air::Kind::operator bool):
2291         * b3/air/AirLowerAfterRegAlloc.cpp:
2292         (JSC::B3::Air::lowerAfterRegAlloc):
2293         * b3/air/AirLowerEntrySwitch.cpp:
2294         (JSC::B3::Air::lowerEntrySwitch):
2295         * b3/air/AirLowerMacros.cpp:
2296         (JSC::B3::Air::lowerMacros):
2297         * b3/air/AirOptimizeBlockOrder.cpp:
2298         (JSC::B3::Air::optimizeBlockOrder):
2299         * b3/air/AirReportUsedRegisters.cpp:
2300         (JSC::B3::Air::reportUsedRegisters):
2301         * b3/air/AirSimplifyCFG.cpp:
2302         (JSC::B3::Air::simplifyCFG):
2303         * b3/air/AirTmpWidth.cpp:
2304         (JSC::B3::Air::TmpWidth::recompute):
2305         * b3/air/AirUseCounts.h:
2306         (JSC::B3::Air::UseCounts::UseCounts):
2307         * b3/air/AirValidate.cpp:
2308         * b3/air/opcode_generator.rb:
2309         * b3/testb3.cpp:
2310         (JSC::B3::testTernarySubInstructionSelection):
2311         (JSC::B3::testBranchBitAndImmFusion):
2312
2313 2016-09-29  Filip Pizlo  <fpizlo@apple.com>
2314
2315         REGRESSION(r206555): It made Dromaeo/jslib-style-jquery.html crash
2316         https://bugs.webkit.org/show_bug.cgi?id=162721
2317
2318         Reviewed by Keith Miller.
2319         
2320         The put_by_id-in-put_by_val optimization had the write barrier in the wrong place and
2321         incorrectly filtered on value instead of base.
2322         
2323         No reduced test case. You really need to run Dromaeo/jslib to catch it. I love Dromaeo's
2324         ability to catch GC bugs.
2325
2326         * jit/JITPropertyAccess.cpp:
2327         (JSC::JIT::emitPutByValWithCachedId):
2328
2329 2016-09-29  Joseph Pecoraro  <pecoraro@apple.com>
2330
2331         Arrow functions do not infer name from computed property but normal functions do
2332         https://bugs.webkit.org/show_bug.cgi?id=162720
2333
2334         Reviewed by Saam Barati.
2335
2336         * bytecompiler/BytecodeGenerator.cpp:
2337         (JSC::BytecodeGenerator::emitSetFunctionNameIfNeeded):
2338         Set function name on arrow functions as well.
2339
2340 2016-09-29  Joseph Pecoraro  <pecoraro@apple.com>
2341
2342         test262: class and function names should be inferred in assignment
2343         https://bugs.webkit.org/show_bug.cgi?id=146262
2344
2345         Reviewed by Saam Barati.
2346
2347         * parser/ASTBuilder.h:
2348         (JSC::ASTBuilder::appendParameter):
2349         (JSC::ASTBuilder::appendArrayPatternEntry):
2350         (JSC::ASTBuilder::appendObjectPatternEntry):
2351         (JSC::ASTBuilder::tryInferFunctionNameInPattern):
2352         Assign names to default value functions and classes in destructuring.
2353
2354         (JSC::ASTBuilder::createAssignResolve):
2355         (JSC::ASTBuilder::createProperty):
2356         (JSC::ASTBuilder::makeAssignNode):
2357         Assign names to both normal and arrow functions.
2358
2359         * parser/Nodes.h:
2360         (JSC::ExpressionNode::isBaseFuncExprNode):
2361         Both functions and arrow functions infer name, they both extend
2362         this base so give the base an is check.
2363
2364 2016-09-28  Filip Pizlo  <fpizlo@apple.com>
2365
2366         B3 opcodes should leave room for flags
2367         https://bugs.webkit.org/show_bug.cgi?id=162692
2368
2369         Reviewed by Keith Miller.
2370
2371         It used to be that the main thing that determined what a Value did was the opcode. The
2372         Opcode was how you knew what subclass of Value you had. The opcode told you what the Value
2373         actually did. This change replaces Opcode with Kind, which is a tuple of opcode and other
2374         stuff.
2375         
2376         Opcodes are great, and that's how most compilers work. But opcodes are one-dimensional. Here
2377         is how this manifests. Say you have an opcode, like Load. You will be happy if your IR has
2378         one Load opcode. But then, you might add Load8S/Load8Z/Load16S/Load16Z opcodes, as we have
2379         done in B3. B3 has one dimension of Load opcodes, which determines something like the C type
2380         of the load. But in the very near future, we will want to add two more dimensions to Loads:
2381         
2382         - A flag to say if the load traps.
2383         - A flag to say if the load has acquire semantics.
2384         
2385         Mapping these three dimensions (type, trap, acquire) onto the one-dimensional Opcode space
2386         would create mayham: Load8S, Load8STrap, Load8SAcquire, Load8STrapAcquire, Load8Z,
2387         Load8ZTrap, etc.
2388         
2389         This happens in other parts of the IR. For example, we have a dimension of arithmetic
2390         operations: add, sub, mul, div, mod, etc. Then we have the chill flag. But since opcodes
2391         are one-dimensional, that means having ChillDiv and ChillMod, and tons of places in the
2392         compiler that case on both Div and ChillDiv, or case on both Mod and ChillMod, since they
2393         are only interested in the kind of arithmetic being done and not the chillness.
2394         
2395         Though the examples all involve bits (chill or not, trapping or not, etc), I can imagine
2396         other properties that behave more like small enums, like if we fill out more memory ordering
2397         modes other than just "acquire? yes/no". There will eventually have to be something like a
2398         std::memory_order associated with memory accesses.
2399         
2400         One approach to this problem is to have a Value subclass that contains fields with the meta
2401         data. I don't like this for two reasons:
2402         
2403         - In bug 162688, I want to make trapping memory accesses have stackmaps. This means that a
2404           trapping memory access would have a different Value subclass than a non-trapping memory
2405           access. So, this meta-data needs to channel into ValueType::accepts(). Currently that
2406           takes Opcode and nothing else.
2407         
2408         - Compiler IRs are all about making common tasks easy. If it becomes commonplace for opcodes
2409           to require a custom Value subclass just for a bit then that's not very easy.
2410         
2411         This change addresses this problem by making the compiler pass around Kinds rather than
2412         Opcodes. A Kind contains an Opcode as well as any number of opcode-specific bits. This
2413         change demonstrates how Kind should be used by converting chillness to it. Kind has
2414         hasIsChill(), isChill(), and setIsChill() methods. hasIsChill() is true only for Div and
2415         Mod. setIsChill() asserts if !hasIsChill(). If you want to create a Chill Div, you say
2416         chill(Div). IR dumps will print it like this:
2417
2418             Int32 @38 = Div<Chill>(@36, @37, DFG:@24, ControlDependent)
2419         
2420         Where "Div<Chill>" is how a Kind that hasExtraBits() dumps itself. If a Kind does not
2421         hasExtraBits() (the normal case) then it dumps like a normal Opcode (without the "<>").
2422         
2423         I replaced many uses of Opcode with Kind. New code has to be mindful that Opcode may not be
2424         the right way to summarize what a value does, and so in many cases it's better to carry
2425         around a Kind instead - especially if you will use it to stamp out new Values. Opcode is no
2426         longer sufficient to perform a dynamic Value cast, since that code now uses Kind. ValueKey
2427         now wants a Kind instead of an Opcode. All Value constructors now take Kind instead of
2428         Opcode. But most opcodes don't get any extra Kind bits, and so the code that operates on
2429         those opcodes is largely unchanged.
2430         
2431         * CMakeLists.txt:
2432         * JavaScriptCore.xcodeproj/project.pbxproj:
2433         * b3/B3ArgumentRegValue.h:
2434         * b3/B3CCallValue.h:
2435         * b3/B3CheckValue.cpp:
2436         (JSC::B3::CheckValue::convertToAdd):
2437         (JSC::B3::CheckValue::CheckValue):
2438         * b3/B3CheckValue.h:
2439         (JSC::B3::CheckValue::accepts):
2440         * b3/B3Const32Value.h:
2441         * b3/B3Const64Value.h:
2442         * b3/B3ConstDoubleValue.h:
2443         * b3/B3ConstFloatValue.h:
2444         * b3/B3FenceValue.h:
2445         * b3/B3Kind.cpp: Added.
2446         (JSC::B3::Kind::dump):
2447         * b3/B3Kind.h: Added.
2448         (JSC::B3::Kind::Kind):
2449         (JSC::B3::Kind::opcode):
2450         (JSC::B3::Kind::setOpcode):
2451         (JSC::B3::Kind::hasExtraBits):
2452         (JSC::B3::Kind::hasIsChill):
2453         (JSC::B3::Kind::isChill):
2454         (JSC::B3::Kind::setIsChill):
2455         (JSC::B3::Kind::operator==):
2456         (JSC::B3::Kind::operator!=):
2457         (JSC::B3::Kind::hash):
2458         (JSC::B3::Kind::isHashTableDeletedValue):
2459         (JSC::B3::chill):
2460         (JSC::B3::KindHash::hash):
2461         (JSC::B3::KindHash::equal):
2462         * b3/B3LowerMacros.cpp:
2463         * b3/B3LowerToAir.cpp:
2464         (JSC::B3::Air::LowerToAir::lower):
2465         * b3/B3MemoryValue.h:
2466         * b3/B3Opcode.cpp:
2467         (WTF::printInternal):
2468         * b3/B3Opcode.h:
2469         * b3/B3PatchpointValue.h:
2470         (JSC::B3::PatchpointValue::accepts):
2471         * b3/B3ReduceStrength.cpp:
2472         * b3/B3SlotBaseValue.h:
2473         * b3/B3StackmapValue.cpp:
2474         (JSC::B3::StackmapValue::StackmapValue):
2475         * b3/B3StackmapValue.h:
2476         * b3/B3SwitchValue.h:
2477         (JSC::B3::SwitchValue::accepts):
2478         * b3/B3UpsilonValue.h:
2479         * b3/B3Validate.cpp:
2480         * b3/B3Value.cpp:
2481         (JSC::B3::Value::dump):
2482         (JSC::B3::Value::deepDump):
2483         (JSC::B3::Value::invertedCompare):
2484         (JSC::B3::Value::effects):
2485         (JSC::B3::Value::key):
2486         (JSC::B3::Value::typeFor):
2487         (JSC::B3::Value::badKind):
2488         (JSC::B3::Value::badOpcode): Deleted.
2489         * b3/B3Value.h:
2490         * b3/B3ValueInlines.h:
2491         (JSC::B3::Value::as):
2492         * b3/B3ValueKey.cpp:
2493         (JSC::B3::ValueKey::dump):
2494         (JSC::B3::ValueKey::materialize):
2495         * b3/B3ValueKey.h:
2496         (JSC::B3::ValueKey::ValueKey):
2497         (JSC::B3::ValueKey::kind):
2498         (JSC::B3::ValueKey::opcode):
2499         (JSC::B3::ValueKey::operator==):
2500         (JSC::B3::ValueKey::hash):
2501         * b3/B3ValueKeyInlines.h:
2502         (JSC::B3::ValueKey::ValueKey):
2503         * b3/B3VariableValue.cpp:
2504         (JSC::B3::VariableValue::VariableValue):
2505         * b3/B3VariableValue.h:
2506         * b3/testb3.cpp:
2507         (JSC::B3::testChillDiv):
2508         (JSC::B3::testChillDivTwice):
2509         (JSC::B3::testChillDiv64):
2510         (JSC::B3::testChillModArg):
2511         (JSC::B3::testChillModArgs):
2512         (JSC::B3::testChillModImms):
2513         (JSC::B3::testChillModArg32):
2514         (JSC::B3::testChillModArgs32):
2515         (JSC::B3::testChillModImms32):
2516         (JSC::B3::testSwitchChillDiv):
2517         (JSC::B3::testEntrySwitchWithCommonPaths):
2518         (JSC::B3::testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint):
2519         * ftl/FTLOutput.cpp:
2520         (JSC::FTL::Output::chillDiv):
2521         (JSC::FTL::Output::chillMod):
2522
2523 2016-09-29  Saam Barati  <sbarati@apple.com>
2524
2525         We don't properly propagate non-simple-parameter-list when parsing a setter
2526         https://bugs.webkit.org/show_bug.cgi?id=160483
2527
2528         Reviewed by Joseph Pecoraro.
2529
2530         * parser/Parser.cpp:
2531         (JSC::Parser<LexerType>::parseFunctionParameters):
2532
2533 2016-09-28  Saam Barati  <sbarati@apple.com>
2534
2535         stringProtoFuncRepeatCharacter will return `null` when it should not
2536         https://bugs.webkit.org/show_bug.cgi?id=161944
2537
2538         Reviewed by Yusuke Suzuki.
2539
2540         stringProtoFuncRepeatCharacter was expecting its second argument
2541         to always be a boxed integer. This is not correct. The DFG may decide
2542         to represent a particular value as a double instead of integer. This
2543         function needs to have correct behavior when its second argument is
2544         a boxed double. I also added an assertion stating that the second argument
2545         is always a number. We can guarantee this since it's only called from
2546         builtins.
2547
2548         * runtime/StringPrototype.cpp:
2549         (JSC::stringProtoFuncRepeatCharacter):
2550
2551 2016-09-28  Filip Pizlo  <fpizlo@apple.com>
2552
2553         The write barrier should be down with TSO
2554         https://bugs.webkit.org/show_bug.cgi?id=162316
2555
2556         Reviewed by Geoffrey Garen.
2557         
2558         This makes our write barrier behave correctly when it races with the collector. The
2559         collector wants to do this when visiting:
2560         
2561             object->cellState = black
2562             visit(object)
2563         
2564         The mutator wants to do this when storing:
2565         
2566             object->property = newValue
2567             if (object->cellState == black)
2568                 remember(object)
2569         
2570         Prior to this change, this didn't work right because the compiler would sometimes place
2571         barriers before the store to the property and because the mutator did not have adequate
2572         fences.
2573         
2574         Prior to this change, the DFG and FTL would emit this:
2575         
2576             if (object->cellState == black)
2577                 remember(object)
2578             object->property = newValue
2579         
2580         Which is wrong, because the object could start being scanned just after the cellState
2581         check, at which point the store would be lost. We need to confirm that the state was not
2582         black *after* the store! This change was harder than you'd expect: placing the barrier
2583         after the store broke B3's ability to do its super crazy ninja CSE on some store-load
2584         redundancies. Because the B3 CSE has some moves that the DFG CSE lacks, the DFG CSE's
2585         ability to ignore barriers didn't help. I fixed this by having the FTL convey precise
2586         heap ranges for the patchpoint corresponding to the barrier slow path. It reads the world
2587         (because of the store-load fence) and it writes only cellState (because the B3 heap ranges
2588         don't have any way to represent any of the GC's other state, which means that B3 does not
2589         have to worry about aliasing with any of that).
2590         
2591         The collector already uses a store-load fence on x86 just after setting the cellState and
2592         before visiting the object. The mutator needs to do the same. But we cannot put a
2593         store-load fence of any kind before store barriers, because that causes enormous slow
2594         downs. In the worst case, Octane/richards slowed down by 90%! That's crazy! However, the
2595         overall slow downs were small enough (0-15% on benchmark suite aggregates) that it would be
2596         reasonable if the slow down only happened while the GC was running. Then, the concurrent GC
2597         would lift throughput-while-collecting from 0% of peak to 85% of peak. This changes the
2598         barrier so that it looks like this:
2599         
2600             if (object->cellState <= heap.sneakyBlackThreshold)
2601                 slowPath(object)
2602         
2603         Where sneakyBlackThreshold is the normal blackThreshold when we're not collecting, or a
2604         tautoligical threshold (that makes everything look black) when we are collecting. This
2605         turns out to not be any more expensive than the barrier in tip of tree when the GC is not
2606         running, or a 0-15% slow-down when it is "running". (Of course we don't run the GC
2607         concurrently yet. I still have more work to do.) The slowPath() does some extra work to
2608         check if we are concurrently collecting; if so, it does a fence and rechecks if the object
2609         really did need that barrier.
2610         
2611         This also reintroduces elimination of redundant store barriers, which was lost in the last
2612         store barrier change. We can only do it when there is no possibility of GC, exit, or
2613         exceptions between the two store barriers. We could remove the exit/exception limitation if
2614         we taught OSR exit how to buffer store barriers, which is an insane thing to do considering
2615         that I've never been able to detect a win from redundant store barrier elimination. I just
2616         want us to have it for stupidly obvious situations, like a tight sequence of stores to the
2617         same object. This same optimization also sometimes strength-reduces the store barrier so
2618         that it uses a constant black threshold rather than the sneaky one, thereby saving one
2619         load.
2620         
2621         Even with all of those optimizations, I still had problems with barrier cost. I found that one
2622         of the benchmarks that was being hit particularly hard was JetStream/regexp-2010. Fortunately
2623         that benchmark does most of its barriers in a tight C++ loop in RegExpMatchesArray.h. When we
2624         know what we're doing, we can defer GC around a bunch of object initializations and then remove
2625         all of the barriers between any of the objects allocated within the deferral. Unfortunately,
2626         our GC deferral mechanism isn't really performant enough to make this be a worthwhile
2627         optimization. The most efficient version of such an optimization that I could come up with was
2628         to have a DeferralContext object that houses a boolean that is false by default, but the GC
2629         writes true into it if it would have wanted to GC. You thread a pointer to the deferralContext
2630         through all of your allocations. This kind of mechanism has the overhead of a zero 
2631         initialization on the stack on entry and a zero check on exit. This is probably even efficient
2632         enough that we could start thinking about having the DFG use it, for example if we found a
2633         bounded-time section of code with a lot of barriers and entry/exit sites that aren't totally
2634         wacky. This optimization took this patch from 0.68% JetStream regressed to neutral, according
2635         to my latest data.
2636         
2637         Finally, an earlier version of this change put the store-load fence in B3 IR, so I ended up
2638         adding FTLOutput support for it and AbstractHeapRepository magic for decorating the heaps.
2639         I think we might as well keep that, it'll be useful.
2640
2641         * CMakeLists.txt:
2642         * JavaScriptCore.xcodeproj/project.pbxproj:
2643         * assembler/MacroAssembler.h:
2644         (JSC::MacroAssembler::branch32):
2645         * assembler/MacroAssemblerX86_64.h:
2646         (JSC::MacroAssemblerX86_64::branch32):
2647         (JSC::MacroAssemblerX86_64::branch64): Deleted.
2648         * bytecode/PolymorphicAccess.cpp:
2649         (JSC::AccessCase::generateImpl):
2650         * dfg/DFGAbstractHeap.h:
2651         * dfg/DFGAbstractInterpreterInlines.h:
2652         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2653         * dfg/DFGClobberize.h:
2654         (JSC::DFG::clobberize):
2655         * dfg/DFGClobbersExitState.cpp:
2656         (JSC::DFG::clobbersExitState):
2657         * dfg/DFGDoesGC.cpp:
2658         (JSC::DFG::doesGC):
2659         * dfg/DFGFixupPhase.cpp:
2660         (JSC::DFG::FixupPhase::fixupNode):
2661         * dfg/DFGMayExit.cpp:
2662         * dfg/DFGNode.h:
2663         (JSC::DFG::Node::isStoreBarrier):
2664         * dfg/DFGNodeType.h:
2665         * dfg/DFGPlan.cpp:
2666         (JSC::DFG::Plan::compileInThreadImpl):
2667         * dfg/DFGPredictionPropagationPhase.cpp:
2668         * dfg/DFGSafeToExecute.h:
2669         (JSC::DFG::safeToExecute):
2670         * dfg/DFGSpeculativeJIT.cpp:
2671         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
2672         (JSC::DFG::SpeculativeJIT::storeToWriteBarrierBuffer): Deleted.
2673         (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
2674         * dfg/DFGSpeculativeJIT.h:
2675         * dfg/DFGSpeculativeJIT32_64.cpp:
2676         (JSC::DFG::SpeculativeJIT::compile):
2677         (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): Deleted.
2678         (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
2679         * dfg/DFGSpeculativeJIT64.cpp:
2680         (JSC::DFG::SpeculativeJIT::compile):
2681         (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier): Deleted.
2682         (JSC::DFG::SpeculativeJIT::writeBarrier): Deleted.
2683         * dfg/DFGStoreBarrierClusteringPhase.cpp: Added.
2684         (JSC::DFG::performStoreBarrierClustering):
2685         * dfg/DFGStoreBarrierClusteringPhase.h: Added.
2686         * dfg/DFGStoreBarrierInsertionPhase.cpp:
2687         * dfg/DFGStoreBarrierInsertionPhase.h:
2688         * ftl/FTLAbstractHeap.h:
2689         (JSC::FTL::AbsoluteAbstractHeap::at):
2690         (JSC::FTL::AbsoluteAbstractHeap::operator[]):
2691         * ftl/FTLAbstractHeapRepository.cpp:
2692         (JSC::FTL::AbstractHeapRepository::decorateFenceRead):
2693         (JSC::FTL::AbstractHeapRepository::decorateFenceWrite):
2694         (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
2695         * ftl/FTLAbstractHeapRepository.h:
2696         * ftl/FTLCapabilities.cpp:
2697         (JSC::FTL::canCompile):
2698         * ftl/FTLLowerDFGToB3.cpp:
2699         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2700         (JSC::FTL::DFG::LowerDFGToB3::compileStoreBarrier):
2701         (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
2702         (JSC::FTL::DFG::LowerDFGToB3::lazySlowPath):
2703         (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
2704         * ftl/FTLOutput.cpp:
2705         (JSC::FTL::Output::fence):
2706         (JSC::FTL::Output::absolute):
2707         * ftl/FTLOutput.h:
2708         * heap/CellState.h:
2709         (JSC::isWithinThreshold):
2710         (JSC::isBlack):
2711         * heap/Heap.cpp:
2712         (JSC::Heap::writeBarrierSlowPath):
2713         * heap/Heap.h:
2714         (JSC::Heap::barrierShouldBeFenced):
2715         (JSC::Heap::addressOfBarrierShouldBeFenced):
2716         (JSC::Heap::sneakyBlackThreshold):
2717         (JSC::Heap::addressOfSneakyBlackThreshold):
2718         * heap/HeapInlines.h:
2719         (JSC::Heap::writeBarrier):
2720         (JSC::Heap::writeBarrierWithoutFence):
2721         * jit/AssemblyHelpers.h:
2722         (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEdenWithoutFence):
2723         (JSC::AssemblyHelpers::sneakyJumpIfIsRememberedOrInEden):
2724         (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
2725         (JSC::AssemblyHelpers::storeBarrierStoreLoadFence):
2726         (JSC::AssemblyHelpers::jumpIfStoreBarrierStoreLoadFenceNotNeeded):
2727         * jit/JITOperations.cpp:
2728         * jit/JITOperations.h:
2729         * jit/JITPropertyAccess.cpp:
2730         (JSC::JIT::emit_op_put_by_id):
2731         (JSC::JIT::emitWriteBarrier):
2732         (JSC::JIT::privateCompilePutByVal):
2733         * jit/JITPropertyAccess32_64.cpp:
2734         (JSC::JIT::emit_op_put_by_id):
2735         * llint/LowLevelInterpreter.asm:
2736         * offlineasm/x86.rb:
2737         * runtime/Options.h:
2738
2739 2016-09-27  Joseph Pecoraro  <pecoraro@apple.com>
2740
2741         Improve useCodeCache Option description string.
2742
2743         * runtime/Options.h:
2744         Address late review comments and clarify description.
2745
2746 2016-09-28  Filip Pizlo  <fpizlo@apple.com>
2747
2748         Optimize B3->Air lowering of Fence on ARM
2749         https://bugs.webkit.org/show_bug.cgi?id=162342
2750
2751         Reviewed by Geoffrey Garen.
2752
2753         This gives us comprehensive support for standalone fences on x86 and ARM. The changes are as
2754         follows:
2755
2756         - Sets in stone the rule that the heaps of a B3::Fence tell you what the fence protects. If the
2757           fence reads, it protects motion of stores. If the fence writes, it protects motion of loads.
2758           This allows us to express for example load-load fences in a portable way: on x86 they will just
2759           block B3 optimizations and emit no code, while on ARM you will get some fence.
2760
2761         - Adds comprehensive support for WTF-style fences in the ARM assembler. I simplified it just a bit
2762           to match what B3, the main client, knows. There are three fences: MemoryFence, StoreFence, and
2763           LoadFence. On x86, MemoryFence is ortop while StoreFence and LoadFence emit no code. On ARM64,
2764           MemoryFence and LoadFence are dmb ish while StoreFence is dmb ishst.
2765
2766         - Tests! To test this, I needed to teach the disassembler how to disassemble dmb ish and dmb
2767           ishst. I think that the canonical way to do it would be to create a group for dmb and then teach
2768           that group how to decode the operands. But I don't actually know what are all of the ways of
2769           encoding dmb, so I'd rather that unrecognized encodings fall through to the ".long blah"
2770           bailout. So, this creates explicit matching rules for "dmb ish" and "dmb ishst", which is the
2771           most conservative thing we can do.
2772
2773         * assembler/ARM64Assembler.h:
2774         (JSC::ARM64Assembler::dmbISH):
2775         (JSC::ARM64Assembler::dmbISHST):
2776         (JSC::ARM64Assembler::dmbSY): Deleted.
2777         * assembler/MacroAssemblerARM64.h:
2778         (JSC::MacroAssemblerARM64::memoryFence):
2779         (JSC::MacroAssemblerARM64::storeFence):
2780         (JSC::MacroAssemblerARM64::loadFence):
2781         * assembler/MacroAssemblerX86Common.h:
2782         (JSC::MacroAssemblerX86Common::storeFence):
2783         (JSC::MacroAssemblerX86Common::loadFence):
2784         * b3/B3FenceValue.h:
2785         * b3/B3LowerToAir.cpp:
2786         (JSC::B3::Air::LowerToAir::lower):
2787         * b3/air/AirOpcode.opcodes:
2788         * b3/testb3.cpp:
2789         (JSC::B3::testMemoryFence):
2790         (JSC::B3::testStoreFence):
2791         (JSC::B3::testLoadFence):
2792         (JSC::B3::run):
2793         (JSC::B3::testX86MFence): Deleted.
2794         (JSC::B3::testX86CompilerFence): Deleted.
2795         * disassembler/ARM64/A64DOpcode.cpp:
2796         (JSC::ARM64Disassembler::A64DOpcodeDmbIsh::format):
2797         (JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::format):
2798         * disassembler/ARM64/A64DOpcode.h:
2799         (JSC::ARM64Disassembler::A64DOpcodeDmbIsh::opName):
2800         (JSC::ARM64Disassembler::A64DOpcodeDmbIshSt::opName):
2801
2802 2016-09-28  Joseph Pecoraro  <pecoraro@apple.com>
2803
2804         Adopt #pragma once in some generated resources
2805         https://bugs.webkit.org/show_bug.cgi?id=162666
2806
2807         Reviewed by Alex Christensen.
2808
2809         * Scripts/builtins/builtins_generate_combined_header.py:
2810         * Scripts/builtins/builtins_generate_internals_wrapper_header.py:
2811         * Scripts/builtins/builtins_generate_internals_wrapper_implementation.py:
2812         * Scripts/builtins/builtins_generate_separate_header.py:
2813         * Scripts/builtins/builtins_generate_wrapper_header.py:
2814         * Scripts/builtins/builtins_generate_wrapper_implementation.py:
2815         Remove headerGuard attribute unused by templates.
2816
2817         * Scripts/tests/builtins/expected/JavaScriptCore-Operations.Promise-Combined.js-result: Removed.
2818         No such test exists. It was likely renamed.
2819
2820         * generate-bytecode-files:
2821         Simplify header guard output.
2822
2823         * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
2824         (ObjCBackendDispatcherHeaderGenerator.generate_output):
2825         * replay/scripts/CodeGeneratorReplayInputs.py:
2826         (Generator.generate_header):
2827         * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
2828         Simplify header guard output.
2829
2830         * replay/scripts/tests/expected/generate-enum-encoding-helpers-with-guarded-values.json-TestReplayInputs.h:
2831         * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
2832         * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
2833         * replay/scripts/tests/expected/generate-enums-with-same-base-name.json-TestReplayInputs.h:
2834         * replay/scripts/tests/expected/generate-input-with-guard.json-TestReplayInputs.h:
2835         * replay/scripts/tests/expected/generate-input-with-vector-members.json-TestReplayInputs.h:
2836         * replay/scripts/tests/expected/generate-inputs-with-flags.json-TestReplayInputs.h:
2837         * replay/scripts/tests/expected/generate-memoized-type-modes.json-TestReplayInputs.h:
2838         Rebaseline.
2839
2840 2016-09-28  Filip Pizlo  <fpizlo@apple.com>
2841
2842         Store-load fences should be a lot cheaper on ARM
2843         https://bugs.webkit.org/show_bug.cgi?id=162461
2844
2845         Rubber stamped by Keith Miller.
2846
2847         It turns out that they are already cheap enough, so this change just make us use them.
2848
2849         * heap/SlotVisitor.cpp:
2850         (JSC::SlotVisitor::visitChildren):
2851
2852 2016-09-28  Ryan Haddad  <ryanhaddad@apple.com>
2853
2854         Unreviewed, rolling out r206522.
2855
2856         Roll r206506 back in since the build fix landed in r206521
2857
2858         Reverted changeset:
2859
2860         "Unreviewed, rolling out r206506."
2861         https://bugs.webkit.org/show_bug.cgi?id=162682
2862         http://trac.webkit.org/changeset/206522
2863
2864 2016-09-28  Commit Queue  <commit-queue@webkit.org>
2865
2866         Unreviewed, rolling out r206506.
2867         https://bugs.webkit.org/show_bug.cgi?id=162682
2868
2869         Broke the Windows and WinCairo builds. (Requested by
2870         ryanhaddad on #webkit).
2871
2872         Reverted changeset:
2873
2874         "Adopt #pragma once in JavaScriptCore"
2875         https://bugs.webkit.org/show_bug.cgi?id=162664
2876         http://trac.webkit.org/changeset/206506
2877
2878 2016-09-28  Joseph Pecoraro  <pecoraro@apple.com>
2879
2880         Adopt #pragma once in JavaScriptCore
2881         https://bugs.webkit.org/show_bug.cgi?id=162664
2882
2883         Reviewed by Saam Barati.
2884
2885         * **/**.h:
2886         Adopt pragma once in all but API headers and generated headers.
2887         Include some namespace closing comments for consistency.
2888
2889 2016-09-27  JF Bastien  <jfbastien@apple.com>
2890
2891         Missing Atomics.h include in MarkedBlock.h
2892         https://bugs.webkit.org/show_bug.cgi?id=162648
2893
2894         Missing include from my previous patch.
2895
2896         Reviewed by Yusuke Suzuki.
2897
2898         * heap/MarkedBlock.h:
2899
2900 2016-09-27  Mark Lam  <mark.lam@apple.com>
2901
2902         createError() and JSObject::calculatedClassName() should not throw any exceptions.
2903         https://bugs.webkit.org/show_bug.cgi?id=162637
2904
2905         Reviewed by Geoffrey Garen.
2906
2907         * runtime/ExceptionHelpers.cpp:
2908         (JSC::createError):
2909         - assert that errorDescriptionForValue() did not throw an exception.
2910
2911         * runtime/JSObject.cpp:
2912         (JSC::JSObject::calculatedClassName):
2913         - the code already ensures that we always return a non-null String.  Just need to
2914           make sure that it catches its own exceptions.
2915
2916 2016-09-27  Filip Pizlo  <fpizlo@apple.com>
2917
2918         B3::lowerMacros forgets to before->updatePredecessorsAfter() when lowering ChillMod on ARM64
2919         https://bugs.webkit.org/show_bug.cgi?id=162644
2920
2921         Reviewed by Keith Miller.
2922
2923         If you forget to update the predecessors of your successors, then bad things will happen if you
2924         do something that requires accurate predecessors for correctness. lowerMacros() uses
2925         BlockInsertionSet, which relies on accurate predecessors.
2926
2927         * b3/B3LowerMacros.cpp:
2928
2929 2016-09-27  JF Bastien  <jfbastien@apple.com>
2930
2931         Speed up Heap::isMarkedConcurrently
2932         https://bugs.webkit.org/show_bug.cgi?id=162095
2933
2934         Reviewed by Filip Pizlo.
2935
2936         Speed up isMarkedConcurrently by using WTF::consumeLoad.
2937
2938         * heap/MarkedBlock.h:
2939         (JSC::MarkedBlock::areMarksStale):
2940         (JSC::MarkedBlock::areMarksStaleWithDependency):
2941         (JSC::MarkedBlock::isMarkedConcurrently): do away with the load-load fence
2942
2943 2016-09-27  Mark Lam  <mark.lam@apple.com>
2944
2945         Add some needed CatchScopes in code that should not throw.
2946         https://bugs.webkit.org/show_bug.cgi?id=162584
2947
2948         Reviewed by Keith Miller.
2949
2950         Re-landing minus the jsc.cpp and ExceptionHelpers.cpp changes.  I'll address
2951         those in a subsequent patch if the need manifests again in my testing.
2952
2953         * API/JSObjectRef.cpp:
2954         (JSObjectSetProperty):
2955         - This function already handles exceptions in its own way.  We're honoring this
2956           contract and catching exceptions and passing it to the handler.
2957
2958         * interpreter/Interpreter.cpp:
2959         (JSC::notifyDebuggerOfUnwinding):
2960         - The debugger should not be throwing any exceptions.
2961
2962         * profiler/ProfilerDatabase.cpp:
2963         (JSC::Profiler::Database::save):
2964         - If an exception was thrown while saving the database, there's nothing we can
2965           really do about it anyway.  Just fail nicely and return false.  This is in line
2966           with existing error checking code in Database::save() that returns false if
2967           it's not able to open the file to save to.
2968
2969         * runtime/JSModuleLoader.cpp:
2970         (JSC::JSModuleLoader::finishCreation):
2971         - The existing code already RELEASE_ASSERT that no exception was thrown.
2972           Hence, it's appropriate to use a CatchScope here.
2973
2974         * runtime/SamplingProfiler.cpp:
2975         (JSC::SamplingProfiler::StackFrame::nameFromCallee):
2976         - The sampling profiler is doing a VMInquiry get here.  It should never throw an
2977           exception.  Hence, we'll just use a CatchScope and assert accordingly.
2978
2979 2016-09-27  Jer Noble  <jer.noble@apple.com>
2980
2981         Remove deprecated ENCRYPTED_MEDIA implementation.
2982         https://bugs.webkit.org/show_bug.cgi?id=161010
2983
2984         Reviewed by Eric Carlson.
2985
2986         Remove ENABLE_ENCRYPTED_MEDIA.
2987
2988         * Configurations/FeatureDefines.xcconfig:
2989
2990 2016-09-27  Michael Catanzaro  <mcatanzaro@igalia.com>
2991
2992         [GTK] Install binaries to pkglibexecdir rather than bindir
2993         https://bugs.webkit.org/show_bug.cgi?id=162602
2994
2995         Reviewed by Carlos Garcia Campos.
2996
2997         Install jsc shell to LIBEXEC_INSTALL_DIR rather than EXEC_INSTALL_DIR.
2998
2999         Note these locations are the same on non-GTK ports.
3000
3001         * shell/CMakeLists.txt:
3002
3003 2016-09-26  Sam Weinig  <sam@webkit.org>
3004
3005         Make DFGSlowPathGenerator a bit more variadic
3006         https://bugs.webkit.org/show_bug.cgi?id=162378
3007
3008         Reviewed by Filip Pizlo.
3009
3010         Make the subclass of CallSlowPathGenerator that takes arguments variadic
3011         so it can take any number of arguments. Also updates the slowPathCall helper
3012         function to be variadic. I had to move the spill mode and exception check 
3013         requirement parameters to before the arguments since the variadic arguments
3014         must be at the end. As a convenience, I added an overload of slowPathCall that
3015         doesn't take spill mode and exception check requirement parameters.
3016
3017         * dfg/DFGSlowPathGenerator.h:
3018         (JSC::DFG::CallResultAndArgumentsSlowPathGenerator::CallResultAndArgumentsSlowPathGenerator):
3019         (JSC::DFG::CallResultAndArgumentsSlowPathGenerator::unpackAndGenerate):
3020         (JSC::DFG::slowPathCall):
3021         (JSC::DFG::CallResultAndNoArgumentsSlowPathGenerator::CallResultAndNoArgumentsSlowPathGenerator): Deleted.
3022         (JSC::DFG::CallResultAndOneArgumentSlowPathGenerator::CallResultAndOneArgumentSlowPathGenerator): Deleted.
3023         (JSC::DFG::CallResultAndTwoArgumentsSlowPathGenerator::CallResultAndTwoArgumentsSlowPathGenerator): Deleted.
3024         (JSC::DFG::CallResultAndThreeArgumentsSlowPathGenerator::CallResultAndThreeArgumentsSlowPathGenerator): Deleted.
3025         (JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::CallResultAndFourArgumentsSlowPathGenerator): Deleted.
3026         (JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::generateInternal): Deleted.
3027         (JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::CallResultAndFiveArgumentsSlowPathGenerator): Deleted.
3028         (JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::generateInternal): Deleted.
3029         * dfg/DFGSpeculativeJIT.cpp:
3030         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
3031         (JSC::DFG::SpeculativeJIT::compileNotifyWrite):
3032         * dfg/DFGSpeculativeJIT64.cpp:
3033         (JSC::DFG::SpeculativeJIT::cachedGetById):
3034
3035 2016-09-26  Commit Queue  <commit-queue@webkit.org>
3036
3037         Unreviewed, rolling out r206405.
3038         https://bugs.webkit.org/show_bug.cgi?id=162588
3039
3040         This change caused LayoutTest crashes. (Requested by
3041         ryanhaddad on #webkit).
3042
3043         Reverted changeset:
3044
3045         "Add some needed CatchScopes in code that should not throw."
3046         https://bugs.webkit.org/show_bug.cgi?id=162584
3047         http://trac.webkit.org/changeset/206405
3048
3049 2016-09-26  Mark Lam  <mark.lam@apple.com>
3050
3051         Add some needed CatchScopes in code that should not throw.
3052         https://bugs.webkit.org/show_bug.cgi?id=162584
3053
3054         Reviewed by Keith Miller.
3055
3056         * API/JSObjectRef.cpp:
3057         (JSObjectSetProperty):
3058         - This function already handles exceptions in its own way.  We're honoring this
3059           contract and catching exceptions and passing it to the handler.
3060
3061         * interpreter/Interpreter.cpp:
3062         (JSC::notifyDebuggerOfUnwinding):
3063         - The debugger should not be throwing any exceptions.
3064
3065         * jsc.cpp:
3066         (runJSC):
3067         - the buck stops here.  There's no reason an exception should propagate past here.
3068
3069         * profiler/ProfilerDatabase.cpp:
3070         (JSC::Profiler::Database::save):
3071         - If an exception was thrown while saving the database, there's nothing we can
3072           really do about it anyway.  Just fail nicely and return false.  This is in line
3073           with existing error checking code in Database::save() that returns false if
3074           it's not able to open the file to save to.
3075
3076         * runtime/ExceptionHelpers.cpp:
3077         (JSC::createError):
3078         - If we're not able to stringify the error value, then we'll just use the
3079           provided message as the error string.  It doesn't make sense to have the
3080           Error factory throw an exception that shadows the intended exception that the
3081           client probably wants to throw (assuming that that's why the client is creating
3082           this Error object).
3083
3084         * runtime/JSModuleLoader.cpp:
3085         (JSC::JSModuleLoader::finishCreation):
3086         - The existing code already RELEASE_ASSERT that no exception was thrown.
3087           Hence, it's appropriate to use a CatchScope here.
3088
3089         * runtime/SamplingProfiler.cpp:
3090         (JSC::SamplingProfiler::StackFrame::nameFromCallee):
3091         - The sampling profiler is doing a VMInquiry get here.  It should never throw an
3092           exception.  Hence, we'll just use a CatchScope and assert accordingly.
3093
3094 2016-09-26  Mark Lam  <mark.lam@apple.com>
3095
3096         Exception unwinding code should use a CatchScope instead of a ThrowScope.
3097         https://bugs.webkit.org/show_bug.cgi?id=162583
3098
3099         Reviewed by Geoffrey Garen.
3100
3101         This is because the exception unwinding code does not throw an exception.
3102         It only inspects the thrown exception and passes it to the appropriate handler.
3103
3104         * interpreter/Interpreter.cpp:
3105         (JSC::Interpreter::unwind):
3106         * jit/JITExceptions.cpp:
3107         (JSC::genericUnwind):
3108
3109 2016-09-26  Joseph Pecoraro  <pecoraro@apple.com>
3110
3111         Add an Option to disable the CodeCache
3112         https://bugs.webkit.org/show_bug.cgi?id=162579
3113
3114         Reviewed by Geoffrey Garen.
3115
3116         * runtime/CodeCache.cpp:
3117         (JSC::CodeCache::getGlobalCodeBlock):
3118         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
3119         Do not use the cache if the Option is disabled.
3120
3121         * runtime/Options.h:
3122         New option to not use the code cache.
3123
3124 2016-09-26  Daniel Bates  <dabates@apple.com>
3125
3126         Rename IOS_TEXT_AUTOSIZING to TEXT_AUTOSIZING
3127         https://bugs.webkit.org/show_bug.cgi?id=162365
3128
3129         Reviewed by Simon Fraser.
3130
3131         * Configurations/FeatureDefines.xcconfig:
3132
3133 2016-09-26  Benjamin Poulain  <benjamin@webkit.org>
3134
3135         [JSC] Shrink the Math inline caches some more
3136         https://bugs.webkit.org/show_bug.cgi?id=162485
3137
3138         Reviewed by Saam Barati.
3139
3140         This patch applies some lessons learnt from op_negate
3141         to shrink the generated asm of the previous 3 inline
3142         caches.
3143
3144         In order of importance:
3145         -We do not need to pass the pointer to ArithProfile
3146          on the slow path. We can just get the profile out
3147          of the Math IC.
3148          This saves us from materializing a 64bits value
3149          in a register before the call on the slow path.
3150         -We can remove a bunch of mov by setting up the registers
3151          in the way the slow path needs them.
3152          The slow path makes a function calls with the input
3153          as second and third arguments, and return the result in
3154          the "return register". By using those as target when
3155          loading/storing from the stack, we remove 3 mov per slow path.
3156         -When performing integer add, we can set the result directly in
3157          the output register if that does not trashes one of the input
3158          register. This removes one mov per integer add.
3159
3160         The inline cache average sizes on Sunspider change as follow:
3161         -Adds: 147.573099->131.555556 (~10%)
3162         -Muls: 186.882353->170.991597 (~8%)
3163         -Subs: 139.127907->121.523256 (~12%)
3164
3165         * jit/JIT.h:
3166         * jit/JITAddGenerator.cpp:
3167         (JSC::JITAddGenerator::generateInline):
3168         (JSC::JITAddGenerator::generateFastPath):
3169         * jit/JITArithmetic.cpp:
3170         (JSC::JIT::emitMathICFast):
3171         (JSC::JIT::emitMathICSlow):
3172         * jit/JITInlines.h:
3173         (JSC::JIT::callOperation): Deleted.
3174         * jit/JITOperations.cpp:
3175         * jit/JITOperations.h:
3176
3177 2016-09-26  Mark Lam  <mark.lam@apple.com>
3178
3179         Added RETURN_IF_EXCEPTION() macro and use it for exception checks.
3180         https://bugs.webkit.org/show_bug.cgi?id=162521
3181
3182         Reviewed by Saam Barati.
3183
3184         Also, where possible, if the return type is JSValue, changed the returned value
3185         (on exception) to the empty JSValue (instead of sometimes jsUndefined, jsNull,
3186         or the thrown exception value).
3187
3188         There are a few places where I had to continue to return the previously returned
3189         value (instead of the empty JSValue) in order for tests to pass.  This is needed
3190         because there are missing exception checks that will need to be added before I
3191         can change those to return the empty JSValue too.  Identifying all the places
3192         where those checks need to be added is beyond the scope of this patch.  I will
3193         work on adding missing exception checks in a subsequent patch.
3194
3195         In this patch, there is one missing exception check in replaceUsingRegExpSearch()
3196         that was easily identified, and is necessary so that Interpreter::execute()
3197         functions can return JSValue.  I've added this missing check.
3198
3199         This patch has passed the JSC and layout tests.
3200
3201         * dfg/DFGOperations.cpp:
3202         (JSC::DFG::operationPutByValInternal):
3203         * inspector/JSInjectedScriptHost.cpp:
3204         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
3205         (Inspector::JSInjectedScriptHost::getInternalProperties):
3206         (Inspector::JSInjectedScriptHost::weakMapEntries):
3207         (Inspector::JSInjectedScriptHost::weakSetEntries):
3208         (Inspector::JSInjectedScriptHost::iteratorEntries):
3209         * inspector/JSJavaScriptCallFrame.cpp:
3210         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
3211         * interpreter/Interpreter.cpp:
3212         (JSC::eval):
3213         (JSC::sizeOfVarargs):
3214         (JSC::Interpreter::execute):
3215         (JSC::Interpreter::executeCall):
3216         (JSC::Interpreter::executeConstruct):
3217         * interpreter/ShadowChicken.cpp:
3218         (JSC::ShadowChicken::functionsOnStack):
3219         * jit/JITOperations.cpp:
3220         (JSC::getByVal):
3221         * jsc.cpp:
3222         (WTF::ImpureGetter::getOwnPropertySlot):
3223         (functionRun):
3224         (functionRunString):
3225         (functionLoad):
3226         (functionLoadString):
3227         (functionReadFile):
3228         (functionCheckSyntax):
3229         (functionSetRandomSeed):
3230         (functionLoadModule):
3231         (functionCreateBuiltin):
3232         (functionCheckModuleSyntax):
3233         * llint/LLIntSlowPaths.cpp:
3234         (JSC::LLInt::getByVal):
3235         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3236         * profiler/ProfilerBytecodeSequence.cpp:
3237         (JSC::Profiler::BytecodeSequence::addSequenceProperties):
3238         * profiler/ProfilerCompilation.cpp:
3239         (JSC::Profiler::Compilation::toJS):
3240         * profiler/ProfilerDatabase.cpp:
3241         (JSC::Profiler::Database::toJS):
3242         * profiler/ProfilerOSRExitSite.cpp:
3243         (JSC::Profiler::OSRExitSite::toJS):
3244         * profiler/ProfilerOriginStack.cpp:
3245         (JSC::Profiler::OriginStack::toJS):
3246         * runtime/ArrayPrototype.cpp:
3247         (JSC::speciesConstructArray):
3248         (JSC::shift):
3249         (JSC::unshift):
3250         (JSC::arrayProtoFuncToString):
3251         (JSC::arrayProtoFuncToLocaleString):
3252         (JSC::slowJoin):
3253         (JSC::fastJoin):
3254         (JSC::arrayProtoFuncJoin):
3255         (JSC::arrayProtoFuncPop):
3256         (JSC::arrayProtoFuncPush):
3257         (JSC::arrayProtoFuncReverse):
3258         (JSC::arrayProtoFuncShift):
3259         (JSC::arrayProtoFuncSlice):
3260         (JSC::arrayProtoFuncSplice):
3261         (JSC::arrayProtoFuncUnShift):
3262         (JSC::arrayProtoFuncIndexOf):
3263         (JSC::arrayProtoFuncLastIndexOf):
3264         (JSC::moveElements):
3265         (JSC::arrayProtoPrivateFuncConcatMemcpy):
3266         * runtime/BooleanConstructor.cpp:
3267         (JSC::constructWithBooleanConstructor):
3268         * runtime/CommonSlowPaths.h:
3269         (JSC::CommonSlowPaths::opIn):
3270         * runtime/Completion.cpp:
3271         (JSC::loadAndEvaluateModule):
3272         (JSC::loadModule):
3273         * runtime/ConsoleObject.cpp:
3274         (JSC::consoleProtoFuncAssert):
3275         (JSC::consoleProtoFuncProfile):
3276         (JSC::consoleProtoFuncProfileEnd):
3277         (JSC::consoleProtoFuncTakeHeapSnapshot):
3278         (JSC::consoleProtoFuncTime):
3279         (JSC::consoleProtoFuncTimeEnd):
3280         * runtime/DateConstructor.cpp:
3281         (JSC::constructDate):
3282         (JSC::dateParse):
3283         * runtime/DatePrototype.cpp:
3284         (JSC::dateProtoFuncToPrimitiveSymbol):
3285         (JSC::dateProtoFuncToJSON):
3286         * runtime/ErrorConstructor.cpp:
3287         (JSC::Interpreter::constructWithErrorConstructor):
3288         * runtime/ErrorInstance.cpp:
3289         (JSC::ErrorInstance::sanitizedToString):
3290         * runtime/ErrorPrototype.cpp:
3291         (JSC::errorProtoFuncToString):
3292         * runtime/ExceptionScope.h:
3293         * runtime/FunctionConstructor.cpp:
3294         (JSC::constructFunctionSkippingEvalEnabledCheck):
3295         * runtime/GenericArgumentsInlines.h:
3296         (JSC::GenericArguments<Type>::copyToArguments):
3297         * runtime/GetterSetter.cpp:
3298         (JSC::callGetter):
3299         * runtime/HashMapImpl.h:
3300         (JSC::jsMapHash):
3301         (JSC::HashMapImpl::finishCreation):
3302         (JSC::HashMapImpl::findBucket):
3303         (JSC::HashMapImpl::add):
3304         (JSC::HashMapImpl::rehash):
3305         * runtime/InspectorInstrumentationObject.cpp:
3306         (JSC::inspectorInstrumentationObjectLog):
3307         * runtime/InternalFunction.cpp:
3308         (JSC::InternalFunction::createSubclassStructure):
3309         * runtime/IntlCollator.cpp:
3310         (JSC::IntlCollator::initializeCollator):
3311         * runtime/IntlCollatorConstructor.cpp:
3312         (JSC::constructIntlCollator):
3313         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
3314         * runtime/IntlCollatorPrototype.cpp:
3315         (JSC::IntlCollatorFuncCompare):
3316         (JSC::IntlCollatorPrototypeGetterCompare):
3317         * runtime/IntlDateTimeFormat.cpp:
3318         (JSC::toDateTimeOptionsAnyDate):
3319         (JSC::IntlDateTimeFormat::initializeDateTimeFormat):
3320         * runtime/IntlDateTimeFormatConstructor.cpp:
3321         (JSC::constructIntlDateTimeFormat):
3322         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
3323         * runtime/IntlDateTimeFormatPrototype.cpp:
3324         (JSC::IntlDateTimeFormatFuncFormatDateTime):
3325         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
3326         * runtime/IntlNumberFormat.cpp:
3327         (JSC::IntlNumberFormat::initializeNumberFormat):
3328         * runtime/IntlNumberFormatConstructor.cpp:
3329         (JSC::constructIntlNumberFormat):
3330         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
3331         * runtime/IntlNumberFormatPrototype.cpp:
3332         (JSC::IntlNumberFormatFuncFormatNumber):
3333         (JSC::IntlNumberFormatPrototypeGetterFormat):
3334         * runtime/IntlObject.cpp:
3335         (JSC::intlBooleanOption):
3336         (JSC::intlStringOption):
3337         (JSC::intlNumberOption):
3338         (JSC::canonicalizeLocaleList):
3339         (JSC::supportedLocales):
3340         * runtime/IntlObjectInlines.h:
3341         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
3342         * runtime/IteratorOperations.cpp:
3343         (JSC::iteratorNext):
3344         (JSC::iteratorStep):
3345         (JSC::iteratorClose):
3346         (JSC::iteratorForIterable):
3347         * runtime/IteratorOperations.h:
3348         (JSC::forEachInIterable):
3349         * runtime/JSArray.cpp:
3350         (JSC::JSArray::pop):
3351         (JSC::JSArray::copyToArguments):
3352         * runtime/JSArrayBufferConstructor.cpp:
3353         (JSC::constructArrayBuffer):
3354         * runtime/JSArrayBufferPrototype.cpp:
3355         (JSC::arrayBufferProtoFuncSlice):
3356         * runtime/JSArrayInlines.h:
3357         (JSC::getLength):
3358         (JSC::toLength):
3359         * runtime/JSBoundFunction.cpp:
3360         (JSC::getBoundFunctionStructure):
3361         (JSC::JSBoundFunction::create):
3362         * runtime/JSCJSValue.cpp:
3363         (JSC::JSValue::putToPrimitive):
3364         (JSC::JSValue::toStringSlowCase):
3365         * runtime/JSCJSValueInlines.h:
3366         (JSC::toPreferredPrimitiveType):
3367         (JSC::JSValue::getPropertySlot):
3368         (JSC::JSValue::equalSlowCaseInline):
3369         * runtime/JSDataViewPrototype.cpp:
3370         (JSC::getData):
3371         (JSC::setData):
3372         * runtime/JSFunction.cpp:
3373         (JSC::JSFunction::setFunctionName):
3374         * runtime/JSGenericTypedArrayView.h:
3375         (JSC::JSGenericTypedArrayView::setIndex):
3376         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
3377         (JSC::constructGenericTypedArrayViewFromIterator):
3378         (JSC::constructGenericTypedArrayViewWithArguments):
3379         (JSC::constructGenericTypedArrayView):
3380         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
3381         (JSC::speciesConstruct):
3382         (JSC::genericTypedArrayViewProtoFuncSet):
3383         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
3384         (JSC::genericTypedArrayViewProtoFuncIncludes):
3385         (JSC::genericTypedArrayViewProtoFuncIndexOf):
3386         (JSC::genericTypedArrayViewProtoFuncJoin):
3387         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
3388         (JSC::genericTypedArrayViewProtoFuncSlice):
3389         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
3390         * runtime/JSGlobalObject.h:
3391         (JSC::constructEmptyArray):
3392         (JSC::constructArray):
3393         (JSC::constructArrayNegativeIndexed):
3394         * runtime/JSGlobalObjectFunctions.cpp:
3395         (JSC::globalFuncEval):
3396         * runtime/JSModuleRecord.cpp:
3397         (JSC::JSModuleRecord::instantiateDeclarations):
3398         * runtime/JSONObject.cpp:
3399         (JSC::Stringifier::stringify):
3400         (JSC::Stringifier::toJSON):
3401         (JSC::Stringifier::appendStringifiedValue):
3402         (JSC::Stringifier::Holder::appendNextProperty):
3403         (JSC::Walker::walk):
3404         (JSC::JSONProtoFuncParse):
3405         * runtime/JSObject.cpp:
3406         (JSC::ordinarySetSlow):
3407         (JSC::JSObject::setPrototypeWithCycleCheck):
3408         (JSC::callToPrimitiveFunction):
3409         (JSC::JSObject::defaultHasInstance):
3410         (JSC::JSObject::getPropertyNames):
3411         (JSC::JSObject::toNumber):
3412         (JSC::JSObject::toString):
3413         (JSC::JSObject::defineOwnNonIndexProperty):
3414         (JSC::JSObject::getGenericPropertyNames):
3415         (JSC::JSObject::getMethod):
3416         * runtime/JSObjectInlines.h:
3417         (JSC::createListFromArrayLike):
3418         (JSC::JSObject::getPropertySlot):
3419         (JSC::JSObject::getNonIndexPropertySlot):
3420         * runtime/JSPromiseConstructor.cpp:
3421         (JSC::constructPromise):
3422         * runtime/JSPromiseDeferred.cpp:
3423         (JSC::JSPromiseDeferred::create):
3424         * runtime/JSPropertyNameEnumerator.h:
3425         (JSC::propertyNameEnumerator):
3426         * runtime/JSPropertyNameIterator.cpp:
3427         (JSC::JSPropertyNameIterator::create):
3428         * runtime/JSScope.cpp:
3429         (JSC::isUnscopable):
3430         * runtime/JSString.cpp:
3431         (JSC::JSString::equalSlowCase):
3432         * runtime/JSStringJoiner.cpp:
3433         (JSC::JSStringJoiner::join):
3434         * runtime/LiteralParser.cpp:
3435         (JSC::LiteralParser<CharType>::parse):
3436         * runtime/MapBase.h:
3437         (JSC::MapBase::finishCreation):
3438         * runtime/MapConstructor.cpp:
3439         (JSC::constructMap):
3440         * runtime/MathObject.cpp:
3441         (JSC::mathProtoFuncClz32):
3442         (JSC::mathProtoFuncHypot):
3443         (JSC::mathProtoFuncIMul):
3444         * runtime/ModuleLoaderPrototype.cpp:
3445         (JSC::moduleLoaderPrototypeParseModule):
3446         (JSC::moduleLoaderPrototypeRequestedModules):
3447         (JSC::moduleLoaderPrototypeModuleDeclarationInstantiation):
3448         * runtime/NativeErrorConstructor.cpp:
3449         (JSC::Interpreter::constructWithNativeErrorConstructor):
3450         * runtime/NumberConstructor.cpp:
3451         (JSC::constructWithNumberConstructor):
3452         * runtime/ObjectConstructor.cpp:
3453         (JSC::constructObject):
3454         (JSC::objectConstructorGetPrototypeOf):
3455         (JSC::objectConstructorSetPrototypeOf):
3456         (JSC::objectConstructorGetOwnPropertyDescriptor):
3457         (JSC::objectConstructorGetOwnPropertyDescriptors):
3458         (JSC::objectConstructorGetOwnPropertyNames):
3459         (JSC::objectConstructorGetOwnPropertySymbols):
3460         (JSC::objectConstructorKeys):
3461         (JSC::ownEnumerablePropertyKeys):
3462         (JSC::toPropertyDescriptor):
3463         (JSC::objectConstructorDefineProperty):
3464         (JSC::defineProperties):
3465         (JSC::objectConstructorSeal):
3466         (JSC::objectConstructorFreeze):
3467         (JSC::objectConstructorIsSealed):
3468         (JSC::objectConstructorIsFrozen):
3469         (JSC::objectConstructorIsExtensible):
3470         (JSC::ownPropertyKeys):
3471         * runtime/ObjectConstructor.h:
3472         (JSC::constructObjectFromPropertyDescriptor):
3473         * runtime/ObjectPrototype.cpp:
3474         (JSC::objectProtoFuncHasOwnProperty):
3475         (JSC::objectProtoFuncIsPrototypeOf):
3476         (JSC::objectProtoFuncDefineGetter):
3477         (JSC::objectProtoFuncDefineSetter):
3478         (JSC::objectProtoFuncLookupGetter):
3479         (JSC::objectProtoFuncLookupSetter):
3480         (JSC::objectProtoFuncPropertyIsEnumerable):
3481         (JSC::objectProtoFuncToLocaleString):
3482         (JSC::objectProtoFuncToString):
3483         * runtime/Operations.cpp:
3484         (JSC::jsAddSlowCase):
3485         * runtime/PropertyDescriptor.cpp:
3486         (JSC::PropertyDescriptor::slowGetterSetter):
3487         * runtime/ProxyConstructor.cpp:
3488         (JSC::makeRevocableProxy):
3489         * runtime/ProxyObject.cpp:
3490         (JSC::performProxyGet):
3491         (JSC::ProxyObject::performGet):
3492         (JSC::ProxyObject::performInternalMethodGetOwnProperty):
3493         (JSC::ProxyObject::performHasProperty):
3494         (JSC::ProxyObject::performPut):
3495         (JSC::ProxyObject::putByIndexCommon):
3496         (JSC::performProxyCall):
3497         (JSC::performProxyConstruct):
3498         (JSC::ProxyObject::performDelete):
3499         (JSC::ProxyObject::performPreventExtensions):
3500         (JSC::ProxyObject::performIsExtensible):
3501         (JSC::ProxyObject::performDefineOwnProperty):
3502         (JSC::ProxyObject::performGetOwnPropertyNames):
3503         (JSC::ProxyObject::performSetPrototype):
3504         (JSC::ProxyObject::performGetPrototype):
3505         * runtime/ReflectObject.cpp:
3506         (JSC::reflectObjectConstruct):
3507         (JSC::reflectObjectDefineProperty):
3508         (JSC::reflectObjectGet):
3509         (JSC::reflectObjectGetOwnPropertyDescriptor):
3510         (JSC::reflectObjectIsExtensible):
3511         (JSC::reflectObjectPreventExtensions):
3512         (JSC::reflectObjectSet):
3513         (JSC::reflectObjectSetPrototypeOf):
3514         * runtime/RegExpConstructor.cpp:
3515         (JSC::toFlags):
3516         (JSC::regExpCreate):
3517         (JSC::constructRegExp):
3518         * runtime/RegExpConstructor.h:
3519         (JSC::isRegExp):
3520         * runtime/RegExpObject.cpp:
3521         (JSC::collectMatches):
3522         (JSC::RegExpObject::matchGlobal):
3523         * runtime/RegExpPrototype.cpp:
3524         (JSC::regExpProtoFuncCompile):
3525         (JSC::flagsString):
3526         (JSC::regExpProtoFuncToString):
3527         (JSC::regExpProtoGetterFlags):
3528         (JSC::regExpProtoFuncSearchFast):
3529         (JSC::regExpProtoFuncSplitFast):
3530         * runtime/SetConstructor.cpp:
3531         (JSC::constructSet):
3532         * runtime/StringConstructor.cpp:
3533         (JSC::stringFromCodePoint):
3534         (JSC::constructWithStringConstructor):
3535         * runtime/StringObject.cpp:
3536         (JSC::StringObject::defineOwnProperty):
3537         * runtime/StringPrototype.cpp:
3538         (JSC::replaceUsingRegExpSearch):
3539         (JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
3540         (JSC::replaceUsingStringSearch):
3541         (JSC::replace):
3542         (JSC::stringProtoFuncReplaceUsingRegExp):
3543         (JSC::stringProtoFuncReplaceUsingStringSearch):
3544         (JSC::stringProtoFuncCodePointAt):
3545         (JSC::stringProtoFuncSlice):
3546         (JSC::stringProtoFuncSplitFast):
3547         (JSC::stringProtoFuncSubstr):
3548         (JSC::stringProtoFuncSubstring):
3549         (JSC::stringProtoFuncLocaleCompare):
3550         (JSC::toLocaleCase):
3551         (JSC::stringProtoFuncBig):
3552         (JSC::stringProtoFuncSmall):
3553         (JSC::stringProtoFuncBlink):
3554         (JSC::stringProtoFuncBold):
3555         (JSC::stringProtoFuncFixed):
3556         (JSC::stringProtoFuncItalics):
3557         (JSC::stringProtoFuncStrike):
3558         (JSC::stringProtoFuncSub):
3559         (JSC::stringProtoFuncSup):
3560         (JSC::stringProtoFuncFontcolor):
3561         (JSC::stringProtoFuncFontsize):
3562         (JSC::stringProtoFuncAnchor):
3563         (JSC::stringProtoFuncLink):
3564         (JSC::trimString):
3565         (JSC::stringProtoFuncStartsWith):
3566         (JSC::stringProtoFuncEndsWith):
3567         (JSC::stringIncludesImpl):
3568         (JSC::stringProtoFuncIncludes):
3569         (JSC::builtinStringIncludesInternal):
3570         (JSC::stringProtoFuncNormalize):
3571         * runtime/SymbolConstructor.cpp:
3572         (JSC::symbolConstructorFor):
3573         * runtime/TemplateRegistry.cpp:
3574         (JSC::TemplateRegistry::getTemplateObject):
3575         * runtime/WeakMapConstructor.cpp:
3576         (JSC::constructWeakMap):
3577         * runtime/WeakSetConstructor.cpp:
3578         (JSC::constructWeakSet):
3579         * tools/JSDollarVMPrototype.cpp:
3580         (JSC::functionPrint):
3581
3582 2016-09-26  Don Olmstead  <don.olmstead@am.sony.com>
3583
3584         [JSC] Allow fixedExecutableMemoryPoolSize to be set during build
3585         https://bugs.webkit.org/show_bug.cgi?id=162514
3586
3587         Reviewed by Mark Lam.
3588
3589         * jit/ExecutableAllocator.h:
3590
3591 == Rolled over to ChangeLog-2016-09-26 ==