Implement some arithmetic instructions in WebAssembly
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-09-03  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2
3         Implement some arithmetic instructions in WebAssembly
4         https://bugs.webkit.org/show_bug.cgi?id=148737
5
6         Reviewed by Geoffrey Garen.
7
8         This patch implements the addition and subtraction instructions in
9         WebAssembly using a stack-based approach: each instruction reads its
10         operands from the top of the 'temporary' stack, pops them, and
11         optionally pushes a return value to the stack. Since operands are passed
12         on the stack, we don't use the arguments that are passed to the methods
13         of WASMFunctionCompiler, and we don't use the return values from these
14         methods. (We will use them when we implement LLVM IR generation for
15         WebAssembly, where each expression is an LLVMValueRef.)
16
17         * tests/stress/wasm-arithmetic.js: Added.
18         * tests/stress/wasm-arithmetic.wasm: Added.
19         * wasm/WASMFunctionCompiler.h:
20         (JSC::WASMFunctionCompiler::endFunction):
21         (JSC::WASMFunctionCompiler::buildReturn):
22         (JSC::WASMFunctionCompiler::buildImmediateI32):
23         (JSC::WASMFunctionCompiler::buildBinaryI32):
24         (JSC::WASMFunctionCompiler::temporaryAddress):
25         * wasm/WASMFunctionParser.cpp:
26         (JSC::WASMFunctionParser::parseReturnStatement):
27         (JSC::WASMFunctionParser::parseExpressionI32):
28         (JSC::WASMFunctionParser::parseImmediateExpressionI32):
29         (JSC::WASMFunctionParser::parseBinaryExpressionI32):
30         * wasm/WASMFunctionParser.h:
31         * wasm/WASMFunctionSyntaxChecker.h:
32         (JSC::WASMFunctionSyntaxChecker::startFunction):
33         (JSC::WASMFunctionSyntaxChecker::endFunction):
34         (JSC::WASMFunctionSyntaxChecker::buildReturn):
35         (JSC::WASMFunctionSyntaxChecker::buildImmediateI32):
36         (JSC::WASMFunctionSyntaxChecker::buildBinaryI32):
37         (JSC::WASMFunctionSyntaxChecker::stackHeight):
38         (JSC::WASMFunctionSyntaxChecker::updateTempStackHeight):
39
40 2015-09-03  Brian Burg  <bburg@apple.com>
41
42         Web Inspector: should crash on purpose if InjectedScriptSource.js is unparseable
43         https://bugs.webkit.org/show_bug.cgi?id=148750
44
45         Reviewed by Timothy Hatcher.
46
47         If an injected script cannot be parsed or executed without exception, we should abort as
48         soon as possible. This patch adds a release assertion after creating the injected
49         script and dumps the bad injected script's source as it was embedded into the binary.
50
51         * inspector/InjectedScriptManager.cpp:
52         (Inspector::InjectedScriptManager::injectedScriptFor):
53
54 2015-09-03  Basile Clement  <basile_clement@apple.com> and Michael Saboff  <msaboff@apple.com>
55
56         Clean up register naming
57         https://bugs.webkit.org/show_bug.cgi?id=148658
58
59         Reviewed by Geoffrey Garen.
60
61         This changes register naming conventions in the llint and baseline JIT
62         in order to use as few (native) callee-save registers as possible on
63         64-bits platforms. It also introduces significant changes in the way
64         registers names are defined in the LLint and baseline JIT in order to
65         enable a simpler convention about which registers can be aliased. That
66         convention is valid across all architecture, and described in
67         llint/LowLevelInterpreter.asm.
68
69         Callee save registers are now called out regCS<n> (in the JIT) or
70         csr<n> (in the LLInt) with a common numbering across all tiers. Some
71         registers are unused in some tiers.
72
73         As a part of this change, rdi was removed from the list of temporary
74         registers for X86-64 Windows as it is a callee saves register. This
75         reduced the number of temporary registers for X86-64 Windows.
76
77         This is in preparation for properly handling callee save register
78         preservation and restoration.
79
80         * dfg/DFGJITCompiler.cpp:
81         (JSC::DFG::JITCompiler::compileFunction):
82         * ftl/FTLLink.cpp:
83         (JSC::FTL::link):
84         * jit/FPRInfo.h:
85         (JSC::FPRInfo::toRegister):
86         (JSC::FPRInfo::toIndex):
87         * jit/GPRInfo.h:
88         (JSC::GPRInfo::toIndex):
89         (JSC::GPRInfo::toRegister):
90         (JSC::GPRInfo::debugName): Deleted.
91         * jit/JIT.cpp:
92         (JSC::JIT::privateCompile):
93         * jit/JITArithmetic.cpp:
94         (JSC::JIT::emit_op_mod):
95         * jit/JITOpcodes.cpp:
96         (JSC::JIT::emitSlow_op_loop_hint):
97         * jit/JITOpcodes32_64.cpp:
98         (JSC::JIT::emit_op_end):
99         (JSC::JIT::emit_op_new_object):
100         * jit/RegisterPreservationWrapperGenerator.cpp:
101         (JSC::generateRegisterPreservationWrapper):
102         (JSC::generateRegisterRestoration):
103         * jit/ThunkGenerators.cpp:
104         (JSC::arityFixupGenerator):
105         (JSC::nativeForGenerator): Deleted.
106         * llint/LowLevelInterpreter.asm:
107         * llint/LowLevelInterpreter32_64.asm:
108         * llint/LowLevelInterpreter64.asm:
109         * offlineasm/arm.rb:
110         * offlineasm/arm64.rb:
111         * offlineasm/cloop.rb:
112         * offlineasm/mips.rb:
113         * offlineasm/registers.rb:
114         * offlineasm/sh4.rb:
115         * offlineasm/x86.rb:
116
117 2015-09-03  Filip Pizlo  <fpizlo@apple.com>
118
119         Get rid of RepatchBuffer and replace it with static functions
120         https://bugs.webkit.org/show_bug.cgi?id=148742
121
122         Reviewed by Geoffrey Garen and Mark Lam.
123
124         RepatchBuffer is an object that doesn't have any state. All of its instance methods are
125         just wrappers for methods on MacroAssembler. So, we should make those MacroAssembler
126         methods public and call them directly.
127
128         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
129         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
130         * JavaScriptCore.xcodeproj/project.pbxproj:
131         * assembler/AbstractMacroAssembler.h:
132         (JSC::AbstractMacroAssembler::linkJump):
133         (JSC::AbstractMacroAssembler::linkPointer):
134         (JSC::AbstractMacroAssembler::getLinkerAddress):
135         (JSC::AbstractMacroAssembler::getLinkerCallReturnOffset):
136         (JSC::AbstractMacroAssembler::repatchJump):
137         (JSC::AbstractMacroAssembler::repatchNearCall):
138         (JSC::AbstractMacroAssembler::repatchCompact):
139         (JSC::AbstractMacroAssembler::repatchInt32):
140         (JSC::AbstractMacroAssembler::repatchPointer):
141         (JSC::AbstractMacroAssembler::readPointer):
142         (JSC::AbstractMacroAssembler::replaceWithLoad):
143         (JSC::AbstractMacroAssembler::replaceWithAddressComputation):
144         (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
145         * assembler/MacroAssemblerARM64.h:
146         (JSC::MacroAssemblerARM64::revertJumpReplacementToPatchableBranch32WithPatch):
147         (JSC::MacroAssemblerARM64::repatchCall):
148         (JSC::MacroAssemblerARM64::makeBranch):
149         (JSC::MacroAssemblerARM64::linkCall):
150         * assembler/MacroAssemblerARMv7.h:
151         (JSC::MacroAssemblerARMv7::revertJumpReplacementToPatchableBranch32WithPatch):
152         (JSC::MacroAssemblerARMv7::repatchCall):
153         (JSC::MacroAssemblerARMv7::linkCall):
154         (JSC::MacroAssemblerARMv7::trustedImm32FromPtr):
155         * assembler/MacroAssemblerX86.h:
156         (JSC::MacroAssemblerX86::revertJumpReplacementToPatchableBranch32WithPatch):
157         (JSC::MacroAssemblerX86::repatchCall):
158         (JSC::MacroAssemblerX86::linkCall):
159         * assembler/MacroAssemblerX86_64.h:
160         (JSC::MacroAssemblerX86_64::revertJumpReplacementToBranchPtrWithPatch):
161         (JSC::MacroAssemblerX86_64::repatchCall):
162         (JSC::MacroAssemblerX86_64::linkCall):
163         * assembler/RepatchBuffer.h: Removed.
164         * bytecode/CallLinkInfo.cpp:
165         (JSC::CallLinkInfo::clearStub):
166         (JSC::CallLinkInfo::unlink):
167         (JSC::CallLinkInfo::visitWeak):
168         * bytecode/CallLinkInfo.h:
169         (JSC::CallLinkInfo::registerPreservationMode):
170         (JSC::CallLinkInfo::isLinked):
171         (JSC::CallLinkInfo::setUpCall):
172         (JSC::CallLinkInfo::codeOrigin):
173         * bytecode/CodeBlock.cpp:
174         (JSC::CodeBlock::finalizeUnconditionally):
175         (JSC::CodeBlock::resetStub):
176         (JSC::CodeBlock::resetStubInternal):
177         (JSC::CodeBlock::resetStubDuringGCInternal):
178         (JSC::CodeBlock::unlinkIncomingCalls):
179         * bytecode/CodeBlock.h:
180         * bytecode/PolymorphicGetByIdList.cpp:
181         (JSC::GetByIdAccess::fromStructureStubInfo):
182         (JSC::GetByIdAccess::visitWeak):
183         (JSC::PolymorphicGetByIdList::didSelfPatching):
184         (JSC::PolymorphicGetByIdList::visitWeak):
185         * bytecode/PolymorphicGetByIdList.h:
186         (JSC::GetByIdAccess::doesCalls):
187         * bytecode/PolymorphicPutByIdList.cpp:
188         (JSC::PutByIdAccess::fromStructureStubInfo):
189         (JSC::PutByIdAccess::visitWeak):
190         (JSC::PolymorphicPutByIdList::addAccess):
191         (JSC::PolymorphicPutByIdList::visitWeak):
192         * bytecode/PolymorphicPutByIdList.h:
193         (JSC::PutByIdAccess::customSetter):
194         (JSC::PolymorphicPutByIdList::kind):
195         * bytecode/StructureStubInfo.cpp:
196         (JSC::StructureStubInfo::deref):
197         (JSC::StructureStubInfo::visitWeakReferences):
198         * bytecode/StructureStubInfo.h:
199         (JSC::StructureStubInfo::seenOnce):
200         * dfg/DFGOSRExitCompiler.cpp:
201         * ftl/FTLCompile.cpp:
202         (JSC::FTL::mmAllocateDataSection):
203         * ftl/FTLOSRExitCompiler.cpp:
204         (JSC::FTL::compileFTLOSRExit):
205         * jit/AccessorCallJITStubRoutine.cpp:
206         (JSC::AccessorCallJITStubRoutine::~AccessorCallJITStubRoutine):
207         (JSC::AccessorCallJITStubRoutine::visitWeak):
208         * jit/AccessorCallJITStubRoutine.h:
209         * jit/JIT.cpp:
210         (JSC::ctiPatchCallByReturnAddress):
211         (JSC::JIT::JIT):
212         (JSC::ctiPatchNearCallByReturnAddress): Deleted.
213         * jit/JIT.h:
214         * jit/JITCall.cpp:
215         * jit/JITOpcodes.cpp:
216         (JSC::JIT::privateCompileHasIndexedProperty):
217         (JSC::JIT::emit_op_has_indexed_property):
218         * jit/JITOperations.cpp:
219         (JSC::getByVal):
220         * jit/JITPropertyAccess.cpp:
221         (JSC::JIT::privateCompileGetByVal):
222         (JSC::JIT::privateCompileGetByValWithCachedId):
223         (JSC::JIT::privateCompilePutByVal):
224         (JSC::JIT::privateCompilePutByValWithCachedId):
225         * jit/JITPropertyAccess32_64.cpp:
226         * jit/JITStubRoutine.cpp:
227         (JSC::JITStubRoutine::~JITStubRoutine):
228         (JSC::JITStubRoutine::visitWeak):
229         * jit/JITStubRoutine.h:
230         * jit/PolymorphicCallStubRoutine.cpp:
231         (JSC::PolymorphicCallNode::~PolymorphicCallNode):
232         (JSC::PolymorphicCallNode::unlink):
233         (JSC::PolymorphicCallStubRoutine::clearCallNodesFor):
234         (JSC::PolymorphicCallStubRoutine::visitWeak):
235         * jit/PolymorphicCallStubRoutine.h:
236         (JSC::PolymorphicCallNode::hasCallLinkInfo):
237         * jit/Repatch.cpp:
238         (JSC::readCallTarget):
239         (JSC::repatchCall):
240         (JSC::repatchByIdSelfAccess):
241         (JSC::checkObjectPropertyConditions):
242         (JSC::replaceWithJump):
243         (JSC::tryCacheGetByID):
244         (JSC::repatchGetByID):
245         (JSC::patchJumpToGetByIdStub):
246         (JSC::tryBuildGetByIDList):
247         (JSC::tryCachePutByID):
248         (JSC::tryBuildPutByIdList):
249         (JSC::tryRepatchIn):
250         (JSC::repatchIn):
251         (JSC::linkSlowFor):
252         (JSC::linkFor):
253         (JSC::revertCall):
254         (JSC::unlinkFor):
255         (JSC::linkVirtualFor):
256         (JSC::linkPolymorphicCall):
257         (JSC::resetGetByID):
258         (JSC::resetPutByID):
259         (JSC::resetIn):
260         * jit/Repatch.h:
261
262 2015-09-03  Sukolsak Sakshuwong  <sukolsak@gmail.com>
263
264         Initial implementation of WebAssembly function compiler
265         https://bugs.webkit.org/show_bug.cgi?id=148734
266
267         Reviewed by Filip Pizlo.
268
269         This patch introduces WASMFunctionCompiler, a class for generating
270         baseline JIT code for WebAssembly functions. The source for each
271         WebAssembly function is parsed in two passes.
272         - The first pass is done by WASMFunctionSyntaxChecker when the
273           WebAssembly module is initialized. It validates the syntax,
274           determines the start and the end offsets in the source, and
275           calculates the stack height of the function.
276         - The second pass is done by WASMFunctionCompiler when the function
277           is about to be executed.
278         This patch doesn't calculate the correct stack height nor generate
279         the correct code. That will be done in a subsequent patch.
280
281         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
282         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
283         * JavaScriptCore.xcodeproj/project.pbxproj:
284         * wasm/JSWASMModule.h:
285         (JSC::JSWASMModule::functionStartOffsetsInSource):
286         (JSC::JSWASMModule::functionStackHeights):
287         * wasm/WASMFunctionCompiler.h: Added.
288         (JSC::WASMFunctionCompiler::WASMFunctionCompiler):
289         (JSC::WASMFunctionCompiler::startFunction):
290         (JSC::WASMFunctionCompiler::endFunction):
291         (JSC::WASMFunctionCompiler::throwStackOverflowError):
292         (JSC::WASMFunctionCompiler::localAddress):
293         * wasm/WASMFunctionParser.cpp:
294         (JSC::WASMFunctionParser::checkSyntax):
295         (JSC::WASMFunctionParser::compile):
296         (JSC::WASMFunctionParser::parseFunction):
297         * wasm/WASMFunctionParser.h:
298         * wasm/WASMFunctionSyntaxChecker.h:
299         (JSC::WASMFunctionSyntaxChecker::startFunction):
300         (JSC::WASMFunctionSyntaxChecker::endFunction):
301         (JSC::WASMFunctionSyntaxChecker::stackHeight):
302         * wasm/WASMModuleParser.cpp:
303         (JSC::WASMModuleParser::parseFunctionDeclarationSection):
304         (JSC::WASMModuleParser::parseFunctionDefinition):
305
306 2015-09-03  Saam barati  <sbarati@apple.com>
307
308         Block scoped variables should be visible across scripts
309         https://bugs.webkit.org/show_bug.cgi?id=147813
310
311         Reviewed by Filip Pizlo.
312
313         This patch properly implements the global lexical tier described in
314         http://www.ecma-international.org/ecma-262/6.0/index.html#sec-globaldeclarationinstantiation.
315         The sepcification mandates that there is a global lexical environment
316         that wrtaps all program execution. This global lexical environment
317         holds let/const/class variables defined at the top-level scope
318         inside a program. These variables can never shadow other program-level
319         "var"s, global object properties, or other global lexical environment
320         declarations. Doing so is a SyntaxError.
321
322         This patch adds new ResolveTypes that describe the global lexical environment:
323         GlobalLexicalVar and GlobalLexiclaVarWithInjectionChecks. Resolving to
324         these means we're doing a load/store from the JSGlobalLexicalEnvironment.
325         This patch also addes new ResolveTypes: UnresolvedProperty and
326         UnresolvedPropertyWithVarInjectionChecks. Before, we used GlobalProperty
327         to encompass this category because if JSScope::abstractAccess didn't
328         resolve to anything, we could safely assume that this property is
329         on the global object. Such an assumption is no longer true in ES6.
330         When we have a resolve_scope/put_to_scope/get_from_scope with this
331         ResolveType, we try to transition it to either a GlobalProperty
332         ResolveType or a GlobalLexicalVar resolve type.
333
334         JSGlobalLexicalEnvironment is a subclass of JSSegmentedVariableObject.
335         This means get_from_scopes are direct pointer reads and
336         put_to_scopes are direct pointer stores.
337
338         * CMakeLists.txt:
339         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
340         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
341         * JavaScriptCore.xcodeproj/project.pbxproj:
342         * bytecode/CodeBlock.cpp:
343         (JSC::CodeBlock::dumpBytecode):
344         (JSC::CodeBlock::CodeBlock):
345         (JSC::CodeBlock::finalizeUnconditionally):
346         * bytecode/EvalCodeCache.h:
347         (JSC::EvalCodeCache::clear):
348         (JSC::EvalCodeCache::isCacheableScope):
349         (JSC::EvalCodeCache::isCacheable):
350         * bytecode/SpeculatedType.h:
351         * bytecode/UnlinkedCodeBlock.h:
352         * bytecompiler/BytecodeGenerator.cpp:
353         (JSC::BytecodeGenerator::generate):
354         (JSC::BytecodeGenerator::BytecodeGenerator):
355         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
356         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
357         (JSC::BytecodeGenerator::emitGetFromScope):
358         (JSC::BytecodeGenerator::emitPutToScope):
359         (JSC::BytecodeGenerator::initializeVariable):
360         (JSC::BytecodeGenerator::emitInstanceOf):
361         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
362         (JSC::BytecodeGenerator::pushScopedControlFlowContext):
363         (JSC::BytecodeGenerator::emitPushCatchScope):
364         (JSC::BytecodeGenerator::emitPopCatchScope):
365         * bytecompiler/BytecodeGenerator.h:
366         * bytecompiler/NodesCodegen.cpp:
367         (JSC::PostfixNode::emitResolve):
368         (JSC::PrefixNode::emitResolve):
369         (JSC::ReadModifyResolveNode::emitBytecode):
370         (JSC::AssignResolveNode::emitBytecode):
371         (JSC::EmptyLetExpression::emitBytecode):
372         (JSC::ForInNode::emitLoopHeader):
373         (JSC::ForOfNode::emitBytecode):
374         (JSC::BindingNode::bindValue):
375         * debugger/DebuggerScope.cpp:
376         (JSC::DebuggerScope::isGlobalScope):
377         (JSC::DebuggerScope::isGlobalLexicalEnvironment):
378         (JSC::DebuggerScope::isClosureScope):
379         (JSC::DebuggerScope::caughtValue):
380         (JSC::DebuggerScope::isFunctionOrEvalScope): Deleted.
381         * debugger/DebuggerScope.h:
382         * dfg/DFGAbstractInterpreterInlines.h:
383         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
384         * dfg/DFGByteCodeParser.cpp:
385         (JSC::DFG::ByteCodeParser::parseBlock):
386         * dfg/DFGCapabilities.cpp:
387         (JSC::DFG::capabilityLevel):
388         * dfg/DFGClobberize.h:
389         (JSC::DFG::clobberize):
390         * dfg/DFGDoesGC.cpp:
391         (JSC::DFG::doesGC):
392         * dfg/DFGFixupPhase.cpp:
393         (JSC::DFG::FixupPhase::fixupNode):
394         * dfg/DFGGraph.cpp:
395         (JSC::DFG::Graph::dump):
396         * dfg/DFGNode.h:
397         (JSC::DFG::Node::hasRegisterPointer):
398         (JSC::DFG::Node::variablePointer):
399         (JSC::DFG::Node::hasHeapPrediction):
400         * dfg/DFGNodeType.h:
401         * dfg/DFGPredictionPropagationPhase.cpp:
402         (JSC::DFG::PredictionPropagationPhase::propagate):
403         * dfg/DFGSafeToExecute.h:
404         (JSC::DFG::safeToExecute):
405         * dfg/DFGSpeculativeJIT32_64.cpp:
406         (JSC::DFG::SpeculativeJIT::compile):
407         * dfg/DFGSpeculativeJIT64.cpp:
408         (JSC::DFG::SpeculativeJIT::compile):
409         * dfg/DFGStoreBarrierInsertionPhase.cpp:
410         * ftl/FTLCapabilities.cpp:
411         (JSC::FTL::canCompile):
412         * ftl/FTLLowerDFGToLLVM.cpp:
413         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
414         (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiPutByOffset):
415         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetGlobalVariable):
416         (JSC::FTL::DFG::LowerDFGToLLVM::compilePutGlobalVariable):
417         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetGlobalVar): Deleted.
418         (JSC::FTL::DFG::LowerDFGToLLVM::compilePutGlobalVar): Deleted.
419         * inspector/JSJavaScriptCallFrame.cpp:
420         (Inspector::JSJavaScriptCallFrame::scopeType):
421         * interpreter/Interpreter.cpp:
422         (JSC::Interpreter::execute):
423         * jit/JIT.h:
424         * jit/JITOperations.cpp:
425         * jit/JITOperations.h:
426         * jit/JITPropertyAccess.cpp:
427         (JSC::JIT::emit_op_resolve_scope):
428         (JSC::JIT::emitSlow_op_resolve_scope):
429         (JSC::JIT::emitLoadWithStructureCheck):
430         (JSC::JIT::emitGetGlobalProperty):
431         (JSC::JIT::emitGetVarFromPointer):
432         (JSC::JIT::emitGetClosureVar):
433         (JSC::JIT::emit_op_get_from_scope):
434         (JSC::JIT::emitSlow_op_get_from_scope):
435         (JSC::JIT::emitPutGlobalProperty):
436         (JSC::JIT::emitPutGlobalVariable):
437         (JSC::JIT::emit_op_put_to_scope):
438         (JSC::JIT::emitSlow_op_put_to_scope):
439         (JSC::JIT::emitGetGlobalVar): Deleted.
440         (JSC::JIT::emitPutGlobalVar): Deleted.
441         * jit/JITPropertyAccess32_64.cpp:
442         (JSC::JIT::emit_op_resolve_scope):
443         (JSC::JIT::emitSlow_op_resolve_scope):
444         (JSC::JIT::emitLoadWithStructureCheck):
445         (JSC::JIT::emitGetGlobalProperty):
446         (JSC::JIT::emitGetVarFromPointer):
447         (JSC::JIT::emitGetClosureVar):
448         (JSC::JIT::emit_op_get_from_scope):
449         (JSC::JIT::emitSlow_op_get_from_scope):
450         (JSC::JIT::emitPutGlobalProperty):
451         (JSC::JIT::emitPutGlobalVariable):
452         (JSC::JIT::emit_op_put_to_scope):
453         (JSC::JIT::emitSlow_op_put_to_scope):
454         (JSC::JIT::emitGetGlobalVar): Deleted.
455         (JSC::JIT::emitPutGlobalVar): Deleted.
456         * llint/LLIntData.cpp:
457         (JSC::LLInt::Data::performAssertions):
458         * llint/LLIntSlowPaths.cpp:
459         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
460         * llint/LLIntSlowPaths.h:
461         * llint/LowLevelInterpreter.asm:
462         * llint/LowLevelInterpreter32_64.asm:
463         * llint/LowLevelInterpreter64.asm:
464         * runtime/CommonSlowPaths.cpp:
465         (JSC::SLOW_PATH_DECL):
466         * runtime/CommonSlowPaths.h:
467         (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
468         (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
469         * runtime/Executable.cpp:
470         (JSC::ProgramExecutable::initializeGlobalProperties):
471         * runtime/GetPutInfo.h: Added.
472         (JSC::resolveModeName):
473         (JSC::resolveTypeName):
474         (JSC::initializationModeName):
475         (JSC::makeType):
476         (JSC::needsVarInjectionChecks):
477         (JSC::ResolveOp::ResolveOp):
478         (JSC::GetPutInfo::GetPutInfo):
479         (JSC::GetPutInfo::resolveType):
480         (JSC::GetPutInfo::initializationMode):
481         (JSC::GetPutInfo::resolveMode):
482         (JSC::GetPutInfo::operand):
483         * runtime/JSGlobalLexicalEnvironment.cpp: Added.
484         (JSC::JSGlobalLexicalEnvironment::getOwnPropertySlot):
485         (JSC::JSGlobalLexicalEnvironment::put):
486         * runtime/JSGlobalLexicalEnvironment.h: Added.
487         (JSC::JSGlobalLexicalEnvironment::create):
488         (JSC::JSGlobalLexicalEnvironment::isEmpty):
489         (JSC::JSGlobalLexicalEnvironment::createStructure):
490         (JSC::JSGlobalLexicalEnvironment::JSGlobalLexicalEnvironment):
491         * runtime/JSGlobalObject.cpp:
492         (JSC::JSGlobalObject::init):
493         (JSC::JSGlobalObject::put):
494         (JSC::JSGlobalObject::addGlobalVar):
495         (JSC::JSGlobalObject::visitChildren):
496         (JSC::JSGlobalObject::addStaticGlobals):
497         * runtime/JSGlobalObject.h:
498         (JSC::JSGlobalObject::addVar):
499         (JSC::JSGlobalObject::globalScope):
500         (JSC::JSGlobalObject::globalLexicalEnvironment):
501         (JSC::JSGlobalObject::hasOwnPropertyForWrite):
502         (JSC::constructEmptyArray):
503         (JSC::JSGlobalObject::symbolTableHasProperty): Deleted.
504         * runtime/JSGlobalObjectFunctions.cpp:
505         (JSC::globalFuncEval):
506         (JSC::globalFuncParseInt):
507         * runtime/JSLexicalEnvironment.h:
508         (JSC::JSLexicalEnvironment::createStructure):
509         * runtime/JSObject.h:
510         (JSC::JSObject::isGlobalObject):
511         (JSC::JSObject::isErrorInstance):
512         (JSC::JSObject::isVariableObject): Deleted.
513         (JSC::JSObject::isStaticScopeObject): Deleted.
514         (JSC::JSObject::isNameScopeObject): Deleted.
515         (JSC::JSObject::isActivationObject): Deleted.
516         * runtime/JSScope.cpp:
517         (JSC::JSScope::visitChildren):
518         (JSC::abstractAccess):
519         (JSC::JSScope::resolve):
520         (JSC::JSScope::abstractResolve):
521         (JSC::JSScope::collectVariablesUnderTDZ):
522         (JSC::isScopeType):
523         (JSC::JSScope::isVarScope):
524         (JSC::JSScope::isLexicalScope):
525         (JSC::JSScope::isCatchScope):
526         (JSC::JSScope::isFunctionNameScopeObject):
527         (JSC::JSScope::isGlobalLexicalEnvironment):
528         (JSC::JSScope::constantScopeForCodeBlock):
529         (JSC::resolveModeName): Deleted.
530         (JSC::resolveTypeName): Deleted.
531         * runtime/JSScope.h:
532         (JSC::makeType): Deleted.
533         (JSC::needsVarInjectionChecks): Deleted.
534         (JSC::ResolveOp::ResolveOp): Deleted.
535         (JSC::ResolveModeAndType::ResolveModeAndType): Deleted.
536         (JSC::ResolveModeAndType::mode): Deleted.
537         (JSC::ResolveModeAndType::type): Deleted.
538         (JSC::ResolveModeAndType::operand): Deleted.
539         * runtime/JSSegmentedVariableObject.cpp:
540         (JSC::JSSegmentedVariableObject::findVariableIndex):
541         (JSC::JSSegmentedVariableObject::addVariables):
542         * runtime/JSSegmentedVariableObject.h:
543         * runtime/JSSymbolTableObject.h:
544         (JSC::symbolTablePut):
545         * runtime/JSType.h:
546         * runtime/PutPropertySlot.h:
547         (JSC::PutPropertySlot::PutPropertySlot):
548         (JSC::PutPropertySlot::isCacheablePut):
549         (JSC::PutPropertySlot::isCacheableSetter):
550         (JSC::PutPropertySlot::isCacheableCustom):
551         (JSC::PutPropertySlot::isInitialization):
552         (JSC::PutPropertySlot::cachedOffset):
553         * runtime/SymbolTable.h:
554         * tests/stress/global-lexical-let-no-rhs.js: Added.
555         (assert):
556         (foo):
557         * tests/stress/global-lexical-redeclare-variable.js: Added.
558         (globalFunction):
559         (globalClass):
560         (assert):
561         (assertExpectations):
562         (assertProperError):
563         * tests/stress/global-lexical-redefine-const.js: Added.
564         * tests/stress/global-lexical-var-injection.js: Added.
565         (assert):
566         (baz):
567         * tests/stress/global-lexical-variable-tdz.js: Added.
568         * tests/stress/global-lexical-variable-unresolved-property.js: Added.
569         * tests/stress/global-lexical-variable-with-statement.js: Added.
570         (assert):
571         (shouldThrowInvalidConstAssignment):
572         (makeObj):
573         * tests/stress/multiple-files-tests: Added.
574         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable: Added.
575         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/fifth.js: Added.
576         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/first.js: Added.
577         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/fourth.js: Added.
578         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/second.js: Added.
579         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/sixth.js: Added.
580         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/third.js: Added.
581         * tests/stress/multiple-files-tests/global-lexical-redefine-const: Added.
582         * tests/stress/multiple-files-tests/global-lexical-redefine-const/first.js: Added.
583         (assert):
584         (shouldThrowInvalidConstAssignment):
585         * tests/stress/multiple-files-tests/global-lexical-redefine-const/second.js: Added.
586         (foo):
587         (bar):
588         (baz):
589         * tests/stress/multiple-files-tests/global-lexical-variable-tdz: Added.
590         * tests/stress/multiple-files-tests/global-lexical-variable-tdz/first.js: Added.
591         (assert):
592         (shouldThrowTDZ):
593         (foo):
594         (bar):
595         * tests/stress/multiple-files-tests/global-lexical-variable-tdz/second.js: Added.
596         * tests/stress/multiple-files-tests/global-lexical-variable-unresolved-property: Added.
597         * tests/stress/multiple-files-tests/global-lexical-variable-unresolved-property/first.js: Added.
598         (assert):
599         (shouldThrowTDZ):
600         (foo):
601         * tests/stress/multiple-files-tests/global-lexical-variable-unresolved-property/second.js: Added.
602
603 2015-09-03  Filip Pizlo  <fpizlo@apple.com>
604
605         RepatchBuffer should be stateless
606         https://bugs.webkit.org/show_bug.cgi?id=148741
607
608         Reviewed by Geoffrey Garen.
609
610         This removes our reliance on RepatchBuffer having a pointer to CodeBlock. This is in
611         preparation for removing RepatchBuffer entirely (see
612         https://bugs.webkit.org/show_bug.cgi?id=148742). In the longer term, this is necessary
613         for making inline cache code, particularly in StructureStubInfo, more self-contained.
614         Currently StructureStubInfo relies on very pointless-looking methods in CodeBlock to
615         clear itself, and the only thing that those methods do is create a RepatchBuffer. It's
616         quite silly.
617
618         * assembler/LinkBuffer.cpp:
619         (JSC::LinkBuffer::allocate):
620         (JSC::LinkBuffer::performFinalization):
621         * assembler/RepatchBuffer.h:
622         (JSC::RepatchBuffer::RepatchBuffer):
623         (JSC::RepatchBuffer::~RepatchBuffer):
624         (JSC::RepatchBuffer::relink):
625         (JSC::RepatchBuffer::revertJumpReplacementToPatchableBranch32WithPatch):
626         (JSC::RepatchBuffer::codeBlock): Deleted.
627         * bytecode/CallLinkInfo.cpp:
628         (JSC::CallLinkInfo::clearStub):
629         (JSC::CallLinkInfo::unlink):
630         (JSC::CallLinkInfo::visitWeak):
631         * bytecode/CallLinkInfo.h:
632         (JSC::CallLinkInfo::registerPreservationMode):
633         (JSC::CallLinkInfo::isLinked):
634         (JSC::CallLinkInfo::setUpCall):
635         (JSC::CallLinkInfo::codeOrigin):
636         * bytecode/CodeBlock.cpp:
637         (JSC::CodeBlock::finalizeUnconditionally):
638         (JSC::CodeBlock::resetStubInternal):
639         (JSC::CodeBlock::unlinkIncomingCalls):
640         * bytecode/PolymorphicGetByIdList.cpp:
641         (JSC::GetByIdAccess::fromStructureStubInfo):
642         (JSC::GetByIdAccess::visitWeak):
643         (JSC::PolymorphicGetByIdList::didSelfPatching):
644         (JSC::PolymorphicGetByIdList::visitWeak):
645         * bytecode/PolymorphicGetByIdList.h:
646         (JSC::GetByIdAccess::doesCalls):
647         * bytecode/PolymorphicPutByIdList.cpp:
648         (JSC::PutByIdAccess::fromStructureStubInfo):
649         (JSC::PutByIdAccess::visitWeak):
650         (JSC::PolymorphicPutByIdList::addAccess):
651         (JSC::PolymorphicPutByIdList::visitWeak):
652         * bytecode/PolymorphicPutByIdList.h:
653         (JSC::PutByIdAccess::customSetter):
654         (JSC::PolymorphicPutByIdList::kind):
655         * bytecode/StructureStubInfo.cpp:
656         (JSC::StructureStubInfo::deref):
657         (JSC::StructureStubInfo::visitWeakReferences):
658         * bytecode/StructureStubInfo.h:
659         (JSC::StructureStubInfo::seenOnce):
660         * jit/AccessorCallJITStubRoutine.cpp:
661         (JSC::AccessorCallJITStubRoutine::~AccessorCallJITStubRoutine):
662         (JSC::AccessorCallJITStubRoutine::visitWeak):
663         * jit/AccessorCallJITStubRoutine.h:
664         * jit/ExecutableAllocator.h:
665         (JSC::ExecutableAllocator::makeWritable): Deleted.
666         (JSC::ExecutableAllocator::makeExecutable): Deleted.
667         (JSC::ExecutableAllocator::allocator): Deleted.
668         * jit/JITStubRoutine.cpp:
669         (JSC::JITStubRoutine::~JITStubRoutine):
670         (JSC::JITStubRoutine::visitWeak):
671         * jit/JITStubRoutine.h:
672         * jit/PolymorphicCallStubRoutine.cpp:
673         (JSC::PolymorphicCallNode::~PolymorphicCallNode):
674         (JSC::PolymorphicCallNode::unlink):
675         (JSC::PolymorphicCallStubRoutine::clearCallNodesFor):
676         (JSC::PolymorphicCallStubRoutine::visitWeak):
677         * jit/PolymorphicCallStubRoutine.h:
678         (JSC::PolymorphicCallNode::hasCallLinkInfo):
679         * jit/Repatch.cpp:
680         (JSC::readCallTarget):
681         (JSC::repatchCall):
682         (JSC::repatchByIdSelfAccess):
683         (JSC::tryCacheGetByID):
684         (JSC::tryCachePutByID):
685         (JSC::tryBuildPutByIdList):
686         (JSC::revertCall):
687         (JSC::unlinkFor):
688         (JSC::linkVirtualFor):
689         (JSC::linkPolymorphicCall):
690         (JSC::resetGetByID):
691         (JSC::resetPutByID):
692         (JSC::resetIn):
693         * jit/Repatch.h:
694
695 2015-09-02  Filip Pizlo  <fpizlo@apple.com>
696
697         Replace all the various forms of branchStructure() with a single method in AssemblyHelpers
698         https://bugs.webkit.org/show_bug.cgi?id=148725
699
700         Reviewed by Saam Barati.
701
702         Previously there were the following branchStructure() implementations:
703
704         JSC::JIT::branchStructure()
705         JSC::branchStructure()
706         JSC::DFG::JITCompiler::branchStructurePtr()
707
708         They all did the same thing.  Now there is only one, AssemblyHelpers::branchStructure().
709
710         * dfg/DFGJITCompiler.h:
711         (JSC::DFG::JITCompiler::branchWeakStructure):
712         (JSC::DFG::JITCompiler::jitCode):
713         (JSC::DFG::JITCompiler::branchStructurePtr): Deleted.
714         * dfg/DFGSpeculativeJIT.cpp:
715         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
716         (JSC::DFG::SpeculativeJIT::speculateStringOrStringObject):
717         * dfg/DFGSpeculativeJIT.h:
718         (JSC::DFG::SpeculativeJIT::speculateStringObjectForStructure):
719         * jit/AssemblyHelpers.h:
720         (JSC::AssemblyHelpers::branchIfEmpty):
721         (JSC::AssemblyHelpers::branchStructure):
722         (JSC::AssemblyHelpers::addressForByteOffset):
723         * jit/JIT.h:
724         * jit/JITInlines.h:
725         (JSC::JIT::branchStructure): Deleted.
726         (JSC::branchStructure): Deleted.
727         * jit/JITPropertyAccess.cpp:
728         (JSC::JIT::stringGetByValStubGenerator):
729         * jit/JITPropertyAccess32_64.cpp:
730         (JSC::JIT::stringGetByValStubGenerator):
731         * jit/Repatch.cpp:
732         (JSC::checkObjectPropertyCondition):
733         (JSC::checkObjectPropertyConditions):
734         (JSC::generateByIdStub):
735         (JSC::emitPutReplaceStub):
736         (JSC::emitPutTransitionStub):
737         (JSC::tryRepatchIn):
738         * jit/SpecializedThunkJIT.h:
739         (JSC::SpecializedThunkJIT::loadJSStringArgument):
740
741 2015-09-02  Filip Pizlo  <fpizlo@apple.com>
742
743         Remove some unused methods from GetByIdAccess.
744
745         Rubber stamped by Michael Saboff.
746
747         * bytecode/PolymorphicGetByIdList.h:
748         (JSC::GetByIdAccess::stubRoutine):
749         (JSC::GetByIdAccess::doesCalls):
750         (JSC::GetByIdAccess::isWatched): Deleted.
751         (JSC::GetByIdAccess::isSimple): Deleted.
752
753 2015-09-02  Geoffrey Garen  <ggaren@apple.com>
754
755         Fix the no JIT build.
756
757         Unreviewed.
758
759         * heap/Heap.cpp:
760         (JSC::Heap::markRoots):
761
762 2015-09-02  Geoffrey Garen  <ggaren@apple.com>
763
764         CodeBlock should have a more explicit "strongly referenced" state
765         https://bugs.webkit.org/show_bug.cgi?id=148714
766
767         Reviewed by Filip Pizlo.
768
769         Previously, CodeBlock had a "may be executing" bit, which was used by
770         both the stack visitor and the compiler to indicate "this CodeBlock must
771         not jettison itself".
772
773         Now, CodeBlock has an explicit "is strongly referenced" bit to do the
774         same.
775
776         For now, there is no behavior change. In future, I will use the "is
777         strongly referenced" bit to indicate the set of all references that
778         cause a CodeBlock not to jettison itself. Strong references and stack
779         references will be different because:
780
781             (1) A stack reference requires a write barrier at the end of GC
782             (since CodeBlocks only barrier themselves on function entry,
783             and GC will clear that barrier); but a strong reference does not
784             need or want a write barrier at the end of GC.
785
786             (2) Visiting more heap objects might reveal more strong references
787             but, by definition, it cannot reveal more stack references.
788
789         Also, this patch adds an explicit mark clearing phase for compiler
790         CodeBlocks, which does the work that would normally be done by a write
791         barrier. A compiler CodeBlock can't rely on a normal write barrier 
792         because the compiler writes to CodeBlocks without invoking a write
793         barrier, and because the CodeBlock write barrier operates on an
794         executable, but an in-flight compilation is not pointed to by any
795         executable. This bug does not appear to be noticeable in the current
796         system, but I will probably make it noticeable.
797
798         * bytecode/CodeBlock.cpp:
799         (JSC::CodeBlock::CodeBlock):
800         (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan):
801         (JSC::CodeBlock::isKnownToBeLiveDuringGC):
802         * bytecode/CodeBlock.h:
803         (JSC::ExecState::uncheckedR):
804         (JSC::CodeBlockSet::clearMarks):
805         (JSC::CodeBlockSet::mark):
806         * dfg/DFGPlan.cpp:
807         (JSC::DFG::Plan::key):
808         (JSC::DFG::Plan::clearCodeBlockMarks):
809         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
810         * dfg/DFGPlan.h:
811         * dfg/DFGWorklist.cpp:
812         (JSC::DFG::Worklist::completeAllPlansForVM):
813         (JSC::DFG::Worklist::clearCodeBlockMarks):
814         (JSC::DFG::Worklist::suspendAllThreads):
815         (JSC::DFG::Worklist::visitWeakReferences):
816         (JSC::DFG::completeAllPlansForVM):
817         (JSC::DFG::clearCodeBlockMarks):
818         * dfg/DFGWorklist.h:
819         (JSC::DFG::worklistForIndexOrNull):
820         * heap/CodeBlockSet.cpp:
821         (JSC::CodeBlockSet::clearMarksForFullCollection):
822         (JSC::CodeBlockSet::clearMarksForEdenCollection):
823         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
824         (JSC::CodeBlockSet::traceMarked):
825         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
826         * heap/CodeBlockSet.h:
827         * heap/Heap.cpp:
828         (JSC::Heap::markRoots):
829
830 2015-09-01  Brian Burg  <bburg@apple.com>
831
832         Web Inspector: protocol generator should not allow non-boolean values for "optional" key
833         https://bugs.webkit.org/show_bug.cgi?id=148679
834
835         Reviewed by Joseph Pecoraro.
836
837         In Python, the 'bool' type inherits from 'int'. In the runtime, True and False are
838         just numbers to Python. So, the existing check for boolean literals was not quite right.
839
840         * inspector/scripts/codegen/models.py: Use isinstance instead.
841         (TypeMember.__init__):
842         (Parameter.__init__):
843         * inspector/scripts/tests/expected/fail-on-number-typed-optional-parameter-flag.json-error: Added.
844         * inspector/scripts/tests/expected/fail-on-number-typed-optional-type-member.json-error: Added.
845         * inspector/scripts/tests/fail-on-number-typed-optional-parameter-flag.json: Added.
846         * inspector/scripts/tests/fail-on-number-typed-optional-type-member.json: Added.
847
848 2015-09-01  Filip Pizlo  <fpizlo@apple.com>
849
850         DFG AI assertions about not having to do type checks at the point of a Known use kind are unsound
851         https://bugs.webkit.org/show_bug.cgi?id=148649
852
853         Reviewed by Saam Barati.
854
855         We often generate IR like:
856
857         Check(Int32:@x)
858         ...
859         Foo(KnownInt32:@x)
860
861         It would be valid for any optimization that somehow proves the type of @x to remove the
862         Check node entirely. But then, AI might fail on an assertion at Foo() because of the
863         KnownInt32 use kind, if AI isn't smart enough to construct the same proof that the former
864         optimization used for removing the Check.
865
866         The correct solution is to remove the compile-time assertions about Known use kinds
867         having already been checked.
868
869         * dfg/DFGAbstractInterpreterInlines.h:
870         (JSC::DFG::AbstractInterpreter<AbstractStateType>::verifyEdge):
871
872 2015-09-01  Brian Burg  <bburg@apple.com>
873
874         Web Inspector: tighten up lifetimes for InspectorController-owned objects; add brace initializers to agents
875         https://bugs.webkit.org/show_bug.cgi?id=148612
876
877         Reviewed by Joseph Pecoraro.
878
879         Both InjectedScriptManager and AgentRegistry (thus all agents) are
880         owned by JSGlobalObjectInspectorController. So, use references.
881
882         Add brace initalizers for scalar and pointer members in agent classes.
883
884         * inspector/ConsoleMessage.cpp:
885         (Inspector::ConsoleMessage::addToFrontend):
886         (Inspector::ConsoleMessage::updateRepeatCountInConsole):
887         (Inspector::ConsoleMessage::ConsoleMessage):
888         * inspector/ConsoleMessage.h:
889         * inspector/JSGlobalObjectInspectorController.cpp:
890         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
891         * inspector/agents/InspectorAgent.cpp:
892         (Inspector::InspectorAgent::InspectorAgent):
893         * inspector/agents/InspectorAgent.h:
894         * inspector/agents/InspectorConsoleAgent.cpp:
895         (Inspector::InspectorConsoleAgent::InspectorConsoleAgent):
896         (Inspector::InspectorConsoleAgent::enable):
897         (Inspector::InspectorConsoleAgent::clearMessages):
898         (Inspector::InspectorConsoleAgent::addMessageToConsole):
899         (Inspector::InspectorConsoleAgent::addConsoleMessage):
900         * inspector/agents/InspectorConsoleAgent.h:
901         * inspector/agents/InspectorDebuggerAgent.cpp:
902         (Inspector::InspectorDebuggerAgent::InspectorDebuggerAgent):
903         (Inspector::InspectorDebuggerAgent::removeBreakpoint):
904         (Inspector::InspectorDebuggerAgent::getFunctionDetails):
905         (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
906         (Inspector::InspectorDebuggerAgent::didPause):
907         (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
908         (Inspector::InspectorDebuggerAgent::didContinue):
909         (Inspector::InspectorDebuggerAgent::clearExceptionValue):
910         * inspector/agents/InspectorDebuggerAgent.h:
911         * inspector/agents/InspectorRuntimeAgent.cpp:
912         (Inspector::InspectorRuntimeAgent::InspectorRuntimeAgent):
913         (Inspector::InspectorRuntimeAgent::callFunctionOn):
914         (Inspector::InspectorRuntimeAgent::getProperties):
915         (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
916         (Inspector::InspectorRuntimeAgent::getCollectionEntries):
917         (Inspector::InspectorRuntimeAgent::saveResult):
918         (Inspector::InspectorRuntimeAgent::releaseObject):
919         (Inspector::InspectorRuntimeAgent::releaseObjectGroup):
920         * inspector/agents/InspectorRuntimeAgent.h:
921         * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
922         (Inspector::JSGlobalObjectConsoleAgent::JSGlobalObjectConsoleAgent):
923         * inspector/agents/JSGlobalObjectConsoleAgent.h:
924         * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
925         (Inspector::JSGlobalObjectDebuggerAgent::JSGlobalObjectDebuggerAgent):
926         (Inspector::JSGlobalObjectDebuggerAgent::injectedScriptForEval):
927         * inspector/agents/JSGlobalObjectDebuggerAgent.h:
928         * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
929         (Inspector::JSGlobalObjectRuntimeAgent::JSGlobalObjectRuntimeAgent):
930         (Inspector::JSGlobalObjectRuntimeAgent::injectedScriptForEval):
931         * inspector/agents/JSGlobalObjectRuntimeAgent.h:
932
933 2015-08-31  Yusuke Suzuki  <utatane.tea@gmail.com>
934
935         [ES6] Introduce ModuleProgramExecutable families and compile Module code to bytecode
936         https://bugs.webkit.org/show_bug.cgi?id=148581
937
938         Reviewed by Saam Barati.
939
940         This patch introduces ModuleProgramExecutable, that is new executable type for the ES6 modules.
941         And related code block types, UninkedModuleProgramCodeBlock and ModuleProgramCodeBlock are also
942         introduced. BytecodeGenerator now recognizes these types and emits the bytecode and constructs
943         the symbol table for the module environment. While this patch introduces the bytecode generation
944         for the ES6 modules, the module environment instantiation initialization and imported binding
945         resolution are not included in this patch. They will be implemented in the subsequent patch.
946
947         The interesting part is the symbol table construction for the module environment.
948         Since the module code will be only executed once, the module environment need not to be allocated
949         and instantiated inside the module code; In the case of the function code, the function code need
950         to allocate the environment inside the prologue of it because the function code can be executed
951         more than once and the function environments are different in each time of the executions.
952         The module environment will be instantiated outside the module code before executing the module code.
953         This is required because we need to link the module environments to import the bindings before
954         executing the any module code in the dependency graph. And this is because the function inside the
955         module may be executed before the module top-level body is executed. (See the code comment for more
956         detailed situations)
957
958         The module environment will hold the top-most heap allocated variables in the module code.
959         This has the following benefits.
960         1) This enables JSC to perform the usual LocalClosureVar operations onto it.
961         2) It also makes the exported lexical variables just the heap allocated lexical variables.
962         3) Make it possible to initialize the heap allocated function declarations before executing the module
963            code. It is required under the circular dependency (see the code comment for more details).
964
965         To do so, the module environment will be constructed with the symbol table that is generated by the
966         bytecode generator. And the symbol table is held by the unlinked code block. That means, once the module
967         environment is instantiated, we cannot clear the unlinked code block before executing the module since
968         the layout of the instantiated module environment is coupled with the unlinked code block. This is OK
969         because the module code can be cleared once we executed the module code. If we failed to execute the
970         module (some errors occur), we can throw away the both, the module environment and the unlinked code block.
971
972         The unlinked module program code block holds the symbol table, but it does not hold the module environment.
973         So the unlinked module program code block can be cached. While unlinked code block can be cached, the linked
974         code block cannot be cached because it is already linked to the specific set of the module environment to
975         resolve the imported bindings.
976
977         * JavaScriptCore.xcodeproj/project.pbxproj:
978         * bytecode/BytecodeList.json:
979         * bytecode/CodeBlock.cpp:
980         (JSC::CodeBlock::inferredName):
981         (JSC::ModuleProgramCodeBlock::replacement):
982         (JSC::ProgramCodeBlock::capabilityLevelInternal):
983         (JSC::ModuleProgramCodeBlock::capabilityLevelInternal):
984         * bytecode/CodeBlock.h:
985         (JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
986         (JSC::EvalCodeBlock::EvalCodeBlock):
987         (JSC::FunctionCodeBlock::FunctionCodeBlock):
988         * bytecode/CodeType.cpp:
989         (WTF::printInternal):
990         * bytecode/CodeType.h:
991         * bytecode/UnlinkedCodeBlock.cpp:
992         (JSC::UnlinkedModuleProgramCodeBlock::visitChildren):
993         (JSC::UnlinkedModuleProgramCodeBlock::destroy):
994         (JSC::UnlinkedCodeBlock::visitChildren): Deleted.
995         * bytecode/UnlinkedCodeBlock.h:
996         (JSC::UnlinkedCodeBlock::finishCreation): Deleted.
997         * bytecompiler/BytecodeGenerator.cpp:
998         (JSC::BytecodeGenerator::generate):
999         (JSC::BytecodeGenerator::BytecodeGenerator):
1000         (JSC::BytecodeGenerator::instantiateLexicalVariables):
1001         (JSC::BytecodeGenerator::emitPrefillStackTDZVariables):
1002         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
1003         * bytecompiler/BytecodeGenerator.h:
1004         * bytecompiler/NodesCodegen.cpp:
1005         (JSC::emitProgramNodeBytecode):
1006         (JSC::ProgramNode::emitBytecode):
1007         (JSC::ModuleProgramNode::emitBytecode):
1008         (JSC::ImportDeclarationNode::emitBytecode):
1009         (JSC::ExportAllDeclarationNode::emitBytecode):
1010         (JSC::ExportDefaultDeclarationNode::emitBytecode):
1011         (JSC::ExportLocalDeclarationNode::emitBytecode):
1012         (JSC::ExportNamedDeclarationNode::emitBytecode):
1013         * interpreter/Interpreter.cpp:
1014         (JSC::StackFrame::friendlySourceURL):
1015         (JSC::StackFrame::friendlyFunctionName):
1016         (JSC::getStackFrameCodeType):
1017         * interpreter/Interpreter.h:
1018         * interpreter/StackVisitor.cpp:
1019         (JSC::StackVisitor::Frame::codeType):
1020         (JSC::StackVisitor::Frame::functionName):
1021         (JSC::StackVisitor::Frame::sourceURL):
1022         * interpreter/StackVisitor.h:
1023         * jit/JIT.cpp:
1024         (JSC::JIT::privateCompile):
1025         * llint/LLIntData.cpp:
1026         (JSC::LLInt::Data::performAssertions):
1027         * llint/LLIntEntrypoint.cpp:
1028         (JSC::LLInt::setModuleProgramEntrypoint):
1029         (JSC::LLInt::setEntrypoint):
1030         * llint/LLIntOffsetsExtractor.cpp:
1031         * llint/LLIntThunks.cpp:
1032         (JSC::LLInt::moduleProgramEntryThunkGenerator):
1033         * llint/LLIntThunks.h:
1034         * llint/LowLevelInterpreter.asm:
1035         * parser/ModuleAnalyzer.cpp:
1036         (JSC::ModuleAnalyzer::exportVariable):
1037         * parser/Parser.cpp:
1038         (JSC::Parser<LexerType>::parseImportClauseItem):
1039         (JSC::Parser<LexerType>::parseExportDeclaration):
1040         * parser/Parser.h:
1041         (JSC::Scope::declareLexicalVariable):
1042         * parser/VariableEnvironment.h:
1043         (JSC::VariableEnvironmentEntry::isImportedNamespace):
1044         (JSC::VariableEnvironmentEntry::setIsImportedNamespace):
1045         (JSC::VariableEnvironment::find):
1046         * runtime/CodeCache.cpp:
1047         (JSC::CodeCache::getGlobalCodeBlock):
1048         (JSC::CodeCache::getModuleProgramCodeBlock):
1049         * runtime/CodeCache.h:
1050         * runtime/Executable.cpp:
1051         (JSC::ScriptExecutable::installCode):
1052         (JSC::ScriptExecutable::newCodeBlockFor):
1053         (JSC::ScriptExecutable::newReplacementCodeBlockFor):
1054         (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
1055         (JSC::ModuleProgramExecutable::create):
1056         (JSC::ModuleProgramExecutable::destroy):
1057         (JSC::ModuleProgramExecutable::visitChildren):
1058         (JSC::ModuleProgramExecutable::clearCode):
1059         (JSC::ExecutableBase::dump):
1060         * runtime/Executable.h:
1061         (JSC::ExecutableBase::isModuleProgramExecutable):
1062         (JSC::ExecutableBase::clearCodeVirtual):
1063         * runtime/JSGlobalObject.cpp:
1064         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
1065         * runtime/JSGlobalObject.h:
1066         * runtime/JSModuleRecord.cpp:
1067         (JSC::JSModuleRecord::visitChildren):
1068         (JSC::JSModuleRecord::link):
1069         * runtime/JSModuleRecord.h:
1070         (JSC::JSModuleRecord::moduleProgramExecutable):
1071         * runtime/JSType.h:
1072         * runtime/ModuleLoaderObject.cpp:
1073         (JSC::moduleLoaderObjectModuleDeclarationInstantiation):
1074         * runtime/VM.cpp:
1075         (JSC::VM::VM):
1076         * runtime/VM.h:
1077
1078 2015-08-31  Basile Clement  <basile_clement@apple.com>
1079
1080         Unreviewed, build fix after r189292
1081
1082         * bytecode/ValueRecovery.h:
1083         (JSC::ValueRecovery::jsValueRegs): Deleted.
1084
1085 2015-08-24  Basile Clement  <basile_clement@apple.com>
1086
1087         ValueRecovery should distinguish between doubles in an FPR and JSValues in an FPR
1088         https://bugs.webkit.org/show_bug.cgi?id=148336
1089
1090         Reviewed by Michael Saboff.
1091
1092         Currently, ValueRecovery::InFPR means "this is a *double* value in an
1093         FPR". Let's change the semantics to be "this is a *JSValue* in an FPR"
1094         (to match ValueRecovery::InGPR), and introduce
1095         ValueRecovery::UnboxedDoubleInFPR to mean "this is a double value in an
1096         FPR".
1097
1098         * bytecode/ValueRecovery.cpp:
1099         (JSC::ValueRecovery::dumpInContext):
1100         * bytecode/ValueRecovery.h:
1101         (JSC::ValueRecovery::operator bool):
1102         (JSC::ValueRecovery::inFPR):
1103         (JSC::ValueRecovery::isInGPR):
1104         (JSC::ValueRecovery::isInFPR):
1105         (JSC::ValueRecovery::isInRegisters):
1106         (JSC::ValueRecovery::isInJSStack):
1107         (JSC::ValueRecovery::dataFormat):
1108         (JSC::ValueRecovery::gpr):
1109         (JSC::ValueRecovery::isInJSValueRegs):
1110         (JSC::ValueRecovery::jsValueRegs):
1111         (JSC::ValueRecovery::fpr):
1112         (JSC::ValueRecovery::virtualRegister):
1113         (JSC::ValueRecovery::constant):
1114         * dfg/DFGOSRExitCompiler32_64.cpp:
1115         (JSC::DFG::OSRExitCompiler::compileExit):
1116         * dfg/DFGOSRExitCompiler64.cpp:
1117         (JSC::DFG::OSRExitCompiler::compileExit):
1118         * dfg/DFGVariableEventStream.cpp:
1119         (JSC::DFG::VariableEventStream::reconstruct):
1120
1121 2015-08-31  Chris Dumez  <cdumez@apple.com>
1122
1123         NodeFilter.SHOW_ALL has wrong value on 32-bit
1124         https://bugs.webkit.org/show_bug.cgi?id=148602
1125
1126         Reviewed by Geoffrey Garen.
1127
1128         NodeFilter.SHOW_ALL has wrong value on 32-bit. This is because
1129         NodeFilter.SHOW_ALL is an unsigned long whose value is 0xFFFFFFFF but
1130         our bindings code is casting it to an intptr_t type which is not wide
1131         enough on 32-bit.
1132
1133         * create_hash_table:
1134         Add extra curly brackets to initialize the union.
1135
1136         * runtime/Lookup.h:
1137         Use a union type to store either a struct containing 2 intptr_t members
1138         (value1 / value2) or a large constant of type unsigned long long. When
1139         storing a constant, we only need one of the values so this allows us to
1140         support larger constants without increasing the actual HashTableValue
1141         size.
1142
1143 2015-08-31  Mark Lam  <mark.lam@apple.com>
1144
1145         Watchdog timer callback should release the lock before deref'ing the watchdog.
1146         https://bugs.webkit.org/show_bug.cgi?id=148635
1147
1148         Reviewed by Filip Pizlo.
1149
1150         The deref'ing of the watchdog may free it.  The lock may not be available to be unlocked
1151         after the deref.
1152
1153         * runtime/Watchdog.cpp:
1154         (JSC::Watchdog::Watchdog):
1155
1156 2015-08-30  Yusuke Suzuki  <utatane.tea@gmail.com>
1157
1158         [ES6] JSON.stringify should ignore object properties that have symbol values and convert the symbol values in array to null
1159         https://bugs.webkit.org/show_bug.cgi?id=148628
1160
1161         Reviewed by Saam Barati.
1162
1163         As per ECMA262 6.0,
1164
1165         1. JSON.stringify should ignore object properties that have symbol values.
1166
1167             SerializeJSONProperty[1] will return undefined if the value of the property is a symbol.
1168             In this case, SerializeJSONObject[2] does not append any string for this property.
1169
1170         2. JSON.stringify should convert the symbol values in array to null
1171
1172             As the same to the object case, SerializeJSONProperty will return undefined if the value of the property is a symbol.
1173             But in the case of arrays, if the result of SerializeJSONProperty is undefined, it will emit "null"[3].
1174             This behavior is already implemented in the existing JSON.stringify. Added tests to ensure that.
1175
1176         [1]: http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonproperty
1177         [2]: http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonobject
1178         [3]: http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonarray
1179
1180         * runtime/JSONObject.cpp:
1181         (JSC::unwrapBoxedPrimitive):
1182         (JSC::Stringifier::appendStringifiedValue):
1183         (JSC::Stringifier::Holder::appendNextProperty):
1184         * tests/stress/symbol-with-json.js:
1185         (shouldBe):
1186
1187 2015-08-30  Filip Pizlo  <fpizlo@apple.com>
1188
1189         JSC property attributes should fit in a byte
1190         https://bugs.webkit.org/show_bug.cgi?id=148611
1191
1192         Reviewed by Sam Weinig.
1193
1194         I want to make room in PropertyMapEntry for more things to support property type inference (see
1195         https://bugs.webkit.org/show_bug.cgi?id=148610). The most obvious candidate for a size reduction is
1196         attributes, since we only have a small number of attribute bits. Even without complex changes, it
1197         would have been possible to reduce the attribute field from 32 bits to 16 bits. Specifically, prior
1198         to this change, the attributes field needed 9 bits. This made it very tempting to trim it so that
1199         it could fit in a byte.
1200
1201         Luckily, many of the attributes bits are for the static lookup hashtables that we use for lazily
1202         building objects in the standard library. Those bits don't need to stay around after the property
1203         has been created, since they are just for telling the code in Lookup how to create the property.
1204         So, this change separates the attributes bits into those that are interesting for Structure and
1205         those that aren't. The ones used by Structure sit in the low 8 bits, allowing for the attributes
1206         field in PropertyMapEntry to be a uint8_t. The attributes bits used only by Lookup use the higher
1207         bits. In production, the conversion from the Lookup attributes to the Structure attributes is just
1208         a cast to uint8_t. In debug, we assert that those bits are not dropped by accident. Code that
1209         intentionally drops those bits calls attributesForStructure().
1210
1211         It turned out that there was a lot of code that was using the Function bit even in code that didn't
1212         involve Lookup. This change removes those uses of Function. Structure does not need to know if we
1213         think that a property points to a function.
1214
1215         * jsc.cpp:
1216         (GlobalObject::finishCreation):
1217         * runtime/JSGlobalObject.cpp:
1218         (JSC::JSGlobalObject::init):
1219         * runtime/JSObject.h:
1220         * runtime/Lookup.cpp:
1221         (JSC::setUpStaticFunctionSlot):
1222         * runtime/Lookup.h:
1223         (JSC::getStaticPropertySlot):
1224         (JSC::getStaticValueSlot):
1225         (JSC::reifyStaticProperties):
1226         * runtime/MathObject.cpp:
1227         (JSC::MathObject::finishCreation):
1228         * runtime/NumberConstructor.cpp:
1229         (JSC::NumberConstructor::finishCreation):
1230         * runtime/PropertySlot.h:
1231         (JSC::attributesForStructure):
1232         (JSC::PropertySlot::setValue):
1233         (JSC::PropertySlot::setCustom):
1234         (JSC::PropertySlot::setCacheableCustom):
1235         (JSC::PropertySlot::setGetterSlot):
1236         (JSC::PropertySlot::setCacheableGetterSlot):
1237         * runtime/Structure.h:
1238         (JSC::PropertyMapEntry::PropertyMapEntry):
1239
1240 2015-08-29  Chris Dumez  <cdumez@apple.com>
1241
1242         Unreviewed, fix PropertyName::isNull() that was introduced in r188994.
1243
1244         The condition was reversed.
1245
1246         * runtime/PropertyName.h:
1247         (JSC::PropertyName::isNull):
1248
1249 2015-08-28  Commit Queue  <commit-queue@webkit.org>
1250
1251         Unreviewed, rolling out r189136.
1252         https://bugs.webkit.org/show_bug.cgi?id=148608
1253
1254         Made JSC tests flaky (Requested by ap on #webkit).
1255
1256         Reverted changeset:
1257
1258         "[JSC][x86] Improve the compare functions when comparing with
1259         zero"
1260         https://bugs.webkit.org/show_bug.cgi?id=148536
1261         http://trac.webkit.org/changeset/189136
1262
1263 2015-08-28  Benjamin Poulain  <bpoulain@apple.com>
1264
1265         [JSC] Get rid of DFG's MergeMode
1266         https://bugs.webkit.org/show_bug.cgi?id=148245
1267
1268         Reviewed by Mark Lam.
1269
1270         That code has become useless, the merge mode is always MergeToSuccessors.
1271
1272         * JavaScriptCore.xcodeproj/project.pbxproj:
1273         * dfg/DFGCFAPhase.cpp:
1274         (JSC::DFG::CFAPhase::performBlockCFA):
1275         * dfg/DFGInPlaceAbstractState.cpp:
1276         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
1277         * dfg/DFGInPlaceAbstractState.h:
1278         * dfg/DFGMergeMode.h: Removed.
1279
1280 2015-08-28  Benjamin Poulain  <bpoulain@apple.com>
1281
1282         [JSC][x86] Improve the compare functions when comparing with zero
1283         https://bugs.webkit.org/show_bug.cgi?id=148536
1284
1285         Reviewed by Geoffrey Garen.
1286
1287         This patch has two parts:
1288         1) The macro assembler gets an additional cmp->test optimization
1289            for LessThan and GreaterThanOrEqual.
1290            Instead of comparing the value with an immediate, test the value
1291            with itself and use the flag.
1292         2) Extend the DFG JIT optimization of compare.
1293            In particular, use the same optimization in compileInt32Compare()
1294            as we have in compilePeepHoleBooleanBranch().
1295            The generator compileInt32Compare() is unfortunately very
1296            common due to MoveHints placed between the Compare node and the Branch
1297            node.
1298
1299         * assembler/MacroAssembler.h:
1300         (JSC::MacroAssembler::compare32):
1301         * assembler/MacroAssemblerX86Common.h:
1302         (JSC::MacroAssemblerX86Common::branch32):
1303         (JSC::MacroAssemblerX86Common::compare32):
1304         * dfg/DFGSpeculativeJIT.cpp:
1305         (JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch):
1306         * dfg/DFGSpeculativeJIT64.cpp:
1307         (JSC::DFG::SpeculativeJIT::compileInt32Compare):
1308
1309 2015-08-28  Mark Lam  <mark.lam@apple.com>
1310
1311         Add MacroAssemblerPrinter support for printing memory.
1312         https://bugs.webkit.org/show_bug.cgi?id=148600
1313
1314         Reviewed by Saam Barati.
1315
1316         Previously, we can dump registers at runtime.  Now we can dump memory too.
1317         See comment in MacroAssemblerPrinter.h for examples of how to do this.
1318
1319         * assembler/MacroAssemblerPrinter.cpp:
1320         (JSC::printMemory):
1321         (JSC::MacroAssemblerPrinter::printCallback):
1322         * assembler/MacroAssemblerPrinter.h:
1323         (JSC::Memory::Memory):
1324         (JSC::MemWord::MemWord):
1325         (JSC::MacroAssemblerPrinter::PrintArg::PrintArg):
1326
1327 2015-08-28  Khem Raj  <raj.khem@gmail.com>
1328
1329         JavaScriptCore fails to build using GCC 5
1330         https://bugs.webkit.org/show_bug.cgi?id=147815
1331
1332         Reviewed by Filip Pizlo.
1333
1334         * runtime/JSObject.cpp: Explicitly instantiate all variants of
1335         putByIndexBeyondVectorLengthWithAttributes used by JSArray.cpp.
1336
1337 2015-08-28  Mark Lam  <mark.lam@apple.com>
1338
1339         Refactor the JIT printer out of the AbstractMacroAssembler into MacroAssemblerPrinter.
1340         https://bugs.webkit.org/show_bug.cgi?id=148595
1341
1342         Reviewed by Geoffrey Garen.
1343
1344         Why do this?
1345         1. MacroAssembler::print() code (except for the prototype) need no longer be parsed
1346            when compiling C++ files that don't need it.
1347         2. Adding support for more printable types to MacroAssemblerPrinter::PrintArg
1348            triggers recompilation of less files.
1349         3. The printing code is for most the part common between all target platforms and
1350            was previously duplicated by cut-and-paste to all the varieties of MacroAssemblers
1351            that support the MASM_PROBE mechanism.  Now, there is only one copy in
1352            MacroAssemblerPrinter.
1353
1354         * CMakeLists.txt:
1355         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1356         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1357         * JavaScriptCore.xcodeproj/project.pbxproj:
1358
1359         * assembler/AbstractMacroAssembler.h:
1360         (JSC::AbstractMacroAssembler::ProbeContext::print): Deleted.
1361         - Removed this function because it is no longer useful since we have this more
1362           flexible print() functionality.
1363
1364         (JSC::AbstractMacroAssembler::printIndent): Deleted.
1365         (JSC::AbstractMacroAssembler::printCPU): Deleted.
1366         (JSC::AbstractMacroAssembler::print): Deleted.
1367         (JSC::AbstractMacroAssembler::PrintArg::PrintArg): Deleted.
1368         (JSC::AbstractMacroAssembler::appendPrintArg): Deleted.
1369         (JSC::AbstractMacroAssembler::printInternal): Deleted.
1370         (JSC::AbstractMacroAssembler::printCallback): Deleted.
1371         - These got moved into MacroAssemblerPrinter.cpp.
1372
1373         * assembler/MacroAssembler.h:
1374         * assembler/MacroAssemblerARM.cpp:
1375         (JSC::MacroAssemblerARM::printCPURegisters): Deleted.
1376         (JSC::MacroAssemblerARM::printRegister): Deleted.
1377         * assembler/MacroAssemblerARM.h:
1378         * assembler/MacroAssemblerARMv7.cpp:
1379         (JSC::MacroAssemblerARMv7::printCPURegisters): Deleted.
1380         (JSC::MacroAssemblerARMv7::printRegister): Deleted.
1381         * assembler/MacroAssemblerARMv7.h:
1382         * assembler/MacroAssemblerX86Common.cpp:
1383         (JSC::MacroAssemblerX86Common::printCPURegisters): Deleted.
1384         (JSC::MacroAssemblerX86Common::printRegister): Deleted.
1385         * assembler/MacroAssemblerX86Common.h:
1386         - Deleted a whole bunch of mostly duplicated code.
1387
1388         * assembler/MacroAssemblerPrinter.cpp: Added.
1389         (JSC::printIndent):
1390         (JSC::printCPU):
1391         (JSC::printCPURegisters):
1392         (JSC::printRegister):
1393         (JSC::MacroAssemblerPrinter::printCallback):
1394         * assembler/MacroAssemblerPrinter.h: Added.
1395         (JSC::MacroAssemblerPrinter::print):
1396         (JSC::MacroAssemblerPrinter::PrintArg::PrintArg):
1397         (JSC::MacroAssemblerPrinter::appendPrintArg):
1398         (JSC::MacroAssembler::print):
1399
1400 2015-08-28  Filip Pizlo  <fpizlo@apple.com>
1401
1402         LICM should be sound even if the CFG has changed
1403         https://bugs.webkit.org/show_bug.cgi?id=148259
1404
1405         Reviewed by Benjamin Poulain.
1406
1407         Prior to this change, LICM expected a certain CFG shape around a loop: broken critical edges,
1408         a pre-header, and the pre-header's terminal has exitOK. LICM would either crash on an
1409         assertion, or generate code that fails validation, if these conditions weren't met.
1410
1411         The broken critical edge assumption is fine; so far we are assuming that SSA means broken
1412         critical edges. We may revisit this, but we don't have to right now.
1413
1414         The other assumptions are not fine, because it's hard to guarantee that every phase will
1415         preserve the presence of pre-headers. Even if we required that pre-headers are regenerated
1416         before LICM, that regeneration wouldn't be guaranteed to create pre-headers that have exitOK at
1417         the terminal. That's because once in SSA, the loop header probably has exitOK=false at the
1418         head because of Phi's. Pre-header creation has no choice but to use the Node::origin from the
1419         loop header, which means creating a pre-header that has exitOK=false. Regardless of whether
1420         that's a fixable problem, it seems that our best short-term approach is just to be defensive
1421         and turn undesirable pathologies into performance bugs and not crashes.
1422
1423         For the foreseeable future, once pre-headers are created they will probably not be removed. Our
1424         current CFG simplification phase doesn't have a rule for removing pre-headers (since it doesn't
1425         have any jump threading). So, it wouldn't be profitable to put effort towards reneration of
1426         pre-headers for LICM's benefit.
1427
1428         Also, we cannot guarantee that some sequence of CFG transformations will not create a loop that
1429         doesn't have a pre-header. This would be super rare. But you could imagine that some program
1430         has control flow encoded using relooping (like
1431         https://github.com/kripken/Relooper/blob/master/paper.pdf). If that happens, our compiler will
1432         probably incrementally discover the "original" CFG. That may happen only after SSA conversion,
1433         and so after pre-header generation. This is super unlikely for a bunch of reasons, but it
1434         *could* happen.
1435
1436         So, this patch just makes sure that if pre-headers are missing or cannot be exited from, LICM
1437         will simply avoid hoisting out of that block. At some point later, we can worry about a more
1438         comprehensive solution to the pre-header problem. That's covered by this bug:
1439         https://bugs.webkit.org/show_bug.cgi?id=148586
1440
1441         * dfg/DFGLICMPhase.cpp:
1442         (JSC::DFG::LICMPhase::run):
1443         (JSC::DFG::LICMPhase::attemptHoist):
1444         * dfg/DFGPlan.cpp:
1445         (JSC::DFG::Plan::compileInThreadImpl):
1446         * runtime/Options.h:
1447         * tests/stress/licm-no-pre-header.js: Added.
1448         (foo):
1449         * tests/stress/licm-pre-header-cannot-exit.js: Added.
1450         (foo):
1451
1452 2015-08-28  Yusuke Suzuki  <utatane.tea@gmail.com>
1453
1454         Move std::function from JSFunction into NativeStdFunctionCell to correctly destroy the heap allocated std::function
1455         https://bugs.webkit.org/show_bug.cgi?id=148262
1456
1457         Reviewed by Filip Pizlo.
1458
1459         std::function is heap allocated value. So if this is held in the JSCell, the cell should be destructible.
1460         Before this patch, it is held in the JSStdFunction. JSStdFunction is the derived class from the JSFunction,
1461         and they are not destructible. So it leaked the memory.
1462
1463         This patch extracts std::function field from the JSStdFunction to the NativeStdFunctionCell. NativeStdFunctionCell
1464         is responsible for destructing the held std::function.
1465         Instead of moving std::function to the ExecutableBase, we move it to the newly created NativeStdFunctionCell cell.
1466         The reason is the following.
1467
1468         - Each NativeExecutable (in 64_32 JIT environment) has the trampolines to call given host functions.
1469           And the address of the host function is directly embedded on the JIT-compiled trampoline code.
1470         - To suppress the overuse of the executable memory (which is used to generate the trampoline), NativeExecutable
1471           is cached. The host function address is used as the key to look up the cached executable from the table.
1472         - In all the JSStdFunction, we use the same host function that immediately calls the each std::function.
1473         - As a result, without any change, all the JSStdFunction hit the same cached NativeExecutable even if the held
1474           std::function is different.
1475         - To solve it, if we put the std::function in the NativeExecutable, we need to add this std::function
1476           identity (like address) to the cache key, because the address of the stub host function (that calls the
1477           std::function) is the same in the all JSStdFunction.
1478         - But since the std::function will be allocated in the heap, this address is always different. So caching has
1479           no effect.
1480         - If we do not cache the NativeExecutable that holds the std::function, each time when creating the JSStdFunction,
1481           we need to regenerate the completely same trampolines (since it just calls the same host function stub that
1482           calls the std::function).
1483
1484         And this patch drops JSArrowFunction::destroy because (1) JSArrowFunction is not destructible and (2) it no longer
1485         holds any fields that require destructions.
1486
1487         * CMakeLists.txt:
1488         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1489         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1490         * JavaScriptCore.xcodeproj/project.pbxproj:
1491         * jsc.cpp:
1492         (runWithScripts):
1493         * runtime/JSArrowFunction.cpp:
1494         (JSC::JSArrowFunction::destroy): Deleted.
1495         * runtime/JSArrowFunction.h:
1496         * runtime/JSFunction.cpp:
1497         (JSC::JSFunction::lookUpOrCreateNativeExecutable):
1498         (JSC::JSFunction::create):
1499         (JSC::getNativeExecutable): Deleted.
1500         (JSC::JSStdFunction::JSStdFunction): Deleted.
1501         (JSC::runStdFunction): Deleted.
1502         * runtime/JSFunction.h:
1503         * runtime/JSGlobalObject.cpp:
1504         (JSC::JSGlobalObject::init):
1505         (JSC::JSGlobalObject::visitChildren):
1506         * runtime/JSGlobalObject.h:
1507         (JSC::JSGlobalObject::nativeStdFunctionStructure):
1508         * runtime/JSNativeStdFunction.cpp: Added.
1509         (JSC::JSNativeStdFunction::JSNativeStdFunction):
1510         (JSC::JSNativeStdFunction::visitChildren):
1511         (JSC::JSNativeStdFunction::finishCreation):
1512         (JSC::runStdFunction):
1513         (JSC::JSNativeStdFunction::create):
1514         * runtime/JSNativeStdFunction.h: Copied from Source/JavaScriptCore/runtime/JSArrowFunction.h.
1515         (JSC::JSNativeStdFunction::createStructure):
1516         (JSC::JSNativeStdFunction::nativeStdFunctionCell):
1517         * runtime/NativeStdFunctionCell.cpp: Added.
1518         (JSC::NativeStdFunctionCell::create):
1519         (JSC::NativeStdFunctionCell::NativeStdFunctionCell):
1520         (JSC::NativeStdFunctionCell::destroy):
1521         * runtime/NativeStdFunctionCell.h: Added.
1522         (JSC::NativeStdFunctionCell::createStructure):
1523         (JSC::NativeStdFunctionCell::function):
1524         * runtime/VM.cpp:
1525         (JSC::VM::VM):
1526         * runtime/VM.h:
1527
1528 2015-08-28  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1529
1530         Create WebAssembly functions
1531         https://bugs.webkit.org/show_bug.cgi?id=148373
1532
1533         Reviewed by Filip Pizlo.
1534
1535         Create functions from WebAssembly files generated by pack-asmjs
1536         <https://github.com/WebAssembly/polyfill-prototype-1>.
1537         WebAssembly functions created by this patch can only return 0.
1538         Actual code generation will be implemented in subsequent patches.
1539
1540         This patch introduces WebAssemblyExecutable, a new subclass of
1541         ExecutableBase for WebAssembly functions. CodeBlocks can now have
1542         an owner that is not a ScriptExecutable. This patch changes the
1543         return type of CodeBlock::ownerExecutable() from ScriptExecutable*
1544         to ExecutableBase*. It also changes code that calls ScriptExecutable's
1545         methods on CodeBlock::ownerExecutable() to use
1546         CodeBlock::ownerScriptExecutable(), which does jsCast<ScriptExecutable*>.
1547
1548         Since ownerScriptExecutable() is called from WebCore and it uses
1549         jsCast<ScriptExecutable*>, this patch needs to export
1550         ScriptExecutable::info(). This should fix the build error in
1551         https://bugs.webkit.org/show_bug.cgi?id=148555
1552
1553         * bytecode/CodeBlock.cpp:
1554         (JSC::CodeBlock::hash):
1555         (JSC::CodeBlock::sourceCodeForTools):
1556         (JSC::CodeBlock::dumpAssumingJITType):
1557         (JSC::CodeBlock::dumpSource):
1558         (JSC::CodeBlock::CodeBlock):
1559         (JSC::CodeBlock::finalizeUnconditionally):
1560         (JSC::CodeBlock::lineNumberForBytecodeOffset):
1561         (JSC::CodeBlock::expressionRangeForBytecodeOffset):
1562         (JSC::CodeBlock::install):
1563         (JSC::CodeBlock::newReplacement):
1564         (JSC::WebAssemblyCodeBlock::replacement):
1565         (JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
1566         (JSC::CodeBlock::updateAllPredictions):
1567         (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
1568         * bytecode/CodeBlock.h:
1569         (JSC::CodeBlock::ownerExecutable):
1570         (JSC::CodeBlock::ownerScriptExecutable):
1571         (JSC::CodeBlock::codeType):
1572         (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
1573         * debugger/Debugger.cpp:
1574         (JSC::Debugger::toggleBreakpoint):
1575         * debugger/DebuggerCallFrame.cpp:
1576         (JSC::DebuggerCallFrame::sourceIDForCallFrame):
1577         * dfg/DFGByteCodeParser.cpp:
1578         (JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
1579         (JSC::DFG::ByteCodeParser::inliningCost):
1580         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
1581         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1582         * dfg/DFGCapabilities.cpp:
1583         (JSC::DFG::isSupportedForInlining):
1584         (JSC::DFG::mightCompileEval):
1585         (JSC::DFG::mightCompileProgram):
1586         (JSC::DFG::mightCompileFunctionForCall):
1587         (JSC::DFG::mightCompileFunctionForConstruct):
1588         * dfg/DFGGraph.h:
1589         (JSC::DFG::Graph::executableFor):
1590         * dfg/DFGOSREntry.cpp:
1591         (JSC::DFG::prepareOSREntry):
1592         * inspector/ScriptCallStackFactory.cpp:
1593         (Inspector::CreateScriptCallStackFunctor::operator()):
1594         * interpreter/Interpreter.cpp:
1595         (JSC::eval):
1596         (JSC::isWebAssemblyExecutable):
1597         (JSC::GetStackTraceFunctor::operator()):
1598         (JSC::UnwindFunctor::operator()):
1599         * interpreter/StackVisitor.cpp:
1600         (JSC::StackVisitor::Frame::sourceURL):
1601         (JSC::StackVisitor::Frame::computeLineAndColumn):
1602         * jit/JITOperations.cpp:
1603         * jit/Repatch.cpp:
1604         (JSC::linkPolymorphicCall):
1605         * llint/LLIntData.cpp:
1606         (JSC::LLInt::Data::performAssertions):
1607         * llint/LLIntSlowPaths.cpp:
1608         (JSC::LLInt::setUpCall):
1609         * llint/LowLevelInterpreter.asm:
1610         * runtime/CommonSlowPaths.cpp:
1611         (JSC::SLOW_PATH_DECL):
1612         * runtime/Executable.cpp:
1613         (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
1614         (JSC::WebAssemblyExecutable::destroy):
1615         (JSC::WebAssemblyExecutable::visitChildren):
1616         (JSC::WebAssemblyExecutable::clearCode):
1617         (JSC::WebAssemblyExecutable::prepareForExecution):
1618         * runtime/Executable.h:
1619         (JSC::ExecutableBase::isEvalExecutable):
1620         (JSC::ExecutableBase::isFunctionExecutable):
1621         (JSC::ExecutableBase::isProgramExecutable):
1622         (JSC::ExecutableBase::isWebAssemblyExecutable):
1623         (JSC::ExecutableBase::clearCodeVirtual):
1624         * runtime/JSFunction.cpp:
1625         (JSC::JSFunction::create):
1626         * runtime/JSFunction.h:
1627         * runtime/JSFunctionInlines.h:
1628         (JSC::JSFunction::JSFunction):
1629         (JSC::JSFunction::isBuiltinFunction):
1630         * runtime/JSType.h:
1631         * runtime/VM.cpp:
1632         (JSC::VM::VM):
1633         * runtime/VM.h:
1634         * wasm/JSWASMModule.h:
1635         (JSC::JSWASMModule::functions):
1636         * wasm/WASMFunctionParser.cpp:
1637         (JSC::WASMFunctionParser::compile):
1638         * wasm/WASMFunctionParser.h:
1639         * wasm/WASMModuleParser.cpp:
1640         (JSC::WASMModuleParser::WASMModuleParser):
1641         (JSC::WASMModuleParser::parse):
1642         (JSC::WASMModuleParser::parseFunctionDeclarationSection):
1643         (JSC::WASMModuleParser::parseFunctionDefinition):
1644         (JSC::WASMModuleParser::parseExportSection):
1645         (JSC::parseWebAssembly):
1646         * wasm/WASMModuleParser.h:
1647
1648 2015-08-28  Mark Lam  <mark.lam@apple.com>
1649
1650         [Follow up] ScratchRegisterAllocator::preserveReusedRegistersByPushing() should allow room for C helper calls and keep sp properly aligned.
1651         https://bugs.webkit.org/show_bug.cgi?id=148564
1652
1653         Not reviewed.
1654
1655         Updated the test to run with //@ runNoCJITNoAccessInlining instead of specifying
1656         the JSC option directly via //@ run().  This is the right thing to do in order
1657         to guarantee that the test will be compiled by the DFG.
1658
1659         * tests/stress/regress-148564.js:
1660
1661 2015-08-28  Joseph Pecoraro  <pecoraro@apple.com>
1662
1663         Web Inspector: Separate creating a style sheet from adding a new rule in the protocol
1664         https://bugs.webkit.org/show_bug.cgi?id=148502
1665
1666         Reviewed by Timothy Hatcher.
1667
1668         * inspector/protocol/CSS.json:
1669         Add CSS.createStyleSheet. Modify CSS.addRule.
1670
1671 2015-08-28  Mark Lam  <mark.lam@apple.com>
1672
1673         ScratchRegisterAllocator::preserveReusedRegistersByPushing() should allow room for C helper calls and keep sp properly aligned.
1674         https://bugs.webkit.org/show_bug.cgi?id=148564
1675
1676         Reviewed by Saam Barati.
1677
1678         ScratchRegisterAllocator::preserveReusedRegistersByPushing() pushes registers on
1679         the stack in order to preserve them.  But emitPutTransitionStub() (which uses
1680         preserveReusedRegistersByPushing()) may also emit a call to a C helper function
1681         to flush the heap write barrier buffer.  The code for emitting a C helper call
1682         expects the stack pointer (sp) to already be pointing to a location on the stack
1683         where there's adequate space reserved for storing the arguments to the C helper,
1684         and that space is expected to be at the top of the stack.  Hence, there is a
1685         conflict of expectations.  As a result, the arguments for the C helper will
1686         overwrite and corrupt the values that are pushed on the stack by
1687         preserveReusedRegistersByPushing().
1688
1689         In addition, JIT compiled functions always position the sp such that it will be
1690         aligned (according to platform ABI dictates) after a C call is made (i.e. after
1691         the frame pointer and return address is pushed on to the stack).
1692         preserveReusedRegistersByPushing()'s arbitrary pushing of a number of saved
1693         register values may mess up this alignment.
1694
1695         The fix is to have preserveReusedRegistersByPushing(), after it has pushed the
1696         saved register values, adjust the sp to reserve an additional amount of stack
1697         space needed for C call helpers plus any padding needed to restore proper sp
1698         alignment.  The stack's ReservedZone will ensure that we have enough stack space
1699         for this.  ScratchRegisterAllocator::restoreReusedRegistersByPopping() also
1700         needs to be updated to perform the complement of this behavior.
1701
1702         * jit/Repatch.cpp:
1703         (JSC::emitPutReplaceStub):
1704         (JSC::emitPutTransitionStub):
1705         * jit/ScratchRegisterAllocator.cpp:
1706         (JSC::ScratchRegisterAllocator::allocateScratchGPR):
1707         (JSC::ScratchRegisterAllocator::allocateScratchFPR):
1708         (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
1709         (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
1710         * jit/ScratchRegisterAllocator.h:
1711         (JSC::ScratchRegisterAllocator::numberOfReusedRegisters):
1712         * tests/stress/regress-148564.js: Added.
1713         (test):
1714         (runTest):
1715
1716 2015-08-28  Csaba Osztrogon√°c  <ossy@webkit.org>
1717
1718         Unreviewed Windows buildfix.
1719
1720         Revert part of r189072 since the original change was rolled out by r189085.
1721
1722         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1723         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1724
1725 2015-08-28  Csaba Osztrogon√°c  <ossy@webkit.org>
1726
1727         Unreviewed Windows buildfix.
1728
1729         Revert r189077 since the original change was rolled out by r189085.
1730
1731         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1732         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1733
1734 2015-08-27  Yusuke Suzuki  <utatane.tea@gmail.com>
1735
1736         [ES6] Implement Module execution and Loader's ready / link phase
1737         https://bugs.webkit.org/show_bug.cgi?id=148172
1738
1739         Reviewed by Saam Barati.
1740
1741         This patch adds the link / ready phases to the existing module loader.
1742         They are just the stubs and the actual implementations will be
1743         forthcoming in the subsequnt patch.
1744
1745         And this patch paves the way to instantiate the module environment and
1746         compile the executable code in the link phase. Move declaredVariables /
1747         lexicalVariables from ModuleAnalyzer to JSModuleRecord to use them when
1748         instantiating the module environment. Hold the source code in
1749         JSModuleRecord to construct the executable in the link phase. And to
1750         use HostResolveImportedModule operation from the C++ side, we expose
1751         the JSMap from C++ to JS and use it in the builtin JS module loader
1752         code.
1753
1754         * builtins/ModuleLoaderObject.js:
1755         (requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then.):
1756         (requestLink):
1757         (requestReady):
1758         (link):
1759         (moduleEvaluation):
1760         (loadModule):
1761         * parser/ModuleAnalyzer.cpp:
1762         (JSC::ModuleAnalyzer::ModuleAnalyzer):
1763         (JSC::ModuleAnalyzer::analyze):
1764         * parser/ModuleAnalyzer.h:
1765         * runtime/Completion.cpp:
1766         (JSC::checkModuleSyntax):
1767         * runtime/JSModuleRecord.cpp:
1768         (JSC::JSModuleRecord::finishCreation):
1769         (JSC::JSModuleRecord::visitChildren):
1770         (JSC::identifierToJSValue):
1771         (JSC::JSModuleRecord::hostResolveImportedModule):
1772         (JSC::JSModuleRecord::link):
1773         (JSC::JSModuleRecord::execute):
1774         * runtime/JSModuleRecord.h:
1775         (JSC::JSModuleRecord::create):
1776         (JSC::JSModuleRecord::sourceCode):
1777         (JSC::JSModuleRecord::moduleKey):
1778         (JSC::JSModuleRecord::exportEntries):
1779         (JSC::JSModuleRecord::importEntries):
1780         (JSC::JSModuleRecord::declaredVariables):
1781         (JSC::JSModuleRecord::lexicalVariables):
1782         (JSC::JSModuleRecord::JSModuleRecord):
1783         * runtime/ModuleLoaderObject.cpp:
1784         (JSC::moduleLoaderObjectParseModule):
1785         (JSC::moduleLoaderObjectRequestedModules):
1786         (JSC::moduleLoaderObjectModuleDeclarationInstantiation):
1787         (JSC::moduleLoaderObjectEvaluate):
1788         (JSC::ModuleLoaderObject::requestInstantiateAll): Deleted.
1789         * runtime/ModuleLoaderObject.h:
1790
1791 2015-08-27  Mark Lam  <mark.lam@apple.com>
1792
1793         Add noDFG() to jsc to prevent DFG compilation of a specified function.
1794         https://bugs.webkit.org/show_bug.cgi?id=148559
1795
1796         Reviewed by Geoffrey Garen and Saam Barati.
1797
1798         * API/JSCTestRunnerUtils.cpp:
1799         (JSC::setNeverInline):
1800         (JSC::setNeverOptimize):
1801         * API/JSCTestRunnerUtils.h:
1802         * bytecode/CodeBlock.cpp:
1803         (JSC::CodeBlock::dumpAssumingJITType):
1804         * dfg/DFGCapabilities.cpp:
1805         (JSC::DFG::mightCompileEval):
1806         (JSC::DFG::mightCompileProgram):
1807         (JSC::DFG::mightCompileFunctionForCall):
1808         (JSC::DFG::mightCompileFunctionForConstruct):
1809         (JSC::DFG::mightInlineFunctionForCall):
1810         * jsc.cpp:
1811         (GlobalObject::finishCreation):
1812         (functionNoDFG):
1813         * runtime/Executable.h:
1814         (JSC::ScriptExecutable::ecmaMode):
1815         (JSC::ScriptExecutable::setNeverInline):
1816         (JSC::ScriptExecutable::setNeverOptimize):
1817         (JSC::ScriptExecutable::setDidTryToEnterInLoop):
1818         (JSC::ScriptExecutable::neverInline):
1819         (JSC::ScriptExecutable::neverOptimize):
1820         (JSC::ScriptExecutable::didTryToEnterInLoop):
1821         (JSC::ScriptExecutable::isInliningCandidate):
1822         (JSC::ScriptExecutable::isOkToOptimize):
1823         (JSC::ScriptExecutable::addressOfDidTryToEnterInLoop):
1824         * runtime/TestRunnerUtils.cpp:
1825         (JSC::setNeverInline):
1826         (JSC::setNeverOptimize):
1827         (JSC::optimizeNextInvocation):
1828         * runtime/TestRunnerUtils.h:
1829
1830 2015-08-27  Commit Queue  <commit-queue@webkit.org>
1831
1832         Unreviewed, rolling out r189064 and r189084.
1833         https://bugs.webkit.org/show_bug.cgi?id=148560
1834
1835         Breaks 117 JSC tests. (Requested by mlam on #webkit).
1836
1837         Reverted changesets:
1838
1839         "[ES6] Add TypedArray.prototype functionality."
1840         https://bugs.webkit.org/show_bug.cgi?id=148035
1841         http://trac.webkit.org/changeset/189064
1842
1843         "Unbreak JSC tests (broken since r189064)."
1844         http://trac.webkit.org/changeset/189084
1845
1846 2015-08-27  Commit Queue  <commit-queue@webkit.org>
1847
1848         Unreviewed, rolling out r189079.
1849         https://bugs.webkit.org/show_bug.cgi?id=148555
1850
1851         broke the build (Requested by jessieberlin on #webkit).
1852
1853         Reverted changeset:
1854
1855         "Create WebAssembly functions"
1856         https://bugs.webkit.org/show_bug.cgi?id=148373
1857         http://trac.webkit.org/changeset/189079
1858
1859 2015-08-27  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1860
1861         Create WebAssembly functions
1862         https://bugs.webkit.org/show_bug.cgi?id=148373
1863
1864         Reviewed by Geoffrey Garen.
1865
1866         Create functions from WebAssembly files generated by pack-asmjs
1867         <https://github.com/WebAssembly/polyfill-prototype-1>.
1868         WebAssembly functions created by this patch can only return 0.
1869         Actual code generation will be implemented in subsequent patches.
1870
1871         * bytecode/CodeBlock.cpp:
1872         (JSC::CodeBlock::hash):
1873         (JSC::CodeBlock::sourceCodeForTools):
1874         (JSC::CodeBlock::dumpAssumingJITType):
1875         (JSC::CodeBlock::dumpSource):
1876         (JSC::CodeBlock::CodeBlock):
1877         (JSC::CodeBlock::finalizeUnconditionally):
1878         (JSC::CodeBlock::lineNumberForBytecodeOffset):
1879         (JSC::CodeBlock::expressionRangeForBytecodeOffset):
1880         (JSC::CodeBlock::install):
1881         (JSC::CodeBlock::newReplacement):
1882         (JSC::WebAssemblyCodeBlock::replacement):
1883         (JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
1884         (JSC::CodeBlock::updateAllPredictions):
1885         (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
1886         * bytecode/CodeBlock.h:
1887         (JSC::CodeBlock::ownerExecutable):
1888         (JSC::CodeBlock::ownerScriptExecutable):
1889         (JSC::CodeBlock::codeType):
1890         (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
1891         * debugger/Debugger.cpp:
1892         (JSC::Debugger::toggleBreakpoint):
1893         * debugger/DebuggerCallFrame.cpp:
1894         (JSC::DebuggerCallFrame::sourceIDForCallFrame):
1895         * dfg/DFGByteCodeParser.cpp:
1896         (JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
1897         (JSC::DFG::ByteCodeParser::inliningCost):
1898         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
1899         (JSC::DFG::ByteCodeParser::parseCodeBlock):
1900         * dfg/DFGCapabilities.cpp:
1901         (JSC::DFG::isSupportedForInlining):
1902         * dfg/DFGGraph.h:
1903         (JSC::DFG::Graph::executableFor):
1904         * dfg/DFGOSREntry.cpp:
1905         (JSC::DFG::prepareOSREntry):
1906         * inspector/ScriptCallStackFactory.cpp:
1907         (Inspector::CreateScriptCallStackFunctor::operator()):
1908         * interpreter/Interpreter.cpp:
1909         (JSC::eval):
1910         (JSC::isWebAssemblyExecutable):
1911         (JSC::GetStackTraceFunctor::operator()):
1912         (JSC::UnwindFunctor::operator()):
1913         * interpreter/StackVisitor.cpp:
1914         (JSC::StackVisitor::Frame::sourceURL):
1915         (JSC::StackVisitor::Frame::computeLineAndColumn):
1916         * jit/JITOperations.cpp:
1917         * jit/Repatch.cpp:
1918         (JSC::isWebAssemblyExecutable):
1919         (JSC::linkPolymorphicCall):
1920         * llint/LLIntData.cpp:
1921         (JSC::LLInt::Data::performAssertions):
1922         * llint/LLIntSlowPaths.cpp:
1923         (JSC::LLInt::setUpCall):
1924         * llint/LowLevelInterpreter.asm:
1925         * runtime/CommonSlowPaths.cpp:
1926         (JSC::SLOW_PATH_DECL):
1927         * runtime/Executable.cpp:
1928         (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
1929         (JSC::WebAssemblyExecutable::destroy):
1930         (JSC::WebAssemblyExecutable::visitChildren):
1931         (JSC::WebAssemblyExecutable::clearCode):
1932         (JSC::WebAssemblyExecutable::prepareForExecution):
1933         * runtime/Executable.h:
1934         (JSC::ExecutableBase::isEvalExecutable):
1935         (JSC::ExecutableBase::isFunctionExecutable):
1936         (JSC::ExecutableBase::isProgramExecutable):
1937         (JSC::ExecutableBase::isWebAssemblyExecutable):
1938         (JSC::ExecutableBase::clearCodeVirtual):
1939         * runtime/JSFunction.cpp:
1940         (JSC::JSFunction::create):
1941         * runtime/JSFunction.h:
1942         * runtime/JSFunctionInlines.h:
1943         (JSC::JSFunction::JSFunction):
1944         (JSC::JSFunction::isBuiltinFunction):
1945         * runtime/JSType.h:
1946         * runtime/VM.cpp:
1947         (JSC::VM::VM):
1948         * runtime/VM.h:
1949         * wasm/JSWASMModule.h:
1950         (JSC::JSWASMModule::functions):
1951         * wasm/WASMFunctionParser.cpp:
1952         (JSC::WASMFunctionParser::compile):
1953         * wasm/WASMFunctionParser.h:
1954         * wasm/WASMModuleParser.cpp:
1955         (JSC::WASMModuleParser::WASMModuleParser):
1956         (JSC::WASMModuleParser::parse):
1957         (JSC::WASMModuleParser::parseFunctionDeclarationSection):
1958         (JSC::WASMModuleParser::parseFunctionDefinition):
1959         (JSC::WASMModuleParser::parseExportSection):
1960         (JSC::parseWebAssembly):
1961         * wasm/WASMModuleParser.h:
1962
1963 2015-08-27  Brent Fulgham  <bfulgham@apple.com>
1964
1965         [Win] Unreviewed build fix after r189064.
1966
1967         JSTypedArrayViewPrototypes.{h,cpp} -> JSTypedArrayViewPrototype.{h,cpp}
1968
1969         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1970         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1971
1972 2015-08-27  Alex Christensen  <achristensen@webkit.org>
1973
1974         Make DLLLauncherMain executables dependent on dll
1975         https://bugs.webkit.org/show_bug.cgi?id=148548
1976
1977         Reviewed by Brent Fulgham.
1978
1979         * shell/CMakeLists.txt:
1980         * shell/PlatformWin.cmake:
1981
1982 2015-08-27  Filip Pizlo  <fpizlo@apple.com>
1983
1984         DFG::StrCat isn't really effectful
1985         https://bugs.webkit.org/show_bug.cgi?id=148443
1986
1987         Reviewed by Geoffrey Garen.
1988
1989         I previously made the DFG StrCat node effectful because it is implemented by calling a
1990         DFGOperations function that could cause arbitrary effects. But, the node is only generated from the
1991         op_strcat bytecode operation, and that operation is only used when we first ensure that its
1992         operands are primitives. Primitive operands to StrCat cannot cause arbitrary side-effects. The
1993         reason why I didn't immediately mark StrCat as pure was because there was nothing in DFG IR that
1994         guaranteed that StrCat's children were primitives.
1995
1996         This change adds a KnownPrimitiveUse use kind, and applies it to StrCat. This allows us to mark
1997         StrCat as being pure. This should be a speed-up because we can CSE StrCat and because it means that
1998         we can OSR exit after a StrCat (a pure node doesn't clobber exit state), so we can convert more
1999         of a large string concatenation into MakeRope's.
2000
2001         * dfg/DFGAbstractInterpreterInlines.h:
2002         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2003         * dfg/DFGClobberize.h:
2004         (JSC::DFG::clobberize):
2005         * dfg/DFGFixupPhase.cpp:
2006         (JSC::DFG::FixupPhase::fixupNode):
2007         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
2008         * dfg/DFGOperations.cpp:
2009         * dfg/DFGSafeToExecute.h:
2010         (JSC::DFG::SafeToExecuteEdge::operator()):
2011         * dfg/DFGSpeculativeJIT.cpp:
2012         (JSC::DFG::SpeculativeJIT::speculate):
2013         * dfg/DFGSpeculativeJIT32_64.cpp:
2014         (JSC::DFG::SpeculativeJIT::compile):
2015         * dfg/DFGSpeculativeJIT64.cpp:
2016         (JSC::DFG::SpeculativeJIT::compile):
2017         * dfg/DFGUseKind.cpp:
2018         (WTF::printInternal):
2019         * dfg/DFGUseKind.h:
2020         (JSC::DFG::typeFilterFor):
2021         (JSC::DFG::shouldNotHaveTypeCheck):
2022         * ftl/FTLCapabilities.cpp:
2023         (JSC::FTL::canCompile):
2024         * ftl/FTLLowerDFGToLLVM.cpp:
2025         (JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
2026         (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
2027
2028 2015-08-27  Brent Fulgham  <bfulgham@apple.com>
2029
2030         [Win] Unreviewed build fix after r189064.
2031
2032         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2033         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2034
2035 2015-08-27  Yusuke Suzuki  <utatane.tea@gmail.com>
2036
2037         Add module loader "resolve" hook for local file system to test the loader in JSC shell
2038         https://bugs.webkit.org/show_bug.cgi?id=148543
2039
2040         Reviewed by Filip Pizlo.
2041
2042         Add the module loader "resolve" hook to the JSC shell.
2043         It takes the module name and the referrer module key and resolves the name to the unique module key.
2044
2045         resolve(ModuleName moduleName, ModuleKey referrer) -> Promise<ModuleKey>
2046
2047         In the JSC shell, since we load the module from the local file system, we treat an absolute file path
2048         as a module key. So, in this patch, we implement the "resolve" hook that resolves the module name to
2049         the absolute file path.
2050
2051         This local file system "resolve" functionality makes JSC shell easy to test the module loader.
2052
2053         * jsc.cpp:
2054         (GlobalObject::finishCreation):
2055         (GlobalObject::moduleLoaderFetch):
2056         (pathSeparator):
2057         (extractDirectoryName):
2058         (currentWorkingDirectory):
2059         (resolvePath):
2060         (GlobalObject::moduleLoaderResolve):
2061         (functionDrainMicrotasks):
2062         * runtime/JSInternalPromiseDeferred.cpp:
2063         (JSC::JSInternalPromiseDeferred::resolve):
2064         (JSC::JSInternalPromiseDeferred::reject):
2065         * runtime/JSInternalPromiseDeferred.h:
2066         * tests/stress/pathname-resolve.js: Added.
2067         (shouldBe):
2068         (shouldThrow):
2069
2070 2015-08-27  Filip Pizlo  <fpizlo@apple.com>
2071
2072         Unreviewed, fix some FIXMEs and add some new ones, based on things we've learned from some
2073         recent OSR exit work.
2074
2075         * dfg/DFGLICMPhase.cpp:
2076         (JSC::DFG::LICMPhase::run):
2077         (JSC::DFG::LICMPhase::attemptHoist):
2078         * dfg/DFGMayExit.cpp:
2079         * dfg/DFGMayExit.h:
2080
2081 2015-08-27  Keith Miller  <keith_miller@apple.com>
2082
2083         [ES6] Add TypedArray.prototype functionality.
2084         https://bugs.webkit.org/show_bug.cgi?id=148035
2085
2086         Reviewed by Geoffrey Garen.
2087
2088         This patch should add most of the functionality for
2089         the prototype properties of TypedArray objects in ES6.
2090         There are a few exceptions to this, which will be added
2091         in upcoming patches:
2092
2093         1) First we do not use the species constructor for some
2094         of the TypedArray prototype functions (namely: map, filter,
2095         slice, and subarray). That will need to be added when
2096         species constructors are finished.
2097
2098         2) TypedArrays still have a length, byteOffset, byteLength,
2099         and buffer are still attached to the TypedArray instance (in
2100         the spec they are on the TypedArray.prototype instance object)
2101         since the JIT currently assumes those properties are fixed.
2102
2103         3) The TypedArray.constructor property is not added yet
2104         as it should point to the TypedArray instance object,
2105         which will be added in a future patch.
2106
2107         * CMakeLists.txt:
2108         * JavaScriptCore.xcodeproj/project.pbxproj:
2109         * builtins/TypedArray.prototype.js: Added.
2110         (every):
2111         (find):
2112         (findIndex):
2113         (forEach):
2114         (some):
2115         (sort.min):
2116         (sort.merge):
2117         (sort.mergeSort):
2118         (sort):
2119         (reduce):
2120         (reduceRight):
2121         (map):
2122         (filter):
2123         (toLocaleString):
2124         * runtime/ArrayPrototype.cpp:
2125         * runtime/ArrayPrototype.h:
2126         * runtime/CommonIdentifiers.h:
2127         * runtime/JSGenericTypedArrayView.h:
2128         (JSC::sortFloat):
2129         (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
2130         (JSC::JSGenericTypedArrayView::setRangeToValue):
2131         (JSC::JSGenericTypedArrayView::sort):
2132         * runtime/JSGenericTypedArrayViewInlines.h:
2133         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
2134         (JSC::argumentClampedIndexFromStartOrEnd):
2135         (JSC::genericTypedArrayViewProtoFuncSet):
2136         (JSC::genericTypedArrayViewProtoFuncEntries):
2137         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
2138         (JSC::genericTypedArrayViewProtoFuncFill):
2139         (JSC::genericTypedArrayViewProtoFuncIndexOf):
2140         (JSC::genericTypedArrayViewProtoFuncJoin):
2141         (JSC::genericTypedArrayViewProtoFuncKeys):
2142         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
2143         (JSC::genericTypedArrayViewProtoGetterFuncLength):
2144         (JSC::genericTypedArrayViewProtoGetterFuncByteLength):
2145         (JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
2146         (JSC::genericTypedArrayViewProtoFuncReverse):
2147         (JSC::genericTypedArrayViewPrivateFuncSort):
2148         (JSC::genericTypedArrayViewProtoFuncSlice):
2149         (JSC::genericTypedArrayViewProtoFuncSubarray):
2150         (JSC::typedArrayViewProtoFuncValues):
2151         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
2152         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
2153         (JSC::genericTypedArrayViewProtoFuncSet): Deleted.
2154         (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
2155         * runtime/JSGlobalObject.cpp:
2156         (JSC::JSGlobalObject::init):
2157         * runtime/JSObject.h:
2158         * runtime/JSTypedArrayPrototypes.cpp:
2159         * runtime/JSTypedArrayPrototypes.h:
2160         * runtime/JSTypedArrayViewPrototype.cpp: Added.
2161         (JSC::typedArrayViewPrivateFuncLength):
2162         (JSC::typedArrayViewPrivateFuncSort):
2163         (JSC::typedArrayViewProtoFuncSet):
2164         (JSC::typedArrayViewProtoFuncEntries):
2165         (JSC::typedArrayViewProtoFuncCopyWithin):
2166         (JSC::typedArrayViewProtoFuncFill):
2167         (JSC::typedArrayViewProtoFuncLastIndexOf):
2168         (JSC::typedArrayViewProtoFuncIndexOf):
2169         (JSC::typedArrayViewProtoFuncJoin):
2170         (JSC::typedArrayViewProtoFuncKeys):
2171         (JSC::typedArrayViewProtoGetterFuncLength):
2172         (JSC::typedArrayViewProtoGetterFuncByteLength):
2173         (JSC::typedArrayViewProtoGetterFuncByteOffset):
2174         (JSC::typedArrayViewProtoFuncReverse):
2175         (JSC::typedArrayViewProtoFuncSubarray):
2176         (JSC::typedArrayViewProtoFuncSlice):
2177         (JSC::typedArrayViewProtoFuncValues):
2178         (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
2179         (JSC::JSTypedArrayViewPrototype::finishCreation):
2180         (JSC::JSTypedArrayViewPrototype::create):
2181         (JSC::JSTypedArrayViewPrototype::createStructure):
2182         * runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
2183
2184 2015-08-27  Alex Christensen  <achristensen@webkit.org>
2185
2186         Isolate Source directories in CMake build
2187         https://bugs.webkit.org/show_bug.cgi?id=148389
2188
2189         Reviewed by Brent Fulgham.
2190
2191         * PlatformWin.cmake:
2192         Include ../include/private to find WTF headers in internal build.
2193         Don't use a script to generate forwarding headers.
2194         * shell/PlatformWin.cmake:
2195         Copy inspector scripts to the forwarding headers directory to be used by WebCore.
2196
2197 2015-08-27  Alex Christensen  <achristensen@webkit.org>
2198
2199         [Win CMake] Fix incremental build after r188673
2200         https://bugs.webkit.org/show_bug.cgi?id=148539
2201
2202         Reviewed by Brent Fulgham.
2203
2204         * PlatformWin.cmake:
2205         Use xcopy as a build step instead of file(COPY ...) to copy updated headers.
2206
2207 2015-08-27  Jon Davis  <jond@apple.com>
2208
2209         Include ES6 Generators and Proxy object status to feature status page.
2210         https://bugs.webkit.org/show_bug.cgi?id=148095
2211
2212         Reviewed by Timothy Hatcher.
2213
2214         * features.json:
2215
2216 2015-08-27  Filip Pizlo  <fpizlo@apple.com>
2217
2218         Unreviewed, add a comment to describe something I learned about a confusingly-named function.
2219
2220         * dfg/DFGUseKind.h:
2221         (JSC::DFG::isCell):
2222
2223 2015-08-27  Basile Clement  <basile_clement@apple.com>
2224
2225         REGRESSION(r184779): Possible read-after-free in JavaScriptCore/dfg/DFGClobberize.h
2226         https://bugs.webkit.org/show_bug.cgi?id=148411
2227
2228         Reviewed by Geoffrey Garen and Filip Pizlo.
2229
2230         * dfg/DFGClobberize.h:
2231         (JSC::DFG::clobberize):
2232
2233 2015-08-27  Brian Burg  <bburg@apple.com>
2234
2235         Web Inspector: FrontendChannel should know its own connection type
2236         https://bugs.webkit.org/show_bug.cgi?id=148482
2237
2238         Reviewed by Joseph Pecoraro.
2239
2240         * inspector/InspectorFrontendChannel.h: Add connectionType().
2241         * inspector/remote/RemoteInspectorDebuggableConnection.h:
2242
2243 2015-08-26  Filip Pizlo  <fpizlo@apple.com>
2244
2245         Node::origin should always be set, and the dead zone due to SSA Phis can just use exitOK=false
2246         https://bugs.webkit.org/show_bug.cgi?id=148462
2247
2248         Reviewed by Saam Barati.
2249
2250         The need to label nodes that absolutely cannot exit was first observed when we introduced SSA form.
2251         We indicated this by not setting the CodeOrigin.
2252
2253         But just recently (http://trac.webkit.org/changeset/188979), we added a more comprehensive "exitOK"
2254         bit in NodeOrigin. After that change, there were two ways of indicating that you cannot exit:
2255         !exitOK and an unset NodeOrigin. An unset NodeOrigin implied !exitOK.
2256
2257         Now, this change is about removing the old way so that we only use !exitOK. From now on, all nodes
2258         must have their NodeOrigin set, and the IR validation will check this. This means that I could
2259         remove various pieces of cruft for dealing with unset NodeOrigins, but I did have to add some new
2260         cruft to ensure that all nodes we create have a NodeOrigin.
2261
2262         This change simplifies our IR by having a simpler rule about when NodeOrigin is set: it's always
2263         set.
2264
2265         * dfg/DFGBasicBlock.cpp:
2266         (JSC::DFG::BasicBlock::isInBlock):
2267         (JSC::DFG::BasicBlock::removePredecessor):
2268         (JSC::DFG::BasicBlock::firstOriginNode): Deleted.
2269         (JSC::DFG::BasicBlock::firstOrigin): Deleted.
2270         * dfg/DFGBasicBlock.h:
2271         (JSC::DFG::BasicBlock::begin):
2272         (JSC::DFG::BasicBlock::end):
2273         (JSC::DFG::BasicBlock::numSuccessors):
2274         (JSC::DFG::BasicBlock::successor):
2275         * dfg/DFGCombinedLiveness.cpp:
2276         (JSC::DFG::liveNodesAtHead):
2277         * dfg/DFGConstantHoistingPhase.cpp:
2278         * dfg/DFGCriticalEdgeBreakingPhase.cpp:
2279         (JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
2280         * dfg/DFGForAllKills.h:
2281         (JSC::DFG::forAllKilledOperands):
2282         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2283         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
2284         (JSC::DFG::createPreHeader):
2285         (JSC::DFG::LoopPreHeaderCreationPhase::run):
2286         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
2287         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
2288         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2289         * dfg/DFGPutStackSinkingPhase.cpp:
2290         * dfg/DFGSSAConversionPhase.cpp:
2291         (JSC::DFG::SSAConversionPhase::run):
2292         * dfg/DFGValidate.cpp:
2293         (JSC::DFG::Validate::validate):
2294         (JSC::DFG::Validate::validateSSA):
2295
2296 2015-08-26  Saam barati  <sbarati@apple.com>
2297
2298         MarkedBlock::allocateBlock will have the wrong allocation size when (sizeof(MarkedBlock) + bytes) is divisible by WTF::pageSize()
2299         https://bugs.webkit.org/show_bug.cgi?id=148500
2300
2301         Reviewed by Mark Lam.
2302
2303         Consider the following scenario:
2304         - On OS X, WTF::pageSize() is 4*1024 bytes.
2305         - JSEnvironmentRecord::allocationSizeForScopeSize(6621) == 53000
2306         - sizeof(MarkedBlock) == 248
2307         - (248 + 53000) is a multiple of 4*1024.
2308         - (248 + 53000)/(4*1024) == 13
2309
2310         We will allocate a chunk of memory of size 53248 bytes that looks like this:
2311         0            248       256                       53248       53256
2312         [Marked Block | 8 bytes |  payload     ......      ]  8 bytes  |
2313                                 ^                                      ^
2314                            Our Environment record starts here.         ^
2315                                                                        ^
2316                                                                  Our last JSValue in the environment record will go from byte 53248 to 53256. But, we don't own this memory.
2317
2318         We need to ensure that we round up sizeof(MarkedBlock) to an
2319         atomSize boundary. We need to do this because the first atom
2320         inside the MarkedBlock will start at the rounded up multiple
2321         of atomSize past MarkedBlock. If we end up with an allocation
2322         that is perfectly aligned to the page size, then we will be short
2323         8 bytes (in the current implementation where atomSize is 16 bytes,
2324         and MarkedBlock is 248 bytes).
2325
2326         * heap/MarkedAllocator.cpp:
2327         (JSC::MarkedAllocator::allocateBlock):
2328         * tests/stress/heap-allocator-allocates-incorrect-size-for-activation.js: Added.
2329         (use):
2330         (makeFunction):
2331
2332 2015-08-26  Mark Lam  <mark.lam@apple.com>
2333
2334         watchdog m_didFire state erroneously retained.
2335         https://bugs.webkit.org/show_bug.cgi?id=131082
2336
2337         Reviewed by Geoffrey Garen.
2338
2339         The watchdog can fire for 2 reasons:
2340         1. an external controlling entity (i.e. another thread) has scheduled termination
2341            of the script thread via watchdog::terminateSoon().
2342         2. the allowed CPU time has expired.
2343
2344         For case 1, we're doing away with the m_didFire flag.  Watchdog::terminateSoon() 
2345         will set the timer deadlines and m_timeLimit to 0, and m_timerDidFire to true.
2346         This will get the script thread to check Watchdog::didFire() and terminate
2347         execution.
2348
2349         Note: the watchdog only guarantees that script execution will terminate as soon
2350         as possible due to a time limit of 0.  Once we've exited the VM, the client of the
2351         VM is responsible from keeping a flag to prevent new script execution.
2352
2353         In a race condition, if terminateSoon() is called just after execution has gotten
2354         past the client's reentry check and the client is in the process of re-entering,
2355         the worst that can happen is that we will schedule the watchdog timer to fire
2356         after a period of 0.  This will terminate script execution quickly, and thereafter
2357         the client's check should be able to prevent further entry into the VM.
2358
2359         The correctness (i.e. has no race condition) of this type of termination relies
2360         on the termination state being sticky.  Once the script thread is terminated this
2361         way, the VM will continue to terminate scripts quickly until the client sets the
2362         time limit to a non-zero value (or clears it which sets the time limit to
2363         noTimeLimit).
2364
2365         For case 2, the watchdog does not alter m_timeLimit.  If the CPU deadline has
2366         been reached, the script thread will terminate execution and exit the VM.
2367
2368         If the client of the VM starts new script execution, the watchdog will allow
2369         execution for the specified m_timeLimit.  In this case, since m_timeLimit is not
2370         0, the script gets a fresh allowance of CPU time to execute.  Hence, terminations
2371         due to watchdog time outs are no longer sticky.
2372
2373         * API/JSContextRef.cpp:
2374         (JSContextGroupSetExecutionTimeLimit):
2375         (JSContextGroupClearExecutionTimeLimit):
2376         * API/tests/ExecutionTimeLimitTest.cpp:
2377         - Add test scenarios to verify that the watchdog is automatically reset by the VM
2378           upon throwing the TerminatedExecutionException.
2379
2380         (testResetAfterTimeout):
2381         (testExecutionTimeLimit):
2382         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2383         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2384         * JavaScriptCore.xcodeproj/project.pbxproj:
2385         * dfg/DFGByteCodeParser.cpp:
2386         (JSC::DFG::ByteCodeParser::parseBlock):
2387         * interpreter/Interpreter.cpp:
2388         (JSC::Interpreter::execute):
2389         (JSC::Interpreter::executeCall):
2390         (JSC::Interpreter::executeConstruct):
2391         * jit/JITOpcodes.cpp:
2392         (JSC::JIT::emit_op_loop_hint):
2393         (JSC::JIT::emitSlow_op_loop_hint):
2394         * jit/JITOperations.cpp:
2395         * llint/LLIntSlowPaths.cpp:
2396         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2397         * runtime/VM.cpp:
2398         (JSC::VM::VM):
2399         (JSC::VM::ensureWatchdog):
2400         * runtime/VM.h:
2401         * runtime/VMInlines.h: Added.
2402         (JSC::VM::shouldTriggerTermination):
2403         * runtime/Watchdog.cpp:
2404         (JSC::Watchdog::Watchdog):
2405         (JSC::Watchdog::setTimeLimit):
2406         (JSC::Watchdog::terminateSoon):
2407         (JSC::Watchdog::didFireSlow):
2408         (JSC::Watchdog::hasTimeLimit):
2409         (JSC::Watchdog::enteredVM):
2410         (JSC::Watchdog::exitedVM):
2411         (JSC::Watchdog::startTimer):
2412         (JSC::Watchdog::stopTimer):
2413         (JSC::Watchdog::hasStartedTimer): Deleted.
2414         (JSC::Watchdog::fire): Deleted.
2415         * runtime/Watchdog.h:
2416         (JSC::Watchdog::didFire):
2417         (JSC::Watchdog::timerDidFireAddress):
2418
2419 2015-08-26  Joseph Pecoraro  <pecoraro@apple.com>
2420
2421         Web Inspector: Implement tracking of active stylesheets in the frontend
2422         https://bugs.webkit.org/show_bug.cgi?id=105828
2423
2424         Reviewed by Timothy Hatcher.
2425
2426         * inspector/protocol/CSS.json:
2427         Add new events for when a StyleSheet is added or removed.
2428
2429 2015-08-26  Chris Dumez  <cdumez@apple.com>
2430
2431         Distinguish Web IDL callback interfaces from Web IDL callback functions
2432         https://bugs.webkit.org/show_bug.cgi?id=148434
2433
2434         Reviewed by Geoffrey Garen.
2435
2436         Add isNull() convenience method on PropertyName.
2437
2438         * runtime/PropertyName.h:
2439         (JSC::PropertyName::isNull):
2440
2441 2015-08-26  Filip Pizlo  <fpizlo@apple.com>
2442
2443         Node::origin should be able to tell you if it's OK to exit
2444         https://bugs.webkit.org/show_bug.cgi?id=145204
2445
2446         Reviewed by Geoffrey Garen.
2447
2448         This is a major change to DFG IR, that makes it easier to reason about where nodes with
2449         speculations can be soundly hoisted.
2450
2451         A program in DFG IR is a sequence of operations that compute the values of SSA variables,
2452         perform effects on the heap or stack, and perform updates to the OSR exit state. Because
2453         effects and OSR exit updates are interleaved, there are points in execution where exiting
2454         simply won't work. For example, we may have some bytecode operation:
2455
2456             [  24] op_foo loc42 // does something, and puts a value in loc42.
2457
2458         that gets compiled down to a sequence of DFG IR nodes like:
2459
2460             a: Foo(W:Heap, R:World, bc#24) // writes heap, reads world - i.e. an observable effect.
2461             b: MovHint(@a, loc42, bc#24)
2462             c: SetLocal(Check:Int32:@a, loc42, bc#24, exit: bc#26)
2463
2464         Note that we can OSR exit at @a because we haven't yet performed any effects for bc#24 yet and
2465         we have performed all effects for prior bytecode operations. That's what the origin.forExit
2466         being set to "bc#24" guarantees. So, an OSR exit at @a would transfer execution to bc#24 and
2467         this would not be observable. But at @b, if we try to exit to bc#24 as indicated by forExit, we
2468         would end up causing the side effect of bc#24 to execute a second time. This would be
2469         observable, so we cannot do it. And we cannot exit to the next instruction - bc#26 - either,
2470         because @b is responsible for updating the OSR state to indicate that the result of @a should
2471         be put into loc42. It's not until we get to @c that we can exit again.
2472
2473         This is a confusing, but useful, property of DFG IR. It's useful because it allows us to use IR
2474         to spell out how we would have affected the bytecode state, and we use this to implement hard
2475         things like object allocation elimination, where we use IR instructions to indicate what object
2476         allocation and mutation operations we would have performed, and which bytecode variables would
2477         have pointed to those objects. So long as IR allows us to describe how OSR exit state is
2478         updated, there will be points in execution where that state is invalid - especially if the IR
2479         to update exit state is separate from the IR to perform actual effects.
2480
2481         But this property is super confusing! It's difficult to explain that somehow magically, @b is a
2482         bad place to put OSR exits, and that magically we will only have OSR exits at @a. Of course, it
2483         all kind of makes sense - we insert OSR exit checks in phases that *know* where it's safe to
2484         exit - but it's just too opaque. This also gets in the way of more sophisticated
2485         transformations. For example, LICM barely works - it magically knows that loop pre-headers are
2486         good places to exit from, but it has no way of determining if that is actually true. It would
2487         be odd to introduce a restriction that anytime some block qualifies as a pre-header according
2488         to our loop calculator, it must end with a terminal at which it is OK to exit. So, our choices
2489         are to either leave LICM in a magical state and exercise extreme caution when introducing new
2490         optimizations that hoist checks, or to do something to make the "can I exit here" property more
2491         explicit in IR.
2492
2493         We have already, in a separate change, added a NodeOrigin::exitOK property, though it didn't do
2494         anything yet. This change puts exitOK to work, and makes it an integral part of IR. The key
2495         intuition behind this change is that if we know which nodes clobber exit state - i.e. after the
2496         node, it's no longer possible to OSR exit until the exit state is fixed up - then we can figure
2497         out where it's fine to exit. This change mostly adopts the already implicit rule that it's
2498         always safe to exit right at the boundary of exit origins (in between two nodes where
2499         origin.forExit differs), and adds a new node, called ExitOK, which is a kind of declaration
2500         that exit state is good again. When making this change, I struggled with the question of
2501         whether to make origin.exitOK be explicit, or something that we can compute with an analysis.
2502         Of course if we are armed with a clobbersExitState(Node*) function, we can find the places
2503         where it's fine to exit. But this kind of computation could get quite sophisticated if the
2504         nodes belonging to an exit origin are lowered to a control-flow construct. It would also be
2505         harder to see what the original intent was, if we found an error: is the bug that we shouldn't
2506         be clobbering exit state, or that we shouldn't be exiting? This change opts to make exitOK be
2507         an explicit property of IR, so that DFG IR validation will reject any program where exitOK is
2508         true after a node that clobbersExitState(), or if exitOK is true after a node has exitOK set to
2509         false - unless the latter node has a different exit origin or is an ExitOK node. It will also
2510         reject any program where a node mayExit() with !exitOK.
2511
2512         It turns out that this revealed a lot of sloppiness and what almost looked like an outright
2513         bug: the callee property of an inline closure call frame was being set up "as if" by the
2514         callee's op_enter. If we did hoist a check per the old rule - to the boundary of exit origins -
2515         then we would crash because the callee is unknown. It also revealed that LICM could *almost*
2516         get hosed by having a pre-header where there are effects before the jump. I wasn't able to
2517         construct a test case that would crash trunk, but I also couldn't quite prove why such a
2518         program couldn't be constructed. I did fix the issue in loop pre-header creation, and the
2519         validater does catch the issue because of its exitOK assertions.
2520
2521         This doesn't yet add any other safeguards to LICM - that phase still expects that pre-headers
2522         are in place and that they were created in such a way that their terminal origins have exitOK.
2523         It also still keeps the old way of saying "not OK to exit" - having a clear NodeOrigin. In a
2524         later patch I'll remove that and use !exitOK everywhere. Note that I did consider using clear
2525         NodeOrigins to signify that it's not OK to exit, but that would make DFGForAllKills a lot more
2526         expensive - it would have to sometimes search to find nearby forExit origins if the current
2527         node doesn't have it set - and that's a critical phase for DFG compilation performance.
2528         Requiring that forExit is usually set to *something* and that properly shadows the original
2529         bytecode is cheap and easy, so it seemed like a good trade-off.
2530
2531         This change has no performance effect. Its only effect is that it makes the compiler easier to
2532         understand by turning a previously magical concept into an explicit one.
2533
2534         * CMakeLists.txt:
2535         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2536         * JavaScriptCore.xcodeproj/project.pbxproj:
2537         * dfg/DFGAbstractHeap.h:
2538         * dfg/DFGAbstractInterpreterInlines.h:
2539         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2540         * dfg/DFGArgumentsEliminationPhase.cpp:
2541         * dfg/DFGByteCodeParser.cpp:
2542         (JSC::DFG::ByteCodeParser::setDirect):
2543         (JSC::DFG::ByteCodeParser::currentNodeOrigin):
2544         (JSC::DFG::ByteCodeParser::branchData):
2545         (JSC::DFG::ByteCodeParser::addToGraph):
2546         (JSC::DFG::ByteCodeParser::handleCall):
2547         (JSC::DFG::ByteCodeParser::inlineCall):
2548         (JSC::DFG::ByteCodeParser::handleInlining):
2549         (JSC::DFG::ByteCodeParser::handleGetById):
2550         (JSC::DFG::ByteCodeParser::handlePutById):
2551         (JSC::DFG::ByteCodeParser::parseBlock):
2552         * dfg/DFGCFGSimplificationPhase.cpp:
2553         (JSC::DFG::CFGSimplificationPhase::run):
2554         * dfg/DFGClobberize.h:
2555         (JSC::DFG::clobberize):
2556         * dfg/DFGClobbersExitState.cpp: Added.
2557         (JSC::DFG::clobbersExitState):
2558         * dfg/DFGClobbersExitState.h: Added.
2559         * dfg/DFGConstantFoldingPhase.cpp:
2560         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
2561         * dfg/DFGDoesGC.cpp:
2562         (JSC::DFG::doesGC):
2563         * dfg/DFGFixupPhase.cpp:
2564         (JSC::DFG::FixupPhase::fixupNode):
2565         (JSC::DFG::FixupPhase::convertStringAddUse):
2566         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
2567         (JSC::DFG::FixupPhase::fixupGetAndSetLocalsInBlock):
2568         (JSC::DFG::FixupPhase::fixupChecksInBlock):
2569         * dfg/DFGFlushFormat.h:
2570         (JSC::DFG::useKindFor):
2571         (JSC::DFG::uncheckedUseKindFor):
2572         (JSC::DFG::typeFilterFor):
2573         * dfg/DFGGraph.cpp:
2574         (JSC::DFG::printWhiteSpace):
2575         (JSC::DFG::Graph::dumpCodeOrigin):
2576         (JSC::DFG::Graph::dump):
2577         * dfg/DFGGraph.h:
2578         (JSC::DFG::Graph::addSpeculationMode):
2579         * dfg/DFGInsertionSet.cpp:
2580         (JSC::DFG::InsertionSet::insertSlow):
2581         (JSC::DFG::InsertionSet::execute):
2582         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
2583         (JSC::DFG::LoopPreHeaderCreationPhase::run):
2584         * dfg/DFGMayExit.cpp:
2585         (JSC::DFG::mayExit):
2586         (WTF::printInternal):
2587         * dfg/DFGMayExit.h:
2588         * dfg/DFGMovHintRemovalPhase.cpp:
2589         * dfg/DFGNodeOrigin.cpp: Added.
2590         (JSC::DFG::NodeOrigin::dump):
2591         * dfg/DFGNodeOrigin.h:
2592         (JSC::DFG::NodeOrigin::NodeOrigin):
2593         (JSC::DFG::NodeOrigin::isSet):
2594         (JSC::DFG::NodeOrigin::withSemantic):
2595         (JSC::DFG::NodeOrigin::withExitOK):
2596         (JSC::DFG::NodeOrigin::withInvalidExit):
2597         (JSC::DFG::NodeOrigin::takeValidExit):
2598         (JSC::DFG::NodeOrigin::forInsertingAfter):
2599         (JSC::DFG::NodeOrigin::operator==):
2600         (JSC::DFG::NodeOrigin::operator!=):
2601         * dfg/DFGNodeType.h:
2602         * dfg/DFGOSREntrypointCreationPhase.cpp:
2603         (JSC::DFG::OSREntrypointCreationPhase::run):
2604         * dfg/DFGOSRExit.cpp:
2605         (JSC::DFG::OSRExit::OSRExit):
2606         (JSC::DFG::OSRExit::setPatchableCodeOffset):
2607         * dfg/DFGOSRExitBase.h:
2608         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2609         * dfg/DFGPhantomInsertionPhase.cpp:
2610         * dfg/DFGPhase.cpp:
2611         (JSC::DFG::Phase::validate):
2612         (JSC::DFG::Phase::beginPhase):
2613         (JSC::DFG::Phase::endPhase):
2614         * dfg/DFGPhase.h:
2615         (JSC::DFG::Phase::vm):
2616         (JSC::DFG::Phase::codeBlock):
2617         (JSC::DFG::Phase::profiledBlock):
2618         * dfg/DFGPredictionPropagationPhase.cpp:
2619         (JSC::DFG::PredictionPropagationPhase::propagate):
2620         * dfg/DFGPutStackSinkingPhase.cpp:
2621         * dfg/DFGSSAConversionPhase.cpp:
2622         (JSC::DFG::SSAConversionPhase::run):
2623         * dfg/DFGSafeToExecute.h:
2624         (JSC::DFG::safeToExecute):
2625         * dfg/DFGSpeculativeJIT.cpp:
2626         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
2627         (JSC::DFG::SpeculativeJIT::speculationCheck):
2628         (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
2629         (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
2630         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2631         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
2632         (JSC::DFG::SpeculativeJIT::compile):
2633         * dfg/DFGSpeculativeJIT.h:
2634         * dfg/DFGSpeculativeJIT32_64.cpp:
2635         (JSC::DFG::SpeculativeJIT::compile):
2636         * dfg/DFGSpeculativeJIT64.cpp:
2637         (JSC::DFG::SpeculativeJIT::compile):
2638         * dfg/DFGStoreBarrierInsertionPhase.cpp:
2639         * dfg/DFGTypeCheckHoistingPhase.cpp:
2640         (JSC::DFG::TypeCheckHoistingPhase::run):
2641         * dfg/DFGValidate.cpp:
2642         (JSC::DFG::Validate::validate):
2643         * ftl/FTLCapabilities.cpp:
2644         (JSC::FTL::canCompile):
2645         * ftl/FTLLowerDFGToLLVM.cpp:
2646         (JSC::FTL::DFG::LowerDFGToLLVM::lower):
2647         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
2648         (JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon):
2649         (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
2650         (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
2651
2652 2015-08-26  Andreas Kling  <akling@apple.com>
2653
2654         [JSC] StructureTransitionTable should eagerly deallocate single-transition WeakImpls.
2655         <https://webkit.org/b/148478>
2656
2657         Reviewed by Geoffrey Garen.
2658
2659         Use a WeakHandleOwner to eagerly deallocate StructureTransitionTable's Weak pointers
2660         when it's using the single-transition optimization and the Structure it transitioned
2661         to has been GC'd.
2662
2663         This prevents Structures from keeping WeakBlocks alive longer than necessary when
2664         they've been transitioned away from but are still in use themselves.
2665
2666         * runtime/Structure.cpp:
2667         (JSC::singleSlotTransitionWeakOwner):
2668         (JSC::StructureTransitionTable::singleTransition):
2669         (JSC::StructureTransitionTable::setSingleTransition):
2670         (JSC::StructureTransitionTable::add):
2671         * runtime/StructureTransitionTable.h:
2672         (JSC::StructureTransitionTable::singleTransition): Deleted.
2673         (JSC::StructureTransitionTable::setSingleTransition): Deleted.
2674
2675 2015-08-26  Brian Burg  <bburg@apple.com>
2676
2677         Web Inspector: REGRESSION(r188965): BackendDispatcher loses request ids when called re-entrantly
2678         https://bugs.webkit.org/show_bug.cgi?id=148480
2679
2680         Reviewed by Joseph Pecoraro.
2681
2682         I added an assertion that m_currentRequestId is Nullopt when dispatch() is called, but this should
2683         not hold if dispatching a backend command while debugger is paused. I will remove the assertion
2684         and add proper scoping for all dispatch() branches.
2685
2686         No new tests, this wrong assert caused inspector/dom-debugger/node-removed.html to crash reliably.
2687
2688         * inspector/InspectorBackendDispatcher.cpp:
2689         (Inspector::BackendDispatcher::dispatch): Cover each exit with an appropriate TemporaryChange scope.
2690
2691 2015-08-26  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2692
2693         Remove the unused *Executable::unlinkCalls() and CodeBlock::unlinkCalls()
2694         https://bugs.webkit.org/show_bug.cgi?id=148469
2695
2696         Reviewed by Geoffrey Garen.
2697
2698         We use CodeBlock::unlinkIncomingCalls() to unlink calls.
2699         (...)Executable::unlinkCalls() and CodeBlock::unlinkCalls() are no longer used.
2700
2701         * bytecode/CodeBlock.cpp:
2702         (JSC::CodeBlock::unlinkCalls): Deleted.
2703         * bytecode/CodeBlock.h:
2704         * runtime/Executable.cpp:
2705         (JSC::EvalExecutable::unlinkCalls): Deleted.
2706         (JSC::ProgramExecutable::unlinkCalls): Deleted.
2707         (JSC::FunctionExecutable::unlinkCalls): Deleted.
2708         * runtime/Executable.h:
2709         (JSC::ScriptExecutable::unlinkCalls): Deleted.
2710
2711 2015-08-25  Brian Burg  <bburg@apple.com>
2712
2713         Web Inspector: no need to allocate protocolErrors array for every dispatched backend command
2714         https://bugs.webkit.org/show_bug.cgi?id=146466
2715
2716         Reviewed by Joseph Pecoraro.
2717
2718         Clean up some of the backend dispatcher code, with a focus on eliminating useless allocations
2719         of objects in the common case when no protocol errors happen. This is done by saving the
2720         current id of each request as it is being processed by the backend dispatcher, and tagging any
2721         subsequent errors with that id. This also means we don't have to thread the requestId except
2722         in the async command code path.
2723
2724         This patch also lifts some common code shared between all generated backend command
2725         implementatations into the per-domain dispatch method instead. This reduces generated code size.
2726
2727         To be consistent, this patch standardizes on calling the id of a backend message its 'requestId'.
2728         Requests can be handled synchronously or asynchronously (triggered via the 'async' property).
2729
2730         No new tests, covered by existing protocol tests.
2731
2732         * inspector/InspectorBackendDispatcher.cpp:
2733         (Inspector::BackendDispatcher::CallbackBase::CallbackBase): Split the two code paths for reporting
2734         success and failure.
2735
2736         (Inspector::BackendDispatcher::CallbackBase::sendFailure):
2737         (Inspector::BackendDispatcher::CallbackBase::sendSuccess): Renamed from sendIfActive.
2738         (Inspector::BackendDispatcher::dispatch): Reset counters and current requestId before dispatching.
2739         No need to manually thread the requestId to all reportProtocolError calls.
2740
2741         (Inspector::BackendDispatcher::hasProtocolErrors): Added.
2742         (Inspector::BackendDispatcher::sendResponse):
2743         (Inspector::BackendDispatcher::sendPendingErrors): Send any saved protocol errors to the frontend.
2744         Always send a 'data' member with all of the errors, even if there's just one. We might want to add
2745         more information about errors later.
2746
2747         (Inspector::BackendDispatcher::reportProtocolError): Enqueue a protocol error to be sent later.
2748         (Inspector::BackendDispatcher::getPropertyValue): Remove useless type parameters and nuke most of
2749         the type conversion methods. Use std::function types instead of function pointer types.
2750
2751         (Inspector::castToInteger): Added.
2752         (Inspector::castToNumber): Added.
2753         (Inspector::BackendDispatcher::getInteger):
2754         (Inspector::BackendDispatcher::getDouble):
2755         (Inspector::BackendDispatcher::getString):
2756         (Inspector::BackendDispatcher::getBoolean):
2757         (Inspector::BackendDispatcher::getObject):
2758         (Inspector::BackendDispatcher::getArray):
2759         (Inspector::BackendDispatcher::getValue):
2760         (Inspector::getPropertyValue): Deleted.
2761         (Inspector::AsMethodBridges::asInteger): Deleted.
2762         (Inspector::AsMethodBridges::asDouble): Deleted.
2763         (Inspector::AsMethodBridges::asString): Deleted.
2764         (Inspector::AsMethodBridges::asBoolean): Deleted.
2765         (Inspector::AsMethodBridges::asObject): Deleted.
2766         (Inspector::AsMethodBridges::asArray): Deleted.
2767         (Inspector::AsMethodBridges::asValue): Deleted.
2768         * inspector/InspectorBackendDispatcher.h:
2769         * inspector/scripts/codegen/cpp_generator_templates.py: Extract 'params' object in domain dispatch method.
2770         Omit requestIds where possible. Convert dispatch tables to use NeverDestroyed. Check the protocol error count
2771         to decide whether to abort the dispatch or not, rather than allocating our own errors array.
2772
2773         * inspector/scripts/codegen/cpp_generator_templates.py:
2774         (void):
2775         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: Revert to passing RefPtr<InspectorObject>
2776         since parameters are now being passed rather than the message object. Some commands do not require parameters.
2777         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
2778         (CppBackendDispatcherImplementationGenerator.generate_output):
2779         (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
2780         (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
2781         * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
2782         (ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declaration_for_command):
2783         * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
2784         (ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_command):
2785         (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
2786         * inspector/scripts/codegen/objc_generator_templates.py:
2787
2788         Rebaseline some protocol generator tests.
2789         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2790         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2791         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
2792         * inspector/scripts/tests/expected/enum-values.json-result:
2793         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2794         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2795         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
2796         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2797         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
2798         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
2799         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
2800         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2801         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2802
2803 2015-08-25  Saam barati  <sbarati@apple.com>
2804
2805         Lets rename codeOriginIndex to callSiteIndex and get rid of CallFrame::Location.
2806         https://bugs.webkit.org/show_bug.cgi?id=148213
2807
2808         Reviewed by Filip Pizlo.
2809
2810         This patch introduces a struct called CallSiteIndex which is
2811         used as a wrapper for a 32-bit int to place things in the tag for ArgumentCount 
2812         in the call frame. On 32-bit we place Instruction* into this slot for LLInt and Basline.
2813         For 32-bit DFG we place a an index into the code origin table in this slot.
2814         On 64-bit we place a bytecode offset into this slot for LLInt and Baseline.
2815         On 64-bit we place the index into the code origin table in this slot in the
2816         DFG/FTL.
2817
2818         This patch also gets rid of the encoding scheme that describes if something is a
2819         bytecode index or a code origin table index. This information can always
2820         be determined based on the CodeBlock's' JITType.
2821
2822         StructureStubInfo now also has a CallSiteIndex which it stores to
2823         the call frame when making a call.
2824
2825         * bytecode/CodeBlock.h:
2826         (JSC::CodeBlock::hasCodeOrigins):
2827         (JSC::CodeBlock::canGetCodeOrigin):
2828         (JSC::CodeBlock::codeOrigin):
2829         (JSC::CodeBlock::addFrequentExitSite):
2830         * bytecode/StructureStubInfo.h:
2831         (JSC::StructureStubInfo::StructureStubInfo):
2832         * dfg/DFGCommonData.cpp:
2833         (JSC::DFG::CommonData::notifyCompilingStructureTransition):
2834         (JSC::DFG::CommonData::addCodeOrigin):
2835         (JSC::DFG::CommonData::shrinkToFit):
2836         * dfg/DFGCommonData.h:
2837         (JSC::DFG::CommonData::CommonData):
2838         * dfg/DFGJITCompiler.h:
2839         (JSC::DFG::JITCompiler::setEndOfCode):
2840         (JSC::DFG::JITCompiler::addCallSite):
2841         (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
2842         * dfg/DFGOSRExitCompilerCommon.cpp:
2843         (JSC::DFG::reifyInlinedCallFrames):
2844         * dfg/DFGSpeculativeJIT.cpp:
2845         (JSC::DFG::SpeculativeJIT::compileIn):
2846         * dfg/DFGSpeculativeJIT32_64.cpp:
2847         (JSC::DFG::SpeculativeJIT::cachedGetById):
2848         (JSC::DFG::SpeculativeJIT::cachedPutById):
2849         * dfg/DFGSpeculativeJIT64.cpp:
2850         (JSC::DFG::SpeculativeJIT::cachedGetById):
2851         (JSC::DFG::SpeculativeJIT::cachedPutById):
2852         * ftl/FTLCompile.cpp:
2853         (JSC::FTL::mmAllocateDataSection):
2854         * ftl/FTLInlineCacheDescriptor.h:
2855         (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
2856         (JSC::FTL::InlineCacheDescriptor::stackmapID):
2857         (JSC::FTL::InlineCacheDescriptor::callSiteIndex):
2858         (JSC::FTL::InlineCacheDescriptor::uid):
2859         (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
2860         (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
2861         (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
2862         (JSC::FTL::InlineCacheDescriptor::codeOrigin): Deleted.
2863         * ftl/FTLLink.cpp:
2864         (JSC::FTL::link):
2865         * ftl/FTLLowerDFGToLLVM.cpp:
2866         (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
2867         (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
2868         (JSC::FTL::DFG::LowerDFGToLLVM::getById):
2869         (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
2870         * ftl/FTLSlowPathCall.cpp:
2871         (JSC::FTL::storeCodeOrigin):
2872         * interpreter/CallFrame.cpp:
2873         (JSC::CallFrame::currentVPC):
2874         (JSC::CallFrame::setCurrentVPC):
2875         (JSC::CallFrame::callSiteBitsAsBytecodeOffset):
2876         (JSC::CallFrame::bytecodeOffset):
2877         (JSC::CallFrame::codeOrigin):
2878         (JSC::CallFrame::topOfFrameInternal):
2879         (JSC::CallFrame::locationAsBytecodeOffset): Deleted.
2880         (JSC::CallFrame::setLocationAsBytecodeOffset): Deleted.
2881         (JSC::CallFrame::bytecodeOffsetFromCodeOriginIndex): Deleted.
2882         * interpreter/CallFrame.h:
2883         (JSC::CallSiteIndex::CallSiteIndex):
2884         (JSC::CallSiteIndex::bits):
2885         (JSC::ExecState::returnPCOffset):
2886         (JSC::ExecState::abstractReturnPC):
2887         (JSC::ExecState::topOfFrame):
2888         (JSC::ExecState::setCallerFrame):
2889         (JSC::ExecState::setScope):
2890         (JSC::ExecState::currentVPC): Deleted.
2891         (JSC::ExecState::setCurrentVPC): Deleted.
2892         * interpreter/CallFrameInlines.h:
2893         (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
2894         (JSC::CallFrame::callSiteBitsAreCodeOriginIndex):
2895         (JSC::CallFrame::callSiteAsRawBits):
2896         (JSC::CallFrame::callSiteIndex):
2897         (JSC::CallFrame::hasActivation):
2898         (JSC::CallFrame::Location::encode): Deleted.
2899         (JSC::CallFrame::Location::decode): Deleted.
2900         (JSC::CallFrame::Location::encodeAsBytecodeOffset): Deleted.
2901         (JSC::CallFrame::Location::encodeAsBytecodeInstruction): Deleted.
2902         (JSC::CallFrame::Location::encodeAsCodeOriginIndex): Deleted.
2903         (JSC::CallFrame::Location::isBytecodeLocation): Deleted.
2904         (JSC::CallFrame::Location::isCodeOriginIndex): Deleted.
2905         (JSC::CallFrame::hasLocationAsBytecodeOffset): Deleted.
2906         (JSC::CallFrame::hasLocationAsCodeOriginIndex): Deleted.
2907         (JSC::CallFrame::locationAsRawBits): Deleted.
2908         (JSC::CallFrame::setLocationAsRawBits): Deleted.
2909         (JSC::CallFrame::locationAsBytecodeOffset): Deleted.
2910         (JSC::CallFrame::setLocationAsBytecodeOffset): Deleted.
2911         (JSC::CallFrame::locationAsCodeOriginIndex): Deleted.
2912         * interpreter/StackVisitor.cpp:
2913         (JSC::StackVisitor::readFrame):
2914         (JSC::StackVisitor::readNonInlinedFrame):
2915         (JSC::StackVisitor::Frame::print):
2916         * jit/JITCall.cpp:
2917         (JSC::JIT::compileOpCall):
2918         * jit/JITCall32_64.cpp:
2919         (JSC::JIT::compileOpCall):
2920         * jit/JITInlineCacheGenerator.cpp:
2921         (JSC::garbageStubInfo):
2922         (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
2923         (JSC::JITByIdGenerator::JITByIdGenerator):
2924         (JSC::JITByIdGenerator::generateFastPathChecks):
2925         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2926         (JSC::JITGetByIdGenerator::generateFastPath):
2927         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
2928         * jit/JITInlineCacheGenerator.h:
2929         (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
2930         (JSC::JITInlineCacheGenerator::stubInfo):
2931         (JSC::JITByIdGenerator::JITByIdGenerator):
2932         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2933         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
2934         * jit/JITInlines.h:
2935         (JSC::JIT::updateTopCallFrame):
2936         * jit/JITOperations.cpp:
2937         (JSC::getByVal):
2938         (JSC::tryGetByValOptimize):
2939         * jit/JITPropertyAccess.cpp:
2940         (JSC::JIT::emitGetByValWithCachedId):
2941         (JSC::JIT::emitPutByValWithCachedId):
2942         (JSC::JIT::emit_op_get_by_id):
2943         (JSC::JIT::emit_op_put_by_id):
2944         * jit/JITPropertyAccess32_64.cpp:
2945         (JSC::JIT::emitGetByValWithCachedId):
2946         (JSC::JIT::emitPutByValWithCachedId):
2947         (JSC::JIT::emit_op_get_by_id):
2948         (JSC::JIT::emit_op_put_by_id):
2949         * jit/Repatch.cpp:
2950         (JSC::generateByIdStub):
2951
2952 2015-08-25 Aleksandr Skachkov   <gskachkov@gmail.com>
2953
2954         Function.prototype.toString is incorrect for ArrowFunction
2955         https://bugs.webkit.org/show_bug.cgi?id=148148
2956
2957         Reviewed by Saam Barati.
2958         
2959         Added correct support of toString() method for arrow function.
2960
2961         * parser/ASTBuilder.h:
2962         (JSC::ASTBuilder::createFunctionMetadata):
2963         (JSC::ASTBuilder::createArrowFunctionExpr):
2964         * parser/Nodes.cpp:
2965         (JSC::FunctionMetadataNode::FunctionMetadataNode):
2966         * parser/Nodes.h:
2967         * parser/Parser.cpp:
2968         (JSC::Parser<LexerType>::parseFunctionBody):
2969         (JSC::Parser<LexerType>::parseFunctionInfo):
2970         * parser/SyntaxChecker.h:
2971         (JSC::SyntaxChecker::createFunctionMetadata):
2972         * runtime/FunctionPrototype.cpp:
2973         (JSC::functionProtoFuncToString):
2974         * tests/stress/arrowfunction-tostring.js: Added.
2975
2976 2015-08-25  Saam barati  <sbarati@apple.com>
2977
2978         Callee can be incorrectly overridden when it's captured
2979         https://bugs.webkit.org/show_bug.cgi?id=148400
2980
2981         Reviewed by Filip Pizlo.
2982
2983         We now resort to always creating the function name scope
2984         when the function name is in scope. Because the bytecode
2985         generator now has a notion of local lexical scoping,
2986         this incurs no runtime penalty for function expression names
2987         that aren't heap allocated. If they are heap allocated,
2988         this means we may now have one more scope on the runtime
2989         scope stack than before. This modification simplifies the
2990         callee initialization code and uses the lexical scoping constructs
2991         to implement this. This implementation also ensures
2992         that everything Just Works for function's with default
2993         parameter values. Before this patch, IIFE functions
2994         with default parameter values and a captured function
2995         name would crash JSC.
2996
2997         * bytecompiler/BytecodeGenerator.cpp:
2998         (JSC::BytecodeGenerator::BytecodeGenerator):
2999         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
3000         (JSC::BytecodeGenerator::popLexicalScopeInternal):
3001         (JSC::BytecodeGenerator::variable):
3002         (JSC::BytecodeGenerator::resolveType):
3003         (JSC::BytecodeGenerator::emitThrowTypeError):
3004         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
3005         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
3006         * bytecompiler/BytecodeGenerator.h:
3007         (JSC::Variable::isReadOnly):
3008         (JSC::Variable::isSpecial):
3009         (JSC::Variable::isConst):
3010         (JSC::Variable::setIsReadOnly):
3011         * bytecompiler/NodesCodegen.cpp:
3012         (JSC::PostfixNode::emitResolve):
3013         (JSC::PrefixNode::emitResolve):
3014         (JSC::ReadModifyResolveNode::emitBytecode):
3015         (JSC::AssignResolveNode::emitBytecode):
3016         (JSC::BindingNode::bindValue):
3017         * tests/stress/IIFE-es6-default-parameters.js: Added.
3018         (assert):
3019         (.):
3020         * tests/stress/IIFE-function-name-captured.js: Added.
3021         (assert):
3022         (.):
3023
3024 2015-08-24  Brian Burg  <bburg@apple.com>
3025
3026         Web Inspector: add protocol test for existing error handling performed by the backend
3027         https://bugs.webkit.org/show_bug.cgi?id=147097
3028
3029         Reviewed by Joseph Pecoraro.
3030
3031         A new test revealed that the protocol "method" parameter was being parsed in a naive way.
3032         Rewrite it to use String::split and improve error checking to avoid failing later.
3033
3034         * inspector/InspectorBackendDispatcher.cpp:
3035         (Inspector::BackendDispatcher::dispatch):
3036
3037 2015-08-24  Yusuke Suzuki  <utatane.tea@gmail.com>
3038
3039         [ES6] Return JSInternalPromise as result of evaluateModule
3040         https://bugs.webkit.org/show_bug.cgi?id=148173
3041
3042         Reviewed by Saam Barati.
3043
3044         Now evaluateModule returns JSInternalPromise* as its result value.
3045         When an error occurs while loading or executing the modules,
3046         this promise is rejected by that error. By leveraging this, we implemented
3047         asynchronous error reporting when executing the modules in JSC shell.
3048
3049         And this patch also changes the evaluateModule signature to accept the entry
3050         point by the moduleName. By using it, JSC shell can start executing the modules
3051         with the entry point module name.
3052
3053         * builtins/ModuleLoaderObject.js:
3054         (loadModule):
3055         * jsc.cpp:
3056         (dumpException):
3057         (runWithScripts):
3058         * runtime/Completion.cpp:
3059         (JSC::evaluateModule):
3060         * runtime/Completion.h:
3061         * runtime/JSInternalPromise.cpp:
3062         (JSC::JSInternalPromise::then):
3063         * runtime/JSInternalPromise.h:
3064         * runtime/ModuleLoaderObject.cpp:
3065         (JSC::ModuleLoaderObject::requestInstantiateAll):
3066         (JSC::ModuleLoaderObject::loadModule):
3067         (JSC::ModuleLoaderObject::resolve):
3068         (JSC::ModuleLoaderObject::fetch):
3069         (JSC::ModuleLoaderObject::translate):
3070         (JSC::ModuleLoaderObject::instantiate):
3071         (JSC::moduleLoaderObjectParseModule):
3072         * runtime/ModuleLoaderObject.h:
3073
3074 2015-08-24  Basile Clement  <basile_clement@apple.com>
3075
3076         REPTACH is not a word
3077         https://bugs.webkit.org/show_bug.cgi?id=148401
3078
3079         Reviewed by Saam Barati.
3080
3081         * assembler/MacroAssemblerX86_64.h:
3082         (JSC::MacroAssemblerX86_64::callWithSlowPathReturnType):
3083         (JSC::MacroAssemblerX86_64::call):
3084         (JSC::MacroAssemblerX86_64::tailRecursiveCall):
3085         (JSC::MacroAssemblerX86_64::makeTailRecursiveCall):
3086         (JSC::MacroAssemblerX86_64::readCallTarget):
3087         (JSC::MacroAssemblerX86_64::linkCall):
3088         (JSC::MacroAssemblerX86_64::repatchCall):
3089
3090 2015-08-24  Mark Lam  <mark.lam@apple.com>
3091
3092         Add support for setting JSC options from a file.
3093         https://bugs.webkit.org/show_bug.cgi?id=148394
3094
3095         Reviewed by Saam Barati.
3096
3097         This is needed for environments where the JSC executable does not have access to
3098         environmental variables.  This is only needed for debugging, and is currently
3099         guarded under a #define USE_OPTIONS_FILE in Options.cpp, and is disabled by
3100         default.
3101
3102         Also fixed Options::setOptions() to be allow for whitespace that is not a single
3103         ' '.  This makes setOptions() much more flexible and friendlier to use for loading
3104         options in general.
3105
3106         For example, this current use case of loading options from a file may have '\n's
3107         in the character stream, and this feature is easier to implement if setOptions()
3108         just support more than 1 whitespace char between options, and recognize whitespace
3109         characters other than ' '.
3110
3111         * runtime/Options.cpp:
3112         (JSC::parse):
3113         (JSC::Options::initialize):
3114         (JSC::Options::setOptions):
3115
3116 2015-08-24  Filip Pizlo  <fpizlo@apple.com>
3117
3118         DFG::FixupPhase should use the lambda form of m_graph.doToChildren() rather than the old macro
3119         https://bugs.webkit.org/show_bug.cgi?id=148397
3120
3121         Reviewed by Geoffrey Garen.
3122
3123         We used to iterate the edges of a node by using the DFG_NODE_DO_TO_CHILDREN macro. We
3124         don't need to do that anymore since we have the lambda-based m_graph.doToChildren(). This
3125         allows us to get rid of a bunch of helper methods in DFG::FixupPhase.
3126
3127         I also took the opportunity to give the injectTypeConversionsInBlock() method a more
3128         generic name, since after https://bugs.webkit.org/show_bug.cgi?id=145204 it will be used
3129         for fix-up of checks more broadly.
3130
3131         * dfg/DFGFixupPhase.cpp:
3132         (JSC::DFG::FixupPhase::run):
3133         (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
3134         (JSC::DFG::FixupPhase::fixupChecksInBlock):
3135         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock): Deleted.
3136         (JSC::DFG::FixupPhase::tryToRelaxRepresentation): Deleted.
3137         (JSC::DFG::FixupPhase::fixEdgeRepresentation): Deleted.
3138         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge): Deleted.
3139
3140 2015-08-24  Geoffrey Garen  <ggaren@apple.com>
3141
3142         Some renaming to clarify CodeBlock and UnlinkedCodeBlock
3143         https://bugs.webkit.org/show_bug.cgi?id=148391
3144
3145         Reviewed by Saam Barati.
3146
3147         * bytecode/UnlinkedFunctionExecutable.cpp:
3148         (JSC::generateUnlinkedFunctionCodeBlock):
3149         (JSC::UnlinkedFunctionExecutable::visitChildren):
3150         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
3151         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
3152         (JSC::generateFunctionCodeBlock): Deleted.
3153         (JSC::UnlinkedFunctionExecutable::codeBlockFor): Deleted.
3154         * bytecode/UnlinkedFunctionExecutable.h: Call our CodeBlocks "unlinked"
3155         in the name for clarity, since we are unlinked. 
3156
3157         * heap/Heap.cpp:
3158         (JSC::Heap::objectTypeCounts):
3159         (JSC::Heap::deleteAllCodeBlocks):
3160         (JSC::Heap::deleteAllUnlinkedCodeBlocks):
3161         (JSC::Heap::clearUnmarkedExecutables):
3162         (JSC::Heap::deleteOldCode):
3163         (JSC::Heap::FinalizerOwner::finalize):
3164         (JSC::Heap::addExecutable):
3165         (JSC::Heap::collectAllGarbageIfNotDoneRecently):
3166         (JSC::Heap::deleteAllCompiledCode): Deleted.
3167         (JSC::Heap::deleteAllUnlinkedFunctionCode): Deleted.
3168         (JSC::Heap::addCompiledCode): Deleted.
3169         * heap/Heap.h:
3170         (JSC::Heap::notifyIsSafeToCollect):
3171         (JSC::Heap::isSafeToCollect):
3172         (JSC::Heap::sizeBeforeLastFullCollection):
3173         (JSC::Heap::sizeAfterLastFullCollection):
3174         (JSC::Heap::compiledCode): Deleted.
3175
3176             deleteAllCompiledCode => deleteAllCodeBlocks because "compiled"
3177             is a broad phrase these days.
3178
3179             m_compiledCode => m_executables for the same reason.
3180
3181             addCompiledCode => addExecutable for the same reason.
3182
3183             deleteAllUnlinkedFunctionCode => deleteAllUnlinkedCodeBlocks
3184             for consistency.
3185
3186         * jsc.cpp:
3187         (functionDeleteAllCompiledCode):
3188
3189         * runtime/Executable.cpp:
3190         (JSC::ScriptExecutable::newCodeBlockFor): codeBlockFor => unlinkedCodeBlockFor
3191
3192         (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation): Deleted.
3193         It was strange to put this function on executable, since its name implied
3194         that it only changed the executable, but it actually changed all cached
3195         code. Now, a client that wants to change cached code must do so explicitly.
3196
3197         * runtime/Executable.h:
3198         (JSC::ScriptExecutable::finishCreation):
3199         * runtime/VM.cpp:
3200         (JSC::VM::deleteAllCode):
3201         * runtime/VMEntryScope.cpp:
3202         (JSC::VMEntryScope::VMEntryScope): Updated for renames above.
3203
3204 2015-08-22  Filip Pizlo  <fpizlo@apple.com>
3205
3206         DFG::InsertionSet should be tolerant of occasional out-of-order insertions
3207         https://bugs.webkit.org/show_bug.cgi?id=148367
3208
3209         Reviewed by Geoffrey Garen and Saam Barati.
3210
3211         Since forever, the DFG::InsertionSet has been the way we insert nodes into DFG IR, and it
3212         requires that you walk a block in order and perform insertions in order: you can't insert
3213         something at index J, then at index I where I < J, except if you do a second pass.
3214
3215         This restriction makes sense, because it enables a very fast algorithm. And it's very
3216         rare that a phase would need to insert things out of order.
3217
3218         But sometimes - rarely - we need to insert things slightly out-of-order. For example we
3219         may want to insert a node at index J, but to insert a check associated with that node, we
3220         may need to use index I where I < J. This will come up from the work on
3221         https://bugs.webkit.org/show_bug.cgi?id=145204. And it has already come up in the past.
3222         It seems like it would be best to just lift this restriction.
3223
3224         * CMakeLists.txt:
3225         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3226         * JavaScriptCore.xcodeproj/project.pbxproj:
3227         * dfg/DFGInsertionSet.cpp: Added.
3228         (JSC::DFG::InsertionSet::insertSlow):
3229         * dfg/DFGInsertionSet.h:
3230         (JSC::DFG::InsertionSet::InsertionSet):
3231         (JSC::DFG::InsertionSet::graph):
3232         (JSC::DFG::InsertionSet::insert):
3233         (JSC::DFG::InsertionSet::execute):
3234
3235 2015-08-24  Yusuke Suzuki  <utatane.tea@gmail.com>
3236
3237         Create ById IC for ByVal operation only when the specific Id comes more than once
3238         https://bugs.webkit.org/show_bug.cgi?id=148288
3239
3240         Reviewed by Geoffrey Garen.
3241
3242         After introducing byId ICs into byVal ops, byVal ops creates much ICs than before.
3243         The failure fixed in r188767 figures out these ICs are created even if this op is executed only once.
3244
3245         The situation is the following;
3246         In the current code, when byVal op is executed with the Id, we immediately set up the byId IC for that byVal op.
3247         But setting up JITGetByIdGenerator generates the fast path IC code and consumes executable memory.
3248         As a result, if we call eval("contains byVal ops") with the different strings repeatedly under no-llint environment, each eval call creates byId IC for byVal and consumes executable memory.
3249
3250         To solve it, we will add "seen" flag to ByValInfo.
3251         And we will create the IC on the second byVal op call with the same Id.
3252
3253         * bytecode/ByValInfo.h:
3254         (JSC::ByValInfo::ByValInfo):
3255         * jit/JITOperations.cpp:
3256         (JSC::tryGetByValOptimize):
3257         * jit/JITPropertyAccess.cpp:
3258         (JSC::JIT::privateCompileGetByValWithCachedId): Deleted.
3259         (JSC::JIT::privateCompilePutByValWithCachedId): Deleted.
3260
3261 2015-08-23  Benjamin Poulain  <bpoulain@apple.com>
3262
3263         [JSC] Get rid of NodePointerTraits
3264         https://bugs.webkit.org/show_bug.cgi?id=148340
3265
3266         Reviewed by Anders Carlsson.
3267
3268         NodePointerTraits does exactly the same thing has the default trait.
3269
3270         * dfg/DFGBasicBlock.h:
3271         * dfg/DFGCommon.h:
3272         (JSC::DFG::NodePointerTraits::defaultValue): Deleted.
3273         (JSC::DFG::NodePointerTraits::isEmptyForDump): Deleted.
3274
3275 2015-08-23  Benjamin Poulain  <bpoulain@apple.com>
3276
3277         [JSC] Reduce the memory usage of BytecodeLivenessAnalysis
3278         https://bugs.webkit.org/show_bug.cgi?id=148353
3279
3280         Reviewed by Darin Adler.
3281
3282         BytecodeLivenessAnalysis easily takes kilobytes of memory for
3283         non trivial blocks and that memory sticks around because
3284         it stored on CodeBlock.
3285
3286         This patch reduces that memory use a bit.
3287
3288         Most of the memory is in the array of BytecodeBasicBlock.
3289         BytecodeBasicBlock is shrunk by:
3290         -Making it not ref-counted.
3291         -Removing m_predecessors, it was only used for debugging and
3292          is usually big.
3293         -Added a shrinkToFit() phase to shrink the vectors once we are
3294          done building the BytecodeBasicBlock.
3295
3296         There are more things we should do in the future:
3297         -Store all the BytecodeBasicBlock direclty in the array.
3298          We know the size ahead of time, this would be a pure win.
3299          The only tricky part is changing m_successors to have the
3300          index of the successor instead of a pointer.
3301         -Stop&