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