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