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