JavaScriptCore should discard baseline code after some time
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-09-16  Geoffrey Garen  <ggaren@apple.com>
2
3         JavaScriptCore should discard baseline code after some time
4         https://bugs.webkit.org/show_bug.cgi?id=149220
5
6         Reviewed by Saam Barati.
7
8         This is a bit more complicated than discarding optimized code because
9         the engine previously assumed that we would never discard baseline code.
10
11         * bytecode/CodeBlock.cpp:
12         (JSC::CodeBlock::CodeBlock): Record creation time (and compute time since
13         creation) instead of install time because CodeBlocks can be installed
14         more than once, and we don't want to have to worry about edge cases
15         created by CodeBlocks seeming to get younger.
16
17         (JSC::CodeBlock::visitAggregate): Be explicit about only doing the 
18         weak reference fixpoint for optimized CodeBlocks. We used to avoid the
19         fixpoint for baseline CodeBlocks implicitly, since they would always
20         visit themselves strongly right away. But now baseline CodeBlocks might
21         not visit themselves strongly, since they might choose to jettison due
22         to old age.
23
24         (JSC::CodeBlock::shouldVisitStrongly): Add old age as a reason not to
25         visit ourselves strongly, so that baseline CodeBlocks can jettison due
26         to old age.
27
28         (JSC::CodeBlock::shouldJettisonDueToWeakReference): Be explicit about
29         only jettisoning optimized CodeBlocks due to weak references so that we
30         don't confuse ourselves into thinking that we will jettison a baseline
31         CodeBlock due to weak references.
32
33         (JSC::CodeBlock::shouldJettisonDueToOldAge): Updated to use creation time.
34
35         (JSC::CodeBlock::visitOSRExitTargets): Clarify a comment and add an
36         ASSERT to help record some things I discovered while debugging.
37
38         (JSC::CodeBlock::jettison): Allow a baseline CodeBlock to jettison. Don't
39         assume that we have an alternative or a profiler.
40
41         (JSC::CodeBlock::install): Deleted.
42         * bytecode/CodeBlock.h:
43         (JSC::CodeBlock::releaseAlternative): Deleted.
44         (JSC::CodeBlock::setInstallTime): Deleted.
45         (JSC::CodeBlock::timeSinceInstall): Deleted.
46
47         * dfg/DFGOSRExitPreparation.cpp:
48         (JSC::DFG::prepareCodeOriginForOSRExit): Simplified the computation of
49         baseline CodeBlock.
50
51         * dfg/DFGPlan.cpp:
52         (JSC::DFG::Plan::checkLivenessAndVisitChildren): Be sure to strongly
53         visit our inline callframes because we assume that an optimized CodeBlock
54         will keep its OSR exit targets alive, but the CodeBlock object won't be
55         able to mark them for itself until compilation has completed (since it
56         won't have a JITCode object yet).
57
58         * dfg/DFGToFTLDeferredCompilationCallback.cpp:
59         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
60         Updated for interface change.
61
62         * jit/JITCode.h:
63         (JSC::JITCode::timeToLive): Provide a time to live for interpreter and
64         baseline code, so they will jettison when old. Use seconds in our
65         code so that we don't need comments. Make DFG 2X interpreter+baseline,
66         and FTL 2X DFG+interpreter+baseline, also matching the time we allot
67         before throwing away all code.
68
69         * jit/JITToDFGDeferredCompilationCallback.cpp:
70         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
71         * llint/LLIntSlowPaths.cpp:
72         (JSC::LLInt::jitCompileAndSetHeuristics): Updated for interface change.
73
74         * runtime/Executable.cpp:
75         (JSC::ScriptExecutable::installCode): Allow our caller to install nullptr,
76         since we need to do this when jettisoning a baseline CodeBlock. Require
77         our caller to specify the details of the installation because we can't
78         rely on a non-null CodeBlock in order to compute them.
79
80         (JSC::ScriptExecutable::newCodeBlockFor):
81         (JSC::ScriptExecutable::prepareForExecutionImpl):
82         * runtime/Executable.h:
83         (JSC::ScriptExecutable::recordParse): Updated for interface change.
84
85         * runtime/Options.h: Renamed the CodeBlock liveness option since it now
86         controls baseline and optimized code.
87
88 2015-09-16  Geoffrey Garen  <ggaren@apple.com>
89
90         Remove obsolete code for deleting CodeBlocks
91         https://bugs.webkit.org/show_bug.cgi?id=149231
92
93         Reviewed by Mark Lam.
94
95         * heap/Heap.cpp:
96         (JSC::Heap::deleteAllCodeBlocks): ASSERT that we're called in a valid
97         state, and do the compiler waiting ourselves instead of having our
98         caller do it. This is more appropriate to our new limited use.
99
100         (JSC::Heap::collectImpl):
101         (JSC::Heap::deleteOldCode): Deleted. Don't call deleteAllCodeBlocks
102         periodically because it's not such a good idea to delete everything
103         at once, and CodeBlocks now have a more precise individual policy for
104         when to delete. Also, this function used to fail all or nearly all of
105         the time because its invariants that we were not executing or compiling
106         could not be met.
107
108         * heap/Heap.h:
109
110         * jsc.cpp:
111         (GlobalObject::finishCreation):
112         (functionDeleteAllCompiledCode): Deleted.
113         * tests/stress/deleteAllCompiledCode.js: Removed. Removed this testing
114         code because it did not do what it thought it did. All of this code
115         was guaranteed to no-op since it would run JavaScript to call a function
116         that would return early because JavaScript was running.
117
118         * runtime/VM.cpp:
119         (JSC::VM::deleteAllCode): This code is simpler now becaue 
120         heap.deleteAllCodeBlocks does some work for us.
121
122         * runtime/VMEntryScope.cpp:
123         (JSC::VMEntryScope::VMEntryScope): Don't delete code on VM entry. This
124         policy was old, and it dated back to a time when we 
125
126             (a) couldn't run in the interpreter if compilation failed;
127
128             (b) didn't reduce the rate of compilation in response to executable
129             memory pressure;
130
131             (c) didn't throw away individual CodeBlocks automatically.
132
133 2015-09-16  Michael Saboff  <msaboff@apple.com>
134
135         [ES6] Implement tail calls in the LLInt and Baseline JIT
136         https://bugs.webkit.org/show_bug.cgi?id=148661
137
138         Fix for the breakage of Speedometer/Full.html (https://bugs.webkit.org/show_bug.cgi?id=149162).
139
140         Reviewed by Filip Pizlo.
141         Changed SetupVarargsFrame.cpp::emitSetVarargsFrame to align the callframe size to be a
142         multiple of stackAlignmentRegisters() in addition to the location of the new frame.
143
144         Fixed Reviewed by Filip Pizlo.
145
146         * CMakeLists.txt:
147         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
148         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
149         * JavaScriptCore.xcodeproj/project.pbxproj:
150         * assembler/AbortReason.h:
151         * assembler/AbstractMacroAssembler.h:
152         (JSC::AbstractMacroAssembler::Call::Call):
153         (JSC::AbstractMacroAssembler::repatchNearCall):
154         (JSC::AbstractMacroAssembler::repatchCompact):
155         * assembler/CodeLocation.h:
156         (JSC::CodeLocationNearCall::CodeLocationNearCall):
157         (JSC::CodeLocationNearCall::callMode):
158         (JSC::CodeLocationCommon::callAtOffset):
159         (JSC::CodeLocationCommon::nearCallAtOffset):
160         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
161         * assembler/LinkBuffer.h:
162         (JSC::LinkBuffer::locationOfNearCall):
163         (JSC::LinkBuffer::locationOf):
164         * assembler/MacroAssemblerARM.h:
165         (JSC::MacroAssemblerARM::nearCall):
166         (JSC::MacroAssemblerARM::nearTailCall):
167         (JSC::MacroAssemblerARM::call):
168         (JSC::MacroAssemblerARM::linkCall):
169         * assembler/MacroAssemblerARM64.h:
170         (JSC::MacroAssemblerARM64::nearCall):
171         (JSC::MacroAssemblerARM64::nearTailCall):
172         (JSC::MacroAssemblerARM64::ret):
173         (JSC::MacroAssemblerARM64::linkCall):
174         * assembler/MacroAssemblerARMv7.h:
175         (JSC::MacroAssemblerARMv7::nearCall):
176         (JSC::MacroAssemblerARMv7::nearTailCall):
177         (JSC::MacroAssemblerARMv7::call):
178         (JSC::MacroAssemblerARMv7::linkCall):
179         * assembler/MacroAssemblerMIPS.h:
180         (JSC::MacroAssemblerMIPS::nearCall):
181         (JSC::MacroAssemblerMIPS::nearTailCall):
182         (JSC::MacroAssemblerMIPS::call):
183         (JSC::MacroAssemblerMIPS::linkCall):
184         (JSC::MacroAssemblerMIPS::repatchCall):
185         * assembler/MacroAssemblerSH4.h:
186         (JSC::MacroAssemblerSH4::call):
187         (JSC::MacroAssemblerSH4::nearTailCall):
188         (JSC::MacroAssemblerSH4::nearCall):
189         (JSC::MacroAssemblerSH4::linkCall):
190         (JSC::MacroAssemblerSH4::repatchCall):
191         * assembler/MacroAssemblerX86.h:
192         (JSC::MacroAssemblerX86::linkCall):
193         * assembler/MacroAssemblerX86Common.h:
194         (JSC::MacroAssemblerX86Common::breakpoint):
195         (JSC::MacroAssemblerX86Common::nearTailCall):
196         (JSC::MacroAssemblerX86Common::nearCall):
197         * assembler/MacroAssemblerX86_64.h:
198         (JSC::MacroAssemblerX86_64::linkCall):
199         * bytecode/BytecodeList.json:
200         * bytecode/BytecodeUseDef.h:
201         (JSC::computeUsesForBytecodeOffset):
202         (JSC::computeDefsForBytecodeOffset):
203         * bytecode/CallLinkInfo.h:
204         (JSC::CallLinkInfo::callTypeFor):
205         (JSC::CallLinkInfo::isVarargsCallType):
206         (JSC::CallLinkInfo::CallLinkInfo):
207         (JSC::CallLinkInfo::specializationKind):
208         (JSC::CallLinkInfo::callModeFor):
209         (JSC::CallLinkInfo::callMode):
210         (JSC::CallLinkInfo::isTailCall):
211         (JSC::CallLinkInfo::isVarargs):
212         (JSC::CallLinkInfo::registerPreservationMode):
213         * bytecode/CallLinkStatus.cpp:
214         (JSC::CallLinkStatus::computeFromLLInt):
215         * bytecode/CodeBlock.cpp:
216         (JSC::CodeBlock::dumpBytecode):
217         (JSC::CodeBlock::CodeBlock):
218         * bytecompiler/BytecodeGenerator.cpp:
219         (JSC::BytecodeGenerator::BytecodeGenerator):
220         (JSC::BytecodeGenerator::emitCallInTailPosition):
221         (JSC::BytecodeGenerator::emitCallEval):
222         (JSC::BytecodeGenerator::emitCall):
223         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
224         (JSC::BytecodeGenerator::emitConstructVarargs):
225         * bytecompiler/NodesCodegen.cpp:
226         (JSC::CallArguments::CallArguments):
227         (JSC::LabelNode::emitBytecode):
228         * dfg/DFGByteCodeParser.cpp:
229         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
230         * ftl/FTLLowerDFGToLLVM.cpp:
231         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
232         * interpreter/Interpreter.h:
233         (JSC::Interpreter::isCallBytecode):
234         (JSC::calleeFrameForVarargs):
235         * jit/CCallHelpers.h:
236         (JSC::CCallHelpers::jumpToExceptionHandler):
237         (JSC::CCallHelpers::prepareForTailCallSlow):
238         * jit/JIT.cpp:
239         (JSC::JIT::privateCompileMainPass):
240         (JSC::JIT::privateCompileSlowCases):
241         * jit/JIT.h:
242         * jit/JITCall.cpp:
243         (JSC::JIT::compileOpCall):
244         (JSC::JIT::compileOpCallSlowCase):
245         (JSC::JIT::emit_op_call):
246         (JSC::JIT::emit_op_tail_call):
247         (JSC::JIT::emit_op_call_eval):
248         (JSC::JIT::emit_op_call_varargs):
249         (JSC::JIT::emit_op_tail_call_varargs):
250         (JSC::JIT::emit_op_construct_varargs):
251         (JSC::JIT::emitSlow_op_call):
252         (JSC::JIT::emitSlow_op_tail_call):
253         (JSC::JIT::emitSlow_op_call_eval):
254         (JSC::JIT::emitSlow_op_call_varargs):
255         (JSC::JIT::emitSlow_op_tail_call_varargs):
256         (JSC::JIT::emitSlow_op_construct_varargs):
257         * jit/JITCall32_64.cpp:
258         (JSC::JIT::emitSlow_op_call):
259         (JSC::JIT::emitSlow_op_tail_call):
260         (JSC::JIT::emitSlow_op_call_eval):
261         (JSC::JIT::emitSlow_op_call_varargs):
262         (JSC::JIT::emitSlow_op_tail_call_varargs):
263         (JSC::JIT::emitSlow_op_construct_varargs):
264         (JSC::JIT::emit_op_call):
265         (JSC::JIT::emit_op_tail_call):
266         (JSC::JIT::emit_op_call_eval):
267         (JSC::JIT::emit_op_call_varargs):
268         (JSC::JIT::emit_op_tail_call_varargs):
269         (JSC::JIT::emit_op_construct_varargs):
270         (JSC::JIT::compileOpCall):
271         (JSC::JIT::compileOpCallSlowCase):
272         * jit/JITInlines.h:
273         (JSC::JIT::emitNakedCall):
274         (JSC::JIT::emitNakedTailCall):
275         (JSC::JIT::updateTopCallFrame):
276         * jit/JITOperations.cpp:
277         * jit/JITOperations.h:
278         * jit/Repatch.cpp:
279         (JSC::linkVirtualFor):
280         (JSC::linkPolymorphicCall):
281         * jit/SetupVarargsFrame.cpp:
282         (JSC::emitSetVarargsFrame):
283         * jit/ThunkGenerators.cpp:
284         (JSC::throwExceptionFromCallSlowPathGenerator):
285         (JSC::slowPathFor):
286         (JSC::linkCallThunkGenerator):
287         (JSC::virtualThunkFor):
288         (JSC::arityFixupGenerator):
289         (JSC::unreachableGenerator):
290         (JSC::baselineGetterReturnThunkGenerator):
291         * jit/ThunkGenerators.h:
292         * llint/LowLevelInterpreter.asm:
293         * llint/LowLevelInterpreter32_64.asm:
294         * llint/LowLevelInterpreter64.asm:
295         * runtime/CommonSlowPaths.h:
296         (JSC::CommonSlowPaths::arityCheckFor):
297         (JSC::CommonSlowPaths::opIn):
298
299 2015-09-15  Michael Saboff  <msaboff@apple.com>
300
301         Rollout r189774 and 189818.
302
303         Broke Speedometer/Full.html
304
305         Not reviewed.
306
307         * CMakeLists.txt:
308         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
309         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
310         * JavaScriptCore.xcodeproj/project.pbxproj:
311         * assembler/AbortReason.h:
312         * assembler/AbstractMacroAssembler.h:
313         (JSC::AbstractMacroAssembler::Call::Call):
314         (JSC::AbstractMacroAssembler::repatchNearCall):
315         (JSC::AbstractMacroAssembler::repatchCompact):
316         * assembler/CodeLocation.h:
317         (JSC::CodeLocationNearCall::CodeLocationNearCall):
318         (JSC::CodeLocationCommon::callAtOffset):
319         (JSC::CodeLocationCommon::nearCallAtOffset):
320         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
321         (JSC::CodeLocationNearCall::callMode): Deleted.
322         * assembler/LinkBuffer.h:
323         (JSC::LinkBuffer::locationOfNearCall):
324         (JSC::LinkBuffer::locationOf):
325         * assembler/MacroAssemblerARM.h:
326         (JSC::MacroAssemblerARM::nearCall):
327         (JSC::MacroAssemblerARM::call):
328         (JSC::MacroAssemblerARM::linkCall):
329         (JSC::MacroAssemblerARM::nearTailCall): Deleted.
330         * assembler/MacroAssemblerARM64.h:
331         (JSC::MacroAssemblerARM64::nearCall):
332         (JSC::MacroAssemblerARM64::ret):
333         (JSC::MacroAssemblerARM64::linkCall):
334         (JSC::MacroAssemblerARM64::nearTailCall): Deleted.
335         * assembler/MacroAssemblerARMv7.h:
336         (JSC::MacroAssemblerARMv7::nearCall):
337         (JSC::MacroAssemblerARMv7::call):
338         (JSC::MacroAssemblerARMv7::linkCall):
339         (JSC::MacroAssemblerARMv7::nearTailCall): Deleted.
340         * assembler/MacroAssemblerMIPS.h:
341         (JSC::MacroAssemblerMIPS::nearCall):
342         (JSC::MacroAssemblerMIPS::call):
343         (JSC::MacroAssemblerMIPS::linkCall):
344         (JSC::MacroAssemblerMIPS::repatchCall):
345         (JSC::MacroAssemblerMIPS::nearTailCall): Deleted.
346         * assembler/MacroAssemblerSH4.h:
347         (JSC::MacroAssemblerSH4::call):
348         (JSC::MacroAssemblerSH4::nearCall):
349         (JSC::MacroAssemblerSH4::linkCall):
350         (JSC::MacroAssemblerSH4::repatchCall):
351         (JSC::MacroAssemblerSH4::nearTailCall): Deleted.
352         * assembler/MacroAssemblerX86.h:
353         (JSC::MacroAssemblerX86::linkCall):
354         * assembler/MacroAssemblerX86Common.h:
355         (JSC::MacroAssemblerX86Common::breakpoint):
356         (JSC::MacroAssemblerX86Common::nearCall):
357         (JSC::MacroAssemblerX86Common::nearTailCall): Deleted.
358         * assembler/MacroAssemblerX86_64.h:
359         (JSC::MacroAssemblerX86_64::linkCall):
360         * bytecode/BytecodeList.json:
361         * bytecode/BytecodeUseDef.h:
362         (JSC::computeUsesForBytecodeOffset):
363         (JSC::computeDefsForBytecodeOffset):
364         * bytecode/CallLinkInfo.h:
365         (JSC::CallLinkInfo::callTypeFor):
366         (JSC::CallLinkInfo::CallLinkInfo):
367         (JSC::CallLinkInfo::specializationKind):
368         (JSC::CallLinkInfo::registerPreservationMode):
369         (JSC::CallLinkInfo::isVarargsCallType): Deleted.
370         (JSC::CallLinkInfo::callModeFor): Deleted.
371         (JSC::CallLinkInfo::callMode): Deleted.
372         (JSC::CallLinkInfo::isTailCall): Deleted.
373         (JSC::CallLinkInfo::isVarargs): Deleted.
374         * bytecode/CallLinkStatus.cpp:
375         (JSC::CallLinkStatus::computeFromLLInt):
376         * bytecode/CodeBlock.cpp:
377         (JSC::CodeBlock::dumpBytecode):
378         (JSC::CodeBlock::CodeBlock):
379         * bytecompiler/BytecodeGenerator.cpp:
380         (JSC::BytecodeGenerator::BytecodeGenerator):
381         (JSC::BytecodeGenerator::emitCallInTailPosition):
382         (JSC::BytecodeGenerator::emitCallEval):
383         (JSC::BytecodeGenerator::emitCall):
384         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
385         (JSC::BytecodeGenerator::emitConstructVarargs):
386         * bytecompiler/NodesCodegen.cpp:
387         (JSC::CallArguments::CallArguments):
388         (JSC::LabelNode::emitBytecode):
389         * dfg/DFGByteCodeParser.cpp:
390         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
391         * ftl/FTLLowerDFGToLLVM.cpp:
392         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
393         * interpreter/Interpreter.h:
394         (JSC::Interpreter::isCallBytecode):
395         * jit/CCallHelpers.h:
396         (JSC::CCallHelpers::jumpToExceptionHandler):
397         (JSC::CCallHelpers::prepareForTailCallSlow): Deleted.
398         * jit/JIT.cpp:
399         (JSC::JIT::privateCompileMainPass):
400         (JSC::JIT::privateCompileSlowCases):
401         * jit/JIT.h:
402         * jit/JITCall.cpp:
403         (JSC::JIT::compileOpCall):
404         (JSC::JIT::compileOpCallSlowCase):
405         (JSC::JIT::emit_op_call):
406         (JSC::JIT::emit_op_call_eval):
407         (JSC::JIT::emit_op_call_varargs):
408         (JSC::JIT::emit_op_construct_varargs):
409         (JSC::JIT::emitSlow_op_call):
410         (JSC::JIT::emitSlow_op_call_eval):
411         (JSC::JIT::emitSlow_op_call_varargs):
412         (JSC::JIT::emitSlow_op_construct_varargs):
413         (JSC::JIT::emit_op_tail_call): Deleted.
414         (JSC::JIT::emit_op_tail_call_varargs): Deleted.
415         (JSC::JIT::emitSlow_op_tail_call): Deleted.
416         (JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
417         * jit/JITCall32_64.cpp:
418         (JSC::JIT::emitSlow_op_call):
419         (JSC::JIT::emitSlow_op_call_eval):
420         (JSC::JIT::emitSlow_op_call_varargs):
421         (JSC::JIT::emitSlow_op_construct_varargs):
422         (JSC::JIT::emit_op_call):
423         (JSC::JIT::emit_op_call_eval):
424         (JSC::JIT::emit_op_call_varargs):
425         (JSC::JIT::emit_op_construct_varargs):
426         (JSC::JIT::compileOpCall):
427         (JSC::JIT::compileOpCallSlowCase):
428         (JSC::JIT::emitSlow_op_tail_call): Deleted.
429         (JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
430         (JSC::JIT::emit_op_tail_call): Deleted.
431         (JSC::JIT::emit_op_tail_call_varargs): Deleted.
432         * jit/JITInlines.h:
433         (JSC::JIT::emitNakedCall):
434         (JSC::JIT::updateTopCallFrame):
435         (JSC::JIT::emitNakedTailCall): Deleted.
436         * jit/JITOperations.cpp:
437         * jit/JITOperations.h:
438         * jit/Repatch.cpp:
439         (JSC::linkVirtualFor):
440         (JSC::linkPolymorphicCall):
441         * jit/ThunkGenerators.cpp:
442         (JSC::throwExceptionFromCallSlowPathGenerator):
443         (JSC::slowPathFor):
444         (JSC::linkCallThunkGenerator):
445         (JSC::virtualThunkFor):
446         (JSC::arityFixupGenerator):
447         (JSC::baselineGetterReturnThunkGenerator):
448         (JSC::unreachableGenerator): Deleted.
449         * jit/ThunkGenerators.h:
450         * llint/LowLevelInterpreter.asm:
451         * llint/LowLevelInterpreter32_64.asm:
452         * llint/LowLevelInterpreter64.asm:
453         * runtime/CommonSlowPaths.h:
454         (JSC::CommonSlowPaths::arityCheckFor):
455         (JSC::CommonSlowPaths::opIn):
456         * tests/stress/mutual-tail-call-no-stack-overflow.js: Removed.
457         * tests/stress/tail-call-no-stack-overflow.js: Removed.
458         * tests/stress/tail-call-recognize.js: Removed.
459         * tests/stress/tail-call-varargs-no-stack-overflow.js: Removed.
460         * tests/stress/tail-calls-dont-overwrite-live-stack.js: Removed.
461
462 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
463
464         Implement imported global variables in WebAssembly
465         https://bugs.webkit.org/show_bug.cgi?id=149206
466
467         Reviewed by Filip Pizlo.
468
469         Values can now be imported to a WebAssembly module through properties of
470         the imports object that is passed to loadWebAssembly(). In order to
471         avoid any side effect when accessing the imports object, we check that
472         the properties are data properties. We also check that each value is a
473         primitive and is not a Symbol. According to the ECMA262 6.0 spec,
474         calling ToNumber() on a primitive that is not a Symbol should not cause
475         any side effect.[1]
476
477         [1]: http://www.ecma-international.org/ecma-262/6.0/#sec-tonumber
478
479         * tests/stress/wasm-globals.js:
480         * tests/stress/wasm/globals.wasm:
481         * wasm/WASMModuleParser.cpp:
482         (JSC::WASMModuleParser::parseModule):
483         (JSC::WASMModuleParser::parseGlobalSection):
484         * wasm/WASMModuleParser.h:
485
486 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
487
488         Fix asm.js errors in WebAssembly tests
489         https://bugs.webkit.org/show_bug.cgi?id=149203
490
491         Reviewed by Geoffrey Garen.
492
493         Our WebAssembly implementation uses asm.js for testing. Using Firefox to
494         parse asm.js reveals many errors that are not caught by pack-asmjs. For
495         example,
496         - asm.js does not allow the use of the multiplication operator (*) to
497           multiply two integers, because the result can be so large that some
498           lower bits of precision are lost. Math.imul is used instead.
499         - an int variable must be coerced to either signed (via x|0) or unsigned
500           (via x>>>0) before it's returned.
501
502         * tests/stress/wasm-arithmetic-int32.js:
503         * tests/stress/wasm-calls.js:
504         * tests/stress/wasm-control-flow.js:
505         * tests/stress/wasm-globals.js:
506         * tests/stress/wasm-locals.js:
507         * tests/stress/wasm-relational.js:
508         * tests/stress/wasm/control-flow.wasm:
509
510 2015-09-15  Ryosuke Niwa  <rniwa@webkit.org>
511
512         Add ShadowRoot interface and Element.prototype.attachShadow
513         https://bugs.webkit.org/show_bug.cgi?id=149187
514
515         Reviewed by Antti Koivisto.
516
517         * Configurations/FeatureDefines.xcconfig:
518
519 2015-09-15  Joseph Pecoraro  <pecoraro@apple.com>
520
521         Web Inspector: Paused Debugger prevents page reload
522         https://bugs.webkit.org/show_bug.cgi?id=148174
523
524         Reviewed by Brian Burg.
525
526         * debugger/Debugger.h:
527         (JSC::Debugger::suppressAllPauses):
528         (JSC::Debugger::setSuppressAllPauses):
529         * debugger/Debugger.cpp:
530         (JSC::Debugger::Debugger):
531         (JSC::Debugger::pauseIfNeeded):
532         * inspector/agents/InspectorDebuggerAgent.h:
533         * inspector/agents/InspectorDebuggerAgent.cpp:
534         (Inspector::InspectorDebuggerAgent::setSuppressAllPauses):
535         Provide a way to suppress pauses.
536
537 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
538
539         Implement calls to JavaScript functions in WebAssembly
540         https://bugs.webkit.org/show_bug.cgi?id=149093
541
542         Reviewed by Filip Pizlo.
543
544         This patch implements calls to JavaScript functions in WebAssembly.
545         WebAssembly functions can only call JavaScript functions that are
546         imported to their module via an object that is passed into
547         loadWebAssembly(). References to JavaScript functions are resolved at
548         the module's load time, just like asm.js.
549
550         * jsc.cpp:
551         (GlobalObject::finishCreation):
552         (functionLoadWebAssembly):
553         * tests/stress/wasm-calls.js:
554         * tests/stress/wasm/calls.wasm:
555         * wasm/JSWASMModule.cpp:
556         (JSC::JSWASMModule::visitChildren):
557         * wasm/JSWASMModule.h:
558         (JSC::JSWASMModule::importedFunctions):
559         * wasm/WASMFunctionCompiler.h:
560         (JSC::WASMFunctionCompiler::buildCallImport):
561         * wasm/WASMFunctionParser.cpp:
562         (JSC::WASMFunctionParser::parseExpressionI32):
563         (JSC::WASMFunctionParser::parseExpressionF64):
564         (JSC::WASMFunctionParser::parseCallImport):
565         * wasm/WASMFunctionParser.h:
566         * wasm/WASMFunctionSyntaxChecker.h:
567         (JSC::WASMFunctionSyntaxChecker::buildCallInternal):
568         (JSC::WASMFunctionSyntaxChecker::buildCallImport):
569         (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall):
570         * wasm/WASMModuleParser.cpp:
571         (JSC::WASMModuleParser::WASMModuleParser):
572         (JSC::WASMModuleParser::parse):
573         (JSC::WASMModuleParser::parseModule):
574         (JSC::WASMModuleParser::parseFunctionImportSection):
575         (JSC::WASMModuleParser::getImportedValue):
576         (JSC::parseWebAssembly):
577         * wasm/WASMModuleParser.h:
578
579 2015-09-15  Csaba Osztrogon√°c  <ossy@webkit.org>
580
581         Fix the !ENABLE(DFG_JIT) build after r188696
582         https://bugs.webkit.org/show_bug.cgi?id=149158
583
584         Reviewed by Yusuke Suzuki.
585
586         * bytecode/GetByIdStatus.cpp:
587         * bytecode/GetByIdStatus.h:
588
589 2015-09-15  Saam barati  <sbarati@apple.com>
590
591         functions that use try/catch will allocate a top level JSLexicalEnvironment even when it is not necessary
592         https://bugs.webkit.org/show_bug.cgi?id=148169
593
594         Reviewed by Geoffrey Garen.
595
596         We used to do this before we had proper lexical scoping
597         in the bytecode generator. There is absolutely no reason
598         why need to allocate a top-level "var" activation when a
599         function/program uses a "catch" block.
600
601         * parser/ASTBuilder.h:
602         (JSC::ASTBuilder::createTryStatement):
603         (JSC::ASTBuilder::incConstants):
604         (JSC::ASTBuilder::usesThis):
605         (JSC::ASTBuilder::usesArguments):
606         (JSC::ASTBuilder::usesWith):
607         (JSC::ASTBuilder::usesEval):
608         (JSC::ASTBuilder::usesCatch): Deleted.
609         * parser/Nodes.h:
610         (JSC::ScopeNode::isStrictMode):
611         (JSC::ScopeNode::setUsesArguments):
612         (JSC::ScopeNode::usesThis):
613         (JSC::ScopeNode::needsActivation):
614         (JSC::ScopeNode::hasCapturedVariables):
615         (JSC::ScopeNode::captures):
616         (JSC::ScopeNode::needsActivationForMoreThanVariables): Deleted.
617         * parser/ParserModes.h:
618         * runtime/Executable.h:
619         (JSC::ScriptExecutable::usesEval):
620         (JSC::ScriptExecutable::usesArguments):
621         (JSC::ScriptExecutable::needsActivation):
622         (JSC::ScriptExecutable::isStrictMode):
623         (JSC::ScriptExecutable::ecmaMode):
624
625 2015-09-15  Michael Saboff  <msaboff@apple.com>
626
627         REGRESSION(r189774): CLoop doesn't build after r189774
628         https://bugs.webkit.org/show_bug.cgi?id=149171
629
630         Unreviewed build fix for the C Loop.
631
632         Added needed C Loop label opcodes.
633
634         * bytecode/BytecodeList.json:
635
636 2015-09-15  Andy VanWagoner  <thetalecrafter@gmail.com>
637
638         [INTL] Implement supportedLocalesOf on Intl Constructors
639         https://bugs.webkit.org/show_bug.cgi?id=147599
640
641         Reviewed by Benjamin Poulain.
642
643         Implements all of the abstract operations used by supportedLocalesOf,
644         except during canonicalization it does not replace redundant tags,
645         or subtags with their preferred values.
646
647         * icu/unicode/ucal.h: Added.
648         * icu/unicode/udat.h: Added.
649         * icu/unicode/umisc.h: Added.
650         * icu/unicode/unum.h: Added.
651         * icu/unicode/utypes.h: Clear the U_SHOW_CPLUSPLUS_API flag to prevent C++ headers from being included.
652         * runtime/CommonIdentifiers.h: Adde localeMatcher.
653         * runtime/IntlCollatorConstructor.cpp:
654         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf): Implemented.
655         * runtime/IntlDateTimeFormatConstructor.cpp:
656         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): Implemented.
657         * runtime/IntlNumberFormatConstructor.cpp:
658         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): Implemented.
659         * runtime/IntlObject.cpp:
660         (JSC::canonicalizeLanguageTag):
661         (JSC::getCanonicalLangTag):
662         (JSC::getPrivateUseLangTag):
663         (JSC::getGrandfatheredLangTag):
664         (JSC::canonicalizeLocaleList):
665         (JSC::bestAvailableLocale):
666         (JSC::lookupSupportedLocales):
667         (JSC::bestFitSupportedLocales):
668         (JSC::supportedLocales):
669         (JSC::getIntlStringOption):
670         (JSC::getIntlBooleanOption):
671         * runtime/IntlObject.h:
672         * runtime/JSCJSValue.h: Added toLength.
673         * runtime/JSCJSValue.cpp: Added toLength.
674         (JSC::JSValue::toLength): Implement ToLength from ECMA 262 6.0 7.1.15
675         * runtime/JSGlobalObject.cpp:
676         (JSC::JSGlobalObject::intlCollatorAvailableLocales): Added lazy locale list.
677         (JSC::JSGlobalObject::intlDateTimeFormatAvailableLocales): Added lazy locale list.
678         (JSC::JSGlobalObject::intlNumberFormatAvailableLocales): Added lazy locale list.
679         * runtime/JSGlobalObject.h:
680
681 2015-09-14  Saam barati  <sbarati@apple.com>
682
683         rename callFrameForThrow to callFrameForCatch
684         https://bugs.webkit.org/show_bug.cgi?id=149136
685
686         Reviewed by Michael Saboff.
687
688         We use "callFrameForThrow" to mean the call frame in
689         which we're catching the exception. The field name
690         should accurately represent its purpose by being
691         named "callFrameForCatch".
692
693         * jit/CCallHelpers.h:
694         (JSC::CCallHelpers::jumpToExceptionHandler):
695         * jit/JITExceptions.cpp:
696         (JSC::genericUnwind):
697         * jit/JITOpcodes.cpp:
698         (JSC::JIT::emit_op_catch):
699         * jit/JITOpcodes32_64.cpp:
700         (JSC::JIT::emit_op_catch):
701         * jit/JITOperations.cpp:
702         * llint/LowLevelInterpreter32_64.asm:
703         * llint/LowLevelInterpreter64.asm:
704         * runtime/VM.h:
705         (JSC::VM::exceptionOffset):
706         (JSC::VM::callFrameForCatchOffset):
707         (JSC::VM::targetMachinePCForThrowOffset):
708         (JSC::VM::callFrameForThrowOffset): Deleted.
709
710 2015-09-14  Basile Clement  <basile_clement@apple.com>
711
712         [ES6] Implement tail calls in the LLInt and Baseline JIT
713         https://bugs.webkit.org/show_bug.cgi?id=148661
714
715         Reviewed by Filip Pizlo.
716
717         This patch introduces two new opcodes, op_tail_call and
718         op_tail_call_varargs, to perform tail calls, and implements them in the
719         LLInt and baseline JIT. Their use prevents DFG and FTL compilation for
720         now. They are currently implemented by sliding the call frame and
721         masquerading as our own caller right before performing an actual call.
722
723         This required to change the operationLink family of operation to return
724         a SlowPathReturnType instead of a char* in order to distinguish between
725         exception cases and actual call cases. We introduce a new FrameAction
726         enum that indicates whether to reuse (non-exceptional tail call) or
727         keep the current call frame (non-tail call, and exceptional cases).
728
729         This is also a semantics change, since the Function.caller property is
730         now leaking tail calls. Since tail calls are only used in strict mode,
731         which poisons this property, the only way of seeing this semantics
732         change is when a sloppy function calls a strict function that then
733         tail-calls a sloppy function. Previously, the second sloppy function's
734         caller would have been the strict function (i.e. raises a TypeError
735         when the .caller attribute is accessed), while it is now the first
736         sloppy function. Tests have been updated to reflect that.
737
738         This also changes the assumptions we make about call frames. In order
739         to be relatively efficient, we want to be able to compute the frame
740         size based only on the argument count, which was not possible
741         previously. To enable this, we now enforce at the bytecode generator,
742         DFG and FTL level that any space reserved for a call frame is
743         stack-aligned, which allows to easily compute its size when performing
744         a tail call. In all the "special call cases" (calls from native code,
745         inlined cache calls, etc.), we are starting the frame at the current
746         stack pointer and thus will always have a stack-aligned frame size.
747
748         Finally, this patch adds a couple of tests to check that tail calls run
749         in constant stack space, as well as tests checking that tail calls are
750         recognized correctly. Those tests use the handy aforementioned leaking
751         of tail calls through Function.caller to detect tail calls. 
752
753         Given that this patch only implements tail calls for the LLInt and
754         Baseline JIT, tail calls are disabled by default.  Until changes are
755         landed for all tiers, tail call testing and use requires the
756         --enableTailCalls=true or equivalent.
757
758         * CMakeLists.txt:
759         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
760         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
761         * JavaScriptCore.xcodeproj/project.pbxproj:
762         * assembler/AbortReason.h:
763         * assembler/AbstractMacroAssembler.h:
764         (JSC::AbstractMacroAssembler::Call::Call):
765         (JSC::AbstractMacroAssembler::repatchNearCall):
766         (JSC::AbstractMacroAssembler::repatchCompact):
767         * assembler/CodeLocation.h:
768         (JSC::CodeLocationNearCall::CodeLocationNearCall):
769         (JSC::CodeLocationNearCall::callMode):
770         (JSC::CodeLocationCommon::callAtOffset):
771         (JSC::CodeLocationCommon::nearCallAtOffset):
772         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
773         * assembler/LinkBuffer.h:
774         (JSC::LinkBuffer::locationOfNearCall):
775         (JSC::LinkBuffer::locationOf):
776         * assembler/MacroAssemblerARM.h:
777         (JSC::MacroAssemblerARM::nearCall):
778         (JSC::MacroAssemblerARM::nearTailCall):
779         (JSC::MacroAssemblerARM::call):
780         (JSC::MacroAssemblerARM::linkCall):
781         * assembler/MacroAssemblerARM64.h:
782         (JSC::MacroAssemblerARM64::nearCall):
783         (JSC::MacroAssemblerARM64::nearTailCall):
784         (JSC::MacroAssemblerARM64::ret):
785         (JSC::MacroAssemblerARM64::linkCall):
786         * assembler/MacroAssemblerARMv7.h:
787         (JSC::MacroAssemblerARMv7::nearCall):
788         (JSC::MacroAssemblerARMv7::nearTailCall):
789         (JSC::MacroAssemblerARMv7::call):
790         (JSC::MacroAssemblerARMv7::linkCall):
791         * assembler/MacroAssemblerMIPS.h:
792         (JSC::MacroAssemblerMIPS::nearCall):
793         (JSC::MacroAssemblerMIPS::nearTailCall):
794         (JSC::MacroAssemblerMIPS::call):
795         (JSC::MacroAssemblerMIPS::linkCall):
796         (JSC::MacroAssemblerMIPS::repatchCall):
797         * assembler/MacroAssemblerSH4.h:
798         (JSC::MacroAssemblerSH4::call):
799         (JSC::MacroAssemblerSH4::nearTailCall):
800         (JSC::MacroAssemblerSH4::nearCall):
801         (JSC::MacroAssemblerSH4::linkCall):
802         (JSC::MacroAssemblerSH4::repatchCall):
803         * assembler/MacroAssemblerX86.h:
804         (JSC::MacroAssemblerX86::linkCall):
805         * assembler/MacroAssemblerX86Common.h:
806         (JSC::MacroAssemblerX86Common::breakpoint):
807         (JSC::MacroAssemblerX86Common::nearTailCall):
808         (JSC::MacroAssemblerX86Common::nearCall):
809         * assembler/MacroAssemblerX86_64.h:
810         (JSC::MacroAssemblerX86_64::linkCall):
811         * bytecode/BytecodeList.json:
812         * bytecode/BytecodeUseDef.h:
813         (JSC::computeUsesForBytecodeOffset):
814         (JSC::computeDefsForBytecodeOffset):
815         * bytecode/CallLinkInfo.h:
816         (JSC::CallLinkInfo::callTypeFor):
817         (JSC::CallLinkInfo::isVarargsCallType):
818         (JSC::CallLinkInfo::CallLinkInfo):
819         (JSC::CallLinkInfo::specializationKind):
820         (JSC::CallLinkInfo::callModeFor):
821         (JSC::CallLinkInfo::callMode):
822         (JSC::CallLinkInfo::isTailCall):
823         (JSC::CallLinkInfo::isVarargs):
824         (JSC::CallLinkInfo::registerPreservationMode):
825         * bytecode/CallLinkStatus.cpp:
826         (JSC::CallLinkStatus::computeFromLLInt):
827         * bytecode/CallMode.cpp: Added.
828         (WTF::printInternal):
829         * bytecode/CallMode.h: Added.
830         * bytecode/CodeBlock.cpp:
831         (JSC::CodeBlock::dumpBytecode):
832         (JSC::CodeBlock::CodeBlock):
833         * bytecompiler/BytecodeGenerator.cpp:
834         (JSC::BytecodeGenerator::BytecodeGenerator):
835         (JSC::BytecodeGenerator::emitCallInTailPosition):
836         (JSC::BytecodeGenerator::emitCallEval):
837         (JSC::BytecodeGenerator::emitCall):
838         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
839         (JSC::BytecodeGenerator::emitConstructVarargs):
840         * bytecompiler/NodesCodegen.cpp:
841         (JSC::CallArguments::CallArguments):
842         (JSC::LabelNode::emitBytecode):
843         * dfg/DFGByteCodeParser.cpp:
844         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
845         * ftl/FTLLowerDFGToLLVM.cpp:
846         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
847         * interpreter/Interpreter.h:
848         (JSC::Interpreter::isCallBytecode):
849         * jit/CCallHelpers.h:
850         (JSC::CCallHelpers::jumpToExceptionHandler):
851         (JSC::CCallHelpers::prepareForTailCallSlow):
852         * jit/JIT.cpp:
853         (JSC::JIT::privateCompileMainPass):
854         (JSC::JIT::privateCompileSlowCases):
855         * jit/JIT.h:
856         * jit/JITCall.cpp:
857         (JSC::JIT::compileOpCall):
858         (JSC::JIT::compileOpCallSlowCase):
859         (JSC::JIT::emit_op_call):
860         (JSC::JIT::emit_op_tail_call):
861         (JSC::JIT::emit_op_call_eval):
862         (JSC::JIT::emit_op_call_varargs):
863         (JSC::JIT::emit_op_tail_call_varargs):
864         (JSC::JIT::emit_op_construct_varargs):
865         (JSC::JIT::emitSlow_op_call):
866         (JSC::JIT::emitSlow_op_tail_call):
867         (JSC::JIT::emitSlow_op_call_eval):
868         (JSC::JIT::emitSlow_op_call_varargs):
869         (JSC::JIT::emitSlow_op_tail_call_varargs):
870         (JSC::JIT::emitSlow_op_construct_varargs):
871         * jit/JITCall32_64.cpp:
872         (JSC::JIT::emitSlow_op_call):
873         (JSC::JIT::emitSlow_op_tail_call):
874         (JSC::JIT::emitSlow_op_call_eval):
875         (JSC::JIT::emitSlow_op_call_varargs):
876         (JSC::JIT::emitSlow_op_tail_call_varargs):
877         (JSC::JIT::emitSlow_op_construct_varargs):
878         (JSC::JIT::emit_op_call):
879         (JSC::JIT::emit_op_tail_call):
880         (JSC::JIT::emit_op_call_eval):
881         (JSC::JIT::emit_op_call_varargs):
882         (JSC::JIT::emit_op_tail_call_varargs):
883         (JSC::JIT::emit_op_construct_varargs):
884         (JSC::JIT::compileOpCall):
885         (JSC::JIT::compileOpCallSlowCase):
886         * jit/JITInlines.h:
887         (JSC::JIT::emitNakedCall):
888         (JSC::JIT::emitNakedTailCall):
889         (JSC::JIT::updateTopCallFrame):
890         * jit/JITOperations.cpp:
891         * jit/JITOperations.h:
892         * jit/Repatch.cpp:
893         (JSC::linkVirtualFor):
894         (JSC::linkPolymorphicCall):
895         * jit/ThunkGenerators.cpp:
896         (JSC::throwExceptionFromCallSlowPathGenerator):
897         (JSC::slowPathFor):
898         (JSC::linkCallThunkGenerator):
899         (JSC::virtualThunkFor):
900         (JSC::arityFixupGenerator):
901         (JSC::unreachableGenerator):
902         (JSC::baselineGetterReturnThunkGenerator):
903         * jit/ThunkGenerators.h:
904         * llint/LowLevelInterpreter.asm:
905         * llint/LowLevelInterpreter32_64.asm:
906         * llint/LowLevelInterpreter64.asm:
907         * runtime/CommonSlowPaths.h:
908         (JSC::CommonSlowPaths::arityCheckFor):
909         (JSC::CommonSlowPaths::opIn):
910         * runtime/Options.h:
911         * tests/stress/mutual-tail-call-no-stack-overflow.js: Added.
912         (shouldThrow):
913         (sloppyCountdown.even):
914         (sloppyCountdown.odd):
915         (strictCountdown.even):
916         (strictCountdown.odd):
917         (strictCountdown):
918         (odd):
919         (even):
920         * tests/stress/tail-call-no-stack-overflow.js: Added.
921         (shouldThrow):
922         (strictLoop):
923         (strictLoopArityFixup1):
924         (strictLoopArityFixup2):
925         * tests/stress/tail-call-recognize.js: Added.
926         (callerMustBeRun):
927         (callerMustBeStrict):
928         (runTests):
929         * tests/stress/tail-call-varargs-no-stack-overflow.js: Added.
930         (shouldThrow):
931         (strictLoop):
932         * tests/stress/tail-calls-dont-overwrite-live-stack.js: Added.
933         (tail):
934         (obj.method):
935         (obj.get fromNative):
936         (getThis):
937
938 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
939
940         LLInt get/put inline caches shouldn't use tons of opcodes
941         https://bugs.webkit.org/show_bug.cgi?id=149106
942
943         Reviewed by Geoffrey Garen.
944
945         Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
946         example, instead of having get_by_id branch on the kind of offset (inline or
947         out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
948         But the problem with this approach is that it doesn't scale. In the property type
949         inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
950         inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
951         new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
952         checks, we'd have 6 * 11 = 66 variants of put_by_id).
953
954         So, this patch completely changes the strategy to mostly using branching inside the
955         opcode implementation. It's unlikely to have a performance effect. For example, the long
956         road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
957         and yet nobody noticed. The regression was because the inline cache was in terms of the
958         structure, not the structure ID, so the code was doing a structure ID table lookup. If we
959         didn't notice that, then we probably won't notice a couple new branches. (Also, this
960         patch fixes that regression - the code no longer does such lookups except in the one
961         unavoidable case in put_by_id transition chain checking.)
962
963         This patch also turns the isDirect operand of put_by_id into a flags field. I will use
964         this flags field to encode the desired type check in bug 148610.
965
966         This patch has no effect on performance according to run-jsc-benchmarks.
967
968         Relanding this patch with LLInt fixes for non-x86. Previous attempts to fix non-x86 LLInt
969         build also caused every 64-bit test to crash on every platform. So the patch got rolled
970         out. This fixes the non-x86 LLInt build while also ensuring that 64-bit platforms don't
971         crash.
972
973         * CMakeLists.txt:
974         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
975         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
976         * JavaScriptCore.xcodeproj/project.pbxproj:
977         * bytecode/BytecodeList.json:
978         * bytecode/BytecodeUseDef.h:
979         (JSC::computeUsesForBytecodeOffset):
980         (JSC::computeDefsForBytecodeOffset):
981         * bytecode/CodeBlock.cpp:
982         (JSC::CodeBlock::printGetByIdOp):
983         (JSC::CodeBlock::printGetByIdCacheStatus):
984         (JSC::CodeBlock::printPutByIdCacheStatus):
985         (JSC::CodeBlock::dumpBytecode):
986         (JSC::CodeBlock::CodeBlock):
987         (JSC::CodeBlock::propagateTransitions):
988         (JSC::CodeBlock::finalizeLLIntInlineCaches):
989         * bytecode/CodeBlock.h:
990         * bytecode/GetByIdStatus.cpp:
991         (JSC::GetByIdStatus::computeFromLLInt):
992         * bytecode/Instruction.h:
993         (JSC::Instruction::Instruction):
994         * bytecode/PutByIdFlags.cpp: Added.
995         (WTF::printInternal):
996         * bytecode/PutByIdFlags.h: Added.
997         * bytecode/PutByIdStatus.cpp:
998         (JSC::PutByIdStatus::computeFromLLInt):
999         * bytecode/UnlinkedCodeBlock.h:
1000         (JSC::UnlinkedInstruction::UnlinkedInstruction):
1001         * bytecompiler/BytecodeGenerator.cpp:
1002         (JSC::BytecodeGenerator::emitPutById):
1003         (JSC::BytecodeGenerator::emitDirectPutById):
1004         * dfg/DFGByteCodeParser.cpp:
1005         (JSC::DFG::ByteCodeParser::parseBlock):
1006         * dfg/DFGCapabilities.cpp:
1007         (JSC::DFG::capabilityLevel):
1008         * jit/JIT.cpp:
1009         (JSC::JIT::privateCompileMainPass):
1010         (JSC::JIT::privateCompileSlowCases):
1011         * jit/JITPropertyAccess.cpp:
1012         (JSC::JIT::emit_op_put_by_id):
1013         * jit/JITPropertyAccess32_64.cpp:
1014         (JSC::JIT::emit_op_put_by_id):
1015         * llint/LLIntSlowPaths.cpp:
1016         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1017         * llint/LowLevelInterpreter32_64.asm:
1018         * llint/LowLevelInterpreter64.asm:
1019
1020 2015-09-14  Commit Queue  <commit-queue@webkit.org>
1021
1022         Unreviewed, rolling out r189751, r189752, and r189754.
1023         https://bugs.webkit.org/show_bug.cgi?id=149143
1024
1025         caused crashes everywhere (Requested by alexchristensen on
1026         #webkit).
1027
1028         Reverted changesets:
1029
1030         "LLInt get/put inline caches shouldn't use tons of opcodes"
1031         https://bugs.webkit.org/show_bug.cgi?id=149106
1032         http://trac.webkit.org/changeset/189751
1033
1034         "Unreviewed, fix non-x86 LLInt build."
1035         http://trac.webkit.org/changeset/189752
1036
1037         "Unreviewed, really fix non-x86 LLInt build without also
1038         breaking everything else."
1039         http://trac.webkit.org/changeset/189754
1040
1041 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
1042
1043         Unreviewed, really fix non-x86 LLInt build without also breaking everything else.
1044
1045         * llint/LowLevelInterpreter64.asm:
1046
1047 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
1048
1049         Unreviewed, fix non-x86 LLInt build.
1050
1051         * llint/LowLevelInterpreter64.asm:
1052
1053 2015-09-13  Filip Pizlo  <fpizlo@apple.com>
1054
1055         LLInt get/put inline caches shouldn't use tons of opcodes
1056         https://bugs.webkit.org/show_bug.cgi?id=149106
1057
1058         Reviewed by Geoffrey Garen.
1059
1060         Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
1061         example, instead of having get_by_id branch on the kind of offset (inline or
1062         out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
1063         But the problem with this approach is that it doesn't scale. In the property type
1064         inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
1065         inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
1066         new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
1067         checks, we'd have 6 * 11 = 66 variants of put_by_id).
1068
1069         So, this patch completely changes the strategy to mostly using branching inside the
1070         opcode implementation. It's unlikely to have a performance effect. For example, the long
1071         road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
1072         and yet nobody noticed. The regression was because the inline cache was in terms of the
1073         structure, not the structure ID, so the code was doing a structure ID table lookup. If we
1074         didn't notice that, then we probably won't notice a couple new branches. (Also, this
1075         patch fixes that regression - the code no longer does such lookups except in the one
1076         unavoidable case in put_by_id transition chain checking.)
1077
1078         This patch also turns the isDirect operand of put_by_id into a flags field. I will use
1079         this flags field to encode the desired type check in bug 148610.
1080
1081         This patch has no effect on performance according to run-jsc-benchmarks.
1082
1083         * CMakeLists.txt:
1084         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1085         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1086         * JavaScriptCore.xcodeproj/project.pbxproj:
1087         * bytecode/BytecodeList.json:
1088         * bytecode/BytecodeUseDef.h:
1089         (JSC::computeUsesForBytecodeOffset):
1090         (JSC::computeDefsForBytecodeOffset):
1091         * bytecode/CodeBlock.cpp:
1092         (JSC::CodeBlock::printGetByIdOp):
1093         (JSC::CodeBlock::printGetByIdCacheStatus):
1094         (JSC::CodeBlock::printPutByIdCacheStatus):
1095         (JSC::CodeBlock::dumpBytecode):
1096         (JSC::CodeBlock::CodeBlock):
1097         (JSC::CodeBlock::propagateTransitions):
1098         (JSC::CodeBlock::finalizeLLIntInlineCaches):
1099         * bytecode/CodeBlock.h:
1100         * bytecode/GetByIdStatus.cpp:
1101         (JSC::GetByIdStatus::computeFromLLInt):
1102         * bytecode/Instruction.h:
1103         (JSC::Instruction::Instruction):
1104         * bytecode/PutByIdFlags.cpp: Added.
1105         (WTF::printInternal):
1106         * bytecode/PutByIdFlags.h: Added.
1107         * bytecode/PutByIdStatus.cpp:
1108         (JSC::PutByIdStatus::computeFromLLInt):
1109         * bytecode/UnlinkedCodeBlock.h:
1110         (JSC::UnlinkedInstruction::UnlinkedInstruction):
1111         * bytecompiler/BytecodeGenerator.cpp:
1112         (JSC::BytecodeGenerator::emitPutById):
1113         (JSC::BytecodeGenerator::emitDirectPutById):
1114         * dfg/DFGAbstractInterpreterInlines.h:
1115         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1116         * dfg/DFGByteCodeParser.cpp:
1117         (JSC::DFG::ByteCodeParser::parseBlock):
1118         * dfg/DFGCapabilities.cpp:
1119         (JSC::DFG::capabilityLevel):
1120         * jit/JIT.cpp:
1121         (JSC::JIT::privateCompileMainPass):
1122         (JSC::JIT::privateCompileSlowCases):
1123         * jit/JITPropertyAccess.cpp:
1124         (JSC::JIT::emit_op_put_by_id):
1125         * jit/JITPropertyAccess32_64.cpp:
1126         (JSC::JIT::emit_op_put_by_id):
1127         * llint/LLIntSlowPaths.cpp:
1128         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1129         * llint/LowLevelInterpreter32_64.asm:
1130         * llint/LowLevelInterpreter64.asm:
1131
1132 2015-09-14  Alex Christensen  <achristensen@webkit.org>
1133
1134         Progress towards CMake on Mac.
1135         https://bugs.webkit.org/show_bug.cgi?id=149123
1136
1137         Reviewed by Chris Dumez.
1138
1139         * CMakeLists.txt:
1140         Make forwarding headers for the replay subdirectory.
1141         * PlatformMac.cmake:
1142         Make forwarding headers for the generated inspector headers. 
1143         They should eventually either be packaged correctly with JavaScriptCore headers and included correctly.
1144
1145 2015-09-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1146
1147         [ES6] Cache the resolution result in JSModuleRecord
1148         https://bugs.webkit.org/show_bug.cgi?id=148896
1149
1150         Reviewed by Saam Barati.
1151
1152         The resolveExport operation is frequently called. For example,
1153         1. When instantiating the module environment, we call it for each exported name and imported
1154            name.
1155         2. When linking the imported module environment to the code block, we call it to resolve the
1156            resolution.
1157         3. When looking up the property from the namespace object, we call it to look up the original
1158            module for the imported binding.
1159         4. When creating the namespace object, we need to collect all the exported names from the module
1160            and need to resolve them by calling resolveExport.
1161
1162         However, resolveExport takes some cost. It traces the imported modules and resolves the reference
1163         queried by the original module.
1164
1165         The resolveExport operation is pure function; given a module record and an export name,
1166         it always returns the same result. So we cache resolution results in the module record to avoid
1167         repeated resolveExport calls with the same arguments.
1168         Here, we only cache the correctly resolved references, since,
1169         1. We rarely looked up the non-correctly-resolved ones. In the linking phase, attempting to
1170            resolve non-correctly-resolved ones throws a syntax error. So only namespace object creation
1171            phase does it in a syntax valid script.
1172         2. This strategy limits the size of the cache map. The number of the correctly exported bindings
1173            is defined by the modules' code. So the size does not become infinitely large.
1174
1175         Currently, the all modules cannot be linked twice. For example,
1176
1177           graph 1
1178
1179           -> (A) -> (B)
1180
1181           graph 2
1182
1183           -> (C) -> (A) -> (B)
1184
1185         We cannot test the behavior now because when executing the graph 2, (A) and (B) are already linked,
1186         it raises an error in the current loader spec. But it should be allowed[1] since it will occur when
1187         there is multiple module tag in WebCore.
1188
1189         [1]: https://github.com/whatwg/loader/issues/41
1190
1191         * runtime/JSModuleRecord.cpp:
1192         (JSC::JSModuleRecord::ResolveQuery::Hash::hash):
1193         (JSC::JSModuleRecord::ResolveQuery::Hash::equal):
1194         (JSC::JSModuleRecord::cacheResolution):
1195         (JSC::ResolveQueryHash::hash): Deleted.
1196         (JSC::ResolveQueryHash::equal): Deleted.
1197         (JSC::resolveExportLoop): Deleted.
1198         * runtime/JSModuleRecord.h:
1199         * tests/modules/caching-should-not-make-ambiguous.js: Added.
1200         * tests/modules/caching-should-not-make-ambiguous/A.js: Added.
1201         * tests/modules/caching-should-not-make-ambiguous/B.js: Added.
1202         * tests/modules/caching-should-not-make-ambiguous/C.js: Added.
1203         * tests/modules/caching-should-not-make-ambiguous/D.js: Added.
1204         * tests/modules/caching-should-not-make-ambiguous/main.js: Added.
1205         * tests/modules/different-view.js: Added.
1206         (from.string_appeared_here.shouldThrow):
1207         * tests/modules/different-view/A.js: Added.
1208         * tests/modules/different-view/B.js: Added.
1209         * tests/modules/different-view/C.js: Added.
1210         * tests/modules/different-view/D.js: Added.
1211         * tests/modules/different-view/E.js: Added.
1212         * tests/modules/different-view/main.js: Added.
1213         * tests/modules/fallback-ambiguous.js: Added.
1214         (from.string_appeared_here.shouldThrow):
1215         * tests/modules/fallback-ambiguous/A.js: Added.
1216         * tests/modules/fallback-ambiguous/B.js: Added.
1217         * tests/modules/fallback-ambiguous/C.js: Added.
1218         * tests/modules/fallback-ambiguous/D.js: Added.
1219         * tests/modules/fallback-ambiguous/E.js: Added.
1220         * tests/modules/fallback-ambiguous/main.js: Added.
1221         * tests/modules/self-star-link.js: Added.
1222         * tests/modules/self-star-link/A.js: Added.
1223         * tests/modules/self-star-link/B.js: Added.
1224         * tests/modules/self-star-link/C.js: Added.
1225         * tests/modules/self-star-link/D.js: Added.
1226         * tests/modules/self-star-link/E.js: Added.
1227         * tests/modules/uncacheable-when-see-star.js: Added.
1228         * tests/modules/uncacheable-when-see-star/A-pre.js: Added.
1229         * tests/modules/uncacheable-when-see-star/A.js: Added.
1230         * tests/modules/uncacheable-when-see-star/B.js: Added.
1231         * tests/modules/uncacheable-when-see-star/C.js: Added.
1232         * tests/modules/uncacheable-when-see-star/D.js: Added.
1233         * tests/modules/uncacheable-when-see-star/E-pre.js: Added.
1234         * tests/modules/uncacheable-when-see-star/E.js: Added.
1235         * tests/modules/uncacheable-when-see-star/main1.js: Added.
1236         * tests/modules/uncacheable-when-see-star/main2.js: Added.
1237
1238 2015-09-14  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1239
1240         Implement the arithmetic instructions for floats in WebAssembly
1241         https://bugs.webkit.org/show_bug.cgi?id=149102
1242
1243         Reviewed by Geoffrey Garen.
1244
1245         This patch implements the arithmetic instructions for floats (float32)
1246         in WebAssembly by converting the float operands to doubles, performing
1247         the equivalent double instructions, and converting the result back to
1248         float. The asm.js spec says that "As proved in 'When is double rounding
1249         innocuous?' (Figueroa 1995), both the 32- and 64-bit versions of
1250         standard arithmetic operations produce equivalent results when given
1251         32-bit inputs and coerced to 32-bit outputs."
1252         (http://asmjs.org/spec/latest/#floatish)
1253
1254         This patch also pads WebAssembly call frames by maxFrameExtentForSlowPathCall,
1255         so that there is no need to adjust the stack pointer every time we make
1256         a slow path call.
1257
1258         * tests/stress/wasm-arithmetic-float32.js:
1259         * tests/stress/wasm/arithmetic-float32.wasm:
1260         * wasm/WASMFunctionCompiler.h:
1261         (JSC::WASMFunctionCompiler::startFunction):
1262         (JSC::WASMFunctionCompiler::buildUnaryF32):
1263         (JSC::WASMFunctionCompiler::buildBinaryF32):
1264         (JSC::WASMFunctionCompiler::callOperation):
1265         (JSC::WASMFunctionCompiler::callAndUnboxResult):
1266         (JSC::WASMFunctionCompiler::endFunction): Deleted.
1267         (JSC::WASMFunctionCompiler::buildBinaryI32): Deleted.
1268         * wasm/WASMFunctionParser.cpp:
1269         (JSC::WASMFunctionParser::parseExpressionF32):
1270         (JSC::WASMFunctionParser::parseUnaryExpressionF32):
1271         (JSC::WASMFunctionParser::parseBinaryExpressionF32):
1272         * wasm/WASMFunctionParser.h:
1273         * wasm/WASMFunctionSyntaxChecker.h:
1274         (JSC::WASMFunctionSyntaxChecker::buildUnaryF32):
1275         (JSC::WASMFunctionSyntaxChecker::buildBinaryF32):
1276
1277 2015-09-13  Geoffrey Garen  <ggaren@apple.com>
1278
1279         Eden GC should not try to jettison old CodeBlocks in the remembered set
1280         https://bugs.webkit.org/show_bug.cgi?id=149108
1281
1282         Reviewed by Saam Barati.
1283
1284         All we know about objects in the remembered set is that they must be
1285         visited. We don't know whether they're referenced or not because we
1286         won't mark the objects that point to them.
1287
1288         Therefore, it's incorrect for a CodeBlock to consider jettisoning
1289         itself when it's marked as a part of the remembered set: Some
1290         old object might have visited the CodeBlock strongly if given the chance.
1291
1292         I believe this doesn't cause any problems currently because we happen
1293         to visit all strong references to all CodeBlocks elligible for jettison
1294         during every GC.
1295
1296         However, this behavior is a logical oddity that tripped me up, and I
1297         believe it will start causing real problems once we start to jettison
1298         baseline CodeBlocks, since we do not visit all strong references to all
1299         baseline CodeBlocks during every GC.
1300
1301         * heap/CodeBlockSet.cpp:
1302         (JSC::CodeBlockSet::clearMarksForEdenCollection):
1303         (JSC::CodeBlockSet::traceMarked): Be sure to visit the remembered set
1304         strongly, in order to prohibit jettisoning.
1305
1306         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
1307         * heap/CodeBlockSet.h: Track the remembered set during eden GCs.
1308
1309 2015-09-11  Filip Pizlo  <fpizlo@apple.com>
1310
1311         REGRESSION(r189585): run-perf-tests Speedometer fails with a console error
1312         https://bugs.webkit.org/show_bug.cgi?id=149066
1313
1314         Reviewed by Michael Saboff.
1315
1316         The bug here was that the new IC code was calling actionForCell() more than once. That's
1317         illegal, since when actionForCell() returns RetryCacheLater, it means that it changed some
1318         object's Structure. The Repatch code was doing things like "if (actionForCell(blah) ==
1319         AttemptToCache)" in more than one place, so that if the first such expression was false, then
1320         we'd fall through to the next one. It's possible for the first call to return RetryCacheLater,
1321         in which case our view of the world just got clobbered and we need to return, and then the
1322         second call will probably return AttemptToCache because it *thinks* that we had bailed the last
1323         time and we're now in a future IC invocation.
1324
1325         The solution is to cache the actionForCell() result. This is a bit tricky, because we need to
1326         do this after we check if we're in a proxy.
1327
1328         Debugging bugs like these requires adding ad hoc bisection code in various places. We already
1329         had the basic hooks for this. This patch makes those hooks a bit more useful. In the case of
1330         the LLInt->JIT tier-up hooks, it adds a CodeBlock* argument so that we can bisect based on the
1331         CodeBlock. In the case of Repatch, it puts the Options::forceICFailure() check in a helper
1332         function that also takes ExecState*, which allows us to bisect on either CodeBlock or
1333         CodeOrigin.
1334
1335         * jit/Repatch.cpp:
1336         (JSC::actionForCell):
1337         (JSC::forceICFailure):
1338         (JSC::tryCacheGetByID):
1339         (JSC::tryCachePutByID):
1340         (JSC::tryRepatchIn):
1341         * llint/LLIntSlowPaths.cpp:
1342         (JSC::LLInt::shouldJIT):
1343         (JSC::LLInt::jitCompileAndSetHeuristics):
1344         (JSC::LLInt::entryOSR):
1345         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1346         * tests/stress/retry-cache-later.js:
1347
1348 2015-09-11  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1349
1350         Implement the relational instructions for floats in WebAssembly
1351         https://bugs.webkit.org/show_bug.cgi?id=149080
1352
1353         Reviewed by Geoffrey Garen.
1354
1355         This patch implements the relational instructions for floats (float32)
1356         in WebAssembly by converting float operands to doubles and then
1357         comparing them using the existing double comparison instructions in the
1358         macro assembler.
1359
1360         * tests/stress/wasm-relational.js:
1361         * tests/stress/wasm/relational.wasm:
1362         * wasm/WASMFunctionCompiler.h:
1363         (JSC::WASMFunctionCompiler::buildRelationalF32):
1364         * wasm/WASMFunctionParser.cpp:
1365         (JSC::WASMFunctionParser::parseExpressionI32):
1366         (JSC::WASMFunctionParser::parseRelationalF32ExpressionI32):
1367         * wasm/WASMFunctionParser.h:
1368         * wasm/WASMFunctionSyntaxChecker.h:
1369         (JSC::WASMFunctionSyntaxChecker::buildRelationalF32):
1370
1371 2015-09-11  Nan Wang  <n_wang@apple.com>
1372
1373         AX: ARIA 1.1 @aria-current
1374         https://bugs.webkit.org/show_bug.cgi?id=146012
1375
1376         Reviewed by Chris Fleizach.
1377
1378         Updated inspector to support aria-current.
1379
1380         * inspector/protocol/DOM.json:
1381
1382 2015-09-11  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1383
1384         Add initial support for floats in WebAsssembly
1385         https://bugs.webkit.org/show_bug.cgi?id=149062
1386
1387         Reviewed by Geoffrey Garen.
1388
1389         Implement the ConstantPoolIndex, Immediate, GetLocal, and GetGlobal
1390         instructions for floats (float32) in WebAssembly.
1391
1392         * tests/stress/wasm-arithmetic-float32.js: Added.
1393         (shouldBe):
1394         * tests/stress/wasm-globals.js:
1395         * tests/stress/wasm-type-conversion.js:
1396         * tests/stress/wasm/arithmetic-float32.wasm: Added.
1397         * tests/stress/wasm/globals.wasm:
1398         * tests/stress/wasm/type-conversion.wasm:
1399         * wasm/WASMConstants.h:
1400         * wasm/WASMFunctionCompiler.h:
1401         (JSC::WASMFunctionCompiler::buildSetLocal):
1402         (JSC::WASMFunctionCompiler::buildReturn):
1403         (JSC::WASMFunctionCompiler::buildImmediateF32):
1404         (JSC::WASMFunctionCompiler::buildGetLocal):
1405         * wasm/WASMFunctionParser.cpp:
1406         (JSC::WASMFunctionParser::parseExpression):
1407         (JSC::WASMFunctionParser::parseExpressionF32):
1408         (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF32):
1409         (JSC::WASMFunctionParser::parseImmediateExpressionF32):
1410         (JSC::WASMFunctionParser::parseGetLocalExpressionF32):
1411         (JSC::WASMFunctionParser::parseGetGlobalExpressionF32):
1412         * wasm/WASMFunctionParser.h:
1413         * wasm/WASMFunctionSyntaxChecker.h:
1414         (JSC::WASMFunctionSyntaxChecker::buildImmediateF32):
1415         * wasm/WASMReader.cpp:
1416         (JSC::WASMReader::readOpExpressionF32):
1417         * wasm/WASMReader.h:
1418
1419 2015-09-11  Geoffrey Garen  <ggaren@apple.com>
1420
1421         Try to fix the CLOOP build.
1422
1423         Unreviewed.
1424
1425         * bytecode/CodeBlock.cpp:
1426         (JSC::CodeBlock::finalizeBaselineJITInlineCaches):
1427         (JSC::CodeBlock::finalizeUnconditionally):
1428
1429 2015-09-11  Csaba Osztrogon√°c  <ossy@webkit.org>
1430
1431         [EFL] Fix WASM build
1432         https://bugs.webkit.org/show_bug.cgi?id=149065
1433
1434         Reviewed by Darin Adler.
1435
1436         * wasm/WASMFunctionParser.cpp:
1437
1438 2015-09-11  Geoffrey Garen  <ggaren@apple.com>
1439
1440         JavaScriptCore should discard optimized code after some time
1441         https://bugs.webkit.org/show_bug.cgi?id=149048
1442
1443         Reviewed by Michael Saboff.
1444
1445         This patch adds a new jettison type -- JettisonDueToOldAge -- and starts
1446         using it for DFG and FTL code. Baseline and LLInt code will come in a
1447         follow-up patch.
1448
1449         The primary goal is to save memory. Some popular websites leave about 10MB
1450         of dead code sitting around immediately after they finish loading.
1451
1452         Throwing away code periodically might also save us from profiling
1453         pathologies that lead to performance dead ends.
1454
1455         * bytecode/CodeBlock.cpp:
1456         (JSC::CodeBlock::visitAggregate): Updated for rename, and removed a
1457         stale comment.
1458
1459         (JSC::CodeBlock::shouldVisitStrongly): Renamed to shouldVisitStrongly
1460         because the practical effect of this function is to trigger a call to
1461         visitStrongly.
1462
1463         (JSC::CodeBlock::isKnownToBeLiveDuringGC): Check the
1464         m_visitStronglyHasBeenCalled flag instead of
1465         shouldImmediatelyAssumeLivenessDuringScan / shouldVisitStrongly because
1466         m_visitStronglyHasBeenCalled can be set by anybody even if the CodeBlock
1467         would not otherwise visit itself strongly.
1468
1469         (JSC::CodeBlock::shouldJettisonDueToWeakReference): New helper function
1470         for readability.
1471
1472         (JSC::CodeBlock::shouldJettisonDueToOldAge): New helper function that
1473         tells if a CodeBlock is old enough for deletion.
1474
1475         (JSC::CodeBlock::determineLiveness): There's no need to check
1476         shouldImmediatelyAssumeLivenessDuringScan here because we will not call
1477         this function if shouldImmediatelyAssumeLivenessDuringScan is true.
1478         Also, it's just not clear -- if someone chooses to call this function --
1479         that it would be safe to ignore them simply because
1480         shouldImmediatelyAssumeLivenessDuringScan was true.
1481
1482         (JSC::CodeBlock::finalizeLLIntInlineCaches): Moved code out into a helper
1483         function to make the main function more readable.
1484
1485         (JSC::CodeBlock::finalizeBaselineJITInlineCaches): Ditto.
1486
1487         (JSC::CodeBlock::finalizeUnconditionally): Added code for jettisoning a
1488         CodeBlock if it is too old. Moved large sections of code into helper
1489         functions to aid readability in this function.
1490
1491         (JSC::CodeBlock::jettison): Account for the fact that we might jettison
1492         a CodeBlock without OSR exit and without requiring a stack shoot-down.
1493
1494         * bytecode/CodeBlock.h:
1495         (JSC::CodeBlock::setInstallTime):
1496         (JSC::CodeBlock::timeSinceInstall): Track CodeBlock age to help us
1497         decide when to delete.
1498
1499         * jit/JITCode.h:
1500         (JSC::JITCode::timeToLive): Static limits on CodeBlock lifetime. I got
1501         these numbers from the place where numbers come from. 
1502
1503         * profiler/ProfilerJettisonReason.cpp:
1504         (WTF::printInternal):
1505         * profiler/ProfilerJettisonReason.h: Updated for new jettison type.
1506
1507         * runtime/Executable.cpp:
1508         (JSC::ScriptExecutable::installCode): Record install time so that we
1509         can measure how old a CodeBlock is.
1510
1511 2015-09-11  Andreas Kling  <akling@apple.com>
1512
1513         [JSC] Weak should only accept cell pointees.
1514         <https://webkit.org/b/148955>
1515
1516         Reviewed by Geoffrey Garen.
1517
1518         Since WeakImpls only support pointing to JSCell derived objects,
1519         enforce that at compile time by having the API use JSCell* instead of JSValue.
1520
1521         WeakHandleOwner callbacks now get JSCell& and JSCell*& respectively instead
1522         of wrapping the cell pointer in a Handle<Unknown>.
1523
1524         Also added a static_assert so Weak<T> can't be instantiated with a T that's
1525         not convertible to JSCell.
1526
1527         * API/JSAPIWrapperObject.mm:
1528         (JSAPIWrapperObjectHandleOwner::finalize):
1529         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
1530         (JSC::JSAPIWrapperObject::finishCreation):
1531         * API/JSManagedValue.mm:
1532         (JSManagedValueHandleOwner::isReachableFromOpaqueRoots):
1533         (JSManagedValueHandleOwner::finalize):
1534         * builtins/BuiltinExecutables.cpp:
1535         (JSC::BuiltinExecutables::finalize):
1536         * builtins/BuiltinExecutables.h:
1537         * heap/Heap.cpp:
1538         (JSC::Heap::addFinalizer):
1539         (JSC::Heap::FinalizerOwner::finalize):
1540         * heap/Heap.h:
1541         * heap/WeakBlock.cpp:
1542         (JSC::WeakBlock::visit):
1543         (JSC::WeakBlock::reap):
1544         * heap/WeakHandleOwner.cpp:
1545         (JSC::WeakHandleOwner::isReachableFromOpaqueRoots):
1546         (JSC::WeakHandleOwner::finalize):
1547         * heap/WeakHandleOwner.h:
1548         * heap/WeakImpl.h:
1549         (JSC::WeakImpl::WeakImpl):
1550         (JSC::WeakImpl::state):
1551         (JSC::WeakImpl::cell):
1552         (JSC::WeakImpl::asWeakImpl):
1553         (JSC::WeakImpl::jsValue): Deleted.
1554         * heap/WeakInlines.h:
1555         (JSC::Weak<T>::Weak):
1556         (JSC::>):
1557         (JSC::Weak<T>::operator):
1558         (JSC::Weak<T>::get):
1559         (JSC::Weak<T>::was):
1560         * heap/WeakSet.h:
1561         * heap/WeakSetInlines.h:
1562         (JSC::WeakSet::allocate):
1563         (JSC::WeakBlock::finalize):
1564         * jit/JITThunks.cpp:
1565         (JSC::JITThunks::finalize):
1566         * jit/JITThunks.h:
1567         * jsc.cpp:
1568         (WTF::ElementHandleOwner::isReachableFromOpaqueRoots): Deleted.
1569         * runtime/JSCell.h:
1570         (JSC::jsCast):
1571         * runtime/RegExpCache.cpp:
1572         (JSC::RegExpCache::finalize):
1573         * runtime/RegExpCache.h:
1574         * runtime/Structure.cpp:
1575         (JSC::StructureTransitionTable::singleTransition):
1576         (JSC::StructureTransitionTable::setSingleTransition):
1577
1578 2015-09-10  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1579
1580         Implement switch statements in WebAssembly
1581         https://bugs.webkit.org/show_bug.cgi?id=149051
1582
1583         Reviewed by Geoffrey Garen.
1584
1585         This patch implements switch statements in WebAssembly using the
1586         JSC::BinarySwitch class.
1587
1588         * tests/stress/wasm-control-flow.js:
1589         * tests/stress/wasm/control-flow.wasm:
1590         * wasm/WASMFunctionCompiler.h:
1591         (JSC::WASMFunctionCompiler::buildSwitch):
1592         * wasm/WASMFunctionParser.cpp:
1593         (JSC::WASMFunctionParser::parseSwitchStatement):
1594         * wasm/WASMFunctionSyntaxChecker.h:
1595         (JSC::WASMFunctionSyntaxChecker::buildSwitch):
1596
1597 2015-09-10  Filip Pizlo  <fpizlo@apple.com>
1598
1599         Structure should be able to tell you if it had ever been a dictionary
1600         https://bugs.webkit.org/show_bug.cgi?id=149047
1601
1602         Reviewed by Mark Lam.
1603
1604         Introduces the hasBeenDictionary flag to Structure, which tells you if this structure or
1605         any of its ancestors is a dictionary. We already implicitly tracked this for DFG
1606         watchpoint optimizations, so this is mainly just decoupling that existing logic from
1607         watchpoints. Having Structure::hasBeenDictionary() enables some of the heuristics in the
1608         property type inference work (https://bugs.webkit.org/show_bug.cgi?id=148610).
1609
1610         * runtime/Structure.cpp:
1611         (JSC::Structure::Structure):
1612         (JSC::Structure::toDictionaryTransition):
1613         (JSC::Structure::dump):
1614         * runtime/Structure.h:
1615
1616 2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>
1617
1618         Unreviewed, fix Windows file loading in JSC shell after r189583
1619         https://bugs.webkit.org/show_bug.cgi?id=148917
1620
1621         Should load the script files with the binary mode.
1622         Since these loading functions are only used for the simple test scripts,
1623         we just use ftell / fseek now.
1624
1625         * jsc.cpp:
1626         (fillBufferWithContentsOfFile):
1627
1628 2015-09-10  Michael Saboff  <msaboff@apple.com>
1629
1630         REGRESSION(r189575): Appears to break ARM64 linux builds
1631         https://bugs.webkit.org/show_bug.cgi?id=149044
1632
1633         Reviewed by Filip Pizlo.
1634
1635         Changed the use of the ARM64 "fp", a register alias, to be "x29", the real register name.
1636
1637         * llint/LowLevelInterpreter.asm:
1638
1639 2015-09-09  Filip Pizlo  <fpizlo@apple.com>
1640
1641         There should be one stub hanging off an inline cache that contains code for all of the cases, rather than forming a linked list consisting of one stub per case
1642         https://bugs.webkit.org/show_bug.cgi?id=148717
1643
1644         Reviewed by Michael Saboff.
1645
1646         This is a major rewrite of the JSC get/put/in inline caches (ICs), motivated by the need to add
1647         fancy new kinds of inline caches for property type inference (https://webkit.org/b/148610).
1648
1649         Previously, our inline caches had some problems that made them difficult to work with. It was
1650         impossible to change any code that was previously generated by the IC except by blowing the
1651         whole IC away, the ICs scaled poorly if there were many cases, and there was a lot of duplicate
1652         and ad hoc code.
1653
1654         Impossible to regenerate a previously generated stub: Say that some access (o.f = v) causes our
1655         IC code to emit some stub; let's call it stub1. Then later we find that we need to emit a
1656         different stub, stub2, where we think that stub2 might subsume stub1. We say that stub2
1657         subsumes stub1 if failing to execute stub2 to completion means that we are guaranteed to fail
1658         to execute stub1 to completion. This could happen in trunk if stub2 has the same base structure
1659         as stub1 but different prototype conditions. It could happen with property type inference if
1660         stub2 has a looser type check on v than stub1 did. Currently, if this happened, we would emit
1661         stub2 and have its slow path jump to stub1. Hence, we would still end up executing the checks
1662         of stub1 before falling through to the slow path. This gets bad when there are many stubs.
1663         Stub1 might be in front of a bunch of other stubs, so when we add stub2, we will end up
1664         executing both stub2's and stub1's checks before falling through to the other stubs. It would
1665         be better if we could remove stub1 from the list at this point. But since stub1 could be linked
1666         to from a different stub that we had already generated, we'd have to have a way of patching
1667         stubs or regenerating them from scratch. This is currenty impossible because we just don't keep
1668         around enough meta-data to mess with a stub after it's generated. After this change, we never
1669         link new stubs onto a linked list of pre-existing stubs; instead each IC will have one stub
1670         hanging off of it and we always regenerate that one stub from scratch. That one stub contains
1671         either a BinarySwitch or a branch cascade to select one of the AccessCases. Each AccessCase is
1672         an object that describes everything we need to regenerate it in the future. This means that
1673         when we add a new case to an IC stub, we can figure out which previous cases this one subsumes.
1674
1675         Poor scalability when there are many cases: Previously, the cases of a polymorphic inline cache
1676         formed a linked list of branches. This meant that the complexity of an inline cache grew
1677         linearly with the number of cases. This change turns this into a BinarySwitch in most cases,
1678         leading to logarithmic scaling.
1679
1680         Duplicate code between get, put, and in: The code for op_get_by_id, op_put_by_id, and op_in
1681         inline caches grew independently and ended up having a lot of duplicate code. We had the worst
1682         kinds of duplicate code. In some cases, the code was copy-pasted. In other cases, we wrote code
1683         that felt like it was new despite the fact that it was logically identical to code that was
1684         already written elsewhere. The main sources of duplication were in selecting a scratch
1685         register, checking all of the ObjectPropertyConditions and the base structure, the pro forma
1686         involved in generating a stub, and the data structures needed to describe all of the access
1687         cases. This change deduplicates all of that code. Now, all of those ICs use the same classes:
1688         the PolymorphicAccess and AccessCase. There is code in those classes that handles all of the
1689         common things, and for the most part the only code that actually specializes for the kind of
1690         access is in some switch statement in AccessCase::generate().
1691
1692         Special-casing of array length and string length: Previously, array.length and string.length
1693         were handled in an ad hoc manner in the get_by_id repatching code. The handling was separate
1694         from the polymorphic get_by_id handling, which meant that we could not handle polymorphic
1695         length accesses if one of the length cases was either array or string length. For example, if
1696         you had "o.length" where the length was either array length or a vanilla length property, then
1697         the get_by_id inline cache would either emit a monomorphic stub for array length, or a
1698         monomorphic stub for the vanilla length property, but never a polymorphic stub (or list) that
1699         could do both. This change addresses this problem by folding array length and string length
1700         into the polymorphic get_by_id code.
1701
1702         This was meant to be a perf-neutral change to enable property type inference, but it ended up
1703         being a 1% Octane speed-up, mainly because of a 14% speed-up in raytrace. This isn't too
1704         surprising, since that test does use inline caches a lot and this change makes inline caches
1705         more scalable.
1706
1707         This also fixes and adds a test for a BinarySwitch bug. BinarySwitch had an optimization for
1708         consecutive integer cases. Using it on typed array structures triggers this bug. It's a hard
1709         bug to trigger any other way because our other switch optimizations will usually use a jump
1710         table in case of consecutive integers.
1711
1712         * CMakeLists.txt:
1713         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1714         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1715         * JavaScriptCore.xcodeproj/project.pbxproj:
1716         * assembler/MacroAssemblerCodeRef.h:
1717         (JSC::MacroAssemblerCodePtr::dumpWithName):
1718         * bytecode/CodeBlock.cpp:
1719         (JSC::CodeBlock::printGetByIdCacheStatus):
1720         (JSC::CodeBlock::printPutByIdCacheStatus):
1721         (JSC::CodeBlock::propagateTransitions):
1722         (JSC::CodeBlock::getByValInfoMap):
1723         (JSC::CodeBlock::addStubInfo):
1724         (JSC::CodeBlock::findStubInfo):
1725         * bytecode/CodeBlock.h:
1726         (JSC::CodeBlock::stubInfoBegin):
1727         (JSC::CodeBlock::stubInfoEnd):
1728         * bytecode/GetByIdStatus.cpp:
1729         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
1730         * bytecode/PolymorphicAccess.cpp: Copied from Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.cpp.
1731         (JSC::AccessGenerationState::addWatchpoint):
1732         (JSC::AccessGenerationState::restoreScratch):
1733         (JSC::AccessGenerationState::succeed):
1734         (JSC::AccessCase::AccessCase):
1735         (JSC::AccessCase::get):
1736         (JSC::AccessCase::replace):
1737         (JSC::AccessCase::transition):
1738         (JSC::AccessCase::setter):
1739         (JSC::AccessCase::in):
1740         (JSC::AccessCase::getLength):
1741         (JSC::AccessCase::~AccessCase):
1742         (JSC::AccessCase::fromStructureStubInfo):
1743         (JSC::AccessCase::clone):
1744         (JSC::AccessCase::guardedByStructureCheck):
1745         (JSC::AccessCase::alternateBase):
1746         (JSC::AccessCase::canReplace):
1747         (JSC::AccessCase::dump):
1748         (JSC::AccessCase::visitWeak):
1749         (JSC::AccessCase::generateWithGuard):
1750         (JSC::AccessCase::generate):
1751         (JSC::PolymorphicAccess::PolymorphicAccess):
1752         (JSC::PolymorphicAccess::~PolymorphicAccess):
1753         (JSC::PolymorphicAccess::regenerateWithCases):
1754         (JSC::PolymorphicAccess::regenerateWithCase):
1755         (JSC::PolymorphicAccess::visitWeak):
1756         (JSC::PolymorphicAccess::dump):
1757         (JSC::PolymorphicAccess::regenerate):
1758         (WTF::printInternal):
1759         (JSC::GetByIdAccess::GetByIdAccess): Deleted.
1760         (JSC::GetByIdAccess::~GetByIdAccess): Deleted.
1761         (JSC::GetByIdAccess::fromStructureStubInfo): Deleted.
1762         (JSC::GetByIdAccess::visitWeak): Deleted.
1763         (JSC::PolymorphicGetByIdList::PolymorphicGetByIdList): Deleted.
1764         (JSC::PolymorphicGetByIdList::from): Deleted.
1765         (JSC::PolymorphicGetByIdList::~PolymorphicGetByIdList): Deleted.
1766         (JSC::PolymorphicGetByIdList::currentSlowPathTarget): Deleted.
1767         (JSC::PolymorphicGetByIdList::addAccess): Deleted.
1768         (JSC::PolymorphicGetByIdList::isFull): Deleted.
1769         (JSC::PolymorphicGetByIdList::isAlmostFull): Deleted.
1770         (JSC::PolymorphicGetByIdList::didSelfPatching): Deleted.
1771         (JSC::PolymorphicGetByIdList::visitWeak): Deleted.
1772         * bytecode/PolymorphicAccess.h: Copied from Source/JavaScriptCore/bytecode/PolymorphicGetByIdList.h.
1773         (JSC::AccessCase::isGet):
1774         (JSC::AccessCase::isPut):
1775         (JSC::AccessCase::isIn):
1776         (JSC::AccessCase::type):
1777         (JSC::AccessCase::offset):
1778         (JSC::AccessCase::viaProxy):
1779         (JSC::AccessCase::structure):
1780         (JSC::AccessCase::newStructure):
1781         (JSC::AccessCase::conditionSet):
1782         (JSC::AccessCase::additionalSet):
1783         (JSC::AccessCase::customSlotBase):
1784         (JSC::AccessCase::doesCalls):
1785         (JSC::AccessCase::callLinkInfo):
1786         (JSC::AccessCase::RareData::RareData):
1787         (JSC::PolymorphicAccess::isEmpty):
1788         (JSC::PolymorphicAccess::size):
1789         (JSC::PolymorphicAccess::at):
1790         (JSC::PolymorphicAccess::operator[]):
1791         (JSC::GetByIdAccess::GetByIdAccess): Deleted.
1792         (JSC::GetByIdAccess::isSet): Deleted.
1793         (JSC::GetByIdAccess::operator!): Deleted.
1794         (JSC::GetByIdAccess::type): Deleted.
1795         (JSC::GetByIdAccess::structure): Deleted.
1796         (JSC::GetByIdAccess::conditionSet): Deleted.
1797         (JSC::GetByIdAccess::stubRoutine): Deleted.
1798         (JSC::GetByIdAccess::doesCalls): Deleted.
1799         (JSC::PolymorphicGetByIdList::isEmpty): Deleted.
1800         (JSC::PolymorphicGetByIdList::size): Deleted.
1801         (JSC::PolymorphicGetByIdList::at): Deleted.
1802         (JSC::PolymorphicGetByIdList::operator[]): Deleted.
1803         * bytecode/PolymorphicAccessStructureList.h: Removed.
1804         * bytecode/PolymorphicGetByIdList.cpp: Removed.
1805         * bytecode/PolymorphicGetByIdList.h: Removed.
1806         * bytecode/PolymorphicPutByIdList.cpp: Removed.
1807         * bytecode/PolymorphicPutByIdList.h: Removed.
1808         * bytecode/PutByIdStatus.cpp:
1809         (JSC::PutByIdStatus::computeForStubInfo):
1810         * bytecode/StructureStubInfo.cpp:
1811         (JSC::StructureStubInfo::deref):
1812         (JSC::StructureStubInfo::addAccessCase):
1813         (JSC::StructureStubInfo::reset):
1814         (JSC::StructureStubInfo::visitWeakReferences):
1815         * bytecode/StructureStubInfo.h:
1816         (JSC::StructureStubInfo::StructureStubInfo):
1817         (JSC::StructureStubInfo::initGetByIdSelf):
1818         (JSC::StructureStubInfo::initPutByIdReplace):
1819         (JSC::StructureStubInfo::initStub):
1820         (JSC::StructureStubInfo::setSeen):
1821         (JSC::getStructureStubInfoCodeOrigin):
1822         (JSC::isGetByIdAccess): Deleted.
1823         (JSC::isPutByIdAccess): Deleted.
1824         (JSC::isInAccess): Deleted.
1825         (JSC::StructureStubInfo::initGetByIdList): Deleted.
1826         (JSC::StructureStubInfo::initPutByIdTransition): Deleted.
1827         (JSC::StructureStubInfo::initPutByIdList): Deleted.
1828         (JSC::StructureStubInfo::initInList): Deleted.
1829         (JSC::StructureStubInfo::addWatchpoint): Deleted.
1830         * dfg/DFGSpeculativeJIT.cpp:
1831         (JSC::DFG::SpeculativeJIT::compileIn):
1832         * ftl/FTLCompile.cpp:
1833         (JSC::FTL::mmAllocateDataSection):
1834         * jit/AccessorCallJITStubRoutine.cpp: Removed.
1835         * jit/AccessorCallJITStubRoutine.h: Removed.
1836         * jit/AssemblyHelpers.h:
1837         (JSC::AssemblyHelpers::branchIfEmpty):
1838         (JSC::AssemblyHelpers::branchStructure):
1839         (JSC::AssemblyHelpers::boxBooleanPayload):
1840         (JSC::AssemblyHelpers::boxBoolean):
1841         (JSC::AssemblyHelpers::boxInt32):
1842         * jit/BinarySwitch.cpp:
1843         (JSC::BinarySwitch::BinarySwitch):
1844         (JSC::BinarySwitch::build):
1845         (JSC::BinarySwitch::Case::dump):
1846         (JSC::BinarySwitch::BranchCode::dump):
1847         * jit/BinarySwitch.h:
1848         (JSC::BinarySwitch::Case::operator<):
1849         (JSC::BinarySwitch::BranchCode::BranchCode):
1850         * jit/JIT.h:
1851         * jit/JITInlineCacheGenerator.cpp:
1852         (JSC::garbageStubInfo):
1853         (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
1854         (JSC::JITByIdGenerator::JITByIdGenerator):
1855         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1856         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
1857         * jit/JITInlineCacheGenerator.h:
1858         (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
1859         (JSC::JITInlineCacheGenerator::stubInfo):
1860         (JSC::JITByIdGenerator::JITByIdGenerator):
1861         (JSC::JITByIdGenerator::reportSlowPathCall):
1862         * jit/JITOperations.cpp:
1863         * jit/Repatch.cpp:
1864         (JSC::repatchCall):
1865         (JSC::repatchByIdSelfAccess):
1866         (JSC::resetGetByIDCheckAndLoad):
1867         (JSC::resetPutByIDCheckAndLoad):
1868         (JSC::replaceWithJump):
1869         (JSC::tryCacheGetByID):
1870         (JSC::repatchGetByID):
1871         (JSC::appropriateGenericPutByIdFunction):
1872         (JSC::appropriateOptimizingPutByIdFunction):
1873         (JSC::tryCachePutByID):
1874         (JSC::repatchPutByID):
1875         (JSC::tryRepatchIn):
1876         (JSC::repatchIn):
1877         (JSC::resetGetByID):
1878         (JSC::resetPutByID):
1879         (JSC::checkObjectPropertyCondition): Deleted.
1880         (JSC::checkObjectPropertyConditions): Deleted.
1881         (JSC::emitRestoreScratch): Deleted.
1882         (JSC::linkRestoreScratch): Deleted.
1883         (JSC::toString): Deleted.
1884         (JSC::kindFor): Deleted.
1885         (JSC::customFor): Deleted.
1886         (JSC::generateByIdStub): Deleted.
1887         (JSC::patchJumpToGetByIdStub): Deleted.
1888         (JSC::tryBuildGetByIDList): Deleted.
1889         (JSC::buildGetByIDList): Deleted.
1890         (JSC::appropriateListBuildingPutByIdFunction): Deleted.
1891         (JSC::emitPutReplaceStub): Deleted.
1892         (JSC::emitPutTransitionStub): Deleted.
1893         (JSC::tryBuildPutByIdList): Deleted.
1894         (JSC::buildPutByIdList): Deleted.
1895         * jit/ScratchRegisterAllocator.cpp:
1896         (JSC::ScratchRegisterAllocator::lock):
1897         (JSC::ScratchRegisterAllocator::allocateScratch):
1898         * jit/ScratchRegisterAllocator.h:
1899         (JSC::ScratchRegisterAllocator::ScratchRegisterAllocator):
1900         * jsc.cpp:
1901         (GlobalObject::finishCreation):
1902         (functionQuit):
1903         (functionAbort):
1904         (functionFalse1):
1905         (functionFalse2):
1906         * runtime/Options.h:
1907         * tests/stress/array-message-passing.js: Added.
1908         (window.addEventListener):
1909         (window.postMessage):
1910         (window._handleEvents):
1911         (testPassed):
1912         (testFailed):
1913         (classCompare):
1914         (bufferCompare):
1915         (viewCompare):
1916         (typedArrayCompare):
1917         (dataViewCompare):
1918         (dataViewCompare2):
1919         (dataViewCompare3):
1920         (createBuffer):
1921         (createTypedArray):
1922         (createTypedArrayOverBuffer):
1923         (new.DataView):
1924         (testList.testList.concat.basicBufferTypes.map):
1925         (doneTest):
1926
1927 2015-09-10  Geoffrey Garen  <ggaren@apple.com>
1928
1929         CodeBlock::codeType() doesn't need to compute anything
1930         https://bugs.webkit.org/show_bug.cgi?id=149039
1931
1932         Reviewed by Michael Saboff.
1933
1934         CodeBlock already has an m_codeType data member.
1935
1936         * bytecode/CodeBlock.h:
1937         (JSC::CodeBlock::codeType):
1938         (JSC::CodeBlock::putByIdContext):
1939
1940 2015-09-10  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1941
1942         Implement global variables in WebAssembly
1943         https://bugs.webkit.org/show_bug.cgi?id=149031
1944
1945         Reviewed by Geoffrey Garen.
1946
1947         This patch implements global variables in WebAssembly. There are two
1948         types of global variables in the current format that we use (the format
1949         used by <https://github.com/WebAssembly/polyfill-prototype-1>): internal
1950         global variables and imported global variables. This patch does not yet
1951         import values for imported global variables. It will be done in a
1952         subsequent patch.
1953
1954         * tests/stress/wasm-globals.js: Added.
1955         (shouldBe):
1956         * tests/stress/wasm/globals.wasm: Added.
1957         * wasm/JSWASMModule.h:
1958         (JSC::JSWASMModule::globalVariables):
1959         * wasm/WASMFunctionCompiler.h:
1960         (JSC::WASMFunctionCompiler::buildSetGlobal):
1961         (JSC::WASMFunctionCompiler::buildGetGlobal):
1962         * wasm/WASMFunctionParser.cpp:
1963         (JSC::WASMFunctionParser::parseStatement):
1964         (JSC::WASMFunctionParser::parseSetGlobalStatement):
1965         (JSC::WASMFunctionParser::parseExpressionI32):
1966         (JSC::WASMFunctionParser::parseGetGlobalExpressionI32):
1967         (JSC::WASMFunctionParser::parseExpressionF64):
1968         (JSC::WASMFunctionParser::parseGetGlobalExpressionF64):
1969         * wasm/WASMFunctionParser.h:
1970         * wasm/WASMFunctionSyntaxChecker.h:
1971         (JSC::WASMFunctionSyntaxChecker::buildSetGlobal):
1972         (JSC::WASMFunctionSyntaxChecker::buildGetGlobal):
1973         * wasm/WASMModuleParser.cpp:
1974         (JSC::WASMModuleParser::parseGlobalSection):
1975
1976 2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>
1977
1978         Consider long module path name case in Windows
1979         https://bugs.webkit.org/show_bug.cgi?id=148917
1980
1981         Reviewed by Alex Christensen.
1982
1983         The local file system module loader in the JSC shell manages the module files by the absolute path.
1984         However, in Windows, _MAX_PATH is defined as 260. So if the path like the current working directory or the path to the module is long,
1985         it will be truncated by the API and it fail to open the file.
1986         In JSC tests in Apple Windows buildbot, since the current working directory is long enough, the tests failed.
1987
1988         This patch introduces the following 3 tweaks.
1989
1990         1. When retrieving the current working path, we use GetCurrentDirectoryW instead of _getcwd.
1991            GetCurrentDirectoryW allows the long path while _getcwd automatically truncate the result by the _MAX_PATH.
1992
1993         2. Before opening the module file, we prepend "\\?\" to the path. It converts the local file path to the long UNC path
1994            which allows longer path names.
1995
1996         3. Since Windows ASCII API accepts the characters in the current code page, we use the Unicode APIs like _wfopen instead.
1997
1998         And enable the once disabled module tests in Windows.
1999
2000         Since this functionality is the part of the JSC shell to run the module tests, it is now implemented in jsc.cpp.
2001
2002         * jsc.cpp:
2003         (stringFromUTF):
2004         (jscSource):
2005         (extractDirectoryName):
2006         (currentWorkingDirectory):
2007         (convertShebangToJSComment):
2008         (fillBufferWithContentsOfFile):
2009         (fetchScriptFromLocalFileSystem):
2010         (fetchModuleFromLocalFileSystem):
2011         (GlobalObject::moduleLoaderFetch):
2012         (functionRun):
2013         (functionLoad):
2014         (functionReadFile):
2015         (functionCheckSyntax):
2016         (functionLoadModule):
2017         (runWithScripts):
2018         (runInteractive):
2019         * tests/modules.yaml:
2020
2021 2015-09-10  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2022
2023         Convert arguments to WebAssembly functions to the declared types
2024         https://bugs.webkit.org/show_bug.cgi?id=149033
2025
2026         Reviewed by Geoffrey Garen.
2027
2028         This patch checks the types of arguments to WebAssembly functions and
2029         converts them to the declared types. This is necessary because:
2030         - For example, if a function expects an argument of type double and we
2031           pass 1.0 to it, it will get a JSValue of an integer, not a double.
2032         - We should follow asm.js's behavior for now, because we want to be able
2033           to test WebAssembly apps against asm.js apps. asm.js does type
2034           coercion on arguments by using int|0, Math.fround(float), and +double.
2035
2036         * jit/JITOperations.h:
2037         * tests/stress/wasm-type-conversion.js: Added.
2038         (shouldBe):
2039         (two.valueOf):
2040         * tests/stress/wasm/type-conversion.wasm: Added.
2041         * wasm/WASMFunctionCompiler.h:
2042         (JSC::operationConvertJSValueToInt32):
2043         (JSC::operationConvertJSValueToDouble):
2044         (JSC::WASMFunctionCompiler::startFunction):
2045         (JSC::WASMFunctionCompiler::appendCallSetResult):
2046         (JSC::WASMFunctionCompiler::callOperation):
2047         (JSC::WASMFunctionCompiler::loadValueAndConvertToInt32):
2048         (JSC::WASMFunctionCompiler::loadValueAndConvertToDouble):
2049
2050 2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2051
2052         JSInternalPromiseDeferred should inherit JSPromiseDeferred
2053         https://bugs.webkit.org/show_bug.cgi?id=149027
2054
2055         Reviewed by Darin Adler.
2056
2057         JSInternalPromiseDeferred is constructed by using JSPromiseDeferred implementation.
2058         So the class info of JSInternalPromiseDeferred should inherit JSPromiseDeferred.
2059
2060         * runtime/JSInternalPromiseDeferred.cpp:
2061
2062 2015-09-10  Michael Saboff  <msaboff@apple.com>
2063
2064         Add support for Callee-Saves registers
2065         https://bugs.webkit.org/show_bug.cgi?id=148666
2066
2067         Reviewed by Filip Pizlo.
2068
2069         We save platform callee save registers right below the call frame header,
2070         in the location(s) starting with VirtualRegister 0.  This local space is
2071         allocated in the bytecode compiler.  This space is the maximum space
2072         needed for the callee registers that the LLInt and baseline JIT use,
2073         rounded up to a stack aligned number of VirtualRegisters.
2074         The LLInt explicitly saves and restores the registers in the macros
2075         preserveCalleeSavesUsedByLLInt and restoreCalleeSavesUsedByLLInt.
2076         The JITs saves and restores callee saves registers by what registers
2077         are included in m_calleeSaveRegisters in the code block.
2078
2079         Added handling of callee save register restoration to exception handling.
2080         The basic flow is when an exception is thrown or one is recognized to
2081         have been generated in C++ code, we save the current state of all
2082         callee save registers to VM::calleeSaveRegistersBuffer.  As we unwind
2083         looking for the corresponding catch, we copy the callee saves from call 
2084         frames to the same VM::calleeSaveRegistersBuffer.  This is done for all
2085         call frames on the stack up to but not including the call frame that has
2086         the corresponding catch block.  When we process the catch, we restore
2087         the callee save registers with the contents of VM::calleeSaveRegistersBuffer.
2088         If there isn't a catch, then handleUncaughtException will restore callee
2089         saves before it returns back to the calling C++.
2090
2091         Eliminated callee saves registers as free registers for various thunk
2092         generators as the callee saves may not have been saved by the function
2093         calling the thunk.
2094
2095         Added code to transition callee saves from one VM's format to the another
2096         as part of OSR entry and OSR exit.
2097
2098         Cleaned up the static RegisterSet's including adding one for LLInt and 
2099         baseline JIT callee saves and one to be used to allocate local registers
2100         not including the callee saves or other special registers.
2101
2102         Moved ftl/FTLRegisterAtOffset.{cpp,h} to jit/RegisterAtOffset.{cpp,h}.
2103         Factored out the vector of RegisterAtOffsets in ftl/FTLUnwindInfo.{cpp,h}
2104         into a new class in jit/RegisterAtOffsetList.{cpp,h}.
2105         Eliminted UnwindInfo and changed UnwindInfo::parse() into a standalone
2106         function named parseUnwindInfo.  That standalone function now returns
2107         the callee saves RegisterAtOffsetList.  This is stored in the CodeBlock
2108         and used instead of UnwindInfo.
2109
2110         Turned off register preservation thunks for outgoing calls from FTL
2111         generated code.  THey'll be removed in a subsequent patch.
2112
2113         Changed specialized thinks to save and restore the contents of
2114         tagTypeNumberRegister and tagMaskRegister as they can be called by FTL
2115         compiled functions.  We materialize those tag registers for the thunk's
2116         use and then restore the prior contents on function exit.
2117
2118         Also removed the arity check fail return thunk since it is now the
2119         caller's responsibility to restore the stack pointer.
2120
2121         Removed saving of callee save registers and materialization of special
2122         tag registers for 64 bit platforms from vmEntryToJavaScript and
2123         vmEntryToNative.
2124
2125         * CMakeLists.txt:
2126         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2127         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2128         * JavaScriptCore.xcodeproj/project.pbxproj:
2129         * ftl/FTLJITCode.h:
2130         * ftl/FTLRegisterAtOffset.cpp: Removed.
2131         * ftl/FTLRegisterAtOffset.h: Removed.
2132         * ftl/FTLUnwindInfo.cpp:
2133         (JSC::FTL::parseUnwindInfo):
2134         (JSC::FTL::UnwindInfo::UnwindInfo): Deleted.
2135         (JSC::FTL::UnwindInfo::~UnwindInfo): Deleted.
2136         (JSC::FTL::UnwindInfo::parse): Deleted.
2137         (JSC::FTL::UnwindInfo::dump): Deleted.
2138         (JSC::FTL::UnwindInfo::find): Deleted.
2139         (JSC::FTL::UnwindInfo::indexOf): Deleted.
2140         * ftl/FTLUnwindInfo.h:
2141         (JSC::RegisterAtOffset::dump):
2142         * jit/RegisterAtOffset.cpp: Added.
2143         * jit/RegisterAtOffset.h: Added.
2144         (JSC::RegisterAtOffset::RegisterAtOffset):
2145         (JSC::RegisterAtOffset::operator!):
2146         (JSC::RegisterAtOffset::reg):
2147         (JSC::RegisterAtOffset::offset):
2148         (JSC::RegisterAtOffset::offsetAsIndex):
2149         (JSC::RegisterAtOffset::operator==):
2150         (JSC::RegisterAtOffset::operator<):
2151         (JSC::RegisterAtOffset::getReg):
2152         * jit/RegisterAtOffsetList.cpp: Added.
2153         (JSC::RegisterAtOffsetList::RegisterAtOffsetList):
2154         (JSC::RegisterAtOffsetList::sort):
2155         (JSC::RegisterAtOffsetList::dump):
2156         (JSC::RegisterAtOffsetList::find):
2157         (JSC::RegisterAtOffsetList::indexOf):
2158         * jit/RegisterAtOffsetList.h: Added.
2159         (JSC::RegisterAtOffsetList::clear):
2160         (JSC::RegisterAtOffsetList::size):
2161         (JSC::RegisterAtOffsetList::at):
2162         (JSC::RegisterAtOffsetList::append):
2163         Move and refactored use of FTLRegisterAtOffset to RegisterAtOffset.
2164         Added RegisterAtOffset and RegisterAtOffsetList to build configurations.
2165         Remove FTLRegisterAtOffset files.
2166
2167         * bytecode/CallLinkInfo.h:
2168         (JSC::CallLinkInfo::setUpCallFromFTL):
2169         Turned off FTL register preservation thunks.
2170
2171         * bytecode/CodeBlock.cpp:
2172         (JSC::CodeBlock::CodeBlock):
2173         (JSC::CodeBlock::setCalleeSaveRegisters):
2174         (JSC::roundCalleeSaveSpaceAsVirtualRegisters):
2175         (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
2176         (JSC::CodeBlock::calleeSaveSpaceAsVirtualRegisters):
2177         * bytecode/CodeBlock.h:
2178         (JSC::CodeBlock::numberOfLLIntBaselineCalleeSaveRegisters):
2179         (JSC::CodeBlock::calleeSaveRegisters):
2180         (JSC::CodeBlock::llintBaselineCalleeSaveSpaceAsVirtualRegisters):
2181         (JSC::CodeBlock::optimizeAfterWarmUp):
2182         (JSC::CodeBlock::numberOfDFGCompiles):
2183         Methods to manage a set of callee save registers.  Also to allocate the appropriate
2184         number of VirtualRegisters for callee saves.
2185
2186         * bytecompiler/BytecodeGenerator.cpp:
2187         (JSC::BytecodeGenerator::BytecodeGenerator):
2188         (JSC::BytecodeGenerator::allocateCalleeSaveSpace):
2189         * bytecompiler/BytecodeGenerator.h:
2190         Allocate the appropriate number of VirtualRegisters for callee saves needed by LLInt or baseline JIT.
2191
2192         * dfg/DFGJITCompiler.cpp:
2193         (JSC::DFG::JITCompiler::compileEntry):
2194         (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
2195         (JSC::DFG::JITCompiler::compileBody):
2196         (JSC::DFG::JITCompiler::compileExceptionHandlers):
2197         (JSC::DFG::JITCompiler::compile):
2198         (JSC::DFG::JITCompiler::compileFunction):
2199         * dfg/DFGJITCompiler.h:
2200         * interpreter/Interpreter.cpp:
2201         (JSC::UnwindFunctor::operator()):
2202         (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer):
2203         * dfg/DFGPlan.cpp:
2204         (JSC::DFG::Plan::compileInThreadImpl):
2205         * dfg/DFGSpeculativeJIT.cpp:
2206         (JSC::DFG::SpeculativeJIT::usedRegisters):
2207         * dfg/DFGSpeculativeJIT32_64.cpp:
2208         (JSC::DFG::SpeculativeJIT::compile):
2209         * dfg/DFGSpeculativeJIT64.cpp:
2210         (JSC::DFG::SpeculativeJIT::compile):
2211         * dfg/DFGStackLayoutPhase.cpp:
2212         (JSC::DFG::StackLayoutPhase::run):
2213         * ftl/FTLCompile.cpp:
2214         (JSC::FTL::fixFunctionBasedOnStackMaps):
2215         (JSC::FTL::compile):
2216         * ftl/FTLLink.cpp:
2217         (JSC::FTL::link):
2218         * ftl/FTLOSRExitCompiler.cpp:
2219         (JSC::FTL::compileStub):
2220         * ftl/FTLThunks.cpp:
2221         (JSC::FTL::osrExitGenerationThunkGenerator):
2222         * jit/ArityCheckFailReturnThunks.cpp: Removed.
2223         * jit/ArityCheckFailReturnThunks.h: Removed.
2224         * jit/JIT.cpp:
2225         (JSC::JIT::emitEnterOptimizationCheck):
2226         (JSC::JIT::privateCompile):
2227         (JSC::JIT::privateCompileExceptionHandlers):
2228         * jit/JITCall32_64.cpp:
2229         (JSC::JIT::emit_op_ret):
2230         * jit/JITExceptions.cpp:
2231         (JSC::genericUnwind):
2232         * jit/JITExceptions.h:
2233         * jit/JITOpcodes.cpp:
2234         (JSC::JIT::emit_op_end):
2235         (JSC::JIT::emit_op_ret):
2236         (JSC::JIT::emit_op_throw):
2237         (JSC::JIT::emit_op_catch):
2238         (JSC::JIT::emit_op_enter):
2239         (JSC::JIT::emitSlow_op_loop_hint):
2240         * jit/JITOpcodes32_64.cpp:
2241         (JSC::JIT::emit_op_end):
2242         (JSC::JIT::emit_op_throw):
2243         (JSC::JIT::emit_op_catch):
2244         * jit/JITOperations.cpp:
2245         * jit/Repatch.cpp:
2246         (JSC::generateByIdStub):
2247         * jit/ThunkGenerators.cpp:
2248         * llint/LLIntData.cpp:
2249         (JSC::LLInt::Data::performAssertions):
2250         * llint/LLIntSlowPaths.cpp:
2251         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2252         * llint/LowLevelInterpreter.asm:
2253         * llint/LowLevelInterpreter32_64.asm:
2254         * llint/LowLevelInterpreter64.asm:
2255         (JSC::throwExceptionFromCallSlowPathGenerator):
2256         (JSC::arityFixupGenerator):
2257         * runtime/CommonSlowPaths.cpp:
2258         (JSC::setupArityCheckData):
2259         * runtime/CommonSlowPaths.h:
2260         (JSC::CommonSlowPaths::arityCheckFor):
2261         Emit code to save and restore callee save registers and materialize tagTypeNumberRegister
2262         and tagMaskRegister.
2263         Handle callee saves when tiering up.
2264         Copy callee saves register contents to VM::calleeSaveRegistersBuffer at beginning of
2265         exception processing.
2266         Process callee save registers in frames when unwinding from an exception.
2267         Restore callee saves register contents from VM::calleeSaveRegistersBuffer on catch.
2268         Use appropriate register set to make sure we don't allocate a callee save register when
2269         compiling a thunk.
2270         Helper to populate tagTypeNumberRegister and tagMaskRegister with the appropriate
2271         constants.
2272         Removed arity fixup return thunks.
2273
2274         * dfg/DFGOSREntry.cpp:
2275         (JSC::DFG::prepareOSREntry):
2276         * dfg/DFGOSRExitCompiler32_64.cpp:
2277         (JSC::DFG::OSRExitCompiler::compileExit):
2278         * dfg/DFGOSRExitCompiler64.cpp:
2279         (JSC::DFG::OSRExitCompiler::compileExit):
2280         * dfg/DFGOSRExitCompilerCommon.cpp:
2281         (JSC::DFG::reifyInlinedCallFrames):
2282         (JSC::DFG::adjustAndJumpToTarget):
2283         Restore callee saves from the DFG and save the appropriate ones for the baseline JIT.
2284         Materialize the tag registers on 64 bit platforms.
2285
2286         * jit/AssemblyHelpers.h:
2287         (JSC::AssemblyHelpers::emitSaveCalleeSavesFor):
2288         (JSC::AssemblyHelpers::emitRestoreCalleeSavesFor):
2289         (JSC::AssemblyHelpers::emitSaveCalleeSaves):
2290         (JSC::AssemblyHelpers::emitRestoreCalleeSaves):
2291         (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer):
2292         (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer):
2293         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer):
2294         (JSC::AssemblyHelpers::emitMaterializeTagCheckRegisters):
2295         New helpers to save and restore callee saves as well as materialize the tag registers
2296         contents.
2297
2298         * jit/FPRInfo.h:
2299         * jit/GPRInfo.h:
2300         (JSC::GPRInfo::toRegister):
2301         Updated to include FP callee save registers.  Added number of callee saves registers and
2302         cleanup register aliases that collide with callee save registers.
2303
2304         * jit/JITPropertyAccess.cpp:
2305         (JSC::JIT::emitGetByValWithCachedId):
2306         (JSC::JIT::emitPutByValWithCachedId):
2307         (JSC::JIT::emit_op_get_by_id):
2308         (JSC::JIT::emit_op_put_by_id):
2309         * jit/JITPropertyAccess32_64.cpp:
2310         (JSC::JIT::emitGetByValWithCachedId):
2311         (JSC::JIT::emitPutByValWithCachedId):
2312         (JSC::JIT::emit_op_get_by_id):
2313         (JSC::JIT::emit_op_put_by_id):
2314         Uses new stubUnavailableRegisters register set to limit what registers are available for 
2315         temporaries.
2316
2317         * jit/RegisterSet.cpp:
2318         (JSC::RegisterSet::stubUnavailableRegisters):
2319         (JSC::RegisterSet::calleeSaveRegisters):
2320         (JSC::RegisterSet::llintBaselineCalleeSaveRegisters):
2321         (JSC::RegisterSet::dfgCalleeSaveRegisters):
2322         (JSC::RegisterSet::ftlCalleeSaveRegisters):
2323         * jit/RegisterSet.h:
2324         New register sets with the callee saves used by various tiers as well as one listing registers
2325         not availble to stub code.
2326
2327         * jit/SpecializedThunkJIT.h:
2328         (JSC::SpecializedThunkJIT::SpecializedThunkJIT):
2329         (JSC::SpecializedThunkJIT::loadDoubleArgument):
2330         (JSC::SpecializedThunkJIT::returnJSValue):
2331         (JSC::SpecializedThunkJIT::returnDouble):
2332         (JSC::SpecializedThunkJIT::returnInt32):
2333         (JSC::SpecializedThunkJIT::returnJSCell):
2334         (JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn):
2335         (JSC::SpecializedThunkJIT::emitSaveThenMaterializeTagRegisters):
2336         (JSC::SpecializedThunkJIT::emitRestoreSavedTagRegisters):
2337         (JSC::SpecializedThunkJIT::tagReturnAsInt32):
2338         * jit/ThunkGenerators.cpp:
2339         (JSC::nativeForGenerator):
2340         Changed to save and restore existing tag register contents as the may contain other values.
2341         After saving the existing values, we materialize the tag constants.
2342
2343         * jit/TempRegisterSet.h:
2344         (JSC::TempRegisterSet::getFPRByIndex):
2345         (JSC::TempRegisterSet::getFreeFPR):
2346         (JSC::TempRegisterSet::setByIndex):
2347         * offlineasm/arm64.rb:
2348         * offlineasm/registers.rb:
2349         Added methods for floating point registers to support callee save FP registers.
2350
2351         * jit/JITArithmetic32_64.cpp:
2352         (JSC::JIT::emit_op_mod):
2353         Removed unnecessary #if CPU(X86_64) check to this 32 bit only file.
2354
2355         * offlineasm/x86.rb:
2356         Fixed Windows callee saves naming.
2357
2358         * runtime/VM.cpp:
2359         (JSC::VM::VM):
2360         * runtime/VM.h:
2361         (JSC::VM::calleeSaveRegistersBufferOffset):
2362         (JSC::VM::getAllCalleeSaveRegistersMap):
2363         Provide a RegisterSaveMap that has all registers that might be saved.  Added a callee save buffer to be
2364         used for OSR exit and for exception processing in a future patch.
2365
2366 2015-09-10  Yusuke Suzuki  <utatane.tea@gmail.com>
2367
2368         ModuleProgramExecutable should provide CodeBlock to ScriptExecutable::forEachCodeBlock
2369         https://bugs.webkit.org/show_bug.cgi?id=149028
2370
2371         Reviewed by Michael Saboff.
2372
2373         ModuleProgramExecutable should provide CodeBlock since ModuleProgramExecutable inherits
2374         ScriptExecutable.
2375
2376         * bytecode/CodeBlock.h:
2377         (JSC::ScriptExecutable::forEachCodeBlock):
2378
2379 2015-09-09  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2380
2381         Implement internal calls in WebAssembly
2382         https://bugs.webkit.org/show_bug.cgi?id=148998
2383
2384         Reviewed by Filip Pizlo.
2385
2386         This patch implements internal calls to functions that return a 32-bit
2387         integer in WebAssembly.
2388
2389         * tests/stress/wasm-calls.js: Added.
2390         (shouldBe):
2391         * tests/stress/wasm/calls.wasm: Added.
2392         * wasm/WASMFunctionCompiler.h:
2393         (JSC::WASMFunctionCompiler::WASMFunctionCompiler):
2394         (JSC::WASMFunctionCompiler::endFunction):
2395         (JSC::WASMFunctionCompiler::buildCallInternal):
2396         (JSC::WASMFunctionCompiler::appendExpressionList):
2397         (JSC::WASMFunctionCompiler::emitNakedCall):
2398         (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
2399         (JSC::WASMFunctionCompiler::callAndUnboxResult):
2400         * wasm/WASMFunctionParser.cpp:
2401         (JSC::WASMFunctionParser::compile):
2402         (JSC::WASMFunctionParser::parseExpressionI32):
2403         (JSC::WASMFunctionParser::parseCallInternalExpressionI32):
2404         (JSC::WASMFunctionParser::parseCallArguments):
2405         (JSC::WASMFunctionParser::parseCallInternal):
2406         * wasm/WASMFunctionParser.h:
2407         * wasm/WASMFunctionSyntaxChecker.h:
2408         (JSC::WASMFunctionSyntaxChecker::buildCallInternal):
2409         (JSC::WASMFunctionSyntaxChecker::appendExpressionList):
2410
2411 2015-09-09  Commit Queue  <commit-queue@webkit.org>
2412
2413         Unreviewed, rolling out r189522.
2414         https://bugs.webkit.org/show_bug.cgi?id=149020
2415
2416         "Caused a ~4% Speedometer regression" (Requested by cdumez on
2417         #webkit).
2418
2419         Reverted changeset:
2420
2421         "Function.prototype.bind: Bound functions must use the
2422         [[Prototype]] of their target function instead of
2423         Function.prototype"
2424         https://bugs.webkit.org/show_bug.cgi?id=145605
2425         http://trac.webkit.org/changeset/189522
2426
2427 2015-09-09  Geoffrey Garen  <ggaren@apple.com>
2428
2429         Fix the no-DFG build.
2430
2431         Unreviewed.
2432
2433         * bytecode/CodeBlock.cpp:
2434         (JSC::CodeBlock::visitOSRExitTargets):
2435         (JSC::CodeBlock::stronglyVisitStrongReferences):
2436
2437 2015-09-09  Geoffrey Garen  <ggaren@apple.com>
2438
2439         CodeBlocks should strongly visit their OSR exit targets
2440         https://bugs.webkit.org/show_bug.cgi?id=148988
2441
2442         Reviewed by Saam Barati.
2443
2444         CodeBlocks jump to their OSR exit targets, so we need to keep them alive
2445         explicitly.
2446
2447         This is a step toward throwing away CodeBlocks, which is only safe
2448         if we keep alive logically in-use CodeBlocks.
2449
2450         * bytecode/CodeBlock.cpp:
2451         (JSC::CodeBlock::CodeBlock):
2452         (JSC::CodeBlock::visitStrongly): Added a flag to indicate if visit
2453         strongly had been performed yet, since we are likely to revisit
2454         the same CodeBlock many times now.
2455
2456         (JSC::CodeBlock::visitOSRExitTargets):
2457         (JSC::CodeBlock::stronglyVisitStrongReferences): Do the visiting.
2458
2459         * bytecode/CodeBlock.h:
2460         (JSC::CodeBlock::clearMarks):
2461         (JSC::CodeBlockSet::mark): Added a helper function for clearing out
2462         two flags.
2463
2464 2015-09-09  Geoffrey Garen  <ggaren@apple.com>
2465
2466         Unreviewed, rolling back in r189516.
2467         https://bugs.webkit.org/show_bug.cgi?id=148989
2468
2469         Restored changeset:
2470
2471         "GC should be able to discover new strong CodeBlock references
2472         during marking"
2473         https://bugs.webkit.org/show_bug.cgi?id=148981
2474         http://trac.webkit.org/changeset/189516
2475
2476         This patch caused infinite recursion on Windows because of a pre-existing
2477         logical error in the non-parallel GC configuration. Even in non-parallel
2478         GC, we must set the mark bit on a CodeBlock to avoid marking it twice
2479         (or, in the case of our crash, infinitely recursively).
2480
2481 2015-09-09  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2482
2483         Implement the relational instructions for doubles in WebAssembly
2484         https://bugs.webkit.org/show_bug.cgi?id=148999
2485
2486         Reviewed by Filip Pizlo.
2487
2488         Implements the relational instructions for doubles (float64) in
2489         WebAssembly. Also pass the values into the test functions as Mark Lam
2490         suggested in https://bugs.webkit.org/show_bug.cgi?id=148882#c3
2491
2492         * tests/stress/wasm-relational.js:
2493         * tests/stress/wasm/relational.wasm:
2494         * wasm/WASMFunctionCompiler.h:
2495         (JSC::WASMFunctionCompiler::buildRelationalF64):
2496         * wasm/WASMFunctionParser.cpp:
2497         (JSC::WASMFunctionParser::parseExpressionI32):
2498         (JSC::WASMFunctionParser::parseRelationalF64ExpressionI32):
2499         * wasm/WASMFunctionParser.h:
2500         * wasm/WASMFunctionSyntaxChecker.h:
2501         (JSC::WASMFunctionSyntaxChecker::buildRelationalI32):
2502         (JSC::WASMFunctionSyntaxChecker::buildRelationalF64):
2503
2504 2015-09-09  Saam barati  <sbarati@apple.com>
2505
2506         DFG should have a debugging option that runs a phase that flushes all locals
2507         https://bugs.webkit.org/show_bug.cgi?id=148916
2508
2509         Reviewed by Filip Pizlo.
2510
2511         There is now an option to enable the DFG's new MaximalFlushInsertionPhase
2512         phase to run. This phase ensures that we keep all locals and arguments flushed
2513         to the stack at all places in the CFG. This phase is helpful for finding
2514         a class of bugs where enabling this phase to run removes the bug.
2515         This may also be useful in the development of a faster debugger
2516         that doesn't capture all variables.
2517
2518         * CMakeLists.txt:
2519         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2520         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2521         * JavaScriptCore.xcodeproj/project.pbxproj:
2522         * dfg/DFGMaximalFlushInsertionPhase.cpp: Added.
2523         (JSC::DFG::MaximalFlushInsertionPhase::MaximalFlushInsertionPhase):
2524         (JSC::DFG::MaximalFlushInsertionPhase::run):
2525         (JSC::DFG::MaximalFlushInsertionPhase::treatRegularBlock):
2526         (JSC::DFG::MaximalFlushInsertionPhase::treatRootBlock):
2527         (JSC::DFG::MaximalFlushInsertionPhase::newVariableAccessData):
2528         (JSC::DFG::performMaximalFlushInsertion):
2529         * dfg/DFGMaximalFlushInsertionPhase.h: Added.
2530         * dfg/DFGPlan.cpp:
2531         (JSC::DFG::Plan::compileInThreadImpl):
2532         * runtime/Options.cpp:
2533         (JSC::recomputeDependentOptions):
2534         * runtime/Options.h:
2535
2536 2015-09-08  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2537
2538         Refactor the test for the arithmetic instructions in WebAssembly
2539         https://bugs.webkit.org/show_bug.cgi?id=148983
2540
2541         Reviewed by Mark Lam.
2542
2543         Pass the values into the test functions as Mark Lam suggested in
2544         https://bugs.webkit.org/show_bug.cgi?id=148882#c3
2545
2546         * tests/stress/wasm-arithmetic-int32.js: Added.
2547         (shouldBe):
2548         (shouldThrow):
2549         * tests/stress/wasm-arithmetic.js: Removed.
2550         (shouldBe): Deleted.
2551         (shouldThrow): Deleted.
2552         * tests/stress/wasm/arithmetic-int32.wasm: Added.
2553         * tests/stress/wasm/arithmetic.wasm: Removed.
2554
2555 2015-09-08  Benjamin Poulain  <bpoulain@apple.com>
2556
2557         [JSC] reduce the amount of memory access needed for LivenessAnalysisPhase
2558         https://bugs.webkit.org/show_bug.cgi?id=148414
2559
2560         Reviewed by Mark Lam.
2561
2562         LivenessAnalysisPhase still causes a huge number of cache miss.
2563         This patch reduces the amount of accesses needed by the HashTables.
2564
2565         * dfg/DFGBasicBlock.h:
2566         * dfg/DFGLivenessAnalysisPhase.cpp:
2567         (JSC::DFG::LivenessAnalysisPhase::run):
2568         (JSC::DFG::LivenessAnalysisPhase::process):
2569
2570 2015-09-08  Myles C. Maxfield  <mmaxfield@apple.com>
2571
2572         Prospective build fix after r189517
2573
2574         Unreviewed.
2575
2576         * heap/MachineStackMarker.cpp:
2577         (JSC::MachineThreads::Thread::captureStack):
2578
2579 2015-09-08  Yusuke Suzuki  <utatane.tea@gmail.com>
2580
2581         Unify symbolTableGet and Put in JSLexicalEnvironment and JSSymbolTableObject
2582         https://bugs.webkit.org/show_bug.cgi?id=148783
2583
2584         Reviewed by Geoffrey Garen.
2585
2586         Unify the symbolTableGet and symbolTablePut into JSSymbolTableObject's one.
2587         Since symbolTablePutWithAttributes in JSLexicalEnvironment is not used, we drop that function.
2588
2589         * runtime/JSEnvironmentRecord.h:
2590         (JSC::JSEnvironmentRecord::isValidScopeOffset):
2591         (JSC::JSEnvironmentRecord::variableAt):
2592         (JSC::JSEnvironmentRecord::isValid): Deleted.
2593         * runtime/JSGlobalLexicalEnvironment.cpp:
2594         (JSC::JSGlobalLexicalEnvironment::put):
2595         * runtime/JSGlobalObject.cpp:
2596         (JSC::JSGlobalObject::put):
2597         * runtime/JSLexicalEnvironment.cpp:
2598         (JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames):
2599         (JSC::JSLexicalEnvironment::getOwnPropertySlot):
2600         (JSC::JSLexicalEnvironment::put):
2601         (JSC::JSLexicalEnvironment::symbolTableGet): Deleted.
2602         (JSC::JSLexicalEnvironment::symbolTablePut): Deleted.
2603         (JSC::JSLexicalEnvironment::symbolTablePutWithAttributes): Deleted.
2604         * runtime/JSLexicalEnvironment.h:
2605         * runtime/JSModuleRecord.cpp:
2606         (JSC::JSModuleRecord::instantiateDeclarations):
2607         * runtime/JSSegmentedVariableObject.h:
2608         (JSC::JSSegmentedVariableObject::isValidScopeOffset):
2609         * runtime/JSSymbolTableObject.h:
2610         (JSC::symbolTableGet):
2611         (JSC::symbolTablePut):
2612         (JSC::symbolTablePutTouchWatchpointSet):
2613         (JSC::symbolTablePutInvalidateWatchpointSet):
2614         (JSC::symbolTablePutWithAttributesTouchWatchpointSet):
2615         (JSC::symbolTablePutWithAttributes): Deleted.
2616
2617 2015-09-08  Commit Queue  <commit-queue@webkit.org>
2618
2619         Unreviewed, rolling out r189516.
2620         https://bugs.webkit.org/show_bug.cgi?id=148989
2621
2622         broke tests on windows (Requested by alexchristensen on
2623         #webkit).
2624
2625         Reverted changeset:
2626
2627         "GC should be able to discover new strong CodeBlock references
2628         during marking"
2629         https://bugs.webkit.org/show_bug.cgi?id=148981
2630         http://trac.webkit.org/changeset/189516
2631
2632 2015-09-08  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2633
2634         Remove unused DFG::dfgConvertJSValueToInt32()
2635         https://bugs.webkit.org/show_bug.cgi?id=148986
2636
2637         Reviewed by Geoffrey Garen.
2638
2639         Remove unused DFG::dfgConvertJSValueToInt32() and also remove
2640         DFG::JITCompiler::callOperation(D_JITOperation_EJ operation, ...) which
2641         was introduced in Bug 69806 for dfgConvertJSValueToNumber() and is no
2642         longer used.
2643
2644         * dfg/DFGOperations.cpp:
2645         * dfg/DFGOperations.h:
2646         * dfg/DFGSpeculativeJIT.h:
2647         (JSC::DFG::SpeculativeJIT::callOperation): Deleted.
2648
2649 2015-09-08  Matthew Hill  <matthew.jh@outlook.com>
2650
2651         Function.prototype.bind: Bound functions must use the [[Prototype]] of their target function instead of Function.prototype
2652         https://bugs.webkit.org/show_bug.cgi?id=145605
2653
2654         Reviewed by Geoffrey Garen.
2655
2656         * runtime/JSBoundFunction.cpp:
2657         (JSC::JSBoundFunction::create):
2658         * tests/es6.yaml:
2659
2660 2015-09-08  Mark Lam  <mark.lam@apple.com>
2661
2662         Fixed a bad comment r189517.
2663
2664         Not reviewed.
2665
2666         * heap/MachineStackMarker.cpp:
2667         (JSC::osRedZoneAdjustment):
2668
2669 2015-09-08  Geoffrey Garen  <ggaren@apple.com>
2670
2671         InlineCallFrames shouldn't be strongly marked by CodeBlock
2672         https://bugs.webkit.org/show_bug.cgi?id=146613
2673
2674         Reviewed by Saam Barati.
2675
2676         This code was vestigial an unnecessary, so I removed it.
2677
2678         * bytecode/CodeBlock.cpp:
2679         (JSC::CodeBlock::stronglyVisitStrongReferences):
2680         * bytecode/InlineCallFrame.cpp:
2681         (JSC::InlineCallFrame::calleeConstant):
2682         (JSC::InlineCallFrame::calleeForCallFrame):
2683         (JSC::InlineCallFrame::visitAggregate): Deleted.
2684         * bytecode/InlineCallFrame.h:
2685         (JSC::InlineCallFrame::specializationKind):
2686         * bytecode/InlineCallFrameSet.cpp:
2687         (JSC::InlineCallFrameSet::add):
2688         (JSC::InlineCallFrameSet::visitAggregate): Deleted.
2689         * bytecode/InlineCallFrameSet.h:
2690         (JSC::InlineCallFrameSet::begin):
2691         (JSC::InlineCallFrameSet::end):
2692
2693 2015-09-08  Mark Lam  <mark.lam@apple.com>
2694
2695         GC stack scan should include ABI red zone.
2696         https://bugs.webkit.org/show_bug.cgi?id=148976
2697
2698         Reviewed by Geoffrey Garen and Benjamin Poulain.
2699
2700         The x86_64 ABI section 3.2.2[1] and ARM64 ABI[2] both state that there is a
2701         128 byte red zone below the stack pointer (reserved by the OS), and that
2702         "functions may use this area for temporary data that is not needed across
2703         function calls".
2704
2705         Hence, it is possible for a thread to store JSCell pointers in the red zone
2706         area, and the conservative GC thread scanner needs to scan that area as well.
2707
2708         Note: the red zone should not be scanned for the GC thread itself (in
2709         gatherFromCurrentThread()).  This because we're guaranteed that there will
2710         be GC frames below the lowest (top of stack) frame that we need to scan.
2711         Hence, we are guaranteed that there are no red zone areas there containing
2712         JSObject pointers of relevance.
2713
2714         No test added for this issue because the issue relies on:
2715         1. the compiler tool chain generating code that stores local variables
2716            containing the sole reference to a JS object (that needs to be kept
2717            alive) in the stack red zone, and
2718         2. GC has to run on another thread while that red zone containing the
2719            JS object reference is in use. 
2720
2721         These conditions require a race that cannot be reliably reproduced.
2722
2723         [1]: http://people.freebsd.org/~obrien/amd64-elf-abi.pdf
2724         [2]: https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html#//apple_ref/doc/uid/TP40013702-SW7
2725
2726         * heap/MachineStackMarker.cpp:
2727         (JSC::MachineThreads::Thread::Thread):
2728         (JSC::MachineThreads::Thread::createForCurrentThread):
2729         (JSC::MachineThreads::Thread::freeRegisters):
2730         (JSC::osRedZoneAdjustment):
2731         (JSC::MachineThreads::Thread::captureStack):
2732
2733 2015-09-08  Geoffrey Garen  <ggaren@apple.com>
2734
2735         GC should be able to discover new strong CodeBlock references during marking
2736         https://bugs.webkit.org/show_bug.cgi?id=148981
2737
2738         Reviewed by Mark Lam.
2739
2740         Previously, we required a strong reference to register itself before the
2741         first visit to a CodeBlock. Now, we can discover a strong reference at
2742         any time during the marking phase.
2743
2744         * bytecode/CodeBlock.cpp:
2745         (JSC::CodeBlock::CodeBlock): Remove the two strong reference state
2746         variables from CodeBlock. Now, a strong reference immediately marks
2747         the CodeBlock and its references at the moment of its discovery, and no
2748         separate state is required.
2749
2750         (JSC::CodeBlock::visitStrongly): New helper function for establishing
2751         a strong reference to a CodeBlock.
2752
2753         (JSC::CodeBlock::visitAggregate): Adopt helper function above.
2754
2755         (JSC::CodeBlock::shouldImmediatelyAssumeLivenessDuringScan): Updated
2756         for state removal.
2757
2758         (JSC::CodeBlock::isKnownToBeLiveDuringGC): Ditto.
2759
2760         (JSC::CodeBlock::stronglyVisitWeakReferences): Be sure to record that
2761         we have proven liveness (by virtue of marking all the references the
2762         proof would check). This is required so that the CodeBlock knows itself
2763         to be live, and it is also an optimization to avoid testing weak references
2764         after we have already visited them.
2765
2766         * bytecode/CodeBlock.h:
2767         (JSC::CodeBlock::clearMarks):
2768         (JSC::CodeBlockSet::mark):
2769         (JSC::CodeBlockSet::clearMarks): Deleted. Updated for state removal.
2770
2771         * dfg/DFGPlan.cpp:
2772         (JSC::DFG::Plan::clearCodeBlockMarks):
2773         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
2774         * dfg/DFGPlan.h: No need to use a CodeBlockSet in order to mark anymore.
2775
2776         * dfg/DFGWorklist.cpp:
2777         (JSC::DFG::Worklist::completeAllPlansForVM):
2778         (JSC::DFG::Worklist::clearCodeBlockMarks):
2779         (JSC::DFG::Worklist::resumeAllThreads):
2780         (JSC::DFG::Worklist::visitWeakReferences):
2781         (JSC::DFG::completeAllPlansForVM):
2782         (JSC::DFG::clearCodeBlockMarks):
2783         * dfg/DFGWorklist.h:
2784         (JSC::DFG::worklistForIndexOrNull): No need to use a CodeBlockSet in order
2785         to mark anymore.
2786
2787         * heap/CodeBlockSet.cpp:
2788         (JSC::CodeBlockSet::clearMarksForFullCollection):
2789         (JSC::CodeBlockSet::clearMarksForEdenCollection):
2790         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
2791         (JSC::CodeBlockSet::traceMarked):
2792         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
2793         (JSC::CodeBlockSet::dump):
2794         * heap/CodeBlockSet.h: Keep the currently executing CodeBlocks in RefPtrs
2795         since we can no longer rely on the m_currentlyExecuting bit to keep them
2796         alive. (A currently executing CodeBlock may not be referenced by its
2797         Executable because it may since have been replaced by another CodeBlock.
2798         This is common in the cases of OSR entry and exit.)
2799
2800         * heap/Heap.cpp:
2801         (JSC::Heap::markRoots):
2802         (JSC::Heap::visitCompilerWorklistWeakReferences):
2803         (JSC::Heap::visitWeakHandles): No need to trace the list of CodeBlocks
2804         on the stack in the weak reference fixpoint because we no longer overload
2805         "on the stack" to include CodeBlocks referenced by the compiler.
2806
2807 2015-09-08  Andreas Kling  <akling@apple.com>
2808
2809         [JSC] Remove unused Heap::getConservativeRegisterRoots().
2810         <https://webkit.org/b/148974>
2811
2812         Reviewed by Geoffrey Garen.
2813
2814         Spotted this unused stack root gathering helper in Heap. Let's lose it.
2815
2816         * heap/Heap.cpp:
2817         (JSC::Heap::getConservativeRegisterRoots): Deleted.
2818         * interpreter/JSStack.cpp:
2819         (JSC::JSStack::gatherConservativeRoots): Deleted.
2820         * interpreter/JSStack.h:
2821         (JSC::JSStack::gatherConservativeRoots): Deleted.
2822
2823 2015-09-08  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2824
2825         Implement control flow statements in WebAssembly
2826         https://bugs.webkit.org/show_bug.cgi?id=148934
2827
2828         Reviewed by Geoffrey Garen.
2829
2830         This patch implements if, while, do, label, break, and continue
2831         statements in WebAssembly. Switches will be implemented in a subsequent
2832         patch.
2833
2834         * tests/stress/wasm-control-flow.js: Added.
2835         (shouldBe):
2836         * tests/stress/wasm/control-flow.wasm: Added.
2837         * wasm/WASMFunctionCompiler.h:
2838         (JSC::WASMFunctionCompiler::linkTarget):
2839         (JSC::WASMFunctionCompiler::jumpToTarget):
2840         (JSC::WASMFunctionCompiler::jumpToTargetIf):
2841         (JSC::WASMFunctionCompiler::startLoop):
2842         (JSC::WASMFunctionCompiler::endLoop):
2843         (JSC::WASMFunctionCompiler::startSwitch):
2844         (JSC::WASMFunctionCompiler::endSwitch):
2845         (JSC::WASMFunctionCompiler::startLabel):
2846         (JSC::WASMFunctionCompiler::endLabel):
2847         (JSC::WASMFunctionCompiler::breakTarget):
2848         (JSC::WASMFunctionCompiler::continueTarget):
2849         (JSC::WASMFunctionCompiler::breakLabelTarget):
2850         (JSC::WASMFunctionCompiler::continueLabelTarget):
2851         * wasm/WASMFunctionParser.cpp:
2852         (JSC::WASMFunctionParser::parseIfStatement):
2853         (JSC::WASMFunctionParser::parseIfElseStatement):
2854         (JSC::WASMFunctionParser::parseWhileStatement):
2855         (JSC::WASMFunctionParser::parseDoStatement):
2856         (JSC::WASMFunctionParser::parseLabelStatement):
2857         (JSC::WASMFunctionParser::parseBreakStatement):
2858         (JSC::WASMFunctionParser::parseBreakLabelStatement):
2859         (JSC::WASMFunctionParser::parseContinueStatement):
2860         (JSC::WASMFunctionParser::parseContinueLabelStatement):
2861         * wasm/WASMFunctionParser.h:
2862         * wasm/WASMFunctionSyntaxChecker.h:
2863         (JSC::WASMFunctionSyntaxChecker::linkTarget):
2864         (JSC::WASMFunctionSyntaxChecker::jumpToTarget):
2865         (JSC::WASMFunctionSyntaxChecker::jumpToTargetIf):
2866         (JSC::WASMFunctionSyntaxChecker::startLoop):
2867         (JSC::WASMFunctionSyntaxChecker::endLoop):
2868         (JSC::WASMFunctionSyntaxChecker::startSwitch):
2869         (JSC::WASMFunctionSyntaxChecker::endSwitch):
2870         (JSC::WASMFunctionSyntaxChecker::startLabel):
2871         (JSC::WASMFunctionSyntaxChecker::endLabel):
2872         (JSC::WASMFunctionSyntaxChecker::breakTarget):
2873         (JSC::WASMFunctionSyntaxChecker::continueTarget):
2874         (JSC::WASMFunctionSyntaxChecker::breakLabelTarget):
2875         (JSC::WASMFunctionSyntaxChecker::continueLabelTarget):
2876
2877 2015-09-08  Per Arne Vollan  <peavo@outlook.com>
2878
2879         [Win] Compile errors in inspector code.
2880         https://bugs.webkit.org/show_bug.cgi?id=148977
2881
2882         Reviewed by Alex Christensen.
2883
2884         Include definition of class FrontendRouter before use.
2885
2886         * inspector/InspectorBackendDispatcher.h:
2887         * inspector/JSGlobalObjectInspectorController.h:
2888
2889 2015-09-08  Yusuke Suzuki  <utatane.tea@gmail.com>
2890
2891         [ES6] Implement computed accessors
2892         https://bugs.webkit.org/show_bug.cgi?id=147883
2893
2894         Reviewed by Geoffrey Garen.
2895
2896         Patch by Yusuke Suzuki <utatane.tea@gmail.com> and Matthew Mirman <mmirman@apple.com>.
2897
2898         Implement the computed accessors functionality for class syntax and object literal syntax.
2899         Added new opcodes, op_put_getter_by_val and op_put_setter_by_val. LLInt and baseline JIT support them.
2900         As the same to the other accessor opcodes (like op_put_getter_by_id etc.), DFG / FTL does not support
2901         them. This is handled here[1].
2902
2903         [1]: https://bugs.webkit.org/show_bug.cgi?id=148860
2904
2905         * bytecode/BytecodeList.json:
2906         * bytecode/BytecodeUseDef.h:
2907         (JSC::computeUsesForBytecodeOffset):
2908         (JSC::computeDefsForBytecodeOffset):
2909         * bytecode/CodeBlock.cpp:
2910         (JSC::CodeBlock::dumpBytecode):
2911         * bytecompiler/BytecodeGenerator.cpp:
2912         (JSC::BytecodeGenerator::emitPutGetterByVal):
2913         (JSC::BytecodeGenerator::emitPutSetterByVal):
2914         * bytecompiler/BytecodeGenerator.h:
2915         * bytecompiler/NodesCodegen.cpp:
2916         (JSC::PropertyListNode::emitBytecode):
2917         * jit/JIT.cpp:
2918         (JSC::JIT::privateCompileMainPass):
2919         * jit/JIT.h:
2920         * jit/JITInlines.h:
2921         (JSC::JIT::callOperation):
2922         * jit/JITOperations.cpp:
2923         * jit/JITOperations.h:
2924         * jit/JITPropertyAccess.cpp:
2925         (JSC::JIT::emit_op_put_getter_by_val):
2926         (JSC::JIT::emit_op_put_setter_by_val):
2927         * jit/JITPropertyAccess32_64.cpp:
2928         (JSC::JIT::emit_op_put_getter_by_val):
2929         (JSC::JIT::emit_op_put_setter_by_val):
2930         * llint/LLIntSlowPaths.cpp:
2931         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2932         * llint/LLIntSlowPaths.h:
2933         * llint/LowLevelInterpreter.asm:
2934         * parser/ASTBuilder.h:
2935         (JSC::ASTBuilder::createGetterOrSetterProperty):
2936         * parser/Parser.cpp:
2937         (JSC::Parser<LexerType>::parseClass):
2938         (JSC::Parser<LexerType>::parseGetterSetter):
2939         * parser/SyntaxChecker.h:
2940         (JSC::SyntaxChecker::createGetterOrSetterProperty):
2941         * tests/es6.yaml:
2942         * tests/stress/computed-accessor-parsing.js: Added.
2943         (testShouldNotThrow):
2944         (testShouldThrow):
2945         (Val.prototype.get string_appeared_here):
2946         (Val):
2947         * tests/stress/computed-accessor.js: Added.
2948         (shouldBe):
2949         (.):
2950         * tests/stress/duplicate-computed-accessors.js: Added.
2951         (shouldBe):
2952
2953 2015-09-08  Saam barati  <sbarati@apple.com>
2954
2955         baseline JIT should emit better code for UnresolvedProperty in resolve_scope/get_from_scope/put_to_scope
2956         https://bugs.webkit.org/show_bug.cgi?id=148895
2957
2958         Reviewed by Geoffrey Garen.
2959
2960         Previously, if a resolve_scope/get_from_scope/put_to_scope with
2961         UnresolvedProperty made it to the baseline JIT, we would hard compile
2962         a jump to the slow path. This is bad and slow. Because UnresolvedProperty
2963         tries to update itself to something more useful, and succeeds at doing so
2964         with high probability, we should be emitting code that checks to see if the 
2965         slow path has performed an update, and if it has, execute more efficient code 
2966         and not go to the slow path (unless it needs to for var injection check failure, 
2967         or other check failures). This increases the speed of this code greatly because 
2968         we may decide to compile a program/function before certain resolve_scope/get_from_scope/put_to_scope 
2969         operations ever execute. And now, the baseline JIT code better adapts to such
2970         compilation scenarios.
2971
2972         * bytecode/Watchpoint.h:
2973         (JSC::WatchpointSet::isBeingWatched):
2974         (JSC::WatchpointSet::addressOfState):
2975         (JSC::WatchpointSet::offsetOfState):
2976         (JSC::WatchpointSet::addressOfSetIsNotEmpty):
2977         * jit/JIT.cpp:
2978         (JSC::JIT::emitNotifyWrite):
2979         (JSC::JIT::assertStackPointerOffset):
2980         * jit/JIT.h:
2981         * jit/JITPropertyAccess.cpp:
2982         (JSC::JIT::emit_op_resolve_scope):
2983         (JSC::JIT::emitSlow_op_resolve_scope):
2984         (JSC::JIT::emitGetGlobalProperty):
2985         (JSC::JIT::emitGetVarFromPointer):
2986         (JSC::JIT::emitGetVarFromIndirectPointer):
2987         (JSC::JIT::emitGetClosureVar):
2988         (JSC::JIT::emit_op_get_from_scope):
2989         (JSC::JIT::emitSlow_op_get_from_scope):
2990         (JSC::JIT::emitPutGlobalProperty):
2991         (JSC::JIT::emitPutGlobalVariable):
2992         (JSC::JIT::emitPutGlobalVariableIndirect):
2993         (JSC::JIT::emitPutClosureVar):
2994         (JSC::JIT::emit_op_put_to_scope):
2995         (JSC::JIT::emitSlow_op_put_to_scope):
2996         * jit/JITPropertyAccess32_64.cpp:
2997         (JSC::JIT::emit_op_resolve_scope):
2998         (JSC::JIT::emitSlow_op_resolve_scope):
2999         (JSC::JIT::emitGetGlobalProperty):
3000         (JSC::JIT::emitGetVarFromPointer):
3001         (JSC::JIT::emitGetVarFromIndirectPointer):
3002         (JSC::JIT::emitGetClosureVar):
3003         (JSC::JIT::emit_op_get_from_scope):
3004         (JSC::JIT::emitSlow_op_get_from_scope):
3005         (JSC::JIT::emitPutGlobalProperty):
3006         (JSC::JIT::emitPutGlobalVariable):
3007         (JSC::JIT::emitPutGlobalVariableIndirect):
3008         (JSC::JIT::emitPutClosureVar):
3009         (JSC::JIT::emit_op_put_to_scope):
3010         (JSC::JIT::emitSlow_op_put_to_scope):
3011         * runtime/CommonSlowPaths.h:
3012         (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
3013         (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
3014         * runtime/JSScope.cpp:
3015         (JSC::abstractAccess):
3016         * tests/stress/multiple-files-tests/global-lexical-variable-unresolved-property/first.js:
3017         (foo):
3018
3019 2015-09-08  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3020
3021         Implement all the arithmetic and logical instructions in WebAssembly
3022         https://bugs.webkit.org/show_bug.cgi?id=148882
3023
3024         Reviewed by Mark Lam.
3025
3026         This patch implements all the arithmetic and logical instructions for
3027         32-bit integers in WebAssembly.
3028
3029         * tests/stress/wasm-arithmetic.js:
3030         * tests/stress/wasm/arithmetic.wasm:
3031         * wasm/WASMFunctionCompiler.h:
3032         (JSC::WASMFunctionCompiler::buildUnaryI32):
3033         (JSC::WASMFunctionCompiler::buildBinaryI32):
3034         * wasm/WASMFunctionParser.cpp:
3035         (JSC::WASMFunctionParser::parseExpressionI32):
3036         (JSC::WASMFunctionParser::parseUnaryExpressionI32):
3037         * wasm/WASMFunctionParser.h:
3038         * wasm/WASMFunctionSyntaxChecker.h:
3039         (JSC::WASMFunctionSyntaxChecker::buildUnaryI32):
3040
3041 2015-09-08  Filip Pizlo  <fpizlo@apple.com>
3042
3043         Unreviewed, fix debug by removing an assertion that is not correct anymore.
3044
3045         * jit/Repatch.cpp:
3046         (JSC::linkFor):
3047
3048 2015-09-08  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3049
3050         Add initial support for doubles in WebAssembly
3051         https://bugs.webkit.org/show_bug.cgi?id=148913
3052
3053         Reviewed by Filip Pizlo.
3054
3055         Implement the ConstantPoolIndex, Immediate, and GetLocal instructions
3056         for doubles (float64) in WebAssembly.
3057
3058         * tests/stress/wasm-arithmetic-float64.js: Added.
3059         (shouldBe):
3060         * tests/stress/wasm/arithmetic-float64.wasm: Added.
3061         * wasm/WASMConstants.h:
3062         * wasm/WASMFunctionCompiler.h:
3063         (JSC::WASMFunctionCompiler::buildSetLocal):
3064         (JSC::WASMFunctionCompiler::buildReturn):
3065         (JSC::WASMFunctionCompiler::buildImmediateI32):
3066         (JSC::WASMFunctionCompiler::buildImmediateF64):
3067         (JSC::WASMFunctionCompiler::buildGetLocal):
3068         * wasm/WASMFunctionParser.cpp:
3069         (JSC::WASMFunctionParser::parseExpression):
3070         (JSC::WASMFunctionParser::parseExpressionF64):
3071         (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF64):
3072         (JSC::WASMFunctionParser::parseImmediateExpressionF64):
3073         (JSC::WASMFunctionParser::parseGetLocalExpressionF64):
3074         * wasm/WASMFunctionParser.h:
3075         * wasm/WASMFunctionSyntaxChecker.h:
3076         (JSC::WASMFunctionSyntaxChecker::buildImmediateF64):
3077         * wasm/WASMReader.cpp:
3078         (JSC::WASMReader::readOpExpressionF64):
3079         * wasm/WASMReader.h:
3080
3081 2015-09-06  Filip Pizlo  <fpizlo@apple.com>
3082
3083         CallLinkInfo inside StructureStubInfo should not use polymorphic stubs
3084         https://bugs.webkit.org/show_bug.cgi?id=148915
3085
3086         Reviewed by Mark Lam.
3087
3088         There is a subtle bug where if we reset a get_by_id IC that had a getter stub that in
3089         turn had a polymorphic call stub, then the GC won't know to keep the getter stub alive.
3090         This patch documents the bug in a FIXME and disables polymorphic call optimizations for
3091         getters. It also just so happens that the polymorphic call optimizations usually don't
3092         benefit getters, since it's hard to create polymorphism at the point of call without also
3093         introducing polymorphism in the base object's structure.
3094
3095         The added test doesn't reproduce the problem, because it's hard to get the GC to delete
3096         all of the stubs.
3097
3098         * bytecode/CallLinkInfo.h:
3099         (JSC::CallLinkInfo::CallLinkInfo):
3100         (JSC::CallLinkInfo::setCallLocations):
3101         (JSC::CallLinkInfo::allowStubs):
3102         (JSC::CallLinkInfo::disallowStubs):
3103         (JSC::CallLinkInfo::setUpCallFromFTL):
3104         * jit/Repatch.cpp:
3105         (JSC::generateByIdStub):
3106         (JSC::linkFor):
3107         (JSC::linkPolymorphicCall):
3108         * tests/stress/poly-call-stub-in-getter-stub.js: Added.
3109         (foo):
3110         (makeGetter):
3111
3112 2015-09-07  Filip Pizlo  <fpizlo@apple.com>
3113
3114         The put_by_id IC store barrier contract should benefit transition over replace
3115         https://bugs.webkit.org/show_bug.cgi?id=148943
3116
3117         Reviewed by Mark Lam.
3118
3119         Previously, we would only emit a barrier if the value being stored was possibly a cell, so
3120         the transition stub code generator would have to emit a barrier for the store of the
3121         structure, just in case the structure was newer than the base object.
3122
3123         This changes the contract so that the put_by_id callsite would always have a barrier on the
3124         base (except if it proved that the base was brand new). That way, the transition doesn't have
3125         to have a barrier unless it allocates.
3126
3127         This is meant to be a perf-neutral change that I need for the IC refactoring in
3128         https://bugs.webkit.org/show_bug.cgi?id=148717.
3129
3130         * dfg/DFGFixupPhase.cpp:
3131         (JSC::DFG::FixupPhase::fixupNode):
3132         * dfg/DFGStoreBarrierInsertionPhase.cpp:
3133         * jit/Repatch.cpp:
3134         (JSC::emitPutTransitionStub):
3135
3136 2015-09-07  Alex Christensen  <achristensen@webkit.org>
3137
3138         Windows non-cygwin build fix after r189333.
3139
3140         SVN on Windows (non-cygwin) doesn't like having the * character in file names.
3141         I replaced "*" with "star" in some of Geoff's new tests.
3142
3143         * tests/es6.yaml:
3144         Changed all _*_ to _star_
3145         * tests/es6/generators_yield_*_arrays.js: Removed.
3146         * tests/es6/generators_yield_*_astral_plane_strings.js: Removed.
3147         * tests/es6/generators_yield_*_generator_instances.js: Removed.
3148         * tests/es6/generators_yield_*_generic_iterables.js: Removed.
3149         * tests/es6/generators_yield_*_instances_of_iterables.js: Removed.
3150         * tests/es6/generators_yield_*_iterator_closing.js: Removed.
3151         * tests/es6/generators_yield_*_iterator_closing_via_throw.js: Removed.
3152         * tests/es6/generators_yield_*_on_non-iterables_is_a_runtime_error.js: Removed.
3153         * tests/es6/generators_yield_*_sparse_arrays.js: Removed.
3154         * tests/es6/generators_yield_*_strings.js: Removed.
3155         * tests/es6/generators_yield_star_arrays.js: Copied from tests/es6/generators_yield_*_arrays.js.
3156         * tests/es6/generators_yield_star_astral_plane_strings.js: Copied from tests/es6/generators_yield_*_astral_plane_strings.js.
3157         * tests/es6/generators_yield_star_generator_instances.js: Copied from tests/es6/generators_yield_*_generator_instances.js.
3158         * tests/es6/generators_yield_star_generic_iterables.js: Copied from tests/es6/generators_yield_*_generic_iterables.js.
3159         * tests/es6/generators_yield_star_instances_of_iterables.js: Copied from tests/es6/generators_yield_*_instances_of_iterables.js.
3160         * tests/es6/generators_yield_star_iterator_closing.js: Copied from tests/es6/generators_yield_*_iterator_closing.js.
3161         * tests/es6/generators_yield_star_iterator_closing_via_throw.js: Copied from tests/es6/generators_yield_*_iterator_closing_via_throw.js.
3162         * tests/es6/generators_yield_star_on_non-iterables_is_a_runtime_error.js: Copied from tests/es6/generators_yield_*_on_non-iterables_is_a_runtime_error.js.
3163         * tests/es6/generators_yield_star_sparse_arrays.js: Copied from tests/es6/generators_yield_*_sparse_arrays.js.
3164         * tests/es6/generators_yield_star_strings.js: Copied from tests/es6/generators_yield_*_strings.js.
3165
3166 2015-09-06  Mark Lam  <mark.lam@apple.com>
3167
3168         Gardening: fix broken Windows build after r189454.
3169
3170         Not reviewed.
3171
3172         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
3173         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
3174
3175 2015-09-06  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3176
3177         Implement the relational instructions in WebAssembly
3178         https://bugs.webkit.org/show_bug.cgi?id=148838
3179
3180         Reviewed by Saam Barati.
3181
3182         This patch implements the relational instructions for 32-bit integers in
3183         WebAssembly.
3184
3185         * tests/stress/wasm-arithmetic.js:
3186         * tests/stress/wasm-locals.js:
3187         * tests/stress/wasm-relational.js: Added.
3188         (shouldBe):
3189         * tests/stress/wasm/arithmetic.wasm: Renamed from Source/JavaScriptCore/tests/stress/wasm-arithmetic.wasm.
3190         * tests/stress/wasm/locals.wasm: Renamed from Source/JavaScriptCore/tests/stress/wasm-locals.wasm.
3191         * tests/stress/wasm/relational.wasm: Added.
3192         * wasm/WASMFunctionCompiler.h:
3193         (JSC::WASMFunctionCompiler::buildRelationalI32):
3194         * wasm/WASMFunctionParser.cpp:
3195         (JSC::WASMFunctionParser::parseExpressionI32):
3196         (JSC::WASMFunctionParser::parseRelationalI32ExpressionI32):
3197         * wasm/WASMFunctionParser.h:
3198         * wasm/WASMFunctionSyntaxChecker.h:
3199         (JSC::WASMFunctionSyntaxChecker::buildRelationalI32):
3200
3201 2015-09-06  Mark Lam  <mark.lam@apple.com>
3202
3203         StackOverflow stack unwinding should stop at native frames.
3204         https://bugs.webkit.org/show_bug.cgi?id=148749
3205
3206         Reviewed by Michael Saboff.
3207
3208         In the present code, after ping-pong'ing back and forth between native and JS
3209         code a few times, if we have a stack overflow on re-entry into the VM to run
3210         JS code's whose stack frame would overflow the JS stack, the code will end up
3211         unwinding past the native function that is making the call to re-enter the VM.
3212         As a result, any clean up code (e.g. destructors for stack variables) in the
3213         skipped native function frame (and its chain of native function callers) will
3214         not be called.
3215
3216         This patch is based on the Michael Saboff's fix of this issue landed on the
3217         jsc-tailcall branch: http://trac.webkit.org/changeset/188555
3218
3219         We now check for the case where there are no JS frames to unwind since the
3220         last native frame, and treat the exception as an unhandled exception.  The
3221         native function is responsible for further propagating the exception if needed.
3222
3223         Other supporting work:
3224         1. Remove vm->vmEntryFrameForThrow.  It should always be the same as
3225            vm->topVMEntryFrame.
3226         2. Change operationThrowStackOverflowError() to use the throwStackOverflowError()
3227            helper function instead of rolling its own.
3228         3. Added a test that exercises this edge case.  The test should not hang or crash.
3229
3230         * API/tests/PingPongStackOverflowTest.cpp: Added.
3231         (PingPongStackOverflowObject_hasInstance):
3232         (testPingPongStackOverflow):
3233         * API/tests/PingPongStackOverflowTest.h: Added.
3234         * API/tests/testapi.c:
3235         (main):
3236         * JavaScriptCore.xcodeproj/project.pbxproj:
3237         * interpreter/CallFrame.h:
3238         (JSC::ExecState::operator=):
3239         (JSC::ExecState::callerFrame):
3240         (JSC::ExecState::callerFrameOrVMEntryFrame):
3241         (JSC::ExecState::argIndexForRegister):
3242         (JSC::ExecState::callerFrameAndPC):
3243         * interpreter/Interpreter.cpp:
3244         (JSC::UnwindFunctor::UnwindFunctor):
3245         (JSC::UnwindFunctor::operator()):
3246         (JSC::Interpreter::unwind):
3247         * interpreter/Interpreter.h:
3248         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
3249         (JSC::Interpreter::sampler):
3250         * jit/CCallHelpers.h:
3251         (JSC::CCallHelpers::jumpToExceptionHandler):
3252         * jit/JITExceptions.cpp:
3253         (JSC::genericUnwind):
3254         * jit/JITExceptions.h:
3255         * jit/JITOpcodes.cpp:
3256         (JSC::JIT::emit_op_catch):
3257         * jit/JITOpcodes32_64.cpp:
3258         (JSC::JIT::emit_op_catch):
3259         * jit/JITOperations.cpp:
3260         * llint/LowLevelInterpreter32_64.asm:
3261         * llint/LowLevelInterpreter64.asm:
3262         * runtime/VM.h:
3263         (JSC::VM::exceptionOffset):
3264         (JSC::VM::callFrameForThrowOffset):
3265         (JSC::VM::vmEntryFrameForThrowOffset): Deleted.
3266         (JSC::VM::topVMEntryFrameOffset): Deleted.
3267
3268 2015-09-06  Yusuke Suzuki  <utatane.tea@gmail.com>
3269
3270         Unreviewed, disable module tests in Windows until name resolution is fixed
3271         https://bugs.webkit.org/show_bug.cgi?id=148689
3272
3273         Until bug[1] is fixed, we disable the module tests.
3274         Since the local file system name resolution is just implemented in jsc.cpp and
3275         is intended to be used for the module tests, it does not affect JSC framework
3276         and WebKit itself.
3277
3278         [1]: https://bugs.webkit.org/show_bug.cgi?id=148917
3279
3280         * tests/modules.yaml:
3281
3282 2015-09-06  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3283
3284         Simplify JIT::emit_op_mod()
3285         https://bugs.webkit.org/show_bug.cgi?id=148908
3286
3287         Reviewed by Michael Saboff.
3288
3289         The IDIV instruction on x86 divides the value in the EDX:EAX registers
3290         by the source operand and stores the quotient in EAX and the remainder
3291         in EDX. Therefore, we store the values that we don't want to be
3292         overwritten by IDIV in registers that are not EAX or EDX. This patch
3293         makes the intention clearer and makes the code easier to read.
3294
3295         * jit/JITArithmetic.cpp:
3296         (JSC::JIT::emit_op_mod):
3297
3298 2015-09-05  Mark Lam  <mark.lam@apple.com>
3299
3300         Fix JSDollarVMPrototype after r189160.
3301         https://bugs.webkit.org/show_bug.cgi?id=148900
3302
3303         Reviewed by Michael Saboff.
3304
3305         JSDollarVMPrototype needs to be updated to match http://trac.webkit.org/changeset/189160 i.e.
3306         remove the use of JSC::Function bit in its property attributes.
3307
3308         * tools/JSDollarVMPrototype.cpp:
3309         (JSC::JSDollarVMPrototype::finishCreation):
3310
3311 2015-09-05  Yusuke Suzuki  <utatane.tea@gmail.com>
3312
3313         Unreviewed, fix the module name resolution in Windows
3314         https://bugs.webkit.org/show_bug.cgi?id=148689
3315
3316         Attempt to fix the module name resolution in Windows.
3317         A module name is represented as the UNIX path under the current module tests.
3318         This fix split the module name with '/' instead of pathSeparator().
3319
3320         This is only utilized by the jsc.cpp for the local module tests.
3321         So, WebKit production and JavaScriptCore framework are not affected by this change.
3322
3323         * jsc.cpp:
3324         (ModuleName::startsWithRoot):
3325         (ModuleName::ModuleName):
3326         (resolvePath):
3327         (GlobalObject::moduleLoaderResolve):
3328
3329 2015-09-05  Brian Burg  <bburg@apple.com>
3330
3331         Web Inspector: tighten up lifetimes for Agent-owned objects, and initialize agents using contexts
3332         https://bugs.webkit.org/show_bug.cgi?id=148625
3333
3334         Reviewed by Joseph Pecoraro.
3335
3336         All agents own their domain-specific frontend and backend dispatchers. Change so that
3337         they are initialized in constructors rather than when a frontend connects or disconnects.
3338         This may cause additional memory use, but this can be counteracted by lazily creating
3339         some agents that are not required for other agents to function (i.e., runtime and page agents).