Unreviewed, rolling out r207557.
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-10-19  Ryan Haddad  <ryanhaddad@apple.com>
2
3         Unreviewed, rolling out r207557.
4
5         This change caused animations/font-variations tests to time
6         out on pre-Sierra Macs.
7
8         Reverted changeset:
9
10         "[macOS] [iOS] Disable variation fonts on macOS El Capitan and
11         iOS 9"
12         https://bugs.webkit.org/show_bug.cgi?id=163374
13         http://trac.webkit.org/changeset/207557
14
15 2016-10-19  Filip Pizlo  <fpizlo@apple.com>
16
17         Baseline JIT should use AutomaticThread
18         https://bugs.webkit.org/show_bug.cgi?id=163686
19
20         Reviewed by Geoffrey Garen.
21         
22         Change the JITWorklist to use AutomaticThread, so that the Baseline JIT's concurrent
23         compiler thread shuts down automatically after inactivity.
24         
25         With this change, all of JSC's threads shut down automatically. If you run splay for a few
26         seconds (which fires up all threads - compiler and GC) and then go to sleep for a second,
27         you'll see that the only threads left are the main thread and the bmalloc thread.
28
29         * jit/JITWorklist.cpp:
30         (JSC::JITWorklist::Thread::Thread):
31         (JSC::JITWorklist::JITWorklist):
32         (JSC::JITWorklist::completeAllForVM):
33         (JSC::JITWorklist::poll):
34         (JSC::JITWorklist::compileLater):
35         (JSC::JITWorklist::compileNow):
36         (JSC::JITWorklist::finalizePlans):
37         (JSC::JITWorklist::runThread): Deleted.
38         * jit/JITWorklist.h:
39
40 2016-10-19  Myles C. Maxfield  <mmaxfield@apple.com>
41
42         [macOS] [iOS] Disable variation fonts on macOS El Capitan and iOS 9
43         https://bugs.webkit.org/show_bug.cgi?id=163374
44
45         Reviewed by Darin Adler.
46
47         * Configurations/FeatureDefines.xcconfig:
48
49 2016-10-19  Aaron Chu  <aaron_chu@apple.com>
50
51         Web Inspector: AXI: expose computed tree node and heading level
52         https://bugs.webkit.org/show_bug.cgi?id=130825
53         <rdar://problem/16442349>
54
55         Reviewed by Joseph Pecoraro.
56
57         Exposing two new accessibility properties: Heading Level and Hierarchical Level.
58
59         * inspector/protocol/DOM.json:
60
61 2016-10-18  Filip Pizlo  <fpizlo@apple.com>
62
63         DFG worklist should use AutomaticThread
64         https://bugs.webkit.org/show_bug.cgi?id=163615
65
66         Reviewed by Mark Lam.
67         
68         AutomaticThread is a new feature in WTF that allows you to easily create worker threads that
69         shut down automatically. This changes DFG::Worklist to use AutomaticThread, so that its
70         threads shut down automatically, too. This has the potential to save a lot of memory.
71         
72         This required some improvements to AutomaticThread: Worklist likes to be able to keep state
73         around for the whole lifetime of a thread, and so it likes knowing when threads are born and
74         when they die. I added virtual methods for that. Also, Worklist uses notifyOne() so I added
75         that, too.
76         
77         This looks to be perf-neutral.
78
79         * dfg/DFGThreadData.cpp:
80         (JSC::DFG::ThreadData::ThreadData):
81         * dfg/DFGThreadData.h:
82         * dfg/DFGWorklist.cpp:
83         (JSC::DFG::Worklist::ThreadBody::ThreadBody):
84         (JSC::DFG::Worklist::Worklist):
85         (JSC::DFG::Worklist::~Worklist):
86         (JSC::DFG::Worklist::finishCreation):
87         (JSC::DFG::Worklist::isActiveForVM):
88         (JSC::DFG::Worklist::enqueue):
89         (JSC::DFG::Worklist::compilationState):
90         (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
91         (JSC::DFG::Worklist::removeAllReadyPlansForVM):
92         (JSC::DFG::Worklist::completeAllReadyPlansForVM):
93         (JSC::DFG::Worklist::rememberCodeBlocks):
94         (JSC::DFG::Worklist::visitWeakReferences):
95         (JSC::DFG::Worklist::removeDeadPlans):
96         (JSC::DFG::Worklist::removeNonCompilingPlansForVM):
97         (JSC::DFG::Worklist::queueLength):
98         (JSC::DFG::Worklist::dump):
99         (JSC::DFG::Worklist::runThread): Deleted.
100         (JSC::DFG::Worklist::threadFunction): Deleted.
101         * dfg/DFGWorklist.h:
102
103 2016-10-19  Dan Bernstein  <mitz@apple.com>
104
105         [Xcode] JavaScriptCore fails to build when CLANG_WARN_DOCUMENTATION_COMMENTS is enabled
106         https://bugs.webkit.org/show_bug.cgi?id=163642
107
108         Reviewed by Darin Adler.
109
110         * API/JSClassRef.cpp: Removed a bad headerdoc comment inside an implementation file.
111         * API/JSContext.h: Changed @methodgroup to @functiongroup, because the compiler requires the
112           former to be followed by a method (and we have a property), but not the latter. Changed
113           a couple of instances of “method” to “@method”. Removed empty @param entries.
114         * API/JSContextRefInternal.h: Named a parameter referenced in a @param entry.
115         * API/JSContextRefPrivate.h: Ditto.
116         * API/JSManagedValue.h: Removed empty @param entries.
117         * API/JSObjectRef.h: Corrected parameter name in @param entry.
118         * API/JSTypedArray.h: Ditto.
119         * API/JSValue.h: Removed empty @param entries, changed @methodgroup to @functiongroup, and
120           changed @method to @property where appropriate. Removed empty @param entries.
121         * API/JSValueRef.h: Named a parameter referenced in a @param entry.
122         * API/JSWeakObjectMapRefPrivate.h: Ditto.
123         * Configurations/Base.xcconfig: Enabled CLANG_WARN_DOCUMENTATION_COMMENTS. Made the compiler
124           treat the icu headers as system headers, to stop it from emitting warnings about headers
125           we don’t want to change.
126         * Configurations/ToolExecutable.xcconfig: Made the compiler treat the icu headers as system
127           headers.
128
129 2016-10-19  Csaba Osztrogonác  <ossy@webkit.org>
130
131         Unreviewed ARM buildfix after r207475.
132
133         * assembler/ARMAssembler.h:
134         (JSC::ARMAssembler::relinkJumpToNop):
135
136 2016-10-18  Mark Lam  <mark.lam@apple.com>
137
138         Invoking Object.prototype.__proto__ accessors directly should throw a TypeError.
139         https://bugs.webkit.org/show_bug.cgi?id=154377
140         <rdar://problem/27330808>
141
142         Reviewed by Filip Pizlo and Saam Barati.
143
144         In a scenario where we cache the __proto__ accessors in global variables, and
145         later explicitly invoke those accessors as functions, the spec for Function Calls
146         (see https://tc39.github.io/ecma262/#sec-function-calls) states that the function
147         ref value is of type Reference, and base of ref is an Environment Record.  Then,
148         it follows that the thisValue should be set to refEnv.WithBaseObject()
149         (see section 4.b.ii of 12.3.4.1 at
150         https://tc39.github.io/ecma262/#sec-function-calls-runtime-semantics-evaluation).
151
152         refEnv in this case is the environment record that the cached accessors were
153         found in i.e. the global object.  The WithBaseObject() of the global object is
154         undefined (see details about WithBaseObject at
155         https://tc39.github.io/ecma262/#sec-environment-records).
156
157         Hence, the __proto__ accessors should see a thisValue of undefined, and throw
158         TypeErrors.  See https://tc39.github.io/ecma262/#sec-get-object.prototype.__proto__,
159         https://tc39.github.io/ecma262/#sec-set-object.prototype.__proto__,
160         https://tc39.github.io/ecma262/#sec-toobject, and
161         https://tc39.github.io/ecma262/#sec-requireobjectcoercible.
162
163         In JSC's implementation, the callee needs to do a ToThis operation on the
164         incoming "this" argument in order to get the specified thisValue.  The
165         implementations of the __proto__ accessors were not doing this correctly.  This
166         has now been fixed.
167
168         * runtime/JSGlobalObjectFunctions.cpp:
169         (JSC::globalFuncProtoGetter):
170         (JSC::globalFuncProtoSetter):
171
172 2016-10-18  Sam Weinig  <sam@webkit.org>
173
174         Replace std::experimental::variant with WTF::Variant (or similar)
175         https://bugs.webkit.org/show_bug.cgi?id=163626
176
177         Reviewed by Chris Dumez.
178
179         Rename std::experimental::variant, Variant. Move helpers get/holds_alternative/etc.
180         into the WTF namespace.
181
182         * domjit/DOMJITReg.h:
183         (JSC::DOMJIT::Reg::gpr):
184         (JSC::DOMJIT::Reg::fpr):
185         (JSC::DOMJIT::Reg::jsValueRegs):
186
187 2016-10-18  Keith Miller  <keith_miller@apple.com>
188
189         GetByVal to GetById conversion in the DFG is incorrect for getters with control flow
190         https://bugs.webkit.org/show_bug.cgi?id=163629
191
192         Reviewed by Yusuke Suzuki.
193
194         This patch fixes a bug in the DFG when attempt to convert a
195         GetByVal into a GetById. While converting the GetByVal, during
196         handleGetById in the Bytecode parser, we would mistakenly use the
197         opcode length of op_get_by_id rather than op_get_by_val. This causes
198         the new basic block we create to point to the wrong offset. In the
199         added test this will cause us to infinite loop.
200
201         * dfg/DFGByteCodeParser.cpp:
202         (JSC::DFG::ByteCodeParser::handleGetById):
203         (JSC::DFG::ByteCodeParser::parseBlock):
204
205 2016-10-18  Dean Jackson  <dino@apple.com>
206
207         Remove CSS_SHAPES feature definition. This should always be on.
208         https://bugs.webkit.org/show_bug.cgi?id=163628
209         <rdar://problem/28834613>
210         Reviewed by Tim Horton.
211
212         * Configurations/FeatureDefines.xcconfig:
213
214 2016-10-18  Michael Saboff  <msaboff@apple.com>
215
216         Add JSC option to show time spent in each optimization phase
217         https://bugs.webkit.org/show_bug.cgi?id=163617
218
219         Reviewed by Saam Barati.
220
221         Added reportDFGPhaseTimes option.  This outputs one line per phase similar to
222             Phase CPS rethreading took 0.2661 ms
223
224         One line is output for each phase run.
225
226         * dfg/DFGPhase.h:
227         (JSC::DFG::runAndLog):
228         * dfg/DFGPlan.cpp:
229         (JSC::DFG::Plan::compileInThread):
230         * runtime/Options.cpp:
231         (JSC::recomputeDependentOptions):
232         * runtime/Options.h:
233
234 2016-10-18  Filip Pizlo  <fpizlo@apple.com>
235
236         WTF should make it easier to create threads that die automatically after inactivity
237         https://bugs.webkit.org/show_bug.cgi?id=163576
238
239         Reviewed by Andreas Kling.
240         
241         Added a sleepSeconds() function, which made it easier for me to test this change.
242         
243         The WTF changes in this patch change how the JSC GC manages threads: the GC threads will now
244         shut down automatically after 1 second of inactivity. Maybe this will save some memory.
245
246         * jsc.cpp:
247         (GlobalObject::finishCreation):
248         (functionSleepSeconds):
249
250 2016-10-18  Keith Miller  <keith_miller@apple.com>
251
252         Cleanup Wasm memory.
253         https://bugs.webkit.org/show_bug.cgi?id=163601
254
255         Reviewed by Saam Barati.
256
257         There were a couple of issues with the original Wasm memory patch.
258         This is a follow-up patch to fix those issues.
259
260         * wasm/WASMMemory.cpp:
261         (JSC::WASM::Memory::Memory):
262         * wasm/WASMMemory.h:
263
264 2016-10-15  Filip Pizlo  <fpizlo@apple.com>
265
266         DFG and FTL should be able to use DirectCall ICs when they proved the callee or its executable
267         https://bugs.webkit.org/show_bug.cgi?id=163371
268
269         Reviewed by Geoffrey Garen and Saam Barati.
270         
271         This adds a new kind of call inline cache for when the DFG can prove what the callee
272         executable is. In those cases, we can skip some of the things that the traditional call IC
273         would do:
274         
275         - No need to check who the callee is.
276         - No need to do arity checks.
277         
278         This case isn't as simple as just emitting a call instruction since the callee may not be
279         compiled at the time that the caller is compiled. So, we need lazy resolution. Also, the
280         callee may be jettisoned independently of the caller, so we need to be able to revert the
281         call to an unlinked state. This means that we need almost all of the things that
282         CallLinkInfo has. CallLinkInfo already knows about different kinds of calls. This patch
283         teaches it about new "Direct" call types.
284         
285         The direct non-tail call IC looks like this:
286         
287                 set up arguments
288             FastPath:
289                 call _SlowPath
290                 lea -FrameSize(%rbp), %rsp
291             
292             SlowPath:
293                 pop
294                 call operationLinkDirectCall
295                 check exception
296                 jmp FastPath
297         
298         The job of operationLinkDirectCall is to link the fast path's call entrypoint of the callee.
299         This means that in steady state, a call is just that: a call. There are no extra branches or
300         checks.
301         
302         The direct tail call IC is a bit more complicated because the act of setting up arguments
303         destroys our frame, which would prevent us from being able to throw an exception if we
304         failed to compile the callee. So, direct tail call ICs look like this:
305         
306                 jmp _SlowPath
307             FastPath:
308                 set up arguments
309                 jmp 0 // patch to jump to callee
310             
311             SlowPath:
312                 silent spill
313                 call operationLinkDirectCall
314                 silent fill
315                 check exception
316                 jmp FastPath
317         
318         The jmp to the slow path is patched to be a fall-through jmp when we link the call.
319         
320         Direct calls mean less code at call sites, fewer checks on the steady state call fast path,
321         and no need for arity fixup. This looks like a slight speed-up (~0.8%) on both Octane and
322         AsmBench.
323
324         * assembler/ARM64Assembler.h:
325         (JSC::ARM64Assembler::relinkJumpToNop):
326         * assembler/ARMv7Assembler.h:
327         (JSC::ARMv7Assembler::relinkJumpToNop):
328         (JSC::ARMv7Assembler::relinkJump): Deleted.
329         * assembler/AbstractMacroAssembler.h:
330         (JSC::AbstractMacroAssembler::repatchJumpToNop):
331         (JSC::AbstractMacroAssembler::repatchJump): Deleted.
332         * assembler/X86Assembler.h:
333         (JSC::X86Assembler::relinkJumpToNop):
334         * bytecode/CallLinkInfo.cpp:
335         (JSC::CallLinkInfo::CallLinkInfo):
336         (JSC::CallLinkInfo::callReturnLocation):
337         (JSC::CallLinkInfo::patchableJump):
338         (JSC::CallLinkInfo::hotPathBegin):
339         (JSC::CallLinkInfo::slowPathStart):
340         (JSC::CallLinkInfo::setCallee):
341         (JSC::CallLinkInfo::clearCallee):
342         (JSC::CallLinkInfo::callee):
343         (JSC::CallLinkInfo::setCodeBlock):
344         (JSC::CallLinkInfo::clearCodeBlock):
345         (JSC::CallLinkInfo::codeBlock):
346         (JSC::CallLinkInfo::setLastSeenCallee):
347         (JSC::CallLinkInfo::clearLastSeenCallee):
348         (JSC::CallLinkInfo::lastSeenCallee):
349         (JSC::CallLinkInfo::haveLastSeenCallee):
350         (JSC::CallLinkInfo::setExecutableDuringCompilation):
351         (JSC::CallLinkInfo::executable):
352         (JSC::CallLinkInfo::setMaxNumArguments):
353         (JSC::CallLinkInfo::visitWeak):
354         * bytecode/CallLinkInfo.h:
355         (JSC::CallLinkInfo::specializationKindFor):
356         (JSC::CallLinkInfo::callModeFor):
357         (JSC::CallLinkInfo::isDirect):
358         (JSC::CallLinkInfo::nearCallMode):
359         (JSC::CallLinkInfo::isLinked):
360         (JSC::CallLinkInfo::setCallLocations):
361         (JSC::CallLinkInfo::addressOfMaxNumArguments):
362         (JSC::CallLinkInfo::maxNumArguments):
363         (JSC::CallLinkInfo::isTailCall): Deleted.
364         (JSC::CallLinkInfo::setUpCallFromFTL): Deleted.
365         (JSC::CallLinkInfo::callReturnLocation): Deleted.
366         (JSC::CallLinkInfo::hotPathBegin): Deleted.
367         (JSC::CallLinkInfo::callee): Deleted.
368         (JSC::CallLinkInfo::setLastSeenCallee): Deleted.
369         (JSC::CallLinkInfo::clearLastSeenCallee): Deleted.
370         (JSC::CallLinkInfo::lastSeenCallee): Deleted.
371         (JSC::CallLinkInfo::haveLastSeenCallee): Deleted.
372         * bytecode/CallLinkStatus.cpp:
373         (JSC::CallLinkStatus::computeDFGStatuses):
374         * bytecode/PolymorphicAccess.cpp:
375         (JSC::AccessCase::generateImpl):
376         * bytecode/UnlinkedFunctionExecutable.h:
377         * bytecode/ValueRecovery.h:
378         (JSC::ValueRecovery::forEachReg):
379         * dfg/DFGAbstractInterpreterInlines.h:
380         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
381         * dfg/DFGBasicBlock.h:
382         (JSC::DFG::BasicBlock::findTerminal):
383         * dfg/DFGByteCodeParser.cpp:
384         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
385         (JSC::DFG::ByteCodeParser::handleCall):
386         * dfg/DFGClobberize.h:
387         (JSC::DFG::clobberize):
388         * dfg/DFGDoesGC.cpp:
389         (JSC::DFG::doesGC):
390         * dfg/DFGFixupPhase.cpp:
391         (JSC::DFG::FixupPhase::fixupNode):
392         * dfg/DFGGraph.cpp:
393         (JSC::DFG::Graph::parameterSlotsForArgCount):
394         * dfg/DFGGraph.h:
395         * dfg/DFGInPlaceAbstractState.cpp:
396         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
397         * dfg/DFGJITCompiler.cpp:
398         (JSC::DFG::JITCompiler::link):
399         * dfg/DFGJITCompiler.h:
400         (JSC::DFG::JITCompiler::addJSDirectCall):
401         (JSC::DFG::JITCompiler::addJSDirectTailCall):
402         (JSC::DFG::JITCompiler::JSCallRecord::JSCallRecord):
403         (JSC::DFG::JITCompiler::JSDirectCallRecord::JSDirectCallRecord):
404         (JSC::DFG::JITCompiler::JSDirectTailCallRecord::JSDirectTailCallRecord):
405         (JSC::DFG::JITCompiler::currentJSCallIndex): Deleted.
406         * dfg/DFGNode.cpp:
407         (JSC::DFG::Node::convertToDirectCall):
408         * dfg/DFGNode.h:
409         (JSC::DFG::Node::isTerminal):
410         (JSC::DFG::Node::hasHeapPrediction):
411         (JSC::DFG::Node::hasCellOperand):
412         * dfg/DFGNodeType.h:
413         * dfg/DFGPredictionPropagationPhase.cpp:
414         * dfg/DFGSafeToExecute.h:
415         (JSC::DFG::safeToExecute):
416         * dfg/DFGSpeculativeJIT.h:
417         (JSC::DFG::SpeculativeJIT::callOperation):
418         * dfg/DFGSpeculativeJIT64.cpp:
419         (JSC::DFG::SpeculativeJIT::emitCall):
420         (JSC::DFG::SpeculativeJIT::compile):
421         * dfg/DFGStrengthReductionPhase.cpp:
422         (JSC::DFG::StrengthReductionPhase::handleNode):
423         * ftl/FTLCapabilities.cpp:
424         (JSC::FTL::canCompile):
425         * ftl/FTLLowerDFGToB3.cpp:
426         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
427         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
428         (JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
429         (JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
430         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
431         * interpreter/Interpreter.cpp:
432         (JSC::Interpreter::execute):
433         (JSC::Interpreter::executeCall):
434         (JSC::Interpreter::executeConstruct):
435         (JSC::Interpreter::prepareForRepeatCall):
436         * jit/JIT.cpp:
437         (JSC::JIT::link):
438         * jit/JITCall.cpp:
439         (JSC::JIT::compileSetupVarargsFrame):
440         * jit/JITCall32_64.cpp:
441         (JSC::JIT::compileSetupVarargsFrame):
442         * jit/JITOperations.cpp:
443         * jit/JITOperations.h:
444         * jit/Repatch.cpp:
445         (JSC::linkDirectFor):
446         (JSC::revertCall):
447         * jit/Repatch.h:
448         * llint/LLIntSlowPaths.cpp:
449         (JSC::LLInt::setUpCall):
450         * runtime/Executable.cpp:
451         (JSC::ScriptExecutable::prepareForExecutionImpl):
452         * runtime/Executable.h:
453         (JSC::ScriptExecutable::prepareForExecution):
454         * runtime/Options.h:
455
456 2016-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
457
458         [DOMJIT] Not emit exception case if it is not necessary
459         https://bugs.webkit.org/show_bug.cgi?id=163589
460
461         Reviewed by Sam Weinig.
462
463         We should not emit exception case if we do not use the slow path calls.
464         For example, nodeType accessor does not use the slow path calls.
465
466         * bytecode/PolymorphicAccess.cpp:
467         (JSC::AccessCase::emitDOMJITGetter):
468
469 2016-10-18  Caitlin Potter  <caitp@igalia.com>
470
471         [JSC] ES6 Method functions should not have prototype
472         https://bugs.webkit.org/show_bug.cgi?id=162530
473
474         Reviewed by Saam Barati.
475
476         ECMA-262 only adds "prototype" properties to specific syntactic function forms.
477         Specific items which do not contain "prototype" include (most) built-in functions (such as Math.pow),
478         MethodDefinitions which are not either class "constructor" methods or GeneratorMethods, AsyncFunctions,
479         and ArrowFunctions.
480         
481         For details, see the following spec text, and the difference between GeneratorMethod evaluation and
482         the evaluation of other MethodDefinition forms.
483         
484         - https://tc39.github.io/ecma262/#sec-method-definitions-runtime-semantics-propertydefinitionevaluation
485         - https://tc39.github.io/ecma262/#sec-arrow-function-definitions-runtime-semantics-evaluation
486         - https://tc39.github.io/ecmascript-asyncawait/#async-function-instances
487         - https://tc39.github.io/ecma262/#sec-generator-function-definitions-runtime-semantics-propertydefinitionevaluation
488         
489
490         * runtime/Executable.h:
491         * runtime/JSFunction.cpp:
492         (JSC::JSFunction::callerGetter):
493         (JSC::JSFunction::getOwnPropertySlot):
494         (JSC::JSFunction::deleteProperty):
495
496         * bytecompiler/BytecodeGenerator.h:
497         (JSC::BytecodeGenerator::makeFunction):
498         * runtime/Executable.h:
499         * runtime/JSFunction.cpp:
500         (JSC::JSFunction::getOwnPropertySlot):
501         (JSC::JSFunction::getOwnNonIndexPropertyNames):
502         (JSC::JSFunction::put):
503         (JSC::JSFunction::deleteProperty):
504         (JSC::JSFunction::defineOwnProperty):
505         * runtime/JSGlobalObjectFunctions.cpp:
506         (JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller):
507
508 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
509
510         [DOMJIT] Use NativeCallFrameTracer for operations used for DOMJIT slow calls
511         https://bugs.webkit.org/show_bug.cgi?id=163586
512
513         Reviewed by Saam Barati.
514
515         C functions called from the DOMJIT slow path calls should use NativeCallFrameTracer.
516         This fixes the debug assertion caused in r207427.
517
518         * bytecode/DOMJITAccessCasePatchpointParams.cpp:
519         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
520         (JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
521         * bytecode/DOMJITAccessCasePatchpointParams.h:
522         * bytecode/PolymorphicAccess.cpp:
523         (JSC::AccessCase::emitDOMJITGetter):
524         * jsc.cpp:
525         (WTF::DOMJITGetter::DOMJITNodeDOMJIT::slowCall):
526         (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::slowCall):
527
528 2016-10-17  Keith Miller  <keith_miller@apple.com>
529
530         Add support for WASM Memory.
531         https://bugs.webkit.org/show_bug.cgi?id=161710
532
533         Reviewed by Geoffrey Garen.
534
535         This patch add initial support for WASM memory operations. First,
536         it adds the concept of a WASM Module memory management object.
537         This object currently mmaps a 32-bit address space for WASM use,
538         although it marks all the memory outside the current breakpoint as
539         PROT_NONE. For now, we do a range check on each store and load. In
540         the future, we should change this to be an signal handler that
541         checks what module the program trapped in.
542
543         Additionally, this patch changes the way that our temporary tests
544         call into WASM code. There is now a true "thunk" that relocates
545         arguments and calls into WASM. This thunk does not tail call
546         because we use pinned values to memory base-pointer and
547         size. We use the new B3 pinned register api to pin the values.
548
549         * CMakeLists.txt:
550         * Configurations/ToolExecutable.xcconfig:
551         * JavaScriptCore.xcodeproj/project.pbxproj:
552         * testWASM.cpp:
553         (runWASMTests):
554         (main):
555         * wasm/WASMB3IRGenerator.cpp:
556         (JSC::WASM::createJSWrapper):
557         (JSC::WASM::parseAndCompile):
558         * wasm/WASMB3IRGenerator.h:
559         * wasm/WASMCallingConvention.h:
560         (JSC::WASM::CallingConvention::iterate):
561         (JSC::WASM::CallingConvention::setupCall):
562         (JSC::WASM::nextJSCOffset):
563         * wasm/WASMFormat.h:
564         * wasm/WASMFunctionParser.h:
565         (JSC::WASM::FunctionParser<Context>::parseExpression):
566         * wasm/WASMMemory.cpp: Copied from Source/JavaScriptCore/wasm/WASMPlan.cpp.
567         (JSC::WASM::Memory::Memory):
568         * wasm/WASMMemory.h: Copied from Source/JavaScriptCore/wasm/WASMModuleParser.h.
569         (JSC::WASM::Memory::~Memory):
570         (JSC::WASM::Memory::memory):
571         (JSC::WASM::Memory::size):
572         (JSC::WASM::Memory::pinnedRegisters):
573         (JSC::WASM::Memory::mode):
574         (JSC::WASM::Memory::growMemory):
575         (JSC::WASM::Memory::offsetOfSize):
576         * wasm/WASMModuleParser.cpp:
577         (JSC::WASM::ModuleParser::parse):
578         (JSC::WASM::ModuleParser::parseMemory):
579         * wasm/WASMModuleParser.h:
580         (JSC::WASM::ModuleParser::functionInformation):
581         (JSC::WASM::ModuleParser::memory):
582         * wasm/WASMOps.h:
583         * wasm/WASMPlan.cpp:
584         (JSC::WASM::Plan::Plan):
585         * wasm/WASMPlan.h:
586         * wasm/WASMSections.h:
587
588 2016-10-17  Joseph Pecoraro  <pecoraro@apple.com>
589
590         Web Inspector: Add toggles for debugger pauses at console.assert failures
591         https://bugs.webkit.org/show_bug.cgi?id=139542
592         <rdar://problem/19281600>
593
594         Reviewed by Timothy Hatcher.
595
596         * inspector/agents/InspectorDebuggerAgent.h:
597         * inspector/agents/InspectorDebuggerAgent.cpp:
598         (Inspector::InspectorDebuggerAgent::disable):
599         (Inspector::InspectorDebuggerAgent::setPauseOnAssertions):
600         Toggle pause on assertions state. Default is disabled,
601         and disable it when frontends disconnect.
602
603         (Inspector::InspectorDebuggerAgent::handleConsoleAssert):
604         Instead of using the PauseOnAllExceptions state, use this
605         new state specific to assertions.
606
607         * inspector/protocol/Debugger.json:
608         New protocol method to toggle pausing on assertions.
609
610 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
611
612         [DOMJIT][JSC] Add Option::useDOMJIT
613         https://bugs.webkit.org/show_bug.cgi?id=163457
614
615         Reviewed by Saam Barati.
616
617         Add an option to switch the DOMJIT optimization.
618
619         * bytecode/PolymorphicAccess.cpp:
620         (JSC::AccessCase::generateImpl):
621         * dfg/DFGByteCodeParser.cpp:
622         (JSC::DFG::ByteCodeParser::handleGetById):
623         * runtime/Options.cpp:
624         (JSC::recomputeDependentOptions):
625         * runtime/Options.h:
626
627 2016-10-17  Filip Pizlo  <fpizlo@apple.com>
628
629         Air::IRC doesn't need to have a special-case for uncolored Tmps since they all get colored
630         https://bugs.webkit.org/show_bug.cgi?id=163548
631         <rdar://problem/28804381>
632
633         Reviewed by Geoffrey Garen.
634         
635         Before r207408, IRC had a mode where it would silently assign the first assignable register (so
636         %rax, %xmm0, etc) to any tmp that was not colorable due to a pathological interference fencepost.
637         We reason about interference at instruction boundaries. This means that if you have, for example,
638         an instruction that clobbers all registers late followed by an instruction that has an early def
639         in the same register file, then the early def will not be colorable because it interferes with
640         all registers. This already happens in our tests, but IRC silently returns the first assignable
641         register to such tmps. For some reason the resulting code works OK - probably because this tends
642         to only be hit by fuzzing, which may not then stress that code enough to shake out the register
643         corruption. Also, this can only happen for floating point registers, so it's hard to get an
644         exciting crash. The worst case is that your numbers get all messed up.
645         
646         This change fixes the issue:
647         
648         - IRC will now crash if it can't color a tmp.
649         
650         - IRC doesn't crash on our tests anymore because I added a padInterference() utility that works
651           around the interference problem by inserting Nops to pad between those instructions where
652           conflating their early and late actions into one interference fencepost could create an
653           uncolorable graph.
654         
655         See https://bugs.webkit.org/show_bug.cgi?id=163548#c2 for a detailed discussion of how the
656         problem can arise.
657         
658         This problem almost made me want to abandon our use of interference at instruction boundaries,
659         and introduce something more comprehensive, like interference at various stages of an
660         instruction's execution. The reason why I didn't do this is that this problem only arises in well
661         confined corner cases: you need an instruction that does a late use or def followed by an
662         instruction that does an early def. Register clobbers count as defs for this equation.
663         Fortunately, early defs are rare, and even when they do happen, you still need the previous
664         instruction to have a late something. Late uses are rare and many instructions don't have defs at
665         all, which means that it's actually pretty common for an instruction to not have anything late.
666         This means that the padInterference() strategy is ideal: our algorithms stay simple because they
667         only have to worry about interference at boundaries, and we rarely insert any Nops in
668         padInterference() so the IR stays nice and compact. Those Nops get removed by any phase that does
669         DCE, which includes eliminateDeadCode(), allocateStack(), and reportUsedRegisters(). In practice
670         allocateStack() kills them.
671         
672         This also finally refactors our passing of RegisterSet to pass it by value, since it's small
673         enough that we're not gaining anything by using references. On x86, RegisterSet ought to be
674         smaller than a pointer.
675
676         * CMakeLists.txt:
677         * JavaScriptCore.xcodeproj/project.pbxproj:
678         * b3/B3StackmapSpecial.cpp:
679         (JSC::B3::StackmapSpecial::extraClobberedRegs):
680         (JSC::B3::StackmapSpecial::extraEarlyClobberedRegs):
681         * b3/B3StackmapSpecial.h:
682         * b3/air/AirCCallSpecial.cpp:
683         (JSC::B3::Air::CCallSpecial::extraEarlyClobberedRegs):
684         (JSC::B3::Air::CCallSpecial::extraClobberedRegs):
685         * b3/air/AirCCallSpecial.h:
686         * b3/air/AirInst.h:
687         * b3/air/AirInstInlines.h:
688         (JSC::B3::Air::Inst::extraClobberedRegs):
689         (JSC::B3::Air::Inst::extraEarlyClobberedRegs):
690         * b3/air/AirIteratedRegisterCoalescing.cpp:
691         (JSC::B3::Air::iteratedRegisterCoalescing):
692         * b3/air/AirPadInterference.cpp: Added.
693         (JSC::B3::Air::padInterference):
694         * b3/air/AirPadInterference.h: Added.
695         * b3/air/AirSpecial.h:
696         * b3/air/AirSpillEverything.cpp:
697         (JSC::B3::Air::spillEverything):
698         * jit/RegisterSet.h:
699         (JSC::RegisterSet::isEmpty):
700
701 2016-10-17  JF Bastien  <jfbastien@apple.com>
702
703         WebAssembly JS API: implement basic stub
704
705         Implement the global WebAssembly JavaScript object, and its constructor +
706         function properties as described in:
707           https://github.com/WebAssembly/design/blob/master/JS.md
708
709         These don't do anything at the moment, the parent bug will take care of adding
710         more functionality and associated tests.
711
712         WebAssembly JS API: implement basic stub
713         https://bugs.webkit.org/show_bug.cgi?id=163404
714
715         Reviewed by Keith Miller.
716
717         * CMakeLists.txt:
718         * JavaScriptCore.xcodeproj/project.pbxproj:
719         * builtins/BuiltinNames.h: register the new WebAssembly object's name and its constructor properties
720         * jsc.cpp: remove useless include
721         * runtime/JSGlobalObject.cpp:
722         (JSC::JSGlobalObject::init): add the WebAssembly global object and its constructor properties, but only if the JSC option enables it
723         * runtime/Options.h: add the useWebAssembly (alias: enableWebAssembly) option, defaulting to false
724         * wasm/WebAssemblyObject.cpp: Added.
725         (JSC::WebAssemblyObject::create): boilerplate
726         (JSC::WebAssemblyObject::createStructure): boilerplate
727         (JSC::WebAssemblyObject::finishCreation): boilerplate
728         (JSC::WebAssemblyObject::WebAssemblyObject): boilerplate
729         (JSC::wasmObjectFuncvalidate): auto-throws for now
730         (JSC::wasmObjectFunccompile): auto-throws for now
731         * wasm/WebAssemblyObject.h: Added.
732
733 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
734
735         Unreviewed, build fix after r207428
736         https://bugs.webkit.org/show_bug.cgi?id=163223
737
738         Previous build fix r207428 broke all the builds.
739
740         * bytecode/PolymorphicAccess.h:
741
742 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
743
744         Unreviewed, build fix for GTK and Windows
745         https://bugs.webkit.org/show_bug.cgi?id=163223
746
747         Attempt to fix build failures in GTK port and Windows port.
748
749         * bytecode/PolymorphicAccess.cpp:
750         * bytecode/PolymorphicAccess.h:
751         (JSC::AccessGenerationState::SpillState::SpillState):
752
753 2016-10-17  Yusuke Suzuki  <utatane.tea@gmail.com>
754
755         [DOMJIT] Use DOMJIT::Patchpoint in IC
756         https://bugs.webkit.org/show_bug.cgi?id=163223
757
758         Reviewed by Saam Barati.
759
760         This patch uses DOMJIT::Patchpoint to inline DOM accesses even in IC!
761         It is useful for Baseline JIT cases and GetById cases in DFG and FTL.
762         In AccessCase, we construct the environment that allows DOMJIT::Patchpoint
763         to emit code and make DOMJIT accessors inlined in IC.
764
765         To allow DOMJIT::Patchpoint to emit code, we create a mechanism to emit calls
766         required in DOMJIT::Patchpoint. This system is useful when we create the super-
767         polymorphic support[1] later. And inlining mechanism is useful even after
768         introducing super-polymorphic support since it can work even after we fire the
769         watchpoint for super-polymorphic handling.
770
771         This patch improves Dromaeo dom-traverse 8% (263.95 runs/s v.s. 244.07 runs/s).
772
773         [1]: https://bugs.webkit.org/show_bug.cgi?id=163226
774
775         * CMakeLists.txt:
776         * JavaScriptCore.xcodeproj/project.pbxproj:
777         * bytecode/DOMJITAccessCasePatchpointParams.cpp: Added.
778         (JSC::SlowPathCallGeneratorWithArguments::SlowPathCallGeneratorWithArguments):
779         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
780         (JSC::DOMJITAccessCasePatchpointParams::emitSlowPathCalls):
781         * bytecode/DOMJITAccessCasePatchpointParams.h: Copied from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h.
782         (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
783         (JSC::DOMJITAccessCasePatchpointParams::SlowPathCallGenerator::~SlowPathCallGenerator):
784         * bytecode/PolymorphicAccess.cpp:
785         (JSC::AccessGenerationState::liveRegistersForCall):
786         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
787         (JSC::calleeSaveRegisters):
788         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
789         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
790         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
791         (JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
792         (JSC::AccessGenerationState::originalExceptionHandler):
793         (JSC::AccessCase::generateImpl):
794         (JSC::AccessCase::emitDOMJITGetter):
795         (JSC::PolymorphicAccess::regenerate):
796         (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall): Deleted.
797         * bytecode/PolymorphicAccess.h:
798         (JSC::AccessGenerationState::SpillState::isEmpty):
799         (JSC::AccessGenerationState::setSpillStateForJSGetterSetter):
800         (JSC::AccessGenerationState::spillStateForJSGetterSetter):
801         (JSC::AccessGenerationState::liveRegistersForCall): Deleted.
802         (JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation): Deleted.
803         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite): Deleted.
804         * dfg/DFGDOMJITPatchpointParams.cpp:
805         * dfg/DFGDOMJITPatchpointParams.h:
806         * domjit/DOMJITPatchpoint.h:
807         * domjit/DOMJITPatchpointParams.h:
808         (JSC::DOMJIT::PatchpointParams::addSlowPathCall):
809         * ftl/FTLDOMJITPatchpointParams.cpp:
810         * ftl/FTLDOMJITPatchpointParams.h:
811         * jsc.cpp:
812         (WTF::DOMJITNode::checkDOMJITNode):
813         (WTF::DOMJITGetterComplex::DOMJITGetterComplex):
814         (WTF::DOMJITGetterComplex::createStructure):
815         (WTF::DOMJITGetterComplex::create):
816         (WTF::DOMJITGetterComplex::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
817         (WTF::DOMJITGetterComplex::domJITNodeGetterSetter):
818         (WTF::DOMJITGetterComplex::finishCreation):
819         (WTF::DOMJITGetterComplex::functionEnableException):
820         (WTF::DOMJITGetterComplex::customGetter):
821         (GlobalObject::finishCreation):
822         (functionCreateDOMJITGetterComplexObject):
823
824 2016-10-17  Saam Barati  <sbarati@apple.com>
825
826         Build fix for HasOwnPropertyCache::Entry caused slowdown by introducing a constructor that doesn't use move semantics for the RefPtr<UniquedStringImpl> parameter
827         https://bugs.webkit.org/show_bug.cgi?id=163490
828
829         Reviewed by Darin Adler.
830
831         * runtime/HasOwnPropertyCache.h:
832         (JSC::HasOwnPropertyCache::Entry::Entry):
833         (JSC::HasOwnPropertyCache::tryAdd):
834
835 2016-10-17  Mark Lam  <mark.lam@apple.com>
836
837         Use the reject() helper function for conditionally throwing TypeErrors.
838         https://bugs.webkit.org/show_bug.cgi?id=163491
839
840         Reviewed by Filip Pizlo.
841
842         In some places where we may conditionally throw a TypeError (e.g. when in strict
843         mode), we already use the reject() helper function to conditionally throw the
844         TypeError.  Doing so makes the code mode compact.  This patch applies this idiom
845         consistently in all places that throws TypeError where appropriate.
846
847         This patch also does the following:
848         1. Make the reject() helper function take an ASCIILiteral instead of a const char*
849            because we always pass it a literal string anyway.
850         2. Change the reject helper() to take a ThrowScope&.  This allows the thrown
851            error to be attributed to its caller.
852         3. When an error message string is instantiated repeatedly in more than 1 place,
853            create a common copy of that literal string in JSObject.cpp (if one doesn't
854            already exist) and use that common string in all those places.
855         4. Since I was auditing call sites of throwTypeError() to check if they should be
856            using the reject() helper instead, I also fixed those up to pass the error
857            message as an ASCIILiteral where appropriate.
858         5. In functions that I touched, change the code to not recompute the VM& when it
859            is already available.
860
861         * jit/JITOperations.cpp:
862         * llint/LLIntSlowPaths.cpp:
863         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
864         * runtime/ArrayPrototype.cpp:
865         (JSC::shift):
866         (JSC::unshift):
867         (JSC::arrayProtoFuncPop):
868         (JSC::arrayProtoFuncReverse):
869         * runtime/CommonSlowPaths.cpp:
870         (JSC::SLOW_PATH_DECL):
871         * runtime/GetterSetter.cpp:
872         (JSC::callSetter):
873         * runtime/JSArray.cpp:
874         (JSC::JSArray::defineOwnProperty):
875         (JSC::JSArray::setLengthWithArrayStorage):
876         (JSC::JSArray::pop):
877         * runtime/JSArrayBuffer.cpp:
878         (JSC::JSArrayBuffer::put):
879         (JSC::JSArrayBuffer::defineOwnProperty):
880         * runtime/JSCJSValue.cpp:
881         (JSC::JSValue::putToPrimitive):
882         (JSC::JSValue::putToPrimitiveByIndex):
883         * runtime/JSDataView.cpp:
884         (JSC::JSDataView::put):
885         (JSC::JSDataView::defineOwnProperty):
886         * runtime/JSFunction.cpp:
887         (JSC::JSFunction::put):
888         (JSC::JSFunction::defineOwnProperty):
889         * runtime/JSGenericTypedArrayView.h:
890         (JSC::JSGenericTypedArrayView::setIndex):
891         * runtime/JSGenericTypedArrayViewInlines.h:
892         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
893         (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
894         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
895         (JSC::speciesConstruct):
896         (JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
897         * runtime/JSModuleNamespaceObject.cpp:
898         (JSC::JSModuleNamespaceObject::defineOwnProperty):
899         * runtime/JSObject.cpp:
900         (JSC::ordinarySetSlow):
901         (JSC::JSObject::putInlineSlow):
902         (JSC::JSObject::setPrototypeWithCycleCheck):
903         (JSC::JSObject::defineOwnIndexedProperty):
904         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
905         (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
906         (JSC::validateAndApplyPropertyDescriptor):
907         * runtime/JSObject.h:
908         * runtime/JSObjectInlines.h:
909         (JSC::JSObject::putInline):
910         * runtime/JSProxy.cpp:
911         (JSC::JSProxy::setPrototype):
912         * runtime/JSSymbolTableObject.h:
913         (JSC::symbolTablePut):
914         * runtime/Lookup.h:
915         (JSC::putEntry):
916         * runtime/RegExpObject.cpp:
917         (JSC::RegExpObject::defineOwnProperty):
918         * runtime/RegExpObject.h:
919         (JSC::RegExpObject::setLastIndex):
920         * runtime/Reject.h:
921         (JSC::reject):
922         * runtime/SparseArrayValueMap.cpp:
923         (JSC::SparseArrayValueMap::putEntry):
924         (JSC::SparseArrayValueMap::putDirect):
925         (JSC::SparseArrayEntry::put):
926         * runtime/StringObject.cpp:
927         (JSC::StringObject::put):
928         (JSC::StringObject::putByIndex):
929         * runtime/SymbolConstructor.cpp:
930         (JSC::symbolConstructorKeyFor):
931
932 2016-10-16  Filip Pizlo  <fpizlo@apple.com>
933
934         Air::IRC needs to place all Tmps on some worklist, even if they have no interference edges
935         https://bugs.webkit.org/show_bug.cgi?id=163509
936
937         Reviewed by Mark Lam.
938         
939         The worklist building function in IRC skips temporaries that have no degree. This doesn't appear
940         to be necessary. This has been there since the original IRC commit. It hasn't caused bugs because
941         ordinarily, the only way to have a tmp with no degree is to not have any mention of that tmp. But
942         while working on bug 163371, I hit a crazy corner case where a temporary would have no
943         interference edges (i.e. no degree). Here's how it happens:
944         
945         A spill tmp from a previous iteration of IRC may have no degree: imagine a tmp that is live
946         everywhere and interferes with everyone, but has one use like:
947
948         Move %ourTmp, %someOtherTmp
949
950         Where there are no other tmps live.  After spill conversion, this may look like:
951
952         Move (ourSpill), %newTmp
953         Move %newTmp, %someOtherTmp
954
955         Of course, we'd rather not get this kind of spill code but it's totally possible because we now
956         have a bunch of random conditions under which we won't slap the spill address directly into the
957         Move.
958
959         After this happens, assuming that the only thing live was %someOtherTmp, we will have zero degree
960         for %newTmp because the Move is coalescable and does not contribute to interference.
961
962         Then, we might coalesce %someOtherTmp with %newTmp.  Once this happens, if we make the %newTmp be
963         the master, we're in deep trouble because %newTmp is not on any worklist.
964         
965         I don't know how to reproduce this except through the patch in bug 163371. Removing the two lines
966         of code that skipped no-degree tmps causes no regressions, and resolves the problem I was having.
967
968         * b3/air/AirIteratedRegisterCoalescing.cpp:
969
970 2016-10-15  Mark Lam  <mark.lam@apple.com>
971
972         Add a $vm.getpid() method.
973         https://bugs.webkit.org/show_bug.cgi?id=163493
974
975         Reviewed by Saam Barati.
976
977         This is especially useful when we need to know the pid of an instance of jsc in
978         the foreground that we're trying to attach a debugger to while the JSC tests are
979         running in the background with a gazillion other jsc processes live at the same
980         time.
981
982         Currently, $vm.getpid() is only supported on non-Windows platforms.
983         According to https://msdn.microsoft.com/en-us/library/ms235372.aspx, getpid() is
984         deprecated.  According to https://msdn.microsoft.com/en-us/library/t2y34y40.aspx,
985         _getpid() cannot be used in applications that execute in the Windows Runtime.
986
987         Since this is only a debugging tool and is not a required feature, I'll defer
988         the Windows implementation of this function till the time when someone actually
989         needs it.
990
991         * tools/JSDollarVMPrototype.cpp:
992         (JSC::functionGetPID):
993         (JSC::JSDollarVMPrototype::finishCreation):
994
995 2016-10-15  Saam Barati  <sbarati@apple.com>
996
997         Assertion failed under operationToLowerCase with a rope with zero length
998         https://bugs.webkit.org/show_bug.cgi?id=163314
999
1000         Reviewed by Mark Lam.
1001
1002         There are some ways to get JSC to create empty rope strings. ToLowerCase
1003         inside the DFG/FTL goes to the slow path when the argument is a rope.
1004         operationToLowerCase was calling into a WTF string function that
1005         assumed we are passing it a this value that has non-zero length.
1006         However, we were calling it with a string that did have zero length.
1007         To fix this, we make operationToLowerCase return the empty JSString
1008         if it is going to make a string with zero length.
1009
1010         * dfg/DFGOperations.cpp:
1011         * jsc.cpp:
1012         (GlobalObject::finishCreation):
1013         (functionIsRope):
1014
1015 2016-10-14  Benjamin Poulain  <bpoulain@apple.com>
1016
1017         [JSC] op_negate should with any type
1018         https://bugs.webkit.org/show_bug.cgi?id=162587
1019
1020         Reviewed by Saam Barati.
1021
1022         * dfg/DFGAbstractInterpreterInlines.h:
1023         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1024         ArithNegate is quite simple. If the input is double, the output
1025         is double. The other cases are set from the LLInt slow case.
1026
1027         * dfg/DFGByteCodeParser.cpp:
1028         (JSC::DFG::ByteCodeParser::makeSafe):
1029         * dfg/DFGClobberize.h:
1030         (JSC::DFG::clobberize):
1031         * dfg/DFGFixupPhase.cpp:
1032         (JSC::DFG::FixupPhase::fixupNode):
1033
1034         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1035         Tweak a bit the IntegerRangeOptimizationPhase when simplifying
1036         ArithAbs to ArithNegate.
1037         We should not do the conversion if the target nodes OSR Exits
1038         on different input than the source node.
1039
1040         In particular, Checked ArithNegate exits on zero while
1041         ArithAbs has not problem with it.
1042         Unchecked ArithAbs() do not OSR Exit on INT_MIN, ArithNeg
1043         should not either.
1044
1045         * dfg/DFGPredictionPropagationPhase.cpp:
1046         * dfg/DFGSpeculativeJIT.cpp:
1047         (JSC::DFG::SpeculativeJIT::compileArithNegate):
1048         (JSC::DFG::SpeculativeJIT::compileMathIC):
1049         * dfg/DFGSpeculativeJIT.h:
1050         (JSC::DFG::SpeculativeJIT::callOperation):
1051         * ftl/FTLLowerDFGToB3.cpp:
1052         (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
1053         (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
1054
1055         * jit/JITNegGenerator.cpp:
1056         (JSC::JITNegGenerator::generateFastPath):
1057         * jit/JITOperations.cpp:
1058         Add result profiling in baseline to have types we can use
1059         in DFG and FTL.
1060
1061 2016-10-14  Keith Miller  <keith_miller@apple.com>
1062
1063         B3 needs a special WasmAddress Opcode
1064         https://bugs.webkit.org/show_bug.cgi?id=163394
1065
1066         Reviewed by Filip Pizlo.
1067
1068         This patch adds support for WasmAddress. WasmAddress will be used by
1069         Wasm to compute the address of a memory operation from the pinned
1070         base pointer. WasmAddress takes an IntPtr so we can avoid emitting
1071         unnecessary Move32s in Air. This could happen in the following case:
1072
1073         @ptr = Trunc(...)
1074         WasmAddress(@ptr, pinnedGPR)
1075         ...
1076         PatchPoint(...) // Do Wasm call
1077         WasmAddress(@ptr, pinnedGPR)
1078         ...
1079
1080         In this case we will not be able to CSE the WasmAddresses since the
1081         call writes to pinnedGPR. Thus if WasmAddress took an Int32 we would need
1082         to emit an extra Move32 at the second WasmAddress to ensure it saw a proper
1083         32-bit value. If Wasm ensures that there there is a leading ZExt32 then
1084         the duplicated moves become unnecessary.
1085
1086         * CMakeLists.txt:
1087         * JavaScriptCore.xcodeproj/project.pbxproj:
1088         * b3/B3LowerToAir.cpp:
1089         (JSC::B3::Air::LowerToAir::effectiveAddr):
1090         (JSC::B3::Air::LowerToAir::lower):
1091         * b3/B3Opcode.cpp:
1092         (WTF::printInternal):
1093         * b3/B3Opcode.h:
1094         * b3/B3Validate.cpp:
1095         * b3/B3Value.cpp:
1096         (JSC::B3::Value::effects):
1097         * b3/B3WasmAddressValue.cpp: Added.
1098         (JSC::B3::WasmAddressValue::~WasmAddressValue):
1099         (JSC::B3::WasmAddressValue::dumpMeta):
1100         (JSC::B3::WasmAddressValue::cloneImpl):
1101         (JSC::B3::WasmAddressValue::WasmAddressValue):
1102         * b3/B3WasmAddressValue.h: Added.
1103         * b3/testb3.cpp:
1104         (JSC::B3::testWasmAddress):
1105         (JSC::B3::run):
1106
1107 2016-10-14  Joseph Pecoraro  <pecoraro@apple.com>
1108
1109         test262: @isConstructor incorrectly thinks Math.cos is a constructor
1110         https://bugs.webkit.org/show_bug.cgi?id=163437
1111
1112         Reviewed by Saam Barati.
1113
1114         * runtime/JSFunction.cpp:
1115         (JSC::JSFunction::getConstructData):
1116         By default, Host JSFunctions are not constructable. They get
1117         the default callHostFunctionAsConstructor native constructor.
1118         When getting construct data we can return ConstructType::None
1119         in these cases instead of indicating it might be constructable
1120         and later throwing an exception when construction is attempted.
1121
1122 2016-10-14  Ryan Haddad  <ryanhaddad@apple.com>
1123
1124         Unreviewed, rolling out r207322.
1125
1126         This change caused JSC test failures
1127
1128         Reverted changeset:
1129
1130         "Fix Array.prototype.splice ES6 compliance."
1131         https://bugs.webkit.org/show_bug.cgi?id=163372
1132         http://trac.webkit.org/changeset/207322
1133
1134 2016-10-14  Mark Lam  <mark.lam@apple.com>
1135
1136         JSON.parse should not modify frozen objects.
1137         https://bugs.webkit.org/show_bug.cgi?id=163430
1138
1139         Reviewed by Saam Barati.
1140
1141         The ES6 spec for JSON.parse (https://tc39.github.io/ecma262/#sec-json.parse and
1142         https://tc39.github.io/ecma262/#sec-internalizejsonproperty) states that it uses
1143         CreateDataProperty() (https://tc39.github.io/ecma262/#sec-createdataproperty) to
1144         set values returned by a reviver.  The spec for CreateDataPropertyOrThrow states:
1145
1146         "This abstract operation creates a property whose attributes are set to the same
1147         defaults used for properties created by the ECMAScript language assignment
1148         operator. Normally, the property will not already exist. If it does exist and is
1149         not configurable or if O is not extensible, [[DefineOwnProperty]] will return
1150         false."
1151
1152         Note: CreateDataProperty() will not throw a TypeError.
1153
1154         Since the properties of frozen objects are not extensible, not configurable, and
1155         not writeable, JSON.parse should fail to write to any frozen objects.  Similarly,
1156         JSON.parse should fail to delete properties in frozen objects.
1157
1158         In JSON.parse(), we previously write to array elements using the form of
1159         putDirectIndex() that uses mode PutDirectIndexLikePutDirect.  This makes it so
1160         that the write (i.e. put) is always successful.  We've now fixed this to use
1161         PutDirectIndexShouldNotThrow mode instead, which will fail to put the element if
1162         the array is not writeable.
1163
1164         Also changed Walker::walk() to use the version of methodTable() that takes a VM&
1165         since the VM& is already available.
1166
1167         * runtime/JSONObject.cpp:
1168         (JSC::Walker::walk):
1169
1170 2016-10-14  Joseph Pecoraro  <pecoraro@apple.com>
1171
1172         test262: Failure with RegExp.prototype.compile when pattern is undefined
1173         https://bugs.webkit.org/show_bug.cgi?id=163431
1174
1175         Reviewed by Yusuke Suzuki.
1176
1177         If pattern is undefined let P be the empty String.
1178         https://tc39.github.io/ecma262/#sec-regexpinitialize
1179
1180         * runtime/RegExpPrototype.cpp:
1181         (JSC::regExpProtoFuncCompile):
1182
1183 2016-10-13  Joseph Pecoraro  <pecoraro@apple.com>
1184
1185         Exception message for expressions with multiple bracket accesses is inconsistent / incorrect
1186         https://bugs.webkit.org/show_bug.cgi?id=163426
1187
1188         Reviewed by Geoffrey Garen.
1189
1190         * bytecompiler/NodesCodegen.cpp:
1191         (JSC::BracketAccessorNode::emitBytecode):
1192         It matters where emitExpressionInfo is called since it gathers
1193         info about where we are in the instruction stream. We need to
1194         emit it before the bytecode that we want to associate the data
1195         with. In this case, before the getById / getByVal.
1196
1197 2016-10-13  Mark Lam  <mark.lam@apple.com>
1198
1199         Fix Array.prototype.splice ES6 compliance.
1200         https://bugs.webkit.org/show_bug.cgi?id=163372
1201
1202         Reviewed by Geoffrey Garen and Yusuke Suzuki.
1203
1204         Our Array.prototype.splice implementation neglected to set length on the result
1205         array (step 12 of https://tc39.github.io/ecma262/#sec-array.prototype.splice) in
1206         a certain code path.  This is now fixed.
1207
1208         I'm deferring the implementation of step 8 till later because it requires more
1209         careful consideration and the fix is of a lesser value (and therefore, of less
1210         urgency).  See https://bugs.webkit.org/show_bug.cgi?id=163417
1211
1212         Also added some needed exception checks and assertions.
1213
1214         * runtime/ArrayPrototype.cpp:
1215         (JSC::arrayProtoFuncSplice):
1216
1217 2016-10-13  Joseph Pecoraro  <pecoraro@apple.com>
1218
1219         Web Inspector: Stepping highlight for dot/bracket expressions in if statements highlights subset of the expression
1220         https://bugs.webkit.org/show_bug.cgi?id=163378
1221         <rdar://problem/28749376>
1222
1223         Reviewed by Saam Barati.
1224
1225         * parser/Parser.cpp:
1226         (JSC::Parser<LexerType>::parseAssignmentExpression):
1227         Since each expression builds on the previous, always keep the starting
1228         location the first location.
1229
1230 2016-10-13  Per Arne Vollan  <pvollan@apple.com>
1231
1232         [Win64] Compile fix.
1233         https://bugs.webkit.org/show_bug.cgi?id=163384
1234
1235         Reviewed by Brent Fulgham.
1236
1237         Fix use of potentially uninitialized variable.
1238
1239         * dfg/DFGSpeculativeJIT64.cpp:
1240         (JSC::DFG::SpeculativeJIT::compile):
1241
1242 2016-10-12  Chris Dumez  <cdumez@apple.com>
1243
1244         [Web IDL] Drop support for legacy [ConstructorConditional=*]
1245         https://bugs.webkit.org/show_bug.cgi?id=163368
1246
1247         Reviewed by Ryosuke Niwa.
1248
1249         Drop ENABLE_DOM4_EVENTS_CONSTRUCTOR compiler flag.
1250
1251         * Configurations/FeatureDefines.xcconfig:
1252
1253 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
1254
1255         Web Inspector: step-into `console.log(o)` should not step through inspector javascript
1256         https://bugs.webkit.org/show_bug.cgi?id=161656
1257         <rdar://problem/28181123>
1258
1259         Reviewed by Timothy Hatcher.
1260
1261         * debugger/Debugger.h:
1262         * debugger/Debugger.cpp:
1263         (JSC::Debugger::pauseIfNeeded):
1264         If the Script is blacklisted skip checking if we need to pause.
1265
1266         (JSC::Debugger::isBlacklisted):
1267         (JSC::Debugger::addToBlacklist):
1268         (JSC::Debugger::clearBlacklist):
1269         Add the ability to add a Script to a blacklist. Currently the blacklist
1270         only prevents pausing in the Script.
1271
1272         * inspector/agents/InspectorDebuggerAgent.cpp:
1273         (Inspector::isWebKitInjectedScript):
1274         (Inspector::InspectorDebuggerAgent::didParseSource):
1275         Always add Internal InjectedScripts to the Debugger's blacklist.
1276
1277         (Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
1278         Clear blacklists when clearing debugger state.
1279
1280 2016-10-12  Keith Miller  <keith_miller@apple.com>
1281
1282         B3 needs a special WasmBoundsCheck Opcode
1283         https://bugs.webkit.org/show_bug.cgi?id=163246
1284
1285         Reviewed by Filip Pizlo.
1286
1287         This patch adds a new Opcode, WasmBoundsCheck, as well as a B3::Value subclass for it,
1288         WasmBoundsCheckValue. WasmBoundsCheckValue takes three pieces of information. The first is
1289         the Int32 pointer value used to be used by the Load.  Next is the pinned register. The
1290         pinned register must be pinned by calling proc.setPinned() prior to compiling the
1291         Procedure. Lastly, the WasmBoundsCheckValue takes an offset. The WasmBoundsCheckValue is
1292         will then emit code that side-exits if the Int64 sum of the offset and pointer is greater
1293         than or equal to the value in the pinnedRegister. Instead of taking a generator for each
1294         value like Check/Patchpoint, WasmBoundsCheck gets its generator directly off Air::Code. In
1295         Air this patch adds a new Custom opcode, WasmBoundsCheck.
1296
1297         In the future we should add WasmBoundsCheck to CSE so it can eliminate redundant bounds
1298         checks. At the first cut, we can remove any WasmBoundsCheck dominated by another
1299         WasmBoundsCheck with the same pointer and pinnedGPR, and a larger offset.
1300
1301         * CMakeLists.txt:
1302         * JavaScriptCore.xcodeproj/project.pbxproj:
1303         * b3/B3LowerToAir.cpp:
1304         (JSC::B3::Air::LowerToAir::imm):
1305         (JSC::B3::Air::LowerToAir::lower):
1306         * b3/B3Opcode.cpp:
1307         (WTF::printInternal):
1308         * b3/B3Opcode.h:
1309         * b3/B3Procedure.cpp:
1310         (JSC::B3::Procedure::setWasmBoundsCheckGenerator):
1311         * b3/B3Procedure.h:
1312         (JSC::B3::Procedure::setWasmBoundsCheckGenerator):
1313         * b3/B3Validate.cpp:
1314         * b3/B3Value.cpp:
1315         (JSC::B3::Value::effects):
1316         (JSC::B3::Value::typeFor):
1317         * b3/B3WasmBoundsCheckValue.cpp: Added.
1318         (JSC::B3::WasmBoundsCheckValue::~WasmBoundsCheckValue):
1319         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
1320         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
1321         * b3/B3WasmBoundsCheckValue.h: Added.
1322         (JSC::B3::WasmBoundsCheckValue::accepts):
1323         (JSC::B3::WasmBoundsCheckValue::pinnedGPR):
1324         (JSC::B3::WasmBoundsCheckValue::offset):
1325         * b3/air/AirCode.h:
1326         (JSC::B3::Air::Code::setWasmBoundsCheckGenerator):
1327         (JSC::B3::Air::Code::wasmBoundsCheckGenerator):
1328         * b3/air/AirCustom.cpp:
1329         (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
1330         * b3/air/AirCustom.h:
1331         (JSC::B3::Air::WasmBoundsCheckCustom::forEachArg):
1332         (JSC::B3::Air::WasmBoundsCheckCustom::isValidFormStatic):
1333         (JSC::B3::Air::WasmBoundsCheckCustom::admitsStack):
1334         (JSC::B3::Air::WasmBoundsCheckCustom::isTerminal):
1335         (JSC::B3::Air::WasmBoundsCheckCustom::hasNonArgNonControlEffects):
1336         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
1337         * b3/air/AirOpcode.opcodes:
1338         * b3/testb3.cpp:
1339         (JSC::B3::testWasmBoundsCheck):
1340         (JSC::B3::run):
1341
1342 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
1343
1344         The blackening of CellState is a bad way of tracking if the object is being marked for the first time
1345         https://bugs.webkit.org/show_bug.cgi?id=163343
1346
1347         Reviewed by Mark Lam.
1348         
1349         When I first added the concept of NewGrey/OldGrey, I had the SlotVisitor store the old cell
1350         state in itself, so that it could use it to decide what to do for reportExtraMemoryVisited().
1351         
1352         Then I changed it in a recent commit, because I wanted the freedom to have SlotVisitor visit
1353         multiple objects in tandem. But I never ended up using this capability. Still, I liked the
1354         new way better: instead of the SlotVisitor rembemering the state-before-blackening, we would
1355         make the object's state reflect whether it was black for the first time or not. That seemed
1356         convenient.
1357         
1358         Unfortunately it's wrong. After we blacken the object, a concurrent barrier could instantly
1359         grey it. Then we would forget that we are visiting this object for the first time.
1360         Subsequent visits will think that they are not the first. So, we will fail to do the right
1361         thing in reportExtraMemoryVisited().
1362         
1363         So, this reverts that change. This is a little more than just a revert, though. I've changed
1364         the terminology a bit. For example, I got tired of reading Black and having to remind myself
1365         that it really means that the object has begun being visited, instead of the more strict
1366         meaning that implies that it has already been visited. We want to say that it's Black or
1367         currently being scanned. I'm going to adopt Siebert's term for this: Anthracite [1]. So, our
1368         black CellState is now called AnthraciteOrBlack.
1369         
1370         [1] https://pdfs.semanticscholar.org/7ae4/633265aead1f8835cf7966e179d02c2c8a4b.pdf
1371
1372         * heap/CellState.h:
1373         (JSC::isBlack): Deleted.
1374         (JSC::blacken): Deleted.
1375         * heap/Heap.cpp:
1376         (JSC::Heap::addToRememberedSet):
1377         (JSC::Heap::writeBarrierSlowPath):
1378         * heap/Heap.h:
1379         * heap/HeapInlines.h:
1380         (JSC::Heap::reportExtraMemoryVisited):
1381         (JSC::Heap::reportExternalMemoryVisited):
1382         * heap/SlotVisitor.cpp:
1383         (JSC::SlotVisitor::appendToMarkStack):
1384         (JSC::SlotVisitor::visitChildren):
1385         * heap/SlotVisitor.h:
1386         * heap/SlotVisitorInlines.h:
1387         (JSC::SlotVisitor::reportExtraMemoryVisited):
1388         (JSC::SlotVisitor::reportExternalMemoryVisited):
1389         * llint/LLIntData.cpp:
1390         (JSC::LLInt::Data::performAssertions):
1391         * llint/LowLevelInterpreter.asm:
1392
1393 2016-10-12  Mark Lam  <mark.lam@apple.com>
1394
1395         Rename variables in arrayProtoFuncSplice() to match names in the spec.
1396         https://bugs.webkit.org/show_bug.cgi?id=163354
1397
1398         Reviewed by Saam Barati.
1399
1400         This will make it easier to see whether the code matches the spec or not.
1401         Ref: https://tc39.github.io/ecma262/#sec-array.prototype.splice
1402
1403         * runtime/ArrayPrototype.cpp:
1404         (JSC::arrayProtoFuncSplice):
1405
1406 2016-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1407
1408         [DOMJIT][JSC] Explore the way to embed nodeType into JSC::JSType in WebCore
1409         https://bugs.webkit.org/show_bug.cgi?id=163245
1410
1411         Reviewed by Filip Pizlo.
1412
1413         We reserve the highest bit of JSC::JSType for extensions outside JSC.
1414         JSC does not use JSType bits so many: only 52 types are defined.
1415
1416         And we extend CallDOM patchpoint to claim that it does not require a global object.
1417         This global object is used to generate a DOM wrapper. However, nodeType does not require
1418         it since it just returns integer. In the future, we will extend CallDOM to claim
1419         its result type. And we can decide this `requireGlobalObject` condition automatically
1420         according to the result type.
1421
1422         * JavaScriptCore.xcodeproj/project.pbxproj:
1423         * dfg/DFGByteCodeParser.cpp:
1424         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
1425         * dfg/DFGFixupPhase.cpp:
1426         (JSC::DFG::FixupPhase::fixupNode):
1427         * dfg/DFGGraph.h:
1428         * dfg/DFGNode.h:
1429         (JSC::DFG::Node::hasCheckDOMPatchpoint):
1430         (JSC::DFG::Node::checkDOMPatchpoint):
1431         (JSC::DFG::Node::hasCallDOMPatchpoint):
1432         (JSC::DFG::Node::callDOMPatchpoint):
1433         (JSC::DFG::Node::hasDOMJIT): Deleted.
1434         (JSC::DFG::Node::domJIT): Deleted.
1435         * dfg/DFGSpeculativeJIT.cpp:
1436         (JSC::DFG::SpeculativeJIT::compileCallDOM):
1437         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
1438         * domjit/DOMJITCallDOMPatchpoint.h: Copied from Source/JavaScriptCore/domjit/DOMJITGetterSetter.h.
1439         (JSC::DOMJIT::CallDOMPatchpoint::create):
1440         * domjit/DOMJITGetterSetter.h:
1441         * domjit/DOMJITPatchpoint.h:
1442         * ftl/FTLLowerDFGToB3.cpp:
1443         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
1444         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
1445         * jsc.cpp:
1446         * llint/LLIntData.cpp:
1447         (JSC::LLInt::Data::performAssertions):
1448         * llint/LowLevelInterpreter.asm:
1449         * runtime/JSType.h:
1450
1451 2016-10-12  Keith Miller  <keith_miller@apple.com>
1452
1453         Handle non-function, non-undefined comparator in Array.prototype.sort
1454         https://bugs.webkit.org/show_bug.cgi?id=163085
1455
1456         Reviewed by Yusuke Suzuki.
1457
1458         * builtins/ArrayPrototype.js:
1459         (sort.comparatorSort):
1460         (sort.stringSort):
1461         (sort):
1462
1463 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
1464
1465         REGRESSION (r207179): ASSERTION FAILED: node.cell != previousCell
1466         https://bugs.webkit.org/show_bug.cgi?id=163337
1467
1468         Reviewed by Mark Lam.
1469         
1470         It turns out that HeapSnapshot was not down with revisiting. The concurrent GC is going to be
1471         built around the idea that we can revisit objects many times. This means that any action that
1472         should only take place once per object must check the object's state. This fixes the snapshot
1473         code to do this.
1474         
1475         While writing this code, I realized that we're actually doing this check incorrectly, so I
1476         filed bug 163343. That bug requires a race, so we aren't going to see it yet.
1477
1478         * heap/HeapSnapshot.cpp:
1479         (JSC::HeapSnapshot::finalize):
1480         * heap/SlotVisitor.cpp:
1481         (JSC::SlotVisitor::appendToMarkStack):
1482         (JSC::SlotVisitor::visitChildren):
1483
1484 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
1485
1486         Web Inspector: Improve support for logging Proxy objects in console
1487         https://bugs.webkit.org/show_bug.cgi?id=163323
1488         <rdar://problem/28432553>
1489
1490         Reviewed by Timothy Hatcher.
1491
1492         This is based off of similiar patches in Blink for Proxy handling.
1493
1494         * bindings/ScriptValue.cpp:
1495         (Deprecated::ScriptValue::isEqual):
1496         Use strict equality. This is the intent, and it prevents the possibility of triggering
1497         primitive conversion on objects in previous ConsoleMessage argument lists.
1498
1499         * inspector/InjectedScriptSource.js:
1500         (InjectedScript.prototype._propertyDescriptors):
1501         Bail if the object is a Proxy.
1502
1503         (InjectedScript.prototype._describe):
1504         Provide a friendlier name, "Proxy" instead of "ProxyObject".
1505         
1506         (InjectedScript.RemoteObject):
1507         When generating a preview for a Proxy object, generate it from the final target
1508         and mark it as lossy so that the object can always be expanded to get the internal
1509         target/handler properties.
1510
1511         * inspector/JSInjectedScriptHost.h:
1512         * inspector/JSInjectedScriptHost.cpp:
1513         (Inspector::JSInjectedScriptHost::subtype):
1514         New subtype for Proxy objects.
1515
1516         (Inspector::JSInjectedScriptHost::proxyTargetValue):
1517         Resolve the final target value for a Proxy.
1518
1519         * inspector/JSInjectedScriptHostPrototype.cpp:
1520         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
1521         (Inspector::jsInjectedScriptHostPrototypeFunctionProxyTargetValue):
1522         Add the new method.
1523
1524         * inspector/ScriptArguments.cpp:
1525         (Inspector::ScriptArguments::getFirstArgumentAsString):
1526         Avoid triggering Proxy traps on a Proxy object when getting a quick
1527         string description for ConsoleMessages.
1528
1529         * inspector/protocol/Runtime.json:
1530         Add new "proxy" subtype.
1531
1532 2016-10-12  Joseph Pecoraro  <pecoraro@apple.com>
1533
1534         Emit DebugHooks uniformly with pause locations instead of having separate pause locations and op_debug emits
1535         https://bugs.webkit.org/show_bug.cgi?id=162809
1536
1537         Reviewed by Geoffrey Garen.
1538
1539         Change how BytecodeGeneration emits debug hooks to be more consistent.
1540         Previously most nodes individually generated their own debug hook
1541         and we asserted that it matched a breakpoint location identified
1542         by the parser. This could get out of sync, or nodes could forget to
1543         emit debug hooks expected by the parser.
1544         
1545         With this change, we always check and emit a debug hook for any
1546         node. The default behavior is for BytecodeGenerator::emitNode
1547         to emit the debug hook when emitting the node itself. This covers
1548         the majority of cases (statements).
1549
1550         There are a few exceptions where we continue to need to customize
1551         emitting debug hooks:
1552
1553             1. Nodes with emitBytecodeInConditionContext
1554                 - non-Expression nodes customize how they emit their children
1555                 - constants conditions may emit nothing, but we had recorded a breakpoint location so emit a debug hook
1556                 - always emit one debug hook in case we recorded a breakpoint location, but avoid emitting multiple
1557                   in nodes which may call up to the ExpressionNode::emitBytecodeInConditionContext base impl.
1558             2. Specialized Debug Hooks
1559                 - such as hooks for Program start/end, debugger statements, etc.
1560             3. Debug Hooks in for..of / for..in that don't correspond to re-emitting nodes
1561                 - such as pausing on the assignment expression inside these loops
1562
1563         The majority of nodes no longer have custom emits.
1564
1565         * bytecompiler/BytecodeGenerator.h:
1566         (JSC::BytecodeGenerator::emitNodeInTailPosition):
1567         (JSC::BytecodeGenerator::emitNodeInConditionContext):
1568         * bytecompiler/BytecodeGenerator.cpp:
1569         (JSC::BytecodeGenerator::emitDebugHook):
1570         (JSC::BytecodeGenerator::emitEnumeration):
1571         By default, when emitting a node check if we should also emit an op_debug for it.
1572         This default DebugHook is WillExecuteStatement, which is a normal pause point.
1573
1574         * bytecompiler/NodesCodegen.cpp:
1575         (JSC::ConstantNode::emitBytecodeInConditionContext):
1576         (JSC::LogicalNotNode::emitBytecodeInConditionContext):
1577         (JSC::BinaryOpNode::emitBytecodeInConditionContext):
1578         (JSC::LogicalOpNode::emitBytecodeInConditionContext):
1579         The parser would have generated a pause location for these conditions
1580         no matter what constant folding and re-writing these nodes may perform.
1581         So, when emitting these nodes in condition context check if they need
1582         emit their own debug hook.
1583
1584         (JSC::EmptyStatementNode::emitBytecode):
1585         (JSC::ExprStatementNode::emitBytecode):
1586         (JSC::DeclarationStatement::emitBytecode):
1587         (JSC::IfElseNode::emitBytecode):
1588         (JSC::DoWhileNode::emitBytecode):
1589         (JSC::WhileNode::emitBytecode):
1590         (JSC::ForNode::emitBytecode):
1591         (JSC::ContinueNode::emitBytecode):
1592         (JSC::BreakNode::emitBytecode):
1593         (JSC::ReturnNode::emitBytecode):
1594         (JSC::WithNode::emitBytecode):
1595         (JSC::SwitchNode::emitBytecode):
1596         (JSC::ThrowNode::emitBytecode):
1597         No longer need to custom emit debug hooks. The default emitNode will handle these.
1598
1599         (JSC::ForInNode::emitBytecode):
1600         Include extra debug hooks the user expects to return back to the assignment
1601         expression in the loop header before starting the body again. The same is done
1602         for for..of with emitEnumeration.
1603
1604         * parser/ASTBuilder.h:
1605         (JSC::ASTBuilder::createExportDefaultDeclaration):
1606         (JSC::ASTBuilder::createExportLocalDeclaration):
1607         These are no longer needed to fake-satisfy assertions. We never wanted to
1608         emit debug hooks for these inner statements because the export statement
1609         will already have the debug hooks.
1610
1611         (JSC::ASTBuilder::createForInLoop):
1612         (JSC::ASTBuilder::createForOfLoop):
1613         Include the correct location where the declaration starts.
1614
1615         (JSC::ASTBuilder::breakpointLocation):
1616         Simplify to a general implementation for Node.
1617
1618         * parser/SyntaxChecker.h:
1619         (JSC::SyntaxChecker::createForInLoop):
1620         (JSC::SyntaxChecker::createForOfLoop):
1621         Ignore the new extra parameter.
1622
1623         * parser/Nodes.h:
1624         (JSC::Node::needsDebugHook):
1625         (JSC::Node::setNeedsDebugHook):
1626         (JSC::ExpressionNode::needsDebugHook): Deleted.
1627         (JSC::ExpressionNode::setNeedsDebugHook): Deleted.
1628         (JSC::StatementNode::isEmptyStatement): Deleted.
1629         (JSC::StatementNode::needsDebugHook): Deleted.
1630         (JSC::StatementNode::setNeedsDebugHook): Deleted.
1631         Move debug hook logic into the base Node class.
1632
1633         (JSC::StatementNode::isDebuggerStatement):
1634         Provide a way to distinguish a debugger statement.
1635
1636         * parser/Parser.cpp:
1637         (JSC::Parser<LexerType>::parseForStatement):
1638         Provide the location before the declaration starts.
1639
1640 2016-10-12  Mark Lam  <mark.lam@apple.com>
1641
1642         Array.prototype.slice should not modify frozen objects.
1643         https://bugs.webkit.org/show_bug.cgi?id=163338
1644
1645         Reviewed by Filip Pizlo.
1646
1647         1. The ES6 spec for Array.prototype.slice
1648            (https://tc39.github.io/ecma262/#sec-array.prototype.slice) states that it uses
1649            the CreateDataPropertyOrThrow()
1650            (https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow) to add items to
1651            the result array.  The spec for CreateDataPropertyOrThrow states:
1652
1653            "This abstract operation creates a property whose attributes are set to the
1654            same defaults used for properties created by the ECMAScript language assignment
1655            operator. Normally, the property will not already exist. If it does exist and
1656            is not configurable or if O is not extensible, [[DefineOwnProperty]] will
1657            return false causing this operation to throw a TypeError exception."
1658
1659         2. Array.prototype.slice also uses a Set function
1660            (https://tc39.github.io/ecma262/#sec-set-o-p-v-throw) to set the "length"
1661            property and passes true for the Throw argument.  Ultimately, it ends up
1662            calling the OrdinarySet function
1663            (https://tc39.github.io/ecma262/#sec-ordinaryset) that will fail if the
1664            property is not writable.  This failure should result in a TypeError being
1665            thrown in Set.
1666
1667            Since the properties of frozen objects are not extensible, not configurable,
1668            and not writeable, Array.prototype.slice should fail to write to the result
1669            array if it is frozen.
1670
1671         If the source array being sliced has 1 or more elements, (1) will take effect
1672         when we try to set the element in the non-writeable result obj.
1673         If the source array being sliced has 0 elements, we will not set any elements and
1674         (1) will not trigger.  Subsequently, (2) will take effect when we will try to
1675         set the length of the result obj.
1676
1677         * runtime/ArrayPrototype.cpp:
1678         (JSC::putLength):
1679         (JSC::setLength):
1680         (JSC::arrayProtoFuncSlice):
1681         (JSC::arrayProtoFuncSplice):
1682
1683 2016-10-12  Filip Pizlo  <fpizlo@apple.com>
1684
1685         Remove JITWriteBarrier.h
1686         https://bugs.webkit.org/show_bug.cgi?id=163334
1687
1688         Reviewed by Mark Lam.
1689         
1690         I guess that the idea of JITWriteBarrier was to make sure that if you slap some heap pointer
1691         bits into machine code, then you better execute a barrier on the code block. But it's a
1692         complicated piece of code, and I can never remember how it quite works. These days it looks
1693         vestigial, particularly since only the CallLinkInfo patchable callee immediate uses it. It's
1694         not really necessary to have something like this, since our convention is that any pointer
1695         stored in machine code must always be shadowed in the GC heap. I think that convention has
1696         won by overwhelming majority, so we should finally remove JITWriteBarrier.
1697         
1698         A practical outcome of this change is that it makes it easier to implement DirectCall ICs,
1699         which will have to store the callee in the CallLinkInfo but not in the machine code.
1700
1701         * JavaScriptCore.xcodeproj/project.pbxproj:
1702         * assembler/AbstractMacroAssembler.h:
1703         * bytecode/CallLinkInfo.cpp:
1704         (JSC::CallLinkInfo::setCallee):
1705         (JSC::CallLinkInfo::clearCallee):
1706         * bytecode/CallLinkInfo.h:
1707         (JSC::CallLinkInfo::setCallee): Deleted.
1708         (JSC::CallLinkInfo::clearCallee): Deleted.
1709         * heap/SlotVisitor.h:
1710         * jit/JITWriteBarrier.h: Removed.
1711
1712 2016-10-12  Csaba Osztrogonác  <ossy@webkit.org>
1713
1714         Unreviewed buildfix for GCC 4.9 after r207186.
1715         https://bugs.webkit.org/show_bug.cgi?id=163255
1716
1717         * runtime/HasOwnPropertyCache.h:
1718         (JSC::HasOwnPropertyCache::Entry::Entry):
1719
1720 2016-10-11  Saam Barati  <sbarati@apple.com>
1721
1722         HasOwnPropertyCache needs to ref the UniquedStringImpls it sees
1723         https://bugs.webkit.org/show_bug.cgi?id=163255
1724
1725         Reviewed by Geoffrey Garen.
1726
1727         The cache needs to be responsible for ensuring that things
1728         in the cache stay alive. Before, it wasn't doing this, and
1729         that was wrong.
1730
1731         * runtime/HasOwnPropertyCache.h:
1732         (JSC::HasOwnPropertyCache::Entry::operator=):
1733         (JSC::HasOwnPropertyCache::operator delete):
1734         (JSC::HasOwnPropertyCache::create):
1735         (JSC::HasOwnPropertyCache::get):
1736         (JSC::HasOwnPropertyCache::tryAdd):
1737         (JSC::HasOwnPropertyCache::clear):
1738         (JSC::HasOwnPropertyCache::zeroBuffer):
1739
1740 2016-10-06  Filip Pizlo  <fpizlo@apple.com>
1741
1742         MarkedBlock should know what objects are live during marking
1743         https://bugs.webkit.org/show_bug.cgi?id=162309
1744
1745         Reviewed by Geoffrey Garen.
1746         
1747         It used to be that we would forget which objects are live the moment we started collection.
1748         That's because the flip at the beginning clears all mark bits.
1749         
1750         But we already have a facility for tracking objects that are live-but-not-marked. It's called
1751         newlyAllocated. So, instead of clearing mark bits, we want to just transfer them to
1752         newlyAllocated. Then we want to clear all newlyAllocated after GC.
1753         
1754         This implements such an approach, along with a versioning optimization for newlyAllocated.
1755         Instead of walking the whole heap to clear newlyAllocated bits at the end of the GC, we bump
1756         the newlyAllocatedVersion, which causes MarkedBlock to treat newlyAllocated as if it was
1757         clear.
1758         
1759         We could have even avoided allocating newlyAllocated in most cases, since empirically most
1760         blocks are either completely empty or completely full. An earlier version of this patch did
1761         this, but it was not better than this patch. In fact, it seemed to actually be worse for PLT
1762         and membuster.
1763         
1764         To validate this change, we now run the conservative scan after the beginMarking flip. And it
1765         totally works!
1766         
1767         This is a huge step towards concurrent GC. It means that we ought to be able to run the
1768         allocator while marking. Since we already separately made it possible to run the barrier
1769         while marking, this means that we're pretty much ready for some serious concurrency action.
1770         
1771         This appears to be perf-neutral and space-neutral.
1772
1773         * JavaScriptCore.xcodeproj/project.pbxproj:
1774         * bytecode/CodeBlock.cpp:
1775         * bytecode/CodeBlock.h:
1776         (JSC::CodeBlockSet::mark): Deleted.
1777         * heap/CodeBlockSet.cpp:
1778         (JSC::CodeBlockSet::writeBarrierCurrentlyExecuting):
1779         (JSC::CodeBlockSet::clearCurrentlyExecuting):
1780         (JSC::CodeBlockSet::writeBarrierCurrentlyExecutingCodeBlocks): Deleted.
1781         * heap/CodeBlockSet.h:
1782         * heap/CodeBlockSetInlines.h: Added.
1783         (JSC::CodeBlockSet::mark):
1784         * heap/ConservativeRoots.cpp:
1785         * heap/Heap.cpp:
1786         (JSC::Heap::markRoots):
1787         (JSC::Heap::beginMarking):
1788         (JSC::Heap::collectImpl):
1789         (JSC::Heap::writeBarrierCurrentlyExecutingCodeBlocks):
1790         (JSC::Heap::clearCurrentlyExecutingCodeBlocks):
1791         * heap/Heap.h:
1792         * heap/HeapUtil.h:
1793         (JSC::HeapUtil::findGCObjectPointersForMarking):
1794         * heap/MarkedAllocator.cpp:
1795         (JSC::MarkedAllocator::isPagedOut):
1796         * heap/MarkedBlock.cpp:
1797         (JSC::MarkedBlock::Handle::Handle):
1798         (JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated):
1799         (JSC::MarkedBlock::Handle::stopAllocating):
1800         (JSC::MarkedBlock::Handle::lastChanceToFinalize):
1801         (JSC::MarkedBlock::Handle::resumeAllocating):
1802         (JSC::MarkedBlock::aboutToMarkSlow):
1803         (JSC::MarkedBlock::Handle::resetAllocated):
1804         (JSC::MarkedBlock::resetMarks):
1805         (JSC::MarkedBlock::setNeedsDestruction):
1806         (JSC::MarkedBlock::Handle::didAddToAllocator):
1807         (JSC::MarkedBlock::Handle::isLive):
1808         (JSC::MarkedBlock::Handle::isLiveCell):
1809         (JSC::MarkedBlock::clearMarks): Deleted.
1810         * heap/MarkedBlock.h:
1811         (JSC::MarkedBlock::Handle::newlyAllocatedVersion):
1812         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated): Deleted.
1813         (JSC::MarkedBlock::Handle::clearNewlyAllocated): Deleted.
1814         * heap/MarkedBlockInlines.h:
1815         (JSC::MarkedBlock::Handle::cellsPerBlock):
1816         (JSC::MarkedBlock::Handle::isLive):
1817         (JSC::MarkedBlock::Handle::isLiveCell):
1818         (JSC::MarkedBlock::Handle::isNewlyAllocatedStale):
1819         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocatedWithSweep):
1820         (JSC::MarkedBlock::Handle::hasAnyNewlyAllocated):
1821         (JSC::MarkedBlock::heap):
1822         (JSC::MarkedBlock::space):
1823         (JSC::MarkedBlock::Handle::space):
1824         (JSC::MarkedBlock::resetMarkingVersion): Deleted.
1825         * heap/MarkedSpace.cpp:
1826         (JSC::MarkedSpace::beginMarking):
1827         (JSC::MarkedSpace::endMarking):
1828         (JSC::MarkedSpace::clearNewlyAllocated): Deleted.
1829         * heap/MarkedSpace.h:
1830         (JSC::MarkedSpace::nextVersion):
1831         (JSC::MarkedSpace::newlyAllocatedVersion):
1832         (JSC::MarkedSpace::markingVersion): Deleted.
1833         * runtime/SamplingProfiler.cpp:
1834
1835 2016-10-11  Mark Lam  <mark.lam@apple.com>
1836
1837         Array.prototype.concat should not modify frozen objects.
1838         https://bugs.webkit.org/show_bug.cgi?id=163302
1839
1840         Reviewed by Filip Pizlo.
1841
1842         The ES6 spec for Array.prototype.concat states that it uses the
1843         CreateDataPropertyOrThrow() to add items to the result array.  The spec for
1844         CreateDataPropertyOrThrow states:
1845
1846         "This abstract operation creates a property whose attributes are set to the same
1847         defaults used for properties created by the ECMAScript language assignment
1848         operator. Normally, the property will not already exist. If it does exist and is
1849         not configurable or if O is not extensible, [[DefineOwnProperty]] will return
1850         false causing this operation to throw a TypeError exception."
1851
1852         Since the properties of frozen objects are not extensible, not configurable, and
1853         not writable, Array.prototype.concat should fail to write to the result array if
1854         it is frozen.
1855
1856         Ref: https://tc39.github.io/ecma262/#sec-array.prototype.concat,
1857         https://tc39.github.io/ecma262/#sec-createdatapropertyorthrow, and
1858         https://tc39.github.io/ecma262/#sec-createdataproperty.
1859
1860         The fix consists of 2 parts:
1861         1. moveElement() should use the PutDirectIndexShouldThrow mode when invoking
1862            putDirectIndex(), and
1863         2. SparseArrayValueMap::putDirect() should check for the case where the property
1864            is read only.
1865
1866         (2) ensures that we don't write into a non-writable property.
1867         (1) ensures that we throw a TypeError for attempts to write to a non-writeable
1868         property.
1869
1870         * runtime/ArrayPrototype.cpp:
1871         (JSC::moveElements):
1872         * runtime/SparseArrayValueMap.cpp:
1873         (JSC::SparseArrayValueMap::putDirect):
1874
1875 2016-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
1876
1877         [DOMJIT] DOMJIT::Patchpoint should have a way to receive constant folded arguments
1878         https://bugs.webkit.org/show_bug.cgi?id=163224
1879
1880         Reviewed by Filip Pizlo.
1881
1882         We use the GetGlobalObject DFG node to retrieve a global object from a DOM node.
1883         This global object is necessary to check whether the world is normal before entering
1884         the fast path of looking up the DOM wrapper cache.
1885         We can sometimes constant-fold this GetGlobalObject. For example, if we performed
1886         CheckStructure, the structure can offer the information about the possible result
1887         of GetGlobalObject. By using this constant-folded global object, we can drop some
1888         checks.
1889
1890         This patch introduces the way to tell the constant-folded values to DOMJIT::Patchpoint.
1891         We pass DOMJIT::Value instead of DOMJIT::Reg as a parameter of DOMJIT::PatchpointParams.
1892         This DOMJIT::Value is a pair of DOMJIT::Reg and JSValue. If the given parameter has a
1893         constant value, this JSValue is filled with it.
1894
1895         * JavaScriptCore.xcodeproj/project.pbxproj:
1896         * dfg/DFGDOMJITPatchpointParams.h:
1897         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
1898         * dfg/DFGSpeculativeJIT.cpp:
1899         (JSC::DFG::SpeculativeJIT::compileCallDOM):
1900         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
1901         * domjit/DOMJITPatchpointParams.h:
1902         (JSC::DOMJIT::PatchpointParams::at):
1903         (JSC::DOMJIT::PatchpointParams::operator[]):
1904         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
1905         * domjit/DOMJITValue.h: Copied from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h.
1906         (JSC::DOMJIT::Value::Value):
1907         (JSC::DOMJIT::Value::isGPR):
1908         (JSC::DOMJIT::Value::isFPR):
1909         (JSC::DOMJIT::Value::isJSValueRegs):
1910         (JSC::DOMJIT::Value::gpr):
1911         (JSC::DOMJIT::Value::fpr):
1912         (JSC::DOMJIT::Value::jsValueRegs):
1913         (JSC::DOMJIT::Value::reg):
1914         (JSC::DOMJIT::Value::value):
1915         * ftl/FTLDOMJITPatchpointParams.h:
1916         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
1917         * ftl/FTLLowerDFGToB3.cpp:
1918         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
1919         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
1920
1921 2016-10-10  Filip Pizlo  <fpizlo@apple.com>
1922
1923         Air should be able to replace constant materializations with adds
1924         https://bugs.webkit.org/show_bug.cgi?id=162749
1925
1926         Reviewed by Yusuke Suzuki.
1927         
1928         We have a lot of defenses against emitting code that materializes huge contants. But if we do
1929         end up with such code in the backend, it's better to convert those materializations into add
1930         instructions by checking if other registers are known to contain nearby constants. That's
1931         what this patch does.
1932
1933         * b3/air/AirFixObviousSpills.cpp:
1934         * b3/testb3.cpp:
1935
1936 2016-10-11  Filip Pizlo  <fpizlo@apple.com>
1937
1938         B3->Air lowering needs the same defenses in effectiveAddr() that it has in tryAppendLea()
1939         https://bugs.webkit.org/show_bug.cgi?id=163264
1940
1941         Reviewed by Mark Lam.
1942         
1943         When writing the lea patch (r207039), I was very careful about how I convert a Shl into a
1944         BaseIndex scale. But I forgot to check if the older code for creating BaseIndexes for
1945         effectiveAddr() got this right. It turns out that the older code missed the <<32 corner
1946         case.
1947         
1948         It's sad that the two paths can't share all of their code, but it's somewhat inevitable due
1949         to how matching an address and matching a lea have to do very different things. Matching a
1950         lea means creating an instruction that is distinct from other instructions to do multiple
1951         math operations at once. Matching an address means making some instruction do extra work
1952         for free. Also, address matching can take advantage of the fact that the offset is already
1953         associated with the memory operation by strength reduction - lea matching can't do this; it
1954         has to figure out Add(@value, $const) on its own. This change makes the situation slightly
1955         more sane by adding a scaleForShl() helper that handles this weird case. It's based on the
1956         new Shl handling from r207039, and exposes it as an API for effectiveAddr() to use.
1957         
1958         The testLoadBaseIndexShift32() used to crash. I don't think that this case affects JS
1959         content, since <<32 is such a bizarre outlier. I don't think we even have a path along
1960         which the FTL would emit a 64-bit <<32. It probably won't even affect WebAssembly since
1961         that uses 32-bit pointers, so we won't see 64-bit <<32 in effectiveAddr() there.
1962
1963         * b3/B3LowerToAir.cpp:
1964         (JSC::B3::Air::LowerToAir::scaleForShl):
1965         (JSC::B3::Air::LowerToAir::effectiveAddr):
1966         (JSC::B3::Air::LowerToAir::tryAppendLea):
1967         (JSC::B3::Air::LowerToAir::crossesInterference): Deleted.
1968         * b3/testb3.cpp:
1969         (JSC::B3::testLoadBaseIndexShift2):
1970         (JSC::B3::testLoadBaseIndexShift32):
1971         (JSC::B3::run):
1972
1973 2016-10-11  Saam Barati  <sbarati@apple.com>
1974
1975         ValueAdd should be constant folded if the operands are constant String,Primitive or Primitive,String
1976         https://bugs.webkit.org/show_bug.cgi?id=163182
1977
1978         Reviewed by Filip Pizlo.
1979
1980         This code pattern shows up in Dromaeo, so it's worth optimizing for.
1981         This might also show up in real world JS code due to inlining and other
1982         types of constant folding.
1983
1984         * dfg/DFGByteCodeParser.cpp:
1985         (JSC::DFG::ByteCodeParser::parseBlock):
1986         * dfg/DFGLazyJSValue.cpp:
1987         (JSC::DFG::LazyJSValue::getValue):
1988         * dfg/DFGStrengthReductionPhase.cpp:
1989         (JSC::DFG::StrengthReductionPhase::handleNode):
1990
1991 2016-10-10  Zan Dobersek  <zdobersek@igalia.com>
1992
1993         Add ENABLE_ENCRYPTED_MEDIA configuration option
1994         https://bugs.webkit.org/show_bug.cgi?id=163219
1995
1996         Reviewed by Darin Adler.
1997
1998         * Configurations/FeatureDefines.xcconfig:
1999         Add the ENABLE_ENCRYPTED_MEDIA configuration option. It will be used
2000         to enable or disable the new EME implementation at build-time.
2001
2002 2016-10-10  Filip Pizlo  <fpizlo@apple.com>
2003
2004         B3->Air lowering should be able to emit complex leas on x86
2005         https://bugs.webkit.org/show_bug.cgi?id=163234
2006
2007         Reviewed by Saam Barati.
2008         
2009         This adds comprehensive support for emitting lea on x86.
2010         
2011         When adding this, I found that it was useful to also finally add more reassociation. That
2012         reduces the amount of patterns that the instruction selector has to deal with.
2013
2014         * assembler/MacroAssembler.h:
2015         (JSC::MacroAssembler::lea32):
2016         (JSC::MacroAssembler::lea64):
2017         (JSC::MacroAssembler::lea): Deleted.
2018         * b3/B3LowerToAir.cpp:
2019         (JSC::B3::Air::LowerToAir::commitInternal):
2020         (JSC::B3::Air::LowerToAir::tryAppendLea):
2021         (JSC::B3::Air::LowerToAir::lower):
2022         (JSC::B3::Air::LowerToAir::createSelect): Deleted.
2023         * b3/B3ReduceStrength.cpp:
2024         * b3/B3Value.h:
2025         * b3/B3ValueInlines.h:
2026         (JSC::B3::Value::isRepresentableAs):
2027         (JSC::B3::Value::representableAs): Deleted.
2028         * b3/air/AirOpcode.opcodes:
2029         * b3/testb3.cpp: Lots of tests for lea and reassociation.
2030
2031 2016-10-10  Mark Lam  <mark.lam@apple.com>
2032
2033         Change ArrayPrototype.cpp's putLength() and setLength() to take a VM& so that we can use vm.propertyNames.
2034         https://bugs.webkit.org/show_bug.cgi?id=163260
2035
2036         Reviewed by Saam Barati.
2037
2038         In all cases where we call these, we already have the VM& anyway.
2039
2040         * runtime/ArrayPrototype.cpp:
2041         (JSC::putLength):
2042         (JSC::setLength):
2043         (JSC::arrayProtoFuncPop):
2044         (JSC::arrayProtoFuncPush):
2045         (JSC::arrayProtoFuncShift):
2046         (JSC::arrayProtoFuncSlice):
2047         (JSC::arrayProtoFuncSplice):
2048         (JSC::arrayProtoFuncUnShift):
2049
2050 2016-10-10  Mark Lam  <mark.lam@apple.com>
2051
2052         Rename the StrictModeReadonlyPropertyWriteError string to ReadonlyPropertyWriteError.
2053         https://bugs.webkit.org/show_bug.cgi?id=163239
2054
2055         Reviewed by Filip Pizlo.
2056
2057         This string is also used for reporting the same error in cases which have nothing
2058         to do with strict mode.
2059
2060         * bytecompiler/BytecodeGenerator.cpp:
2061         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
2062         * runtime/CommonSlowPaths.cpp:
2063         (JSC::SLOW_PATH_DECL):
2064         * runtime/GetterSetter.cpp:
2065         (JSC::callSetter):
2066         * runtime/JSArray.cpp:
2067         (JSC::JSArray::setLengthWithArrayStorage):
2068         (JSC::JSArray::pop):
2069         * runtime/JSCJSValue.cpp:
2070         (JSC::JSValue::putToPrimitive):
2071         (JSC::JSValue::putToPrimitiveByIndex):
2072         * runtime/JSFunction.cpp:
2073         (JSC::JSFunction::put):
2074         * runtime/JSModuleEnvironment.cpp:
2075         (JSC::JSModuleEnvironment::put):
2076         * runtime/JSModuleNamespaceObject.cpp:
2077         (JSC::JSModuleNamespaceObject::put):
2078         (JSC::JSModuleNamespaceObject::putByIndex):
2079         * runtime/JSObject.cpp:
2080         (JSC::ordinarySetSlow):
2081         (JSC::JSObject::putInlineSlow):
2082         (JSC::JSObject::setPrototypeWithCycleCheck):
2083         (JSC::JSObject::putByIndexBeyondVectorLengthWithArrayStorage):
2084         (JSC::JSObject::putDirectIndexBeyondVectorLengthWithArrayStorage):
2085         * runtime/JSObject.h:
2086         * runtime/JSObjectInlines.h:
2087         (JSC::JSObject::putInline):
2088         * runtime/JSSymbolTableObject.h:
2089         (JSC::symbolTablePut):
2090         * runtime/Lookup.h:
2091         (JSC::putEntry):
2092         * runtime/RegExpObject.h:
2093         (JSC::RegExpObject::setLastIndex):
2094         * runtime/SparseArrayValueMap.cpp:
2095         (JSC::SparseArrayValueMap::putEntry):
2096         (JSC::SparseArrayEntry::put):
2097         * runtime/StringObject.cpp:
2098         (JSC::StringObject::put):
2099         (JSC::StringObject::putByIndex):
2100
2101 2016-10-10  Saam Barati  <sbarati@apple.com>
2102
2103         compileCheckStringIdent in the FTL is wrong
2104         https://bugs.webkit.org/show_bug.cgi?id=163215
2105
2106         Reviewed by Mark Lam and Filip Pizlo.
2107
2108         lowStringIdent() returns the StringImpl pointer. The compileCheckStringIdent()
2109         was treating its return value as the actual JSString. This is wrong.
2110
2111         * ftl/FTLLowerDFGToB3.cpp:
2112         (JSC::FTL::DFG::LowerDFGToB3::compileCheckStringIdent):
2113
2114 2016-10-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2115
2116         [DOMJIT] Implement Node accessors in DOMJIT
2117         https://bugs.webkit.org/show_bug.cgi?id=163005
2118
2119         Reviewed by Filip Pizlo.
2120
2121         Add some helper methods and offsetOfXXX for JSC::Weak since it is used
2122         for DOM wrapper caching.
2123
2124         And make DOMJIT::Patchpoint in FTL closer to one in DFG. We add resultConstraint
2125         to avoid the situation that the same register is allocated to child and result.
2126
2127         We also extend DOMJIT::Patchpoint to tell useTagTypeNumberRegister / useTagMaskRegister.
2128
2129         * dfg/DFGSpeculativeJIT.h:
2130         (JSC::DFG::SpeculativeJIT::callOperation):
2131         * domjit/DOMJITSlowPathCalls.h:
2132         * ftl/FTLLowerDFGToB3.cpp:
2133         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2134         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2135         * heap/WeakImpl.h:
2136         (JSC::WeakImpl::offsetOfJSValue):
2137         (JSC::WeakImpl::offsetOfWeakHandleOwner):
2138         * jit/AssemblyHelpers.h:
2139         (JSC::AssemblyHelpers::boxCell):
2140         (JSC::AssemblyHelpers::boxInt32): Deleted.
2141         * jit/JITOperations.h:
2142
2143 2016-10-09  Filip Pizlo  <fpizlo@apple.com>
2144
2145         Air should expose API for pinning registers
2146         https://bugs.webkit.org/show_bug.cgi?id=163175
2147
2148         Reviewed by Keith Miller.
2149         
2150         You can now call Procedure::pinRegister(), or Code::pinRegister(), and it will make this
2151         register behave as follows:
2152         
2153         - B3 and Air will emit no code that modifies the value in this register, except if that
2154           happens via a Patchpoint or stackmap constraint (i.e. the user explicitly asked for it).
2155         - B3 and Air will allow others to modify the register. For example, if the register is not
2156           callee-save, then the compiler knows that the register's value will be trashed by any
2157           C-style call.
2158         - Air will be happy to emit code that reads from this register, including coalescing tmps
2159           with it, so longer as there is no interference (i.e. no chance of the register's value
2160           changing). For example, if we went back to having pinned tag registers, we would tell B3
2161           to use them by (1) excluding them from any clobber set (easy, since they're callee save)
2162           and (2) emitting ArgumentReg to grab their value. There's a test that does this.
2163         
2164         This is accomplished by taking regsInPriorityOrder() and making it a method of Code. Air 
2165         already used this API when choosing registers in register allocation. Code now also vends a
2166         mutableRegs() set, which is derived from regsInPriorityOrder(), that can quickly tell you if
2167         a register can be mutated. Doing it this way means that most of this is a purely mechanical
2168         change. The calls to mutableRegs() are the places where we had to change logic:
2169         
2170         - The register allocators needs to know that coalescing with a precolored pinned tmp is free.
2171         - The callee-save handler needs to know that we're not supposed to save/restore pinned
2172           registers.
2173         
2174         Note that in this scheme, pinned registers are simply registers that do not appear in
2175         regsInPriorityOrder(). This means, for example, that we will now say that FP is pinned. So,
2176         this means that you can also pin registers by calling setRegsInPriorityOrder() and passing a
2177         vector that excludes some registers. More generally, this means that clients can now tweak
2178         the register allocator's register preferences, since the ordering in that list reflects the
2179         order in which the allocator will try registers.
2180
2181         * CMakeLists.txt:
2182         * JavaScriptCore.xcodeproj/project.pbxproj:
2183         * b3/B3Procedure.cpp:
2184         (JSC::B3::Procedure::pinRegister):
2185         * b3/B3Procedure.h:
2186         * b3/air/AirCode.cpp:
2187         (JSC::B3::Air::Code::Code):
2188         (JSC::B3::Air::Code::setRegsInPriorityOrder):
2189         (JSC::B3::Air::Code::pinRegister):
2190         * b3/air/AirCode.h:
2191         (JSC::B3::Air::Code::regsInPriorityOrder):
2192         (JSC::B3::Air::Code::mutableRegs):
2193         (JSC::B3::Air::Code::isPinned):
2194         (JSC::B3::Air::Code::regsInPriorityOrderImpl):
2195         (JSC::B3::Air::Code::proc): Deleted.
2196         * b3/air/AirEmitShuffle.cpp:
2197         (JSC::B3::Air::emitShuffle):
2198         * b3/air/AirEmitShuffle.h:
2199         * b3/air/AirHandleCalleeSaves.cpp:
2200         (JSC::B3::Air::handleCalleeSaves):
2201         * b3/air/AirIteratedRegisterCoalescing.cpp:
2202         * b3/air/AirLowerAfterRegAlloc.cpp:
2203         (JSC::B3::Air::lowerAfterRegAlloc):
2204         * b3/air/AirRegisterPriority.cpp: Removed.
2205         * b3/air/AirRegisterPriority.h: Removed.
2206         * b3/air/AirSpillEverything.cpp:
2207         (JSC::B3::Air::spillEverything):
2208         * b3/air/testair.cpp:
2209         (JSC::B3::Air::testShuffleBroadcastAllRegs):
2210         (JSC::B3::Air::testShuffleShiftAllRegs):
2211         (JSC::B3::Air::testShuffleRotateAllRegs):
2212         (JSC::B3::Air::testShuffleShiftMemoryAllRegs):
2213         (JSC::B3::Air::testShuffleShiftMemoryAllRegs64):
2214         (JSC::B3::Air::testShuffleShiftMemoryAllRegsMixedWidth):
2215         (JSC::B3::Air::testShuffleRotateMemoryAllRegs64):
2216         (JSC::B3::Air::testShuffleRotateMemoryAllRegsMixedWidth):
2217         * b3/testb3.cpp:
2218         (JSC::B3::testPinRegisters):
2219         (JSC::B3::run):
2220         * jit/RegisterSet.h:
2221
2222 2016-10-08  Filip Pizlo  <fpizlo@apple.com>
2223
2224         B3 should know about mutable pinned registers
2225         https://bugs.webkit.org/show_bug.cgi?id=163172
2226
2227         Reviewed by Keith Miller.
2228         
2229         If we have mutable pinned registers then we need to know which operations mutate them. At
2230         first I considered making this into a heap range thing, but I think that this would be very
2231         confusing. Also, in the future, we might want to make Effects track register sets of
2232         clobbered registers (see bug 163173).
2233
2234         * b3/B3Effects.cpp:
2235         (JSC::B3::Effects::interferes):
2236         (JSC::B3::Effects::operator==):
2237         (JSC::B3::Effects::dump):
2238         * b3/B3Effects.h:
2239         (JSC::B3::Effects::forCall):
2240         (JSC::B3::Effects::mustExecute):
2241
2242 2016-10-08  Saam Barati  <sbarati@apple.com>
2243
2244         HasIndexedProperty clobberize rule is wrong for Array::ForceOSRExit
2245         https://bugs.webkit.org/show_bug.cgi?id=159942
2246         <rdar://problem/27328836>
2247
2248         Reviewed by Filip Pizlo.
2249
2250         When HasIndexedProperty has a ForceOSRExit array mode, it should
2251         report to write to side state, like the ForceOSRExit node, and the
2252         other nodes with ForceOSRExit array mode.
2253
2254         * dfg/DFGClobberize.h:
2255         (JSC::DFG::clobberize):
2256
2257 2016-10-07  Mark Lam  <mark.lam@apple.com>
2258
2259         Object.freeze() and seal() should throw if [[PreventExtensions]]() fails.
2260         https://bugs.webkit.org/show_bug.cgi?id=163160
2261
2262         Reviewed by Saam Barati.
2263
2264         See https://tc39.github.io/ecma262/#sec-object.freeze,
2265         https://tc39.github.io/ecma262/#sec-object.seal, and
2266         https://tc39.github.io/ecma262/#sec-setintegritylevel.  We need to call
2267         preventExtensions first before proceeding to freeze / seal the object.  If
2268         preventExtensions fails, we should throw a TypeError.
2269
2270         * runtime/ObjectConstructor.cpp:
2271         (JSC::setIntegrityLevel):
2272         (JSC::objectConstructorSeal):
2273         (JSC::objectConstructorFreeze):
2274
2275 2016-10-06  Yusuke Suzuki  <utatane.tea@gmail.com>
2276
2277         [DOMJIT] Support slow path call
2278         https://bugs.webkit.org/show_bug.cgi?id=162978
2279
2280         Reviewed by Saam Barati.
2281
2282         One of the most important features required in DOMJIT::Patchpoint is slow path calls.
2283         DOM operation typically returns DOMWrapper object. At that time, if wrapper cache hits, we can go
2284         to the fast path. However, if we cannot use the cache, we need to go to the slow path to call toJS function.
2285         At that time, slow path call functionality is necessary.
2286
2287         This patch expose DOMJIT::PatchpointParams::addSlowPathCall. We can request slow path call code generation
2288         through this interface. DOMJIT::PatchpointParams automatically leverages appropriate slow path call systems
2289         in each tier. In DFG, we use slow path call system. In FTL, we implement slow path call by using addLatePath
2290         to construct slow path call. But these details are completely hidden by DOMJIT::PatchpointParams. Users can
2291         just use addSlowPathCall.
2292
2293         Since DFG and FTL slow path call systems are implemented in variadic templates, directly using this means
2294         that we need to expose core part of DFG and FTL. For example, DFG::SpeculativeJIT need to be exposed in
2295         such a design. That is too bad. Instead, we use magical macro in DOMJITSlowPathCalls.h. We can list up the
2296         call signatures in DOMJIT_SLOW_PATH_CALLS. DOMJIT uses these signatures to generate an interface to request
2297         slow path calls inside DFG and FTL instead of exposing everything.
2298
2299         * CMakeLists.txt:
2300         * JavaScriptCore.xcodeproj/project.pbxproj:
2301         * dfg/DFGCommon.h:
2302         * dfg/DFGDOMJITPatchpointParams.cpp: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2303         (JSC::DFG::dispatch):
2304         * dfg/DFGDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2305         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
2306         * dfg/DFGSpeculativeJIT.cpp:
2307         (JSC::DFG::SpeculativeJIT::compileCallDOM):
2308         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
2309         * dfg/DFGSpeculativeJIT.h:
2310         (JSC::DFG::extractResult): Deleted.
2311         * domjit/DOMJITPatchpointParams.h:
2312         (JSC::DOMJIT::PatchpointParams::addSlowPathCall):
2313         * domjit/DOMJITSlowPathCalls.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2314         * ftl/FTLDOMJITPatchpointParams.cpp: Added.
2315         (JSC::FTL::dispatch):
2316         * ftl/FTLDOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
2317         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
2318         * ftl/FTLLowerDFGToB3.cpp:
2319         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2320         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2321         * jit/GPRInfo.h:
2322         (JSC::extractResult):
2323         * jsc.cpp:
2324
2325 2016-10-06  Saam Barati  <sbarati@apple.com>
2326
2327         HasOwnPropertyCache flattening dictionaries is causing insane memory usage with the uBlock Safari extension
2328         https://bugs.webkit.org/show_bug.cgi?id=163091
2329
2330         Reviewed by Mark Lam.
2331
2332         I'm investigating a real fix for this in:
2333         https://bugs.webkit.org/show_bug.cgi?id=163092
2334         However, it's best to get this out of trunk for now.
2335
2336         * runtime/HasOwnPropertyCache.h:
2337         (JSC::HasOwnPropertyCache::tryAdd):
2338
2339 2016-10-06  Keith Miller  <keith_miller@apple.com>
2340
2341         getInternalObjcObject should validate the JSManagedObject's value.
2342         https://bugs.webkit.org/show_bug.cgi?id=162985
2343
2344         Reviewed by Geoffrey Garen.
2345
2346         Previously, if, for instance, the JSManagedObject's weak value had been
2347         cleared we would call tryUnwrapObjcObject with a nil context and value.
2348         This triggered assertions failures as those functions expect their inputs
2349         to be valid.
2350
2351         * API/JSVirtualMachine.mm:
2352         (getInternalObjcObject):
2353
2354 2016-10-06  Brian Burg  <bburg@apple.com>
2355
2356         Web Inspector: RemoteInspector should cache client capabilities for off-main thread usage
2357         https://bugs.webkit.org/show_bug.cgi?id=163039
2358         <rdar://problem/28571460>
2359
2360         Reviewed by Timothy Hatcher.
2361
2362         The fix in r206797 was incorrect because listings are always pushed out on the XPC connection queue.
2363         Instead of delaying the listing needlessly, RemoteInspector should cache the capabilities of its
2364         client while on the main thread, then use the cached struct data on the XPC connection queue rather
2365         than directly accessing m_client. This is similar to how RemoteConnectionToTarget marshalls listing
2366         information from arbitrary queues into m_targetListingMap, which can then be read from any queue.
2367
2368         * inspector/remote/RemoteInspector.h:
2369         * inspector/remote/RemoteInspector.mm:
2370         (Inspector::RemoteInspector::updateClientCapabilities): Cache the capabilities.
2371         (Inspector::RemoteInspector::setRemoteInspectorClient):
2372         Re-cache the capabilities. Scope the lock to avoid reentrant locking.
2373
2374         (Inspector::RemoteInspector::clientCapabilitiesDidChange): Cache the capabilities.
2375         (Inspector::RemoteInspector::pushListingsNow): Use cached client capabilities.
2376         (Inspector::RemoteInspector::receivedGetListingMessage): Revert the change in r206797.
2377         (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
2378
2379 2016-10-06  Yusuke Suzuki  <utatane.tea@gmail.com>
2380
2381         [WebCore][JSC] Use new @throwTypeError and @throwRangeError intrinsics
2382         https://bugs.webkit.org/show_bug.cgi?id=163001
2383
2384         Reviewed by Keith Miller.
2385
2386         Previously, the argument of @throwXXXError intrinsics must be string literal.
2387         But it is error-prone restriction. This patch relaxes the restriction to accept
2388         arbitrary values. To keep emitted bytecode small, if the argument is string literal,
2389         we generate the same bytecode as before. If the argument is not string literal,
2390         we evaluate it and perform to_string before passing to throw_static_error.
2391
2392         * bytecompiler/BytecodeGenerator.cpp:
2393         (JSC::BytecodeGenerator::emitThrowStaticError):
2394         * bytecompiler/BytecodeGenerator.h:
2395         * bytecompiler/NodesCodegen.cpp:
2396         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
2397         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
2398         * dfg/DFGByteCodeParser.cpp:
2399         (JSC::DFG::ByteCodeParser::parseBlock):
2400
2401 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2402
2403         [JSC] Add @throwXXXError bytecode intrinsic
2404         https://bugs.webkit.org/show_bug.cgi?id=162995
2405
2406         Reviewed by Saam Barati.
2407
2408         Builtin JS code need to check arguments carefully since it is somewhat standard library for JS.
2409         So bunch of `throw new @TypeError("...")` exists while usual code does not have so many.
2410         However the above code bloats 32 instructions per site, enlarges the size of bytecodes of builtins,
2411         and prevent us from inlining. We should have a way to reduce this size.
2412
2413         Fortunately, we already have such a opcode: op_throw_static_error. In this patch,
2414         1. We extends op_throw_static_error to throw arbitrary errors. Previously, only TypeError and ReferenceError are allowed.
2415            We can embed ErrorType enum in op_throw_static_error to throw any types of errors.
2416         2. We introduce several new bytecode intrinsics, `@throwTypeError("...")`, `@throwRangeError("...")`,
2417            and `@throwOutOfMemoryError()`. And use it inside builtin JS instead of `throw new @TypeError("...")` thingy.
2418         3. DFG Node for throw_static_error is incorrectly named as "ThrowReferenceError". This patch renames it to "ThrowStaticError".
2419
2420         * builtins/ArrayConstructor.js:
2421         * builtins/ArrayIteratorPrototype.js:
2422         (next):
2423         * builtins/ArrayPrototype.js:
2424         (values):
2425         (keys):
2426         (entries):
2427         (reduce):
2428         (reduceRight):
2429         (every):
2430         (forEach):
2431         (filter):
2432         (map):
2433         (some):
2434         (fill):
2435         (find):
2436         (findIndex):
2437         (includes):
2438         (sort):
2439         (concatSlowPath):
2440         (copyWithin):
2441         * builtins/DatePrototype.js:
2442         (toLocaleString.toDateTimeOptionsAnyAll):
2443         (toLocaleString):
2444         (toLocaleDateString.toDateTimeOptionsDateDate):
2445         (toLocaleDateString):
2446         (toLocaleTimeString.toDateTimeOptionsTimeTime):
2447         (toLocaleTimeString):
2448         * builtins/FunctionPrototype.js:
2449         (bind):
2450         * builtins/GeneratorPrototype.js:
2451         (globalPrivate.generatorResume):
2452         * builtins/GlobalOperations.js:
2453         (globalPrivate.speciesConstructor):
2454         * builtins/MapPrototype.js:
2455         (forEach):
2456         * builtins/ModuleLoaderPrototype.js:
2457         (provide):
2458         * builtins/ObjectConstructor.js:
2459         (values):
2460         (entries):
2461         (assign):
2462         * builtins/PromiseConstructor.js:
2463         (race):
2464         (reject):
2465         (resolve):
2466         * builtins/PromiseOperations.js:
2467         (globalPrivate.newPromiseCapability.executor):
2468         (globalPrivate.newPromiseCapability):
2469         (globalPrivate.initializePromise):
2470         * builtins/PromisePrototype.js:
2471         * builtins/ReflectObject.js:
2472         (apply):
2473         (deleteProperty):
2474         (has):
2475         * builtins/RegExpPrototype.js:
2476         (globalPrivate.regExpExec):
2477         (match):
2478         (replace):
2479         (search):
2480         (split):
2481         (intrinsic.RegExpTestIntrinsic.test):
2482         * builtins/SetPrototype.js:
2483         (forEach):
2484         * builtins/StringConstructor.js:
2485         (raw):
2486         * builtins/StringIteratorPrototype.js:
2487         (next):
2488         * builtins/StringPrototype.js:
2489         (match):
2490         (globalPrivate.repeatSlowPath):
2491         (repeat):
2492         (padStart):
2493         (padEnd):
2494         (intrinsic.StringPrototypeReplaceIntrinsic.replace):
2495         (localeCompare):
2496         (search):
2497         (split):
2498         * builtins/TypedArrayConstructor.js:
2499         (of):
2500         (from):
2501         * builtins/TypedArrayPrototype.js:
2502         (globalPrivate.typedArraySpeciesConstructor):
2503         (every):
2504         (find):
2505         (findIndex):
2506         (forEach):
2507         (some):
2508         (subarray):
2509         (reduce):
2510         (reduceRight):
2511         (map):
2512         (filter):
2513         * bytecode/BytecodeIntrinsicRegistry.h:
2514         * bytecode/CodeBlock.cpp:
2515         (JSC::CodeBlock::dumpBytecode):
2516         * bytecompiler/BytecodeGenerator.cpp:
2517         (JSC::BytecodeGenerator::emitThrowStaticError):
2518         (JSC::BytecodeGenerator::emitThrowReferenceError):
2519         (JSC::BytecodeGenerator::emitThrowTypeError):
2520         (JSC::BytecodeGenerator::emitThrowRangeError):
2521         (JSC::BytecodeGenerator::emitThrowOutOfMemoryError):
2522         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
2523         * bytecompiler/BytecodeGenerator.h:
2524         * bytecompiler/NodesCodegen.cpp:
2525         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
2526         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
2527         (JSC::BytecodeIntrinsicNode::emit_intrinsic_throwOutOfMemoryError):
2528         * dfg/DFGAbstractInterpreterInlines.h:
2529         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2530         * dfg/DFGByteCodeParser.cpp:
2531         (JSC::DFG::ByteCodeParser::parseBlock):
2532         * dfg/DFGClobberize.h:
2533         (JSC::DFG::clobberize):
2534         * dfg/DFGDoesGC.cpp:
2535         (JSC::DFG::doesGC):
2536         * dfg/DFGFixupPhase.cpp:
2537         (JSC::DFG::FixupPhase::fixupNode):
2538         * dfg/DFGNodeType.h:
2539         * dfg/DFGPredictionPropagationPhase.cpp:
2540         * dfg/DFGSafeToExecute.h:
2541         (JSC::DFG::safeToExecute):
2542         * dfg/DFGSpeculativeJIT32_64.cpp:
2543         (JSC::DFG::SpeculativeJIT::compile):
2544         * dfg/DFGSpeculativeJIT64.cpp:
2545         (JSC::DFG::SpeculativeJIT::compile):
2546         * ftl/FTLCapabilities.cpp:
2547         (JSC::FTL::canCompile):
2548         * ftl/FTLLowerDFGToB3.cpp:
2549         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2550         * jit/JITOpcodes.cpp:
2551         (JSC::JIT::emit_op_throw_static_error):
2552         * jit/JITOpcodes32_64.cpp:
2553         (JSC::JIT::emit_op_throw_static_error): Deleted.
2554         * jit/JITOperations.cpp:
2555         * jit/JITOperations.h:
2556         * llint/LLIntSlowPaths.cpp:
2557         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
2558         * llint/LLIntSlowPaths.h:
2559         * llint/LowLevelInterpreter.asm:
2560         * runtime/CommonSlowPaths.cpp:
2561         (JSC::SLOW_PATH_DECL):
2562         * runtime/CommonSlowPaths.h:
2563         * runtime/Error.cpp:
2564         (JSC::createError):
2565         (WTF::printInternal):
2566         * runtime/Error.h:
2567
2568 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2569
2570         Unreviewed, attempt to fix CLoop build after r206846
2571         https://bugs.webkit.org/show_bug.cgi?id=162941
2572
2573         Attempt to fix CLoop build part 2. r206847 was not valid.
2574
2575         * jsc.cpp:
2576
2577 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2578
2579         Unreviewed, build fix after r206846
2580         https://bugs.webkit.org/show_bug.cgi?id=162941
2581
2582         DOMJIT::Patchpoint part should be guarded by ENABLE(JIT).
2583
2584         * jsc.cpp:
2585
2586 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2587
2588         [DOMJIT] Add initial CheckDOM and CallDOM implementations
2589         https://bugs.webkit.org/show_bug.cgi?id=162941
2590
2591         Reviewed by Filip Pizlo.
2592
2593         This patch implements a prototype of DOMJIT accelerated getter.
2594         We add two new DFG nodes, CheckDOM and CallDOM.
2595
2596         CheckDOM is used to filter inappropriate |this| object for DOM getter. Its functionality
2597         is equivalent to jsDynamicCast's Check. You can use like "CheckDOM, @1, JSNode::info()",
2598         and this CheckDOM incurs a BadType exit if the class of the given @1 is not a subclass of
2599         JSNode::info().
2600
2601         CallDOM is used to emit actual DOM operations. It takes GlobalObject and checked DOM
2602         object. And it returns JSValue as its result.
2603
2604         Both CheckDOM and CallDOM can take a DOMJIT::Patchpoint. This is somewhat code snippet
2605         generator, and is injectable to DFG and FTL. DFG and FTL set up registers correctly
2606         according to DOMJIT::Patchpoint's requirement and invoke this patchpoint generator to emit code.
2607         While CallDOM always requires a patchpoint, ideally CheckDOM does not require it since
2608         isSubclassOf check can be implemented in DFG / FTL side. However, some classes have a
2609         faster way to query isSubclassOf. For example, JSNode in WebCore introduces a special
2610         JSType to optimize this query. CheckDOM's patchpoint gives us a chance to emit special
2611         faster code for such a case.
2612
2613         By leveraging above nodes, we can construct DOMJIT accelerated getter. When DFG recognizes the
2614         given getter call is CustomGetter and it has DOMJIT::GetterSetter information, DFG emits the above nodes.
2615         We implemented a prototype in jsc.cpp shell as DOMJITGetter to test the functionality.
2616
2617         Notes about the future extensions.
2618
2619         1. Currently, we do not allow CallDOM to emit any function calls. This will be extended by
2620            adding `addSlowPathCall` functionality to DOMJIT::Patchpoint later. Interesting thing is that
2621            we need to create an abstraction over DFG slow path call and FTL slow path call!
2622
2623         2. CheckDOM is not handled in DFGTypeCheckHoistingPhase yet. And we have a chance to merge several CheckDOM into one.
2624            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.
2625
2626         * JavaScriptCore.xcodeproj/project.pbxproj:
2627         * b3/B3Effects.h:
2628         (JSC::B3::Effects::forCheck):
2629         * b3/B3Value.cpp:
2630         (JSC::B3::Value::effects):
2631         * bytecode/GetByIdStatus.cpp:
2632         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
2633         (JSC::GetByIdStatus::makesCalls):
2634         (JSC::GetByIdStatus::dump):
2635         * bytecode/GetByIdStatus.h:
2636         (JSC::GetByIdStatus::GetByIdStatus):
2637         (JSC::GetByIdStatus::isCustom):
2638         (JSC::GetByIdStatus::takesSlowPath):
2639         (JSC::GetByIdStatus::isSimple): Deleted.
2640         * bytecode/SpeculatedType.cpp:
2641         (JSC::speculationFromClassInfo):
2642         * dfg/DFGAbstractInterpreter.h:
2643         (JSC::DFG::AbstractInterpreter::filterClassInfo):
2644         * dfg/DFGAbstractInterpreterInlines.h:
2645         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2646         (JSC::DFG::AbstractInterpreter<AbstractStateType>::filterClassInfo):
2647         * dfg/DFGAbstractValue.cpp:
2648         (JSC::DFG::AbstractValue::filterClassInfo):
2649         * dfg/DFGAbstractValue.h:
2650         * dfg/DFGByteCodeParser.cpp:
2651         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
2652         (JSC::DFG::ByteCodeParser::handleGetById):
2653         * dfg/DFGClobberize.h:
2654         (JSC::DFG::clobberize):
2655         * dfg/DFGConstantFoldingPhase.cpp:
2656         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2657         * dfg/DFGDoesGC.cpp:
2658         (JSC::DFG::doesGC):
2659         * dfg/DFGFixupPhase.cpp:
2660         (JSC::DFG::FixupPhase::fixupNode):
2661         * dfg/DFGNode.h:
2662         (JSC::DFG::Node::hasHeapPrediction):
2663         (JSC::DFG::Node::hasDOMJIT):
2664         (JSC::DFG::Node::domJIT):
2665         (JSC::DFG::Node::hasClassInfo):
2666         (JSC::DFG::Node::classInfo):
2667         (JSC::DFG::Node::OpInfoWrapper::OpInfoWrapper):
2668         (JSC::DFG::Node::OpInfoWrapper::operator=):
2669         * dfg/DFGNodeType.h:
2670         * dfg/DFGOpInfo.h:
2671         (JSC::DFG::OpInfo::OpInfo):
2672         * dfg/DFGPredictionPropagationPhase.cpp:
2673         * dfg/DFGSafeToExecute.h:
2674         (JSC::DFG::safeToExecute):
2675         * dfg/DFGSpeculativeJIT.cpp:
2676         (JSC::DFG::allocateTemporaryRegistersForPatchpoint):
2677         (JSC::DFG::SpeculativeJIT::compileCallDOM):
2678         (JSC::DFG::SpeculativeJIT::compileCheckDOM):
2679         * dfg/DFGSpeculativeJIT.h:
2680         * dfg/DFGSpeculativeJIT32_64.cpp:
2681         (JSC::DFG::SpeculativeJIT::compile):
2682         * dfg/DFGSpeculativeJIT64.cpp:
2683         (JSC::DFG::SpeculativeJIT::compile):
2684         * dfg/DFGStructureAbstractValue.cpp:
2685         (JSC::DFG::StructureAbstractValue::filterClassInfoSlow):
2686         (JSC::DFG::StructureAbstractValue::isSubClassOf):
2687         * dfg/DFGStructureAbstractValue.h:
2688         (JSC::DFG::StructureAbstractValue::filterClassInfo):
2689         (JSC::DFG::StructureAbstractValue::filter): Deleted.
2690         * domjit/DOMJITPatchpointParams.h: Copied from Source/JavaScriptCore/dfg/DFGOpInfo.h.
2691         (JSC::DOMJIT::PatchpointParams::~PatchpointParams):
2692         (JSC::DOMJIT::PatchpointParams::size):
2693         (JSC::DOMJIT::PatchpointParams::at):
2694         (JSC::DOMJIT::PatchpointParams::operator[]):
2695         (JSC::DOMJIT::PatchpointParams::gpScratch):
2696         (JSC::DOMJIT::PatchpointParams::fpScratch):
2697         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
2698         * domjit/DOMJITReg.h: Added.
2699         (JSC::DOMJIT::Reg::Reg):
2700         (JSC::DOMJIT::Reg::isGPR):
2701         (JSC::DOMJIT::Reg::isFPR):
2702         (JSC::DOMJIT::Reg::isJSValueRegs):
2703         (JSC::DOMJIT::Reg::gpr):
2704         (JSC::DOMJIT::Reg::fpr):
2705         (JSC::DOMJIT::Reg::jsValueRegs):
2706         * ftl/FTLCapabilities.cpp:
2707         (JSC::FTL::canCompile):
2708         * ftl/FTLLowerDFGToB3.cpp:
2709         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2710         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM):
2711         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
2712         (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable): Deleted.
2713         * jit/AssemblyHelpers.h:
2714         * jsc.cpp:
2715         (WTF::DOMJITNode::DOMJITNode):
2716         (WTF::DOMJITNode::createStructure):
2717         (WTF::DOMJITNode::create):
2718         (WTF::DOMJITNode::value):
2719         (WTF::DOMJITNode::offsetOfValue):
2720         (WTF::DOMJITGetter::DOMJITGetter):
2721         (WTF::DOMJITGetter::createStructure):
2722         (WTF::DOMJITGetter::create):
2723         (WTF::DOMJITGetter::DOMJITNodeDOMJIT::DOMJITNodeDOMJIT):
2724         (WTF::DOMJITGetter::domJITNodeGetterSetter):
2725         (WTF::DOMJITGetter::finishCreation):
2726         (WTF::DOMJITGetter::customGetter):
2727         (GlobalObject::finishCreation):
2728         (functionCreateDOMJITNodeObject):
2729         (functionCreateDOMJITGetterObject):
2730
2731 2016-10-05  Yusuke Suzuki  <utatane.tea@gmail.com>
2732
2733         [JSC] Do not construct Simple GetByIdStatus against self-custom-accessor case
2734         https://bugs.webkit.org/show_bug.cgi?id=162993
2735
2736         Reviewed by Filip Pizlo.
2737
2738         We accidentally created a Simple GetByIdStatus against self-custom-accessor case: the object has own custom accessor property and get_by_id hits.
2739         If we returned such a result, the GetById will be turned to GetByOffset and it looks up incorrect thing like CustomGetterSetter object.
2740         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.
2741         For example, "Node.prototype" has "firstChild" custom accessor. But since "Node.prototype" itself does not have Node::info(), "Node.prototype.firstChild"
2742         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
2743         it can occur even if we disabled DOMJIT).
2744
2745         But such a assumption is not guaranteed. In this patch, we fix this by not returning Simple GetById.
2746
2747         * bytecode/GetByIdStatus.cpp:
2748         (JSC::GetByIdStatus::computeFromLLInt):
2749         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
2750         (JSC::GetByIdStatus::computeFor):
2751
2752 2016-10-05  Saam Barati  <sbarati@apple.com>
2753
2754         PCToCodeOriginMap builder should use labelIgnoringWatchpoints() inside the DFG
2755         https://bugs.webkit.org/show_bug.cgi?id=162936
2756
2757         Reviewed by Michael Saboff.
2758
2759         label() may insert nops because of an InvalidationPoint. It does that
2760         because we don't want code that comes after an InvalidationPoint that isn't
2761         effected by the invalidation point to be overwritten if we fire the
2762         InvalidationPoint. PCToCodeOriginMap just grabs labels to build
2763         a mapping, it never emits code that actually jumps to those labels.
2764         Therefore, it should never cause us to emit nops.
2765
2766         * dfg/DFGJITCompiler.cpp:
2767         (JSC::DFG::JITCompiler::compile):
2768         (JSC::DFG::JITCompiler::compileFunction):
2769         * dfg/DFGSpeculativeJIT.cpp:
2770         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
2771         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2772
2773 2016-10-05  Myles C. Maxfield  <mmaxfield@apple.com>
2774
2775         Put variation fonts work behind a compile-time flag
2776         https://bugs.webkit.org/show_bug.cgi?id=162949
2777
2778         Reviewed by Simon Fraser.
2779
2780         * Configurations/FeatureDefines.xcconfig:
2781
2782 2016-10-05  Andy VanWagoner  <thetalecrafter@gmail.com>
2783
2784         [INTL] Implement Intl.getCanonicalLocales
2785         https://bugs.webkit.org/show_bug.cgi?id=162768
2786
2787         Reviewed by Benjamin Poulain.
2788
2789         Implement Intl.getCanonicalLocales from ECMA 402 (3rd edition)
2790         http://ecma-international.org/ecma-402/3.0/index.html#sec-intl.getcanonicallocales
2791
2792         Reuse canonicalizeLocaleList and copy the results into a new JSArray.
2793
2794         * runtime/IntlObject.cpp:
2795         (JSC::IntlObject::finishCreation):
2796         (JSC::intlObjectFuncGetCanonicalLocales):
2797
2798 2016-10-05  Michael Saboff  <msaboff@apple.com>
2799
2800         Bad ASSERT in ClonedArguments::createByCopyingFrom()
2801         https://bugs.webkit.org/show_bug.cgi?id=162988
2802
2803         Reviewed by Keith Miller.
2804
2805         Removed bogus assert.
2806
2807         * runtime/ClonedArguments.cpp:
2808         (JSC::ClonedArguments::createByCopyingFrom):
2809
2810 2016-10-05  Zan Dobersek  <zdobersek@igalia.com>
2811
2812         Rename ENABLE_ENCRYPTED_MEDIA_V2 to ENABLE_LEGACY_ENCRYPTED_MEDIA
2813         https://bugs.webkit.org/show_bug.cgi?id=162903
2814
2815         Reviewed by Alex Christensen.
2816
2817         Rename build guards for the remaining implementation of the legacy EME API
2818         to ENABLE_LEGACY_ENCRYPTED_MEDIA. This will allow for the future implementation
2819         of the near-finished API to be guarded with the simple ENABLE_ENCRYPTED_MEDIA guards.
2820
2821         * Configurations/FeatureDefines.xcconfig:
2822
2823 2016-10-05  Csaba Osztrogonác  <ossy@webkit.org>
2824
2825         ARM EABI buildfix after r206778
2826         https://bugs.webkit.org/show_bug.cgi?id=162964
2827
2828         Unreviewed trivial fix.
2829
2830         * jit/CCallHelpers.h:
2831         (JSC::CCallHelpers::setupArgumentsWithExecState):
2832
2833 2016-10-04  Saam Barati  <sbarati@apple.com>
2834
2835         String.prototype.toLowerCase should be a DFG/FTL intrinsic
2836         https://bugs.webkit.org/show_bug.cgi?id=162887
2837
2838         Reviewed by Filip Pizlo and Yusuke Suzuki.
2839
2840         This patch makes ToLowerCase an intrinsic in the DFG/FTL. On the fast
2841         path, the intrinsic will loop over an 8-bit string ensuring it's already
2842         lower case, and simply return the string. In the slow path, it'll call
2843         into C code to make a new string.
2844
2845         This is a 7-8% speedup on ES6SampleBench/Basic.
2846
2847         * dfg/DFGAbstractInterpreterInlines.h:
2848         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2849         * dfg/DFGByteCodeParser.cpp:
2850         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2851         * dfg/DFGClobberize.h:
2852         (JSC::DFG::clobberize):
2853         * dfg/DFGDoesGC.cpp:
2854         (JSC::DFG::doesGC):
2855         * dfg/DFGFixupPhase.cpp:
2856         (JSC::DFG::FixupPhase::fixupNode):
2857         * dfg/DFGNodeType.h:
2858         * dfg/DFGOperations.cpp:
2859         * dfg/DFGOperations.h:
2860         * dfg/DFGPredictionPropagationPhase.cpp:
2861         * dfg/DFGSafeToExecute.h:
2862         (JSC::DFG::safeToExecute):
2863         * dfg/DFGSpeculativeJIT.cpp:
2864         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
2865         * dfg/DFGSpeculativeJIT.h:
2866         (JSC::DFG::SpeculativeJIT::callOperation):
2867         * dfg/DFGSpeculativeJIT32_64.cpp:
2868         (JSC::DFG::SpeculativeJIT::compile):
2869         * dfg/DFGSpeculativeJIT64.cpp:
2870         (JSC::DFG::SpeculativeJIT::compile):
2871         * ftl/FTLAbstractHeapRepository.h:
2872         * ftl/FTLCapabilities.cpp:
2873         (JSC::FTL::canCompile):
2874         * ftl/FTLLowerDFGToB3.cpp:
2875         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2876         (JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
2877         * jit/JITOperations.h:
2878         * runtime/Intrinsic.h:
2879         * runtime/StringPrototype.cpp:
2880         (JSC::StringPrototype::finishCreation):
2881
2882 2016-10-04  Brian Burg  <bburg@apple.com>
2883
2884         Web Inspector: don't synchronously send a listing message if we might need to query _WKAutomationDelegate
2885         https://bugs.webkit.org/show_bug.cgi?id=162810
2886         <rdar://problem/28571460>
2887
2888         Reviewed by Timothy Hatcher.
2889
2890         We shouldn't ever access the _WKAutomationDelegate through RemoteInspector::Client methods
2891         off of the main thread, because it could cause problems. This happens when we pushListingsNow()
2892         in response to a WIRApplicationGetListingMessage XPC message. In this case, just use
2893         pushListingsSoon() since it dispatches on the correct (main) queue to gather listing information.
2894
2895         This may induce a slight update delay when first connecting to the UIProcess through RemoteInspector,
2896         but this is at most 200ms and will coalesce with other updates that happen when UIProcess gets set up.
2897
2898         There are no other code paths through RemoteInspector (for UIProcess) that could cause a call
2899         to pushListingsNow(), so this only needs to be changed in the XPC message handler.
2900
2901         * inspector/remote/RemoteInspector.mm:
2902         (Inspector::RemoteInspector::receivedGetListingMessage):
2903
2904 2016-10-04  JF Bastien  <jfbastien@apple.com>
2905
2906         WebAssembly: handle a few corner cases
2907         https://bugs.webkit.org/show_bug.cgi?id=162884
2908
2909         Reviewed by Keith Miller.
2910
2911         * wasm/JSWASMModule.cpp: missing include broke cmake build
2912         * wasm/WASMFunctionParser.h:
2913         (JSC::WASM::FunctionParser<Context>::parseBlock): check op is valid
2914         (JSC::WASM::FunctionParser<Context>::parseExpression): switch covers all cases
2915         * wasm/WASMOps.h:
2916         (JSC::WASM::isValidOpType): op is valid
2917         * wasm/WASMParser.h:
2918         (JSC::WASM::Parser::consumeString): avoid str[i] being one-past-the-end
2919         (JSC::WASM::Parser::parseUInt32): shift math around to avoid overflow
2920
2921 2016-10-04  Yusuke Suzuki  <utatane.tea@gmail.com>
2922
2923         REGRESSION (r206778): Release JSC test ChakraCore.yaml/ChakraCore/test/Error/validate_line_column.js.default failing
2924         https://bugs.webkit.org/show_bug.cgi?id=162937
2925
2926         Reviewed by Saam Barati.
2927
2928         We dropped expression info accidentally at r206777.
2929
2930         * bytecompiler/BytecodeGenerator.cpp:
2931         (JSC::BytecodeGenerator::emitCallDefineProperty):
2932         * bytecompiler/BytecodeGenerator.h:
2933         * bytecompiler/NodesCodegen.cpp:
2934         (JSC::PropertyListNode::emitPutConstantProperty):
2935         (JSC::ClassExprNode::emitBytecode):
2936
2937 2016-10-04  Yusuke Suzuki  <utatane.tea@gmail.com>
2938
2939         [DOMJIT] Introduce DOMJIT::GetterSetter to tell JIT information
2940         https://bugs.webkit.org/show_bug.cgi?id=162916
2941
2942         Reviewed by Filip Pizlo.
2943
2944         In this patch, we introduce DOMJIT::GetterSetter.
2945         This class maintains information required to emit JIT code in DFG and FTL.
2946         DOMJIT::GetterSetter has 2 virtual functions: checkDOM and callDOM.
2947         These functions can return a DOMJIT::Patchpoint that allows us to inject
2948         appropriate machine code during DFG and FTL phases. DFG and FTL will invoke
2949         these functions to get a patchpoint. And this patchpoint will be used to
2950         emit code corresponding to CheckDOM and CallDOM DFG nodes, which will be added
2951         in subsqeunt patch.
2952
2953         We propagate DOMJIT::GetterSetter through PropertySlot, AccessCase, GetByIdVariant,
2954         and GetByIdStatus along with CustomGetter to teach DFG that this custom access
2955         code has a chance to be inlined with this DOMJIT::GetterSetter information.
2956         Instead of propagating CustomGetterSetter holding DOMJIT::GetterSetter and CustomGetter,
2957         we propagate CustomGetter and DOMJIT::GetterSetter. This is because of the current
2958         CustomGetterSetter design that we reify CustomGetterSetters only when we need to reify
2959         all the properties. This design allows us to avoid frequent CustomGetterSetter allocations
2960         and structure transitions.
2961
2962         Currently, domJIT field is always nullptr since there is no DOMJITAttribute user.
2963         When we add this, we will add code handling this DOMJIT::GetterSetter in DFG::ByteCodeParser.
2964
2965         * CMakeLists.txt:
2966         * JavaScriptCore.xcodeproj/project.pbxproj:
2967         * bytecode/GetByIdStatus.cpp:
2968         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
2969         * bytecode/GetByIdVariant.cpp:
2970         (JSC::GetByIdVariant::GetByIdVariant):
2971         (JSC::GetByIdVariant::operator=):
2972         (JSC::GetByIdVariant::attemptToMerge):
2973         (JSC::GetByIdVariant::dumpInContext):
2974         * bytecode/GetByIdVariant.h:
2975         (JSC::GetByIdVariant::domJIT):
2976         (JSC::GetByIdVariant::intrinsic): Deleted.
2977         * bytecode/PolymorphicAccess.cpp:
2978         (JSC::AccessCase::get):
2979         (JSC::AccessCase::clone):
2980         * bytecode/PolymorphicAccess.h:
2981         (JSC::AccessCase::domJIT):
2982         (JSC::AccessCase::RareData::RareData):
2983         * dfg/DFGNode.h:
2984         * domjit/DOMJITGetterSetter.h: Added.
2985         (JSC::DOMJIT::GetterSetter::GetterSetter):
2986         (JSC::DOMJIT::GetterSetter::~GetterSetter):
2987         (JSC::DOMJIT::GetterSetter::getter):
2988         (JSC::DOMJIT::GetterSetter::setter):
2989         (JSC::DOMJIT::GetterSetter::thisClassInfo):
2990         * domjit/DOMJITPatchpoint.h: Added.
2991         (JSC::DOMJIT::Patchpoint::create):
2992         (JSC::DOMJIT::Patchpoint::setGenerator):
2993         (JSC::DOMJIT::Patchpoint::generator):
2994         * jit/Repatch.cpp:
2995         (JSC::tryCacheGetByID):
2996         * runtime/CustomGetterSetter.h:
2997         * runtime/JSObject.h:
2998         (JSC::JSObject::fillCustomGetterPropertySlot):
2999         * runtime/Lookup.h:
3000         (JSC::HashTableValue::domJIT):
3001         (JSC::getStaticPropertySlotFromTable):
3002         (JSC::putEntry):
3003         (JSC::reifyStaticProperty):
3004         * runtime/PropertySlot.h:
3005         (JSC::PropertySlot::domJIT):
3006         (JSC::PropertySlot::setCacheableCustom):
3007
3008 2016-09-27  Yusuke Suzuki  <utatane.tea@gmail.com>
3009
3010         [JSC] Add a new byte code op_define_property instead of calling defineProperty
3011         https://bugs.webkit.org/show_bug.cgi?id=162108
3012
3013         Reviewed by Saam Barati.
3014
3015         To construct ES6 class, we emitted bytecode that performs the following operations.
3016
3017             1. construct a new object
3018             2. put "configurable", "enumerable" etc. fields
3019             3. call "defineProperty" function
3020
3021         However, this approach has problems. Every time we define a class method, we need to create
3022         a new object to represent property descriptor. This can be removed if we can introduce
3023         a special bytecode or special function.
3024
3025         This patch introduces new bytecodes, op_define_data_property and op_define_accessor_property.
3026         Instead of taking an object, they takes several registers to avoid object allocations.
3027         We're planning to use this bytecode to implement Object.defineProperty in builtin JS next.
3028         This allows us to leverage object allocation sinking. And it also gives us a chance to use
3029         faster ::get and ::hasProperty in JS.
3030
3031         Originally, I attempted to create one bytecode, op_define_property. However, it takes too many
3032         children in DFG and uses so many registers in DFG. This leads tricky program in 32bit platforms.
3033         Furthermore, it does not fit to the number of x64 argument registers. So instead, we introduce
3034         two bytecodes.
3035
3036         And for op_define_accessor_property, we perform CellUse edge filter to getter and setter children.
3037         This edge filter makes us possible to use SpeculateCellOperand and reduce the number of used registers
3038         in comparison with JSValueOperand. To make children Cells even if we do not specify some accessors (for
3039         example, { get: func, set: null } case), we fill registers with special throwTypeErrorFunction.
3040         The attributes bitset keep information like "This property descriptor only has getter slot".
3041
3042         In these two bytecodes, we take attributes (configurable, enumerable, writable, hasGetter etc.) as
3043         register instead of embedding constant int value because we will use these bytecodes to implement
3044         Object.defineProperty next. In Object.defineProperty case, an attributes are not statically defined
3045         at bytecode compiling time.
3046
3047         Run ES6SampleBench/Air 20 times. The result shows ~2% performance improvement.
3048
3049         Baseline:
3050             firstIteration:     84.05 ms +- 4.37 ms
3051             averageWorstCase:   40.54 ms +- 2.81 ms
3052             steadyState:        3317.49 ms +- 48.25 ms
3053             summary:            223.51 ms +- 5.07 ms
3054
3055         Patched:
3056             firstIteration:     84.46 ms +- 4.22 ms
3057             averageWorstCase:   41.48 ms +- 2.33 ms
3058             steadyState:        3253.48 ms +- 29.31 ms
3059             summary:            224.40 ms +- 4.72 ms
3060
3061         * JavaScriptCore.xcodeproj/project.pbxproj:
3062         * bytecode/BytecodeList.json:
3063         * bytecode/BytecodeUseDef.h:
3064         (JSC::computeUsesForBytecodeOffset):
3065         (JSC::computeDefsForBytecodeOffset):
3066         * bytecode/CodeBlock.cpp:
3067         (JSC::CodeBlock::dumpBytecode):
3068         * bytecode/SpecialPointer.h:
3069         * bytecompiler/BytecodeGenerator.cpp:
3070         (JSC::BytecodeGenerator::emitMoveLinkTimeConstant):
3071         (JSC::BytecodeGenerator::emitCallDefineProperty):
3072         * bytecompiler/BytecodeGenerator.h:
3073         * bytecompiler/NodesCodegen.cpp:
3074         (JSC::PropertyListNode::emitPutConstantProperty):
3075         (JSC::BitwiseNotNode::emitBytecode):
3076         (JSC::ClassExprNode::emitBytecode):
3077         (JSC::ObjectPatternNode::bindValue):
3078         * dfg/DFGAbstractInterpreterInlines.h:
3079         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3080         * dfg/DFGByteCodeParser.cpp:
3081         (JSC::DFG::ByteCodeParser::parseBlock):
3082         * dfg/DFGCapabilities.cpp:
3083         (JSC::DFG::capabilityLevel):
3084         * dfg/DFGClobberize.h:
3085         (JSC::DFG::clobberize):
3086         * dfg/DFGDoesGC.cpp:
3087         (JSC::DFG::doesGC):
3088         * dfg/DFGFixupPhase.cpp:
3089         (JSC::DFG::FixupPhase::fixupNode):
3090         * dfg/DFGNodeType.h:
3091         * dfg/DFGOperations.cpp:
3092         * dfg/DFGOperations.h:
3093         * dfg/DFGPredictionPropagationPhase.cpp:
3094         * dfg/DFGSafeToExecute.h:
3095         (JSC::DFG::safeToExecute):
3096         * dfg/DFGSpeculativeJIT.cpp:
3097         (JSC::DFG::SpeculativeJIT::compileDefineDataProperty):
3098         (JSC::DFG::SpeculativeJIT::compileDefineAccessorProperty):
3099         * dfg/DFGSpeculativeJIT.h:
3100         (JSC::DFG::SpeculativeJIT::callOperation):
3101         * dfg/DFGSpeculativeJIT32_64.cpp:
3102         (JSC::DFG::SpeculativeJIT::compile):
3103         * dfg/DFGSpeculativeJIT64.cpp:
3104         (JSC::DFG::SpeculativeJIT::compile):
3105         * ftl/FTLCapabilities.cpp:
3106         (JSC::FTL::canCompile):
3107         * ftl/FTLLowerDFGToB3.cpp:
3108         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3109         (JSC::FTL::DFG::LowerDFGToB3::compileDefineDataProperty):
3110         (JSC::FTL::DFG::LowerDFGToB3::compileDefineAccessorProperty):
3111         (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis): Deleted.
3112         * jit/CCallHelpers.cpp:
3113         (JSC::CCallHelpers::setupFourStubArgsGPR): Deleted.
3114         * jit/CCallHelpers.h:
3115         (JSC::CCallHelpers::setupFourStubArgsGPR):
3116         (JSC::CCallHelpers::setupFiveStubArgsGPR):
3117         (JSC::CCallHelpers::setupArgumentsWithExecState):
3118         (JSC::CCallHelpers::setupStubArgsGPR):
3119         (JSC::CCallHelpers::prepareForTailCallSlow): Deleted.
3120         * jit/JIT.cpp:
3121         (JSC::JIT::privateCompileMainPass):
3122         * jit/JIT.h:
3123         * jit/JITOperations.h:
3124         * jit/JITPropertyAccess.cpp:
3125         (JSC::JIT::emit_op_define_data_property):
3126         (JSC::JIT::emit_op_define_accessor_property):
3127         * llint/LowLevelInterpreter.asm:
3128         * runtime/CommonSlowPaths.cpp:
3129         (JSC::SLOW_PATH_DECL):
3130         * runtime/CommonSlowPaths.h:
3131         * runtime/DefinePropertyAttributes.h: Added.
3132         (JSC::DefinePropertyAttributes::DefinePropertyAttributes):
3133         (JSC::DefinePropertyAttributes::rawRepresentation):
3134         (JSC::DefinePropertyAttributes::hasValue):
3135         (JSC::DefinePropertyAttributes::setValue):
3136         (JSC::DefinePropertyAttributes::hasGet):
3137         (JSC::DefinePropertyAttributes::setGet):
3138         (JSC::DefinePropertyAttributes::hasSet):
3139         (JSC::DefinePropertyAttributes::setSet):
3140         (JSC::DefinePropertyAttributes::writable):
3141         (JSC::DefinePropertyAttributes::configurable):
3142         (JSC::DefinePropertyAttributes::enumerable):
3143         (JSC::DefinePropertyAttributes::setWritable):
3144         (JSC::DefinePropertyAttributes::setConfigurable):
3145         (JSC::DefinePropertyAttributes::setEnumerable):
3146         (JSC::DefinePropertyAttributes::fillWithTriState):
3147         (JSC::DefinePropertyAttributes::extractTriState):
3148         * runtime/JSGlobalObject.cpp:
3149         (JSC::JSGlobalObject::init):
3150         (JSC::JSGlobalObject::visitChildren):
3151         * runtime/JSGlobalObject.h:
3152         (JSC::JSGlobalObject::throwTypeErrorFunction):
3153         (JSC::JSGlobalObject::definePropertyFunction): Deleted.
3154         * runtime/ObjectConstructor.cpp:
3155         (JSC::ObjectConstructor::addDefineProperty): Deleted.
3156         * runtime/ObjectConstructor.h:
3157         * runtime/PropertyDescriptor.h:
3158         (JSC::toPropertyDescriptor):
3159
3160 2016-10-04  Saam Barati  <sbarati@apple.com>
3161
3162         Follow up fix to GetMapBucket and MapHash speculating on child node types.
3163         To fix this, on 32-bit platforms, we do not speculate on the child
3164         type since we just call into C code for these nodes.
3165
3166         * dfg/DFGFixupPhase.cpp:
3167         (JSC::DFG::FixupPhase::fixupNode):
3168
3169 2016-10-03  Saam Barati  <sbarati@apple.com>
3170
3171         GetMapBucket node should speculate on the type of its 'key' child
3172         https://bugs.webkit.org/show_bug.cgi?id=161638
3173
3174         Reviewed by Filip Pizlo.
3175
3176         This eliminates type-check branches when we've already
3177         proven the type of the incoming key. Also, it reduces
3178         the branches we emit when type checking the bucket's key.
3179
3180         This is a 2-3% speedup on ES6SampleBench/Basic.
3181
3182         * dfg/DFGFixupPhase.cpp:
3183         (JSC::DFG::FixupPhase::fixupNode):
3184         * dfg/DFGSpeculativeJIT64.cpp:
3185         (JSC::DFG::SpeculativeJIT::compile):
3186         * ftl/FTLLowerDFGToB3.cpp:
3187         (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
3188
3189 2016-10-03  Christopher Reid  <Christopher.Reid@am.sony.com>
3190
3191         Offline asm should not output masm assembly when using a x86_64 asm backend
3192         https://bugs.webkit.org/show_bug.cgi?id=162705
3193
3194         When cross compiling on windows to Clang, masm was being generated simply because
3195         the os was windows. This change adds a command line parameter --assembler=MASM
3196         to set the output assembly to masm.
3197         The functions isGCC and isCompilingToWindows were removed as they are no longer called.
3198
3199         Reviewed by Mark Lam.
3200
3201         * CMakeLists.txt:
3202         * offlineasm/asm.rb:
3203         * offlineasm/x86.rb:
3204
3205 2016-10-03  JF Bastien  <jfbastien@apple.com>
3206
3207         Auto-generate WASMOps.h, share with testing JSON file
3208         https://bugs.webkit.org/show_bug.cgi?id=162870
3209
3210         Reviewed by Keith Miller.
3211
3212         Add a few new opcodes, but keep this mostly as-is for now. I want
3213         to generate smarter code but will do so in a later update to
3214         reduce disruption.
3215
3216         * wasm/WASMOps.h: auto-generated from ./JSTests/stress/wasm/to-c++.js
3217
3218 2016-10-03  Michael Saboff  <msaboff@apple.com>
3219
3220         Creating pcToOriginMap in FTL shouldn't insert unnecessary NOPs
3221         https://bugs.webkit.org/show_bug.cgi?id=162879
3222
3223         Reviewed by Filip Pizlo.
3224
3225         If there is a recent watchpoint label, using MacroAssembler::label() will pad
3226         the instruction stream with NOPs to provide space for a jump.  This changes
3227         Air::generate() to use labelIgnoringWatchpoints() to create pcToOriginMap
3228         entries to eliminate unneccesary NOPs.
3229         
3230         * b3/air/AirGenerate.cpp:
3231         (JSC::B3::Air::generate):
3232         * b3/testb3.cpp:
3233         (JSC::B3::testPCOriginMapDoesntInsertNops): New test.
3234         (JSC::B3::run):
3235
3236 2016-10-03  Saam Barati  <sbarati@apple.com>
3237
3238         MapHash should speculate on the type of its child node
3239         https://bugs.webkit.org/show_bug.cgi?id=161922
3240
3241         Reviewed by Filip Pizlo.
3242
3243         This allows us to remove runtime type checks when we've already
3244         proven the type of the incoming value.
3245
3246         This is a 2-3% speedup on ES6SampleBench/Basic.
3247
3248         * dfg/DFGFixupPhase.cpp:
3249         (JSC::DFG::FixupPhase::fixupNode):
3250         * dfg/DFGSpeculativeJIT64.cpp:
3251         (JSC::DFG::SpeculativeJIT::compile):
3252         * ftl/FTLLowerDFGToB3.cpp:
3253         (JSC::FTL::DFG::LowerDFGToB3::wangsInt64Hash):
3254         (JSC::FTL::DFG::LowerDFGToB3::mapHashString):
3255         (JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
3256
3257 2016-10-03  Filip Pizlo  <fpizlo@apple.com>
3258
3259         B3 trapping memory accesses should be documented
3260         https://bugs.webkit.org/show_bug.cgi?id=162845
3261
3262         Reviewed by Geoffrey Garen.
3263         
3264         While writing some documentation, I found some small holes in the code.
3265
3266         * b3/B3Effects.cpp:
3267         (JSC::B3::Effects::operator==): Need this to write tests.
3268         (JSC::B3::Effects::operator!=): Need this to write tests.
3269         * b3/B3Effects.h:
3270         * b3/B3HeapRange.h:
3271         * b3/B3MemoryValue.cpp:
3272         (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.
3273         * b3/B3Value.cpp:
3274         (JSC::B3::Value::effects): While documenting this, I remembered that trapping also has to imply reading top. I fixed this.
3275         * b3/testb3.cpp:
3276         (JSC::B3::testTrappingLoad): Added checks for the effects of trapping loads.
3277         (JSC::B3::testTrappingStore): Added checks for the effects of trapping stores.
3278         (JSC::B3::testMoveConstants): Made this not crash with validation.
3279
3280 2016-10-03  Yusuke Suzuki  <utatane.tea@gmail.com>
3281
3282         [ES6] GeneratorFunction (a.k.a. GeneratorWrapperFunction)'s prototype object does not have constructor property
3283         https://bugs.webkit.org/show_bug.cgi?id=162849
3284
3285         Reviewed by Geoffrey Garen.
3286
3287         Since GeneratorFunction is not constructible, GeneratorFunction.prototype does not have "constructor" property.
3288
3289             function* generatorFunction() { }
3290             generatorFunction.prototype.constructor // undefined
3291
3292         * runtime/JSFunction.cpp:
3293         (JSC::JSFunction::getOwnPropertySlot):
3294
3295 2016-10-03  Nicolas Breidinger  <Nicolas.Breidinger@sony.com>
3296
3297         JSStringRef should define JSChar without platform checks
3298         https://bugs.webkit.org/show_bug.cgi?id=162808
3299
3300         Reviewed by Mark Lam.
3301
3302         * API/JSStringRef.h:
3303
3304 2016-10-01  Yusuke Suzuki  <utatane.tea@gmail.com>
3305
3306         [ES6] Align attributes of Generator related properties to spec
3307         https://bugs.webkit.org/show_bug.cgi?id=162839
3308
3309         Reviewed by Saam Barati.
3310
3311         This patch fixes attributes of Generator related properties.
3312         These fixes are covered by test262.
3313
3314         * runtime/GeneratorFunctionConstructor.cpp:
3315         (JSC::GeneratorFunctionConstructor::finishCreation):
3316         * runtime/GeneratorFunctionConstructor.h:
3317         * runtime/GeneratorFunctionPrototype.cpp:
3318         (JSC::GeneratorFunctionPrototype::finishCreation):
3319         * runtime/GeneratorFunctionPrototype.h: