Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script...
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-09-21  Saam barati  <sbarati@apple.com>
2
3         Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script with "class" with default constructor
4         https://bugs.webkit.org/show_bug.cgi?id=149248
5
6         Reviewed by Mark Lam.
7
8         We keep track of which functions have and have not
9         executed so we can show visually, inside the inspector,
10         which functions have and have not executed. With a default
11         constructor, our parser parses code that isn't in the actual
12         JavaScript source code of the user. Our parser would then
13         give us a range of starting at "1" to "1 + default constructor length"
14         as being the text range of a function. But, this would then pollute
15         actual source code that was at these ranges.
16
17         Therefore, we should treat these default constructor source 
18         codes as having "invalid" ranges. We use [UINT_MAX, UINT_MAX] 
19         as the invalid range. This range has the effect of not polluting 
20         valid ranges inside the source code.
21
22         * bytecode/UnlinkedFunctionExecutable.cpp:
23         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
24         (JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets):
25         * bytecode/UnlinkedFunctionExecutable.h:
26         * bytecompiler/BytecodeGenerator.cpp:
27         (JSC::BytecodeGenerator::emitNewDefaultConstructor):
28
29 2015-09-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
30
31         Implement call statements and call expressions of type void in WebAssembly
32         https://bugs.webkit.org/show_bug.cgi?id=149411
33
34         Reviewed by Mark Lam.
35
36         Call instructions in WebAssembly can be both statements and expressions.
37         This patch implements call statements. It also implements call
38         expressions of type void. The only place where call expressions of type
39         void can occur is the left-hand side of the comma (,) operator, which
40         will be implemented in a subsequent patch. The comma operator requires
41         both of its operands to be expressions.
42
43         * tests/stress/wasm-calls.js:
44         * tests/stress/wasm/calls.wasm:
45         * wasm/WASMConstants.h:
46         * wasm/WASMFunctionParser.cpp:
47         (JSC::WASMFunctionParser::parseStatement):
48         (JSC::WASMFunctionParser::parseExpression):
49         (JSC::WASMFunctionParser::parseExpressionI32):
50         (JSC::WASMFunctionParser::parseExpressionF32):
51         (JSC::WASMFunctionParser::parseExpressionF64):
52         (JSC::WASMFunctionParser::parseExpressionVoid):
53         (JSC::WASMFunctionParser::parseCallInternal):
54         (JSC::WASMFunctionParser::parseCallIndirect):
55         (JSC::WASMFunctionParser::parseCallImport):
56         * wasm/WASMFunctionParser.h:
57         * wasm/WASMReader.cpp:
58         (JSC::WASMReader::readOpExpressionVoid):
59         * wasm/WASMReader.h:
60
61 2015-09-21  Filip Pizlo  <fpizlo@apple.com>
62
63         JSC should infer property types
64         https://bugs.webkit.org/show_bug.cgi?id=148610
65
66         Reviewed by Geoffrey Garen.
67
68         This change brings recursive type inference to JavaScript object properties in JSC. We check that a
69         value being stored into a property obeys a property's type before we do the store. If it doesn't,
70         we broaden the property's type to include the new value. If optimized code was relying on the old
71         type, we deoptimize that code.
72
73         The type system that this supports includes important primitive types like Int32 and Boolean. But
74         it goes further and also includes a type kind called ObjectWithStructure, which means that we
75         expect the property to always point to objects with a particular structure. This only works for
76         leaf structures (i.e. structures that have a valid transition watchpoint set). Invalidation of the
77         transition set causes the property type to become Object (meaning an object with any structure).
78         This capability gives us recursive type inference. It's possible for an expression like "o.f.g.h"
79         to execute without any type checks if .f and .g are both ObjectWithStructure.
80
81         The type inference of a property is tracked by an InferredType instance, which is a JSCell. This
82         means that it manages its own memory. That's convenient. For example, when the DFG is interested in
83         one of these, it can just list the InferredType as a weak reference in addition to setting a
84         watchpoint. This ensures that even if the InferredType is dropped by the owning structure, the DFG
85         won't read a dangling pointer. A mapping from property name to InferredType is implemented by
86         InferredTypeTable, which is also a JSCell. Each Structure may point to some InferredTypeTable.
87
88         This feature causes programs to be happier (run faster without otherwise doing bad things like
89         using lots of memory) when four conditions hold:
90
91         1) A property converges to one of the types that we support.
92         2) The property is loaded from more frequently than it is stored to.
93         3) The stores are all cached, so that we statically emit a type check.
94         4) We don't allocate a lot of meta-data for the property's type.
95
96         We maximize the likelihood of (1) by having a rich type system. But having a rich type system means
97         that a reflective put to a property has to have a large switch over the inferred type to decide how
98         to do the type check. That's why we need (3). We ensure (3) by having every reflective property
99         store (i.e. putDirectInternal in any context that isn't PutById) force the inferred type to become
100         Top. We don't really worry about ensuring (2); this is statistically true for most programs
101         already.
102
103         Probably the most subtle trickery goes into (4). Logically we'd like to say that each
104         (Structure, Property) maps to its own InferredType. If structure S1 has a transition edge to S2,
105         then we could ensure that the InferredType I1 where (S1, Property)->I1 has a data flow constraint
106         to I2 where (S2, Property)->I2. That would work, but it would involve a lot of memory. And when I1
107         gets invalidated in some way, it would have to tell I2 about it, and then I2 might tell other
108         InferredType objects downstream. That's madness. So, the first major compromise that we make here
109         is to say that if some property has some InferredType at some Structure, then anytime we
110         transition from that Structure, the new Structure shares the same InferredType for that property.
111         This unifies the type of the property over the entire transition tree starting at the Structure at
112         which the property was added. But this would still mean that each Structure would have its own
113         InferredTypeTable. We don't want that because experience with PropertyTable shows that this can be
114         a major memory hog. So, we don't create an InferredTypeTable until someone adds a property that is
115         subject to type inference (i.e. it was added non-reflectively), and we share that InferredTypeTable
116         with the entire structure transition tree rooted at the Structure that had the first inferred
117         property. We also drop the InferredTypeTable anytime that we do a dictionary transition, and we
118         don't allow further property type inference if a structure had ever been a dictionary.
119
120         This is a 3% speed-up on Octane and a 12% speed-up on Kraken on my setup. It's not a significant
121         slow-down on any benchmark I ran.
122
123         * CMakeLists.txt:
124         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
125         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
126         * JavaScriptCore.xcodeproj/project.pbxproj:
127         * assembler/MacroAssemblerARM64.h:
128         (JSC::MacroAssemblerARM64::branchTest64):
129         * assembler/MacroAssemblerX86_64.h:
130         (JSC::MacroAssemblerX86_64::branchTest64):
131         (JSC::MacroAssemblerX86_64::test64):
132         * bytecode/PolymorphicAccess.cpp:
133         (JSC::AccessCase::generate):
134         * bytecode/PutByIdFlags.cpp:
135         (WTF::printInternal):
136         * bytecode/PutByIdFlags.h:
137         (JSC::encodeStructureID):
138         (JSC::decodeStructureID):
139         * bytecode/PutByIdStatus.cpp:
140         (JSC::PutByIdStatus::computeFromLLInt):
141         (JSC::PutByIdStatus::computeFor):
142         (JSC::PutByIdStatus::computeForStubInfo):
143         * bytecode/PutByIdVariant.cpp:
144         (JSC::PutByIdVariant::operator=):
145         (JSC::PutByIdVariant::replace):
146         (JSC::PutByIdVariant::transition):
147         (JSC::PutByIdVariant::setter):
148         (JSC::PutByIdVariant::attemptToMerge):
149         (JSC::PutByIdVariant::dumpInContext):
150         * bytecode/PutByIdVariant.h:
151         (JSC::PutByIdVariant::newStructure):
152         (JSC::PutByIdVariant::requiredType):
153         * bytecode/UnlinkedCodeBlock.h:
154         (JSC::UnlinkedInstruction::UnlinkedInstruction):
155         * bytecode/Watchpoint.h:
156         (JSC::InlineWatchpointSet::touch):
157         (JSC::InlineWatchpointSet::isBeingWatched):
158         * bytecompiler/BytecodeGenerator.cpp:
159         (JSC::BytecodeGenerator::addConstantValue):
160         (JSC::BytecodeGenerator::emitPutById):
161         (JSC::BytecodeGenerator::emitDirectPutById):
162         * dfg/DFGAbstractInterpreter.h:
163         (JSC::DFG::AbstractInterpreter::filter):
164         (JSC::DFG::AbstractInterpreter::filterByValue):
165         * dfg/DFGAbstractInterpreterInlines.h:
166         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
167         (JSC::DFG::AbstractInterpreter<AbstractStateType>::filter):
168         * dfg/DFGAbstractValue.cpp:
169         (JSC::DFG::AbstractValue::setType):
170         (JSC::DFG::AbstractValue::set):
171         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
172         (JSC::DFG::AbstractValue::mergeOSREntryValue):
173         (JSC::DFG::AbstractValue::isType):
174         (JSC::DFG::AbstractValue::filter):
175         (JSC::DFG::AbstractValue::filterValueByType):
176         * dfg/DFGAbstractValue.h:
177         (JSC::DFG::AbstractValue::setType):
178         (JSC::DFG::AbstractValue::isType):
179         (JSC::DFG::AbstractValue::validate):
180         * dfg/DFGByteCodeParser.cpp:
181         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
182         (JSC::DFG::ByteCodeParser::handleGetByOffset):
183         (JSC::DFG::ByteCodeParser::handlePutByOffset):
184         (JSC::DFG::ByteCodeParser::load):
185         (JSC::DFG::ByteCodeParser::store):
186         (JSC::DFG::ByteCodeParser::handleGetById):
187         (JSC::DFG::ByteCodeParser::handlePutById):
188         * dfg/DFGClobbersExitState.cpp:
189         (JSC::DFG::clobbersExitState):
190         * dfg/DFGConstantFoldingPhase.cpp:
191         (JSC::DFG::ConstantFoldingPhase::foldConstants):
192         (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
193         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
194         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
195         * dfg/DFGDesiredInferredType.h: Added.
196         (JSC::DFG::DesiredInferredType::DesiredInferredType):
197         (JSC::DFG::DesiredInferredType::operator bool):
198         (JSC::DFG::DesiredInferredType::object):
199         (JSC::DFG::DesiredInferredType::expected):
200         (JSC::DFG::DesiredInferredType::isStillValid):
201         (JSC::DFG::DesiredInferredType::add):
202         (JSC::DFG::DesiredInferredType::operator==):
203         (JSC::DFG::DesiredInferredType::operator!=):
204         (JSC::DFG::DesiredInferredType::isHashTableDeletedValue):
205         (JSC::DFG::DesiredInferredType::hash):
206         (JSC::DFG::DesiredInferredType::dumpInContext):
207         (JSC::DFG::DesiredInferredType::dump):
208         (JSC::DFG::DesiredInferredTypeHash::hash):
209         (JSC::DFG::DesiredInferredTypeHash::equal):
210         * dfg/DFGDesiredWatchpoints.cpp:
211         (JSC::DFG::AdaptiveStructureWatchpointAdaptor::add):
212         (JSC::DFG::InferredTypeAdaptor::add):
213         (JSC::DFG::DesiredWatchpoints::DesiredWatchpoints):
214         (JSC::DFG::DesiredWatchpoints::~DesiredWatchpoints):
215         (JSC::DFG::DesiredWatchpoints::addLazily):
216         (JSC::DFG::DesiredWatchpoints::consider):
217         (JSC::DFG::DesiredWatchpoints::reallyAdd):
218         (JSC::DFG::DesiredWatchpoints::areStillValid):
219         (JSC::DFG::DesiredWatchpoints::dumpInContext):
220         * dfg/DFGDesiredWatchpoints.h:
221         (JSC::DFG::AdaptiveStructureWatchpointAdaptor::dumpInContext):
222         (JSC::DFG::InferredTypeAdaptor::hasBeenInvalidated):
223         (JSC::DFG::InferredTypeAdaptor::dumpInContext):
224         (JSC::DFG::DesiredWatchpoints::isWatched):
225         * dfg/DFGFixupPhase.cpp:
226         (JSC::DFG::FixupPhase::fixupNode):
227         * dfg/DFGGraph.cpp:
228         (JSC::DFG::Graph::dump):
229         (JSC::DFG::Graph::isSafeToLoad):
230         (JSC::DFG::Graph::inferredTypeFor):
231         (JSC::DFG::Graph::livenessFor):
232         (JSC::DFG::Graph::tryGetConstantProperty):
233         (JSC::DFG::Graph::inferredValueForProperty):
234         (JSC::DFG::Graph::tryGetConstantClosureVar):
235         * dfg/DFGGraph.h:
236         (JSC::DFG::Graph::registerInferredType):
237         (JSC::DFG::Graph::inferredTypeForProperty):
238         * dfg/DFGInferredTypeCheck.cpp: Added.
239         (JSC::DFG::insertInferredTypeCheck):
240         * dfg/DFGInferredTypeCheck.h: Added.
241         * dfg/DFGNode.h:
242         * dfg/DFGObjectAllocationSinkingPhase.cpp:
243         * dfg/DFGPropertyTypeKey.h: Added.
244         (JSC::DFG::PropertyTypeKey::PropertyTypeKey):
245         (JSC::DFG::PropertyTypeKey::operator bool):
246         (JSC::DFG::PropertyTypeKey::structure):
247         (JSC::DFG::PropertyTypeKey::uid):
248         (JSC::DFG::PropertyTypeKey::operator==):
249         (JSC::DFG::PropertyTypeKey::operator!=):
250         (JSC::DFG::PropertyTypeKey::hash):
251         (JSC::DFG::PropertyTypeKey::isHashTableDeletedValue):
252         (JSC::DFG::PropertyTypeKey::dumpInContext):
253         (JSC::DFG::PropertyTypeKey::dump):
254         (JSC::DFG::PropertyTypeKey::deletedUID):
255         (JSC::DFG::PropertyTypeKeyHash::hash):
256         (JSC::DFG::PropertyTypeKeyHash::equal):
257         * dfg/DFGSafeToExecute.h:
258         (JSC::DFG::SafeToExecuteEdge::operator()):
259         (JSC::DFG::safeToExecute):
260         * dfg/DFGSpeculativeJIT.cpp:
261         (JSC::DFG::SpeculativeJIT::compileTypeOf):
262         (JSC::DFG::SpeculativeJIT::compileCheckStructure):
263         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
264         (JSC::DFG::SpeculativeJIT::speculateCell):
265         (JSC::DFG::SpeculativeJIT::speculateCellOrOther):
266         (JSC::DFG::SpeculativeJIT::speculateObject):
267         (JSC::DFG::SpeculativeJIT::speculate):
268         * dfg/DFGSpeculativeJIT.h:
269         * dfg/DFGSpeculativeJIT32_64.cpp:
270         (JSC::DFG::SpeculativeJIT::compile):
271         * dfg/DFGSpeculativeJIT64.cpp:
272         (JSC::DFG::SpeculativeJIT::compile):
273         * dfg/DFGStoreBarrierInsertionPhase.cpp:
274         * dfg/DFGStructureAbstractValue.h:
275         (JSC::DFG::StructureAbstractValue::at):
276         (JSC::DFG::StructureAbstractValue::operator[]):
277         (JSC::DFG::StructureAbstractValue::onlyStructure):
278         (JSC::DFG::StructureAbstractValue::forEach):
279         * dfg/DFGUseKind.cpp:
280         (WTF::printInternal):
281         * dfg/DFGUseKind.h:
282         (JSC::DFG::typeFilterFor):
283         * dfg/DFGValidate.cpp:
284         (JSC::DFG::Validate::validate):
285         * ftl/FTLCapabilities.cpp:
286         (JSC::FTL::canCompile):
287         * ftl/FTLLowerDFGToLLVM.cpp:
288         (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckStructure):
289         (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckCell):
290         (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiPutByOffset):
291         (JSC::FTL::DFG::LowerDFGToLLVM::numberOrNotCellToInt32):
292         (JSC::FTL::DFG::LowerDFGToLLVM::checkInferredType):
293         (JSC::FTL::DFG::LowerDFGToLLVM::loadProperty):
294         (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
295         (JSC::FTL::DFG::LowerDFGToLLVM::speculateCell):
296         (JSC::FTL::DFG::LowerDFGToLLVM::speculateCellOrOther):
297         (JSC::FTL::DFG::LowerDFGToLLVM::speculateMachineInt):
298         (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
299         * jit/AssemblyHelpers.cpp:
300         (JSC::AssemblyHelpers::decodedCodeMapFor):
301         (JSC::AssemblyHelpers::branchIfNotType):
302         (JSC::AssemblyHelpers::purifyNaN):
303         * jit/AssemblyHelpers.h:
304         (JSC::AssemblyHelpers::branchIfEqual):
305         (JSC::AssemblyHelpers::branchIfNotCell):
306         (JSC::AssemblyHelpers::branchIfCell):
307         (JSC::AssemblyHelpers::branchIfNotOther):
308         (JSC::AssemblyHelpers::branchIfInt32):
309         (JSC::AssemblyHelpers::branchIfNotInt32):
310         (JSC::AssemblyHelpers::branchIfNumber):
311         (JSC::AssemblyHelpers::branchIfNotNumber):
312         (JSC::AssemblyHelpers::branchIfEmpty):
313         (JSC::AssemblyHelpers::branchStructure):
314         * jit/Repatch.cpp:
315         (JSC::tryCachePutByID):
316         * llint/LLIntSlowPaths.cpp:
317         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
318         * llint/LowLevelInterpreter.asm:
319         * llint/LowLevelInterpreter32_64.asm:
320         * llint/LowLevelInterpreter64.asm:
321         * runtime/InferredType.cpp: Added.
322         (JSC::InferredType::create):
323         (JSC::InferredType::destroy):
324         (JSC::InferredType::createStructure):
325         (JSC::InferredType::visitChildren):
326         (JSC::InferredType::kindForFlags):
327         (JSC::InferredType::Descriptor::forValue):
328         (JSC::InferredType::Descriptor::forFlags):
329         (JSC::InferredType::Descriptor::putByIdFlags):
330         (JSC::InferredType::Descriptor::merge):
331         (JSC::InferredType::Descriptor::removeStructure):
332         (JSC::InferredType::Descriptor::subsumes):
333         (JSC::InferredType::Descriptor::dumpInContext):
334         (JSC::InferredType::Descriptor::dump):
335         (JSC::InferredType::InferredType):
336         (JSC::InferredType::~InferredType):
337         (JSC::InferredType::canWatch):
338         (JSC::InferredType::addWatchpoint):
339         (JSC::InferredType::dump):
340         (JSC::InferredType::willStoreValueSlow):
341         (JSC::InferredType::makeTopSlow):
342         (JSC::InferredType::set):
343         (JSC::InferredType::removeStructure):
344         (JSC::InferredType::InferredStructureWatchpoint::fireInternal):
345         (JSC::InferredType::InferredStructureFinalizer::finalizeUnconditionally):
346         (JSC::InferredType::InferredStructure::InferredStructure):
347         (WTF::printInternal):
348         * runtime/InferredType.h: Added.
349         * runtime/InferredTypeTable.cpp: Added.
350         (JSC::InferredTypeTable::create):
351         (JSC::InferredTypeTable::destroy):
352         (JSC::InferredTypeTable::createStructure):
353         (JSC::InferredTypeTable::visitChildren):
354         (JSC::InferredTypeTable::get):
355         (JSC::InferredTypeTable::willStoreValue):
356         (JSC::InferredTypeTable::makeTop):
357         (JSC::InferredTypeTable::InferredTypeTable):
358         (JSC::InferredTypeTable::~InferredTypeTable):
359         * runtime/InferredTypeTable.h: Added.
360         * runtime/JSObject.h:
361         (JSC::JSObject::putDirectInternal):
362         (JSC::JSObject::putDirectWithoutTransition):
363         * runtime/Structure.cpp:
364         (JSC::Structure::materializePropertyMap):
365         (JSC::Structure::addPropertyTransition):
366         (JSC::Structure::removePropertyTransition):
367         (JSC::Structure::startWatchingInternalProperties):
368         (JSC::Structure::willStoreValueSlow):
369         (JSC::Structure::visitChildren):
370         (JSC::Structure::prototypeChainMayInterceptStoreTo):
371         * runtime/Structure.h:
372         (JSC::PropertyMapEntry::PropertyMapEntry):
373         * runtime/StructureInlines.h:
374         (JSC::Structure::get):
375         * runtime/VM.cpp:
376         (JSC::VM::VM):
377         * runtime/VM.h:
378         * tests/stress/prop-type-boolean-then-string.js: Added.
379         * tests/stress/prop-type-int32-then-string.js: Added.
380         * tests/stress/prop-type-number-then-string.js: Added.
381         * tests/stress/prop-type-object-or-other-then-string.js: Added.
382         * tests/stress/prop-type-object-then-string.js: Added.
383         * tests/stress/prop-type-other-then-string.js: Added.
384         * tests/stress/prop-type-string-then-object.js: Added.
385         * tests/stress/prop-type-struct-or-other-then-string.js: Added.
386         * tests/stress/prop-type-struct-then-object.js: Added.
387         * tests/stress/prop-type-struct-then-object-opt.js: Added.
388         * tests/stress/prop-type-struct-then-object-opt-fold.js: Added.
389         * tests/stress/prop-type-struct-then-object-opt-multi.js: Added.
390
391 2015-09-21  Filip Pizlo  <fpizlo@apple.com>
392
393         WebCore shouldn't have to include DFG headers
394         https://bugs.webkit.org/show_bug.cgi?id=149337
395
396         Reviewed by Michael Saboff.
397
398         This does some simple rewiring and outlining of CodeBlock/Heap functionality so that
399         those headers don't have to include DFG headers. As a result, WebCore no longer includes
400         DFG headers, except for two fairly innocent ones (DFGCommon.h and DFGCompilationMode.h).
401         This also changes the Xcode project file so that all but those two headers are Project
402         rather than Private. So, if WebCore accidentally includes any of them, we'll get a build
403         error.
404
405         The main group of headers that this prevents WebCore from including are the DFGDesired*.h
406         files and whatever those include. Those headers used to be fairly simple, but now they
407         are growing in complexity (especially with things like http://webkit.org/b/148610). So,
408         it makes sense to make sure they don't leak out of JSC.
409
410         * JavaScriptCore.xcodeproj/project.pbxproj:
411         * bytecode/CallLinkInfo.cpp:
412         (JSC::CallLinkInfo::CallLinkInfo):
413         (JSC::CallLinkInfo::~CallLinkInfo):
414         (JSC::CallLinkInfo::clearStub):
415         (JSC::CallLinkInfo::visitWeak):
416         (JSC::CallLinkInfo::setFrameShuffleData):
417         * bytecode/CallLinkInfo.h:
418         (JSC::CallLinkInfo::isVarargsCallType):
419         (JSC::CallLinkInfo::specializationKindFor):
420         (JSC::CallLinkInfo::frameShuffleData):
421         (JSC::CallLinkInfo::CallLinkInfo): Deleted.
422         (JSC::CallLinkInfo::~CallLinkInfo): Deleted.
423         (JSC::CallLinkInfo::setFrameShuffleData): Deleted.
424         * bytecode/CodeBlock.cpp:
425         (JSC::CodeBlock::getOrAddArrayProfile):
426         (JSC::CodeBlock::codeOrigins):
427         (JSC::CodeBlock::numberOfDFGIdentifiers):
428         (JSC::CodeBlock::identifier):
429         (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
430         * bytecode/CodeBlock.h:
431         (JSC::CodeBlock::hasExpressionInfo):
432         (JSC::CodeBlock::hasCodeOrigins):
433         (JSC::CodeBlock::numberOfIdentifiers):
434         (JSC::CodeBlock::identifier):
435         (JSC::CodeBlock::codeOrigins): Deleted.
436         (JSC::CodeBlock::numberOfDFGIdentifiers): Deleted.
437         * bytecode/CodeOrigin.h:
438         * dfg/DFGDesiredIdentifiers.cpp:
439         * heap/Heap.cpp:
440         (JSC::Heap::didFinishIterating):
441         (JSC::Heap::completeAllDFGPlans):
442         (JSC::Heap::markRoots):
443         (JSC::Heap::deleteAllCodeBlocks):
444         * heap/Heap.h:
445         * heap/HeapInlines.h:
446         (JSC::Heap::deprecatedReportExtraMemory):
447         (JSC::Heap::forEachCodeBlock):
448         (JSC::Heap::forEachProtectedCell):
449         * runtime/Executable.h:
450         * runtime/JSCInlines.h:
451         (JSC::Heap::forEachCodeBlock): Deleted.
452
453 2015-09-21 Aleksandr Skachkov   <gskachkov@gmail.com>
454
455         Web Inspector: arrow function names are never inferred, call frames are labeled (anonymous function)
456         https://bugs.webkit.org/show_bug.cgi?id=148318
457
458         Reviewed by Saam Barati.
459
460         Tiny change to support of the inferred name in arrow function
461  
462         * parser/ASTBuilder.h:
463         (JSC::ASTBuilder::createAssignResolve):
464
465 2015-09-19 Aleksandr Skachkov   <gskachkov@gmail.com>
466
467         New tests introduced in r188545 fail on 32 bit ARM
468         https://bugs.webkit.org/show_bug.cgi?id=148376
469
470         Reviewed by Saam Barati.
471
472         Added correct support of the ARM CPU in JIT functions that are related to arrow function.
473
474
475         * dfg/DFGSpeculativeJIT.cpp:
476         (JSC::DFG::SpeculativeJIT::compileNewFunction):
477         * dfg/DFGSpeculativeJIT.h:
478         (JSC::DFG::SpeculativeJIT::callOperation):
479         * jit/JIT.h:
480         * jit/JITInlines.h:
481         (JSC::JIT::callOperation):
482         * jit/JITOpcodes.cpp:
483         (JSC::JIT::emitNewFuncExprCommon):
484
485 2015-09-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
486
487         Implement Store expressions in WebAssembly
488         https://bugs.webkit.org/show_bug.cgi?id=149395
489
490         Reviewed by Geoffrey Garen.
491
492         The Store instruction in WebAssembly stores a value in the linear memory
493         at the given index. It can be both a statement and an expression. When
494         it is an expression, it returns the assigned value. This patch
495         implements Store as an expression.
496
497         Since Store uses two operands, which are the index and the value, we
498         need to pop the two operands from the stack and push the value back to
499         the stack. We can simply implement this by copying the value to where
500         the index is in the stack.
501
502         * tests/stress/wasm-linear-memory.js:
503         * wasm/WASMFunctionCompiler.h:
504         (JSC::WASMFunctionCompiler::buildStore):
505         * wasm/WASMFunctionParser.cpp:
506         (JSC::WASMFunctionParser::parseStatement):
507         (JSC::WASMFunctionParser::parseExpressionI32):
508         (JSC::WASMFunctionParser::parseExpressionF32):
509         (JSC::WASMFunctionParser::parseExpressionF64):
510         (JSC::WASMFunctionParser::parseStore):
511         * wasm/WASMFunctionParser.h:
512         * wasm/WASMFunctionSyntaxChecker.h:
513         (JSC::WASMFunctionSyntaxChecker::buildStore):
514
515 2015-09-20  Sukolsak Sakshuwong  <sukolsak@gmail.com>
516
517         Implement SetLocal and SetGlobal expressions in WebAssembly
518         https://bugs.webkit.org/show_bug.cgi?id=149383
519
520         Reviewed by Saam Barati.
521
522         SetLocal and SetGlobal in WebAssembly can be both statements and
523         expressions. We have implemented the statement version. This patch
524         implements the expression version.
525
526         SetLocal and SetGlobal expressions return the assigned value.
527         Since SetLocal and SetGlobal use only one operand, which is the assigned
528         value, we can simply implement them by not removing the value from the
529         top of the stack.
530
531         * tests/stress/wasm-globals.js:
532         * tests/stress/wasm-locals.js:
533         * tests/stress/wasm/globals.wasm:
534         * tests/stress/wasm/locals.wasm:
535         * wasm/WASMConstants.h:
536         * wasm/WASMFunctionCompiler.h:
537         (JSC::WASMFunctionCompiler::buildSetLocal):
538         (JSC::WASMFunctionCompiler::buildSetGlobal):
539         * wasm/WASMFunctionParser.cpp:
540         (JSC::WASMFunctionParser::parseStatement):
541         (JSC::WASMFunctionParser::parseExpressionI32):
542         (JSC::WASMFunctionParser::parseExpressionF32):
543         (JSC::WASMFunctionParser::parseExpressionF64):
544         (JSC::WASMFunctionParser::parseSetLocal):
545         (JSC::WASMFunctionParser::parseSetGlobal):
546         (JSC::WASMFunctionParser::parseSetLocalStatement): Deleted.
547         (JSC::WASMFunctionParser::parseSetGlobalStatement): Deleted.
548         * wasm/WASMFunctionParser.h:
549         * wasm/WASMFunctionSyntaxChecker.h:
550         (JSC::WASMFunctionSyntaxChecker::buildSetLocal):
551         (JSC::WASMFunctionSyntaxChecker::buildSetGlobal):
552
553 2015-09-19 Aleksandr Skachkov    <gskachkov@gmail.com>
554
555         [ES6] Added controlFlowProfiler test for arrow function
556         https://bugs.webkit.org/show_bug.cgi?id=145638
557
558         Reviewed by Saam Barati.
559
560         * Source/JavaScriptCore/tests/controlFlowProfiler/arrowfunction-expression.js: added
561
562 2015-09-20  Youenn Fablet  <youenn.fablet@crf.canon.fr>
563
564         Remove XHR_TIMEOUT compilation guard
565         https://bugs.webkit.org/show_bug.cgi?id=149260
566
567         Reviewed by Benjamin Poulain.
568
569         * Configurations/FeatureDefines.xcconfig:
570
571 2015-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>
572
573         [GTK] Unreviewed, should check the result of fread
574         https://bugs.webkit.org/show_bug.cgi?id=148917
575
576         Suppress the build warning on GTK with GCC.
577
578         * jsc.cpp:
579         (fillBufferWithContentsOfFile):
580         (fetchModuleFromLocalFileSystem):
581
582 2015-09-19  Saam barati  <sbarati@apple.com>
583
584         VariableEnvironmentNode should inherit from ParserArenaDeletable because VariableEnvironment's must have their destructors run
585         https://bugs.webkit.org/show_bug.cgi?id=149359
586
587         Reviewed by Andreas Kling.
588
589         VariableEnvironment must have its destructor run.
590         Therefore, VariableEnvironmentNode should inherit from ParserArenaDeletable.
591         Also, anything that inherits from VariableEnvironmentNode must use
592         ParserArenaDeletable's operator new. Also, any other nodes that own
593         a VariableEnvironment must also have their destructors run.
594
595         * parser/Nodes.h:
596         (JSC::VariableEnvironmentNode::VariableEnvironmentNode):
597
598 2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>
599
600         Remove duplicate code in the WebAssembly parser
601         https://bugs.webkit.org/show_bug.cgi?id=149361
602
603         Reviewed by Saam Barati.
604
605         Refactor the methods for parsing GetLocal and GetGlobal in WebAssembly
606         to remove duplicate code.
607
608         * wasm/WASMFunctionParser.cpp:
609         (JSC::nameOfType):
610         (JSC::WASMFunctionParser::parseExpressionI32):
611         (JSC::WASMFunctionParser::parseExpressionF32):
612         (JSC::WASMFunctionParser::parseExpressionF64):
613         (JSC::WASMFunctionParser::parseUnaryExpressionF64):
614         (JSC::WASMFunctionParser::parseBinaryExpressionF64):
615         (JSC::WASMFunctionParser::parseGetLocalExpression):
616         (JSC::WASMFunctionParser::parseGetGlobalExpression):
617         (JSC::WASMFunctionParser::parseGetLocalExpressionI32): Deleted.
618         (JSC::WASMFunctionParser::parseGetGlobalExpressionI32): Deleted.
619         (JSC::WASMFunctionParser::parseGetLocalExpressionF32): Deleted.
620         (JSC::WASMFunctionParser::parseGetGlobalExpressionF32): Deleted.
621         (JSC::WASMFunctionParser::parseGetLocalExpressionF64): Deleted.
622         (JSC::WASMFunctionParser::parseGetGlobalExpressionF64): Deleted.
623         * wasm/WASMFunctionParser.h:
624
625 2015-09-18  Saam barati  <sbarati@apple.com>
626
627         Refactor common code between GetCatchHandlerFunctor and UnwindFunctor
628         https://bugs.webkit.org/show_bug.cgi?id=149276
629
630         Reviewed by Mark Lam.
631
632         There is currently code copy-pasted between these
633         two functors. Lets not do that. It's better to write
634         a function, even if the function is small.
635
636         I also did a bit of renaming to make the intent of the
637         unwindCallFrame function clear. The name of the function
638         didn't really indicate what it did. It decided if it was
639         okay to unwind further, and it also notified the debugger.
640         I've renamed the function to notifyDebuggerOfUnwinding.
641         And I've inlined the logic of deciding if it's okay
642         to unwind further into UnwindFunctor itself.
643
644         * interpreter/Interpreter.cpp:
645         (JSC::Interpreter::isOpcode):
646         (JSC::getStackFrameCodeType):
647         (JSC::Interpreter::stackTraceAsString):
648         (JSC::findExceptionHandler):
649         (JSC::GetCatchHandlerFunctor::GetCatchHandlerFunctor):
650         (JSC::GetCatchHandlerFunctor::operator()):
651         (JSC::notifyDebuggerOfUnwinding):
652         (JSC::UnwindFunctor::UnwindFunctor):
653         (JSC::UnwindFunctor::operator()):
654         (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
655         (JSC::unwindCallFrame): Deleted.
656
657 2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>
658
659         Implement the arithmetic instructions for doubles in WebAssembly
660         https://bugs.webkit.org/show_bug.cgi?id=148945
661
662         Reviewed by Geoffrey Garen.
663
664         This patch implements the arithmetic instructions for doubles (float64)
665         in WebAssembly.
666
667         * tests/stress/wasm-arithmetic-float64.js:
668         * tests/stress/wasm/arithmetic-float64.wasm:
669         * wasm/WASMFunctionCompiler.h:
670         (JSC::WASMFunctionCompiler::buildUnaryF64):
671         (JSC::WASMFunctionCompiler::buildBinaryF64):
672         (JSC::WASMFunctionCompiler::callOperation):
673         * wasm/WASMFunctionParser.cpp:
674         (JSC::WASMFunctionParser::parseExpressionF64):
675         (JSC::WASMFunctionParser::parseUnaryExpressionF64):
676         (JSC::WASMFunctionParser::parseBinaryExpressionF64):
677         * wasm/WASMFunctionParser.h:
678         * wasm/WASMFunctionSyntaxChecker.h:
679         (JSC::WASMFunctionSyntaxChecker::buildUnaryF64):
680         (JSC::WASMFunctionSyntaxChecker::buildBinaryF32):
681         (JSC::WASMFunctionSyntaxChecker::buildBinaryF64):
682
683 2015-09-18  Basile Clement  <basile_clement@apple.com>
684
685         [ES6] Tail call fast path should efficiently reuse the frame's stack space
686         https://bugs.webkit.org/show_bug.cgi?id=148662
687
688         Reviewed by Geoffrey Garen.
689
690         This introduces a new class (CallFrameShuffler) that is responsible for
691         efficiently building the new frames when performing a tail call. In
692         order for Repatch to know about the position of arguments on the
693         stack/registers (e.g. for polymorphic call inline caches), we store a
694         CallFrameShuffleData in the CallLinkInfo. Otherwise, the JIT and DFG
695         compiler are now using CallFrameShuffler instead of
696         CCallHelpers::prepareForTailCallSlow() to build the frame for a tail
697         call.
698
699         When taking a slow path, we still build the frame as if doing a regular
700         call, because we could throw an exception and need the caller's frame
701         at that point. This means that for virtual calls, we don't benefit from
702         the efficient frame move for now.
703
704         * CMakeLists.txt:
705         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
706         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
707         * JavaScriptCore.xcodeproj/project.pbxproj:
708         * assembler/ARMv7Assembler.h:
709         (JSC::ARMv7Assembler::firstRegister):
710         (JSC::ARMv7Assembler::lastRegister):
711         (JSC::ARMv7Assembler::firstFPRegister):
712         (JSC::ARMv7Assembler::lastFPRegister):
713         * assembler/AbortReason.h:
714         * bytecode/CallLinkInfo.h:
715         (JSC::CallLinkInfo::setFrameShuffleData):
716         (JSC::CallLinkInfo::frameShuffleData):
717         * bytecode/ValueRecovery.h:
718         (JSC::ValueRecovery::inRegister):
719         * dfg/DFGGenerationInfo.h:
720         (JSC::DFG::GenerationInfo::recovery):
721         * jit/CachedRecovery.cpp: Added.
722         (JSC::CachedRecovery::loadsIntoFPR):
723         (JSC::CachedRecovery::loadsIntoGPR):
724         * jit/CachedRecovery.h: Added.
725         (JSC::CachedRecovery::CachedRecovery):
726         (JSC::CachedRecovery::targets):
727         (JSC::CachedRecovery::addTarget):
728         (JSC::CachedRecovery::removeTarget):
729         (JSC::CachedRecovery::clearTargets):
730         (JSC::CachedRecovery::setWantedJSValueRegs):
731         (JSC::CachedRecovery::setWantedFPR):
732         (JSC::CachedRecovery::boxingRequiresGPR):
733         (JSC::CachedRecovery::boxingRequiresFPR):
734         (JSC::CachedRecovery::recovery):
735         (JSC::CachedRecovery::setRecovery):
736         (JSC::CachedRecovery::wantedJSValueRegs):
737         (JSC::CachedRecovery::wantedFPR):
738         * jit/CallFrameShuffleData.cpp: Added.
739         (JSC::CallFrameShuffleData::setupCalleeSaveRegisters):
740         * jit/CallFrameShuffleData.h: Added.
741         * jit/CallFrameShuffler.cpp: Added.
742         (JSC::CallFrameShuffler::CallFrameShuffler):
743         (JSC::CallFrameShuffler::dump):
744         (JSC::CallFrameShuffler::getCachedRecovery):
745         (JSC::CallFrameShuffler::setCachedRecovery):
746         (JSC::CallFrameShuffler::spill):
747         (JSC::CallFrameShuffler::emitDeltaCheck):
748         (JSC::CallFrameShuffler::prepareForSlowPath):
749         (JSC::CallFrameShuffler::prepareForTailCall):
750         (JSC::CallFrameShuffler::tryWrites):
751         (JSC::CallFrameShuffler::performSafeWrites):
752         (JSC::CallFrameShuffler::prepareAny):
753         * jit/CallFrameShuffler.h: Added.
754         (JSC::CallFrameShuffler::lockGPR):
755         (JSC::CallFrameShuffler::acquireGPR):
756         (JSC::CallFrameShuffler::releaseGPR):
757         (JSC::CallFrameShuffler::snapshot):
758         (JSC::CallFrameShuffler::setCalleeJSValueRegs):
759         (JSC::CallFrameShuffler::assumeCalleeIsCell):
760         (JSC::CallFrameShuffler::canBox):
761         (JSC::CallFrameShuffler::ensureBox):
762         (JSC::CallFrameShuffler::ensureLoad):
763         (JSC::CallFrameShuffler::canLoadAndBox):
764         (JSC::CallFrameShuffler::updateRecovery):
765         (JSC::CallFrameShuffler::clearCachedRecovery):
766         (JSC::CallFrameShuffler::addCachedRecovery):
767         (JSC::CallFrameShuffler::numLocals):
768         (JSC::CallFrameShuffler::getOld):
769         (JSC::CallFrameShuffler::setOld):
770         (JSC::CallFrameShuffler::firstOld):
771         (JSC::CallFrameShuffler::lastOld):
772         (JSC::CallFrameShuffler::isValidOld):
773         (JSC::CallFrameShuffler::argCount):
774         (JSC::CallFrameShuffler::getNew):
775         (JSC::CallFrameShuffler::setNew):
776         (JSC::CallFrameShuffler::addNew):
777         (JSC::CallFrameShuffler::firstNew):
778         (JSC::CallFrameShuffler::lastNew):
779         (JSC::CallFrameShuffler::isValidNew):
780         (JSC::CallFrameShuffler::newAsOld):
781         (JSC::CallFrameShuffler::getFreeRegister):
782         (JSC::CallFrameShuffler::getFreeGPR):
783         (JSC::CallFrameShuffler::getFreeFPR):
784         (JSC::CallFrameShuffler::hasFreeRegister):
785         (JSC::CallFrameShuffler::ensureRegister):
786         (JSC::CallFrameShuffler::ensureGPR):
787         (JSC::CallFrameShuffler::ensureFPR):
788         (JSC::CallFrameShuffler::addressForOld):
789         (JSC::CallFrameShuffler::isUndecided):
790         (JSC::CallFrameShuffler::isSlowPath):
791         (JSC::CallFrameShuffler::addressForNew):
792         (JSC::CallFrameShuffler::dangerFrontier):
793         (JSC::CallFrameShuffler::isDangerNew):
794         (JSC::CallFrameShuffler::updateDangerFrontier):
795         (JSC::CallFrameShuffler::hasOnlySafeWrites):
796         * jit/CallFrameShuffler32_64.cpp: Added.
797         (JSC::CallFrameShuffler::emitStore):
798         (JSC::CallFrameShuffler::emitBox):
799         (JSC::CallFrameShuffler::emitLoad):
800         (JSC::CallFrameShuffler::canLoad):
801         (JSC::CallFrameShuffler::emitDisplace):
802         * jit/CallFrameShuffler64.cpp: Added.
803         (JSC::CallFrameShuffler::emitStore):
804         (JSC::CallFrameShuffler::emitBox):
805         (JSC::CallFrameShuffler::emitLoad):
806         (JSC::CallFrameShuffler::canLoad):
807         (JSC::CallFrameShuffler::emitDisplace):
808         * jit/JITCall.cpp:
809         (JSC::JIT::compileOpCall):
810         (JSC::JIT::compileOpCallSlowCase):
811         * jit/RegisterMap.cpp:
812         (JSC::RegisterMap::RegisterMap):
813         (JSC::GPRMap::GPRMap):
814         (JSC::FPRMap::FPRMap):
815         * jit/Repatch.cpp:
816         (JSC::linkPolymorphicCall):
817
818 2015-09-18  Saam barati  <sbarati@apple.com>
819
820         Implement try/catch in the DFG.
821         https://bugs.webkit.org/show_bug.cgi?id=147374
822
823         Reviewed by Filip Pizlo.
824
825         This patch implements try/catch inside the DFG JIT.
826         It also prevents tier up to the FTL for any functions
827         that have an op_catch in them that are DFG compiled.
828
829         This patch accomplishes implementing try/catch inside
830         the DFG by OSR exiting to op_catch when an exception is thrown.
831         We can OSR exit from an exception inside the DFG in two ways:
832         1) We have a JS call (can also be via implicit getter/setter in GetById/PutById)
833         2) We have an exception when returing from a callOperation
834
835         In the case of (1), we get to the OSR exit from genericUnwind because
836         the exception was thrown in a child call frame. This means these
837         OSR exits must act as defacto op_catches (even though we will still OSR
838         exit to a baseline op_catch). That means they must restore the stack pointer
839         and call frame.
840
841         In the case of (2), we can skip genericUnwind because we know the exception 
842         check will take us to a particular OSR exit. Instead, we link these
843         exception checks as jumps to a particular OSR exit.
844
845         Both types of OSR exits will exit into op_catch inside the baseline JIT.
846         Because they exit to op_catch, these OSR exits must set callFrameForCatch
847         to the proper call frame pointer.
848
849         We "handle" all exceptions inside the machine frame of the DFG code
850         block. This means the machine code block is responsible for "catching"
851         exceptions of any inlined frames' try/catch. OSR exit will then exit to 
852         the proper baseline CodeBlock after reifying the inlined frames
853         (DFG::OSRExit::m_codeOrigin corresponds to the op_catch we will exit to). 
854         Also, genericUnwind will never consult an inlined call frame's CodeBlock to 
855         see if they can catch the exception because they can't. We always unwind to the 
856         next machine code block frame. The DFG CodeBlock changes how the exception 
857         handler table is keyed: it is now keyed by CallSiteIndex for DFG code blocks. 
858
859         So, when consulting call sites that throw, we keep track of the CallSiteIndex,
860         and the HandlerInfo for the corresponding baseline exception handler for
861         that particular CallSiteIndex (if an exception at that call site will be caught). 
862         Then, when we're inside DFG::JITCompiler::link(), we install new HandlerInfo's
863         inside the DFG CodeBlock and key it by the corresponding CallSiteIndex.
864         (The CodeBlock only has HandlerInfos for the OSR exits that are to be arrived
865         at from genericUnwind).
866
867         Also, each OSR exit will know if it acting as an exception handler, and
868         whether or not it will be arrived at from genericUnwind. When we know we 
869         will arrive at an OSR exit from genericUnwind, we set the corresponding 
870         HandlerInfo's nativeCode CodeLocationLabel field to be the OSR exit.
871
872         This patch also introduces a new Phase inside the DFG that ensures
873         that DFG CodeBlocks that handle exceptions take the necessary
874         steps to keep live variables at "op_catch" live according the
875         OSR exit value recovery machinery. We accomplish this by flushing
876         all live op_catch variables to the stack when inside a "try" block.
877
878         * CMakeLists.txt:
879         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
880         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
881         * JavaScriptCore.xcodeproj/project.pbxproj:
882         * bytecode/CodeBlock.cpp:
883         (JSC::CodeBlock::handlerForBytecodeOffset):
884         (JSC::CodeBlock::handlerForIndex):
885         * bytecode/CodeBlock.h:
886         (JSC::CodeBlock::clearExceptionHandlers):
887         (JSC::CodeBlock::appendExceptionHandler):
888         * bytecode/PreciseJumpTargets.cpp:
889         (JSC::computePreciseJumpTargets):
890         * dfg/DFGByteCodeParser.cpp:
891         (JSC::DFG::ByteCodeParser::getLocal):
892         (JSC::DFG::ByteCodeParser::setLocal):
893         (JSC::DFG::ByteCodeParser::parseBlock):
894         * dfg/DFGCapabilities.cpp:
895         (JSC::DFG::capabilityLevel):
896         * dfg/DFGCommonData.cpp:
897         (JSC::DFG::CommonData::addCodeOrigin):
898         (JSC::DFG::CommonData::lastCallSite):
899         (JSC::DFG::CommonData::shrinkToFit):
900         * dfg/DFGCommonData.h:
901         * dfg/DFGGraph.h:
902         * dfg/DFGJITCompiler.cpp:
903         (JSC::DFG::JITCompiler::linkOSRExits):
904         (JSC::DFG::JITCompiler::link):
905         (JSC::DFG::JITCompiler::compile):
906         (JSC::DFG::JITCompiler::noticeOSREntry):
907         (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
908         (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
909         (JSC::DFG::JITCompiler::exceptionCheck):
910         (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
911         * dfg/DFGJITCompiler.h:
912         (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
913         (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
914         (JSC::DFG::JITCompiler::appendCall):
915         (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
916         (JSC::DFG::JITCompiler::blockHeads):
917         (JSC::DFG::JITCompiler::exceptionCheck): Deleted.
918         * dfg/DFGLiveCatchVariablePreservationPhase.cpp: Added.
919         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase):
920         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::run):
921         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
922         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock):
923         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::newVariableAccessData):
924         (JSC::DFG::performLiveCatchVariablePreservationPhase):
925         * dfg/DFGLiveCatchVariablePreservationPhase.h: Added.
926         * dfg/DFGOSRExit.cpp:
927         (JSC::DFG::OSRExit::OSRExit):
928         (JSC::DFG::OSRExit::setPatchableCodeOffset):
929         * dfg/DFGOSRExit.h:
930         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
931         * dfg/DFGOSRExitCompiler.cpp:
932         * dfg/DFGOSRExitCompiler32_64.cpp:
933         (JSC::DFG::OSRExitCompiler::compileExit):
934         * dfg/DFGOSRExitCompiler64.cpp:
935         (JSC::DFG::OSRExitCompiler::compileExit):
936         * dfg/DFGOSRExitCompilerCommon.cpp:
937         (JSC::DFG::osrWriteBarrier):
938         (JSC::DFG::adjustAndJumpToTarget):
939         * dfg/DFGOSRExitCompilerCommon.h:
940         * dfg/DFGPlan.cpp:
941         (JSC::DFG::Plan::compileInThreadImpl):
942         * dfg/DFGSlowPathGenerator.h:
943         (JSC::DFG::SlowPathGenerator::SlowPathGenerator):
944         (JSC::DFG::SlowPathGenerator::~SlowPathGenerator):
945         (JSC::DFG::SlowPathGenerator::generate):
946         * dfg/DFGSpeculativeJIT.h:
947         * dfg/DFGSpeculativeJIT32_64.cpp:
948         (JSC::DFG::SpeculativeJIT::cachedGetById):
949         (JSC::DFG::SpeculativeJIT::cachedPutById):
950         (JSC::DFG::SpeculativeJIT::emitCall):
951         * dfg/DFGSpeculativeJIT64.cpp:
952         (JSC::DFG::SpeculativeJIT::cachedGetById):
953         (JSC::DFG::SpeculativeJIT::cachedPutById):
954         (JSC::DFG::SpeculativeJIT::emitCall):
955         * dfg/DFGTierUpCheckInjectionPhase.cpp:
956         (JSC::DFG::TierUpCheckInjectionPhase::run):
957         * ftl/FTLOSRExitCompiler.cpp:
958         (JSC::FTL::compileStub):
959         * interpreter/Interpreter.cpp:
960         (JSC::GetCatchHandlerFunctor::operator()):
961         (JSC::UnwindFunctor::operator()):
962         * interpreter/StackVisitor.cpp:
963         (JSC::StackVisitor::gotoNextFrame):
964         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
965         (JSC::StackVisitor::readFrame):
966         * interpreter/StackVisitor.h:
967         (JSC::StackVisitor::operator*):
968         (JSC::StackVisitor::operator->):
969         * jit/AssemblyHelpers.cpp:
970         (JSC::AssemblyHelpers::emitExceptionCheck):
971         (JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
972         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
973         * jit/AssemblyHelpers.h:
974         (JSC::AssemblyHelpers::emitCount):
975         * jit/JITExceptions.cpp:
976         (JSC::genericUnwind):
977         * jit/JITOpcodes.cpp:
978         (JSC::JIT::emit_op_catch):
979         * jit/JITOpcodes32_64.cpp:
980         (JSC::JIT::emit_op_catch):
981         * llint/LowLevelInterpreter32_64.asm:
982         * llint/LowLevelInterpreter64.asm:
983         * runtime/VM.cpp:
984         (JSC::VM::VM):
985         * runtime/VM.h:
986         (JSC::VM::clearException):
987         (JSC::VM::clearLastException):
988         (JSC::VM::addressOfCallFrameForCatch):
989         (JSC::VM::exception):
990         (JSC::VM::addressOfException):
991         * tests/stress/dfg-exception-try-catch-in-constructor-with-inlined-throw.js: Added.
992         (f):
993         (bar):
994         (Foo):
995         * tests/stress/es6-for-of-loop-exception.js: Added.
996         (assert):
997         (shouldThrowInvalidConstAssignment):
998         (baz):
999         (foo):
1000         * tests/stress/exception-dfg-inlined-frame-not-strict-equal.js: Added.
1001         (assert):
1002         (o.valueOf):
1003         (o.toString):
1004         (read):
1005         (bar):
1006         (foo):
1007         * tests/stress/exception-dfg-not-strict-equal.js: Added.
1008         (foo):
1009         (o.valueOf):
1010         (o.toString):
1011         (assert):
1012         (shouldDoSomethingInFinally):
1013         (catch):
1014         * tests/stress/exception-dfg-operation-read-value.js: Added.
1015         (assert):
1016         (o.valueOf):
1017         (o.toString):
1018         (read):
1019         (foo):
1020         * tests/stress/exception-dfg-throw-from-catch-block.js: Added.
1021         (assert):
1022         (baz):
1023         (bar):
1024         (foo):
1025
1026 2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1027
1028         Implement linear memory instructions in WebAssembly
1029         https://bugs.webkit.org/show_bug.cgi?id=149326
1030
1031         Reviewed by Geoffrey Garen.
1032
1033         This patch implements linear memory instructions in WebAssembly.[1] To
1034         use the linear memory, an ArrayBuffer must be passed to loadWebAssembly().
1035
1036         Notes:
1037         - We limit the ArrayBuffer's byte length to 2^31 - 1. This enables us to
1038           use only one comparison (unsigned greater than) to check for
1039           out-of-bounds access.
1040         - There is no consensus yet on what should happen when an out-of-bounds
1041           access occurs.[2] For now, we throw an error when that happens.
1042         - In asm.js, a heap access looks like this: int32Array[i >> 2]. Note
1043           that ">> 2" is part of the syntax and is required. pack-asmjs will
1044           produce bytecodes that look something like "LoadI32, i" (not
1045           "LoadI32, ShiftRightI32, i, 2"). The requirement of the shift operator
1046           prevents unaligned accesses in asm.js. (There is a proposal to support
1047           unaligned accesses in the future version of asm.js using DataView.[3])
1048           The WebAssembly spec allows unaligned accesses.[4] But since we use
1049           asm.js for testing, we follow asm.js's behaviors for now.
1050
1051         [1]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#linear-memory
1052         [2]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#out-of-bounds
1053         [3]: https://wiki.mozilla.org/Javascript:SpiderMonkey:OdinMonkey#Possible_asm.js_extensions_that_don.27t_require_new_JS_features
1054         [4]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md#alignment
1055
1056         * jit/JITOperations.cpp:
1057         * jit/JITOperations.h:
1058         * jsc.cpp:
1059         (GlobalObject::finishCreation):
1060         (functionLoadWebAssembly):
1061         * tests/stress/wasm-linear-memory.js: Added.
1062         (shouldBe):
1063         (shouldThrow):
1064         * tests/stress/wasm/linear-memory.wasm: Added.
1065         * wasm/JSWASMModule.cpp:
1066         (JSC::JSWASMModule::JSWASMModule):
1067         (JSC::JSWASMModule::visitChildren):
1068         * wasm/JSWASMModule.h:
1069         (JSC::JSWASMModule::create):
1070         (JSC::JSWASMModule::arrayBuffer):
1071         (JSC::JSWASMModule::JSWASMModule): Deleted.
1072         * wasm/WASMConstants.h:
1073         * wasm/WASMFunctionCompiler.h:
1074         (JSC::sizeOfMemoryType):
1075         (JSC::WASMFunctionCompiler::MemoryAddress::MemoryAddress):
1076         (JSC::WASMFunctionCompiler::endFunction):
1077         (JSC::WASMFunctionCompiler::buildLoad):
1078         (JSC::WASMFunctionCompiler::buildStore):
1079         * wasm/WASMFunctionParser.cpp:
1080         (JSC::WASMFunctionParser::parseStatement):
1081         (JSC::WASMFunctionParser::parseExpressionI32):
1082         (JSC::WASMFunctionParser::parseExpressionF32):
1083         (JSC::WASMFunctionParser::parseExpressionF64):
1084         (JSC::WASMFunctionParser::parseMemoryAddress):
1085         (JSC::WASMFunctionParser::parseLoad):
1086         (JSC::WASMFunctionParser::parseStore):
1087         * wasm/WASMFunctionParser.h:
1088         * wasm/WASMFunctionSyntaxChecker.h:
1089         (JSC::WASMFunctionSyntaxChecker::MemoryAddress::MemoryAddress):
1090         (JSC::WASMFunctionSyntaxChecker::buildLoad):
1091         (JSC::WASMFunctionSyntaxChecker::buildStore):
1092         * wasm/WASMModuleParser.cpp:
1093         (JSC::WASMModuleParser::WASMModuleParser):
1094         (JSC::WASMModuleParser::parseModule):
1095         (JSC::parseWebAssembly):
1096         (JSC::WASMModuleParser::parse): Deleted.
1097         * wasm/WASMModuleParser.h:
1098
1099 2015-09-18  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1100
1101         Implement type conversion instructions in WebAssembly
1102         https://bugs.webkit.org/show_bug.cgi?id=149340
1103
1104         Reviewed by Mark Lam.
1105
1106         This patch implements some type conversion instructions in WebAssembly.
1107         The WebAssembly spec has a lot more type conversion instructions than
1108         what are available in asm.js.[1] We only implement the ones that are in
1109         asm.js for now because we can only test those.
1110
1111         [1]: https://github.com/WebAssembly/design/blob/master/AstSemantics.md
1112
1113         * tests/stress/wasm-type-conversion.js:
1114         * tests/stress/wasm/type-conversion.wasm:
1115         * wasm/WASMConstants.h:
1116         * wasm/WASMFunctionCompiler.h:
1117         (JSC::operationConvertUnsignedInt32ToDouble):
1118         (JSC::WASMFunctionCompiler::buildConvertType):
1119         (JSC::WASMFunctionCompiler::callOperation):
1120         * wasm/WASMFunctionParser.cpp:
1121         (JSC::WASMFunctionParser::parseExpressionI32):
1122         (JSC::WASMFunctionParser::parseExpressionF32):
1123         (JSC::WASMFunctionParser::parseExpressionF64):
1124         (JSC::WASMFunctionParser::parseConvertType):
1125         * wasm/WASMFunctionParser.h:
1126         * wasm/WASMFunctionSyntaxChecker.h:
1127         (JSC::WASMFunctionSyntaxChecker::buildConvertType):
1128
1129 2015-09-18  Alex Christensen  <achristensen@webkit.org>
1130
1131         Fix tests on Windows after switching to CMake.
1132         https://bugs.webkit.org/show_bug.cgi?id=149339
1133
1134         Reviewed by Brent Fulgham.
1135
1136         * shell/PlatformWin.cmake:
1137         Build testapi and testRegExp (which doesn't seem to be used any more).
1138
1139 2015-09-17  Brian Burg  <bburg@apple.com>
1140
1141         ASSERT(!m_frontendRouter->hasLocalFrontend()) when running Web Inspector tests
1142         https://bugs.webkit.org/show_bug.cgi?id=149006
1143
1144         Reviewed by Joseph Pecoraro.
1145
1146         Prior to disconnecting, we need to know how many frontends remain connected.
1147
1148         * inspector/InspectorFrontendRouter.h: Add frontendCount().
1149
1150 2015-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1151
1152         Explicitly specify builtin JS files dependency
1153         https://bugs.webkit.org/show_bug.cgi?id=149323
1154
1155         Reviewed by Alex Christensen.
1156
1157         JSCBuiltins.{h,cpp} in CMakeLists.txt and DerivedSources.make just depend on the builtins directory.
1158         As a result, even if we modify builtins/*.js code, regenerating JSCBuiltins.{h,cpp} does not occur.
1159         As the same to the cpp sources, let's list up the JS files explicitly.
1160
1161         * CMakeLists.txt:
1162         * DerivedSources.make:
1163
1164 2015-09-18  Michael Saboff  <msaboff@apple.com>
1165
1166         Remove register preservation and restoration stub code
1167         https://bugs.webkit.org/show_bug.cgi?id=149335
1168
1169         Reviewed by Mark Lam.
1170
1171         Delete the register preservation and restoration thunks and related plumbing.
1172
1173         Much of this change is removing the unneeded RegisterPreservationMode parameter
1174         from various functions.
1175
1176         * CMakeLists.txt:
1177         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1178         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1179         * JavaScriptCore.xcodeproj/project.pbxproj:
1180         * bytecode/CallLinkInfo.h:
1181         (JSC::CallLinkInfo::isVarargsCallType):
1182         (JSC::CallLinkInfo::CallLinkInfo):
1183         (JSC::CallLinkInfo::isVarargs):
1184         (JSC::CallLinkInfo::isLinked):
1185         (JSC::CallLinkInfo::setUpCallFromFTL):
1186         (JSC::CallLinkInfo::registerPreservationMode): Deleted.
1187         * ftl/FTLJITCode.cpp:
1188         (JSC::FTL::JITCode::initializeAddressForCall):
1189         (JSC::FTL::JITCode::addressForCall):
1190         * ftl/FTLJITCode.h:
1191         * ftl/FTLOSREntry.cpp:
1192         (JSC::FTL::prepareOSREntry):
1193         * ftl/FTLOSRExitCompiler.cpp:
1194         (JSC::FTL::compileStub):
1195         * jit/JITCode.cpp:
1196         (JSC::JITCode::execute):
1197         (JSC::DirectJITCode::initializeCodeRef):
1198         (JSC::DirectJITCode::addressForCall):
1199         (JSC::NativeJITCode::initializeCodeRef):
1200         (JSC::NativeJITCode::addressForCall):
1201         (JSC::DirectJITCode::ensureWrappers): Deleted.
1202         * jit/JITCode.h:
1203         (JSC::JITCode::jitTypeFor):
1204         (JSC::JITCode::executableAddress):
1205         * jit/JITOperations.cpp:
1206         * jit/RegisterPreservationWrapperGenerator.cpp: Removed.
1207         * jit/RegisterPreservationWrapperGenerator.h: Removed.
1208         * jit/Repatch.cpp:
1209         (JSC::linkPolymorphicCall):
1210         * jit/ThunkGenerators.cpp:
1211         (JSC::virtualThunkFor):
1212         * jit/ThunkGenerators.h:
1213         * llint/LLIntSlowPaths.cpp:
1214         (JSC::LLInt::entryOSR):
1215         (JSC::LLInt::setUpCall):
1216         * runtime/Executable.cpp:
1217         (JSC::ExecutableBase::clearCode):
1218         (JSC::ScriptExecutable::installCode):
1219         (JSC::WebAssemblyExecutable::prepareForExecution):
1220         * runtime/Executable.h:
1221         (JSC::ExecutableBase::generatedJITCodeFor):
1222         (JSC::ExecutableBase::entrypointFor):
1223         (JSC::ExecutableBase::offsetOfJITCodeWithArityCheckFor):
1224         * runtime/RegisterPreservationMode.h: Removed.
1225
1226 2015-09-17  Joseph Pecoraro  <pecoraro@apple.com>
1227
1228         Web Inspector: Remove unused canClearBrowserCookies / canClearBrowserCache protocol methods
1229         https://bugs.webkit.org/show_bug.cgi?id=149307
1230
1231         Reviewed by Brian Burg.
1232
1233         * inspector/protocol/Network.json:
1234         Remove unused protocol methods.
1235
1236 2015-09-17  Commit Queue  <commit-queue@webkit.org>
1237
1238         Unreviewed, rolling out r189938, r189952, and r189956.
1239         https://bugs.webkit.org/show_bug.cgi?id=149329
1240
1241         Broke Web Workers (Requested by ap on #webkit).
1242
1243         Reverted changesets:
1244
1245         "Implement try/catch in the DFG."
1246         https://bugs.webkit.org/show_bug.cgi?id=147374
1247         http://trac.webkit.org/changeset/189938
1248
1249         "CLoop build fix after r189938."
1250         http://trac.webkit.org/changeset/189952
1251
1252         "add a regress test for richards with try/catch."
1253         https://bugs.webkit.org/show_bug.cgi?id=149301
1254         http://trac.webkit.org/changeset/189956
1255
1256 2015-09-17  Ryosuke Niwa  <rniwa@webkit.org>
1257
1258         CLoop build fix after r189938.
1259
1260         * interpreter/StackVisitor.cpp:
1261         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
1262
1263 2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1264
1265         Convert return values from JavaScript functions to the expected types in WebAssembly
1266         https://bugs.webkit.org/show_bug.cgi?id=149200
1267
1268         Reviewed by Mark Lam.
1269
1270         When a WebAssembly function calls a JavaScript function, there is no
1271         guarantee that the JavaScript function will always return values of the
1272         type we expect. This patch converts the return values to the expected
1273         types.
1274
1275         (The reverse is also true: When a WebAssembly function is called from a
1276         JavaScript function, there is no guarantee that the arguments to the
1277         WebAssembly function will always be of the types we expect. We have
1278         fixed this in Bug 149033.)
1279
1280         We don't need to type check the return values if the callee is a
1281         WebAssembly function. We don't need to type check the arguments if the
1282         caller is a WebAssembly function. This optimization will be
1283         implemented in the future. See https://bugs.webkit.org/show_bug.cgi?id=149310
1284
1285         * tests/stress/wasm-type-conversion.js:
1286         * tests/stress/wasm/type-conversion.wasm:
1287         * wasm/WASMFunctionCompiler.h:
1288         (JSC::WASMFunctionCompiler::startFunction):
1289         (JSC::WASMFunctionCompiler::buildReturn):
1290         (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
1291         (JSC::WASMFunctionCompiler::callAndUnboxResult):
1292         (JSC::WASMFunctionCompiler::convertValueToInt32):
1293         (JSC::WASMFunctionCompiler::convertValueToDouble):
1294         (JSC::WASMFunctionCompiler::convertDoubleToValue):
1295         (JSC::WASMFunctionCompiler::loadValueAndConvertToInt32): Deleted.
1296         (JSC::WASMFunctionCompiler::loadValueAndConvertToDouble): Deleted.
1297         * wasm/WASMFunctionParser.cpp:
1298         (JSC::WASMFunctionParser::parseExpressionI32):
1299         (JSC::WASMFunctionParser::parseExpressionF32):
1300         (JSC::WASMFunctionParser::parseExpressionF64):
1301         (JSC::WASMFunctionParser::parseCallInternalExpressionI32): Deleted.
1302         * wasm/WASMFunctionParser.h:
1303
1304 2015-09-17  Yusuke Suzuki  <utatane.tea@gmail.com>
1305
1306         [ES6] Add more fine-grained APIs and additional hooks to control module loader from WebCore
1307         https://bugs.webkit.org/show_bug.cgi?id=149129
1308
1309         Reviewed by Saam Barati.
1310
1311         No behavior change.
1312
1313         Module tag `<script type="module>` will be executed asynchronously.
1314         But we would like to fetch the resources before when the postTask-ed task is performed.
1315         So instead of 1 API that fetch, instantiate and execute the module,
1316         we need 2 fine-grained APIs.
1317
1318         1. Fetch and initialize a module, but not execute it yet.
1319         2. Link and execute a module specified by the key (this will be invoked asynchronously).
1320
1321         And to instrument the script execution (like reporting the execution time of the module to
1322         the inspector), we need a hook to inject code around an execution of a module body.
1323
1324         * builtins/ModuleLoaderObject.js:
1325         (moduleEvaluation):
1326         (loadAndEvaluateModule):
1327         (loadModule):
1328         (linkAndEvaluateModule):
1329         * jsc.cpp:
1330         (functionLoadModule):
1331         (runWithScripts):
1332         * runtime/Completion.cpp:
1333         (JSC::identifierToJSValue):
1334         (JSC::createSymbolForEntryPointModule):
1335         (JSC::rejectPromise):
1336         (JSC::loadAndEvaluateModule):
1337         (JSC::loadModule):
1338         (JSC::linkAndEvaluateModule):
1339         (JSC::evaluateModule): Deleted.
1340         * runtime/Completion.h:
1341         * runtime/JSGlobalObject.cpp:
1342         * runtime/JSGlobalObject.h:
1343         * runtime/JSModuleRecord.cpp:
1344         (JSC::JSModuleRecord::evaluate):
1345         (JSC::JSModuleRecord::execute): Deleted.
1346         * runtime/JSModuleRecord.h:
1347         * runtime/ModuleLoaderObject.cpp:
1348         (JSC::ModuleLoaderObject::loadAndEvaluateModule):
1349         (JSC::ModuleLoaderObject::linkAndEvaluateModule):
1350         (JSC::ModuleLoaderObject::evaluate):
1351         (JSC::moduleLoaderObjectEvaluate):
1352         * runtime/ModuleLoaderObject.h:
1353
1354 2015-09-17  Saam barati  <sbarati@apple.com>
1355
1356         Implement try/catch in the DFG.
1357         https://bugs.webkit.org/show_bug.cgi?id=147374
1358
1359         Reviewed by Filip Pizlo.
1360
1361         This patch implements try/catch inside the DFG JIT.
1362         It also prevents tier up to the FTL for any functions
1363         that have an op_catch in them that are DFG compiled.
1364
1365         This patch accomplishes implementing try/catch inside
1366         the DFG by OSR exiting to op_catch when an exception is thrown.
1367         We can OSR exit from an exception inside the DFG in two ways:
1368         1) We have a JS call (can also be via implicit getter/setter in GetById/PutById)
1369         2) We have an exception when returing from a callOperation
1370
1371         In the case of (1), we get to the OSR exit from genericUnwind because
1372         the exception was thrown in a child call frame. This means these
1373         OSR exits must act as defacto op_catches (even though we will still OSR
1374         exit to a baseline op_catch). That means they must restore the stack pointer
1375         and call frame.
1376
1377         In the case of (2), we can skip genericUnwind because we know the exception 
1378         check will take us to a particular OSR exit. Instead, we link these
1379         exception checks as jumps to a particular OSR exit.
1380
1381         Both types of OSR exits will exit into op_catch inside the baseline JIT.
1382         Because they exit to op_catch, these OSR exits must set callFrameForCatch
1383         to the proper call frame pointer.
1384
1385         We "handle" all exceptions inside the machine frame of the DFG code
1386         block. This means the machine code block is responsible for "catching"
1387         exceptions of any inlined frames' try/catch. OSR exit will then exit to 
1388         the proper baseline CodeBlock after reifying the inlined frames
1389         (DFG::OSRExit::m_codeOrigin corresponds to the op_catch we will exit to). 
1390         Also, genericUnwind will never consult an inlined call frame's CodeBlock to 
1391         see if they can catch the exception because they can't. We always unwind to the 
1392         next machine code block frame. The DFG CodeBlock changes how the exception 
1393         handler table is keyed: it is now keyed by CallSiteIndex for DFG code blocks. 
1394
1395         So, when consulting call sites that throw, we keep track of the CallSiteIndex,
1396         and the HandlerInfo for the corresponding baseline exception handler for
1397         that particular CallSiteIndex (if an exception at that call site will be caught). 
1398         Then, when we're inside DFG::JITCompiler::link(), we install new HandlerInfo's
1399         inside the DFG CodeBlock and key it by the corresponding CallSiteIndex.
1400         (The CodeBlock only has HandlerInfos for the OSR exits that are to be arrived
1401         at from genericUnwind).
1402
1403         Also, each OSR exit will know if it acting as an exception handler, and
1404         whether or not it will be arrived at from genericUnwind. When we know we 
1405         will arrive at an OSR exit from genericUnwind, we set the corresponding 
1406         HandlerInfo's nativeCode CodeLocationLabel field to be the OSR exit.
1407
1408         This patch also introduces a new Phase inside the DFG that ensures
1409         that DFG CodeBlocks that handle exceptions take the necessary
1410         steps to keep live variables at "op_catch" live according the
1411         OSR exit value recovery machinery. We accomplish this by flushing
1412         all live op_catch variables to the stack when inside a "try" block.
1413
1414         * CMakeLists.txt:
1415         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1416         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1417         * JavaScriptCore.xcodeproj/project.pbxproj:
1418         * bytecode/CodeBlock.cpp:
1419         (JSC::CodeBlock::handlerForBytecodeOffset):
1420         (JSC::CodeBlock::handlerForIndex):
1421         * bytecode/CodeBlock.h:
1422         (JSC::CodeBlock::clearExceptionHandlers):
1423         (JSC::CodeBlock::appendExceptionHandler):
1424         * bytecode/PreciseJumpTargets.cpp:
1425         (JSC::computePreciseJumpTargets):
1426         * dfg/DFGByteCodeParser.cpp:
1427         (JSC::DFG::ByteCodeParser::getLocal):
1428         (JSC::DFG::ByteCodeParser::setLocal):
1429         (JSC::DFG::ByteCodeParser::parseBlock):
1430         * dfg/DFGCapabilities.cpp:
1431         (JSC::DFG::capabilityLevel):
1432         * dfg/DFGCommonData.cpp:
1433         (JSC::DFG::CommonData::addCodeOrigin):
1434         (JSC::DFG::CommonData::lastCallSite):
1435         (JSC::DFG::CommonData::shrinkToFit):
1436         * dfg/DFGCommonData.h:
1437         * dfg/DFGGraph.h:
1438         * dfg/DFGJITCompiler.cpp:
1439         (JSC::DFG::JITCompiler::linkOSRExits):
1440         (JSC::DFG::JITCompiler::link):
1441         (JSC::DFG::JITCompiler::compile):
1442         (JSC::DFG::JITCompiler::noticeOSREntry):
1443         (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
1444         (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
1445         (JSC::DFG::JITCompiler::exceptionCheck):
1446         (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
1447         * dfg/DFGJITCompiler.h:
1448         (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
1449         (JSC::DFG::JITCompiler::emitStoreCallSiteIndex):
1450         (JSC::DFG::JITCompiler::appendCall):
1451         (JSC::DFG::JITCompiler::exceptionCheckWithCallFrameRollback):
1452         (JSC::DFG::JITCompiler::blockHeads):
1453         (JSC::DFG::JITCompiler::exceptionCheck): Deleted.
1454         * dfg/DFGLiveCatchVariablePreservationPhase.cpp: Added.
1455         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase):
1456         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::run):
1457         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
1458         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock):
1459         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::newVariableAccessData):
1460         (JSC::DFG::performLiveCatchVariablePreservationPhase):
1461         * dfg/DFGLiveCatchVariablePreservationPhase.h: Added.
1462         * dfg/DFGOSRExit.cpp:
1463         (JSC::DFG::OSRExit::OSRExit):
1464         (JSC::DFG::OSRExit::setPatchableCodeOffset):
1465         * dfg/DFGOSRExit.h:
1466         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
1467         * dfg/DFGOSRExitCompiler.cpp:
1468         * dfg/DFGOSRExitCompiler32_64.cpp:
1469         (JSC::DFG::OSRExitCompiler::compileExit):
1470         * dfg/DFGOSRExitCompiler64.cpp:
1471         (JSC::DFG::OSRExitCompiler::compileExit):
1472         * dfg/DFGOSRExitCompilerCommon.cpp:
1473         (JSC::DFG::osrWriteBarrier):
1474         (JSC::DFG::adjustAndJumpToTarget):
1475         * dfg/DFGOSRExitCompilerCommon.h:
1476         * dfg/DFGPlan.cpp:
1477         (JSC::DFG::Plan::compileInThreadImpl):
1478         * dfg/DFGSlowPathGenerator.h:
1479         (JSC::DFG::SlowPathGenerator::SlowPathGenerator):
1480         (JSC::DFG::SlowPathGenerator::~SlowPathGenerator):
1481         (JSC::DFG::SlowPathGenerator::generate):
1482         * dfg/DFGSpeculativeJIT.h:
1483         * dfg/DFGSpeculativeJIT32_64.cpp:
1484         (JSC::DFG::SpeculativeJIT::cachedGetById):
1485         (JSC::DFG::SpeculativeJIT::cachedPutById):
1486         (JSC::DFG::SpeculativeJIT::emitCall):
1487         * dfg/DFGSpeculativeJIT64.cpp:
1488         (JSC::DFG::SpeculativeJIT::cachedGetById):
1489         (JSC::DFG::SpeculativeJIT::cachedPutById):
1490         (JSC::DFG::SpeculativeJIT::emitCall):
1491         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1492         (JSC::DFG::TierUpCheckInjectionPhase::run):
1493         * ftl/FTLOSRExitCompiler.cpp:
1494         (JSC::FTL::compileStub):
1495         * interpreter/Interpreter.cpp:
1496         (JSC::GetCatchHandlerFunctor::operator()):
1497         (JSC::UnwindFunctor::operator()):
1498         * interpreter/StackVisitor.cpp:
1499         (JSC::StackVisitor::gotoNextFrame):
1500         (JSC::StackVisitor::unwindToMachineCodeBlockFrame):
1501         (JSC::StackVisitor::readFrame):
1502         * interpreter/StackVisitor.h:
1503         (JSC::StackVisitor::operator*):
1504         (JSC::StackVisitor::operator->):
1505         * jit/AssemblyHelpers.cpp:
1506         (JSC::AssemblyHelpers::emitExceptionCheck):
1507         (JSC::AssemblyHelpers::emitNonPatchableExceptionCheck):
1508         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
1509         * jit/AssemblyHelpers.h:
1510         (JSC::AssemblyHelpers::emitCount):
1511         * jit/JITExceptions.cpp:
1512         (JSC::genericUnwind):
1513         * jit/JITOpcodes.cpp:
1514         (JSC::JIT::emit_op_catch):
1515         * jit/JITOpcodes32_64.cpp:
1516         (JSC::JIT::emit_op_catch):
1517         * llint/LowLevelInterpreter32_64.asm:
1518         * llint/LowLevelInterpreter64.asm:
1519         * runtime/VM.h:
1520         (JSC::VM::clearException):
1521         (JSC::VM::clearLastException):
1522         (JSC::VM::addressOfCallFrameForCatch):
1523         (JSC::VM::exception):
1524         (JSC::VM::addressOfException):
1525         * tests/stress/dfg-exception-try-catch-in-constructor-with-inlined-throw.js: Added.
1526         (f):
1527         (bar):
1528         (Foo):
1529         * tests/stress/es6-for-of-loop-exception.js: Added.
1530         (assert):
1531         (shouldThrowInvalidConstAssignment):
1532         (baz):
1533         (foo):
1534         * tests/stress/exception-dfg-inlined-frame-not-strict-equal.js: Added.
1535         (assert):
1536         (o.valueOf):
1537         (o.toString):
1538         (read):
1539         (bar):
1540         (foo):
1541         * tests/stress/exception-dfg-not-strict-equal.js: Added.
1542         (foo):
1543         (o.valueOf):
1544         (o.toString):
1545         (assert):
1546         (shouldDoSomethingInFinally):
1547         (catch):
1548         * tests/stress/exception-dfg-operation-read-value.js: Added.
1549         (assert):
1550         (o.valueOf):
1551         (o.toString):
1552         (read):
1553         (foo):
1554         * tests/stress/exception-dfg-throw-from-catch-block.js: Added.
1555         (assert):
1556         (baz):
1557         (bar):
1558         (foo):
1559
1560 2015-09-17  Filip Pizlo  <fpizlo@apple.com>
1561
1562         0.0 should really be 0.0
1563         https://bugs.webkit.org/show_bug.cgi?id=149283
1564
1565         Reviewed by Mark Lam.
1566
1567         A while ago (http://trac.webkit.org/changeset/180813) we introduced the idea that if the
1568         user wrote a number with a decimal point (like "0.0") then we should treat that number as
1569         a double. That's probably a pretty good idea. But, we ended up doing it inconsistently.
1570         The DFG would indeed treat such a number as a double by consulting the
1571         SourceCodeRepresentation, but the other execution engines would still see Int32:0.
1572
1573         This patch makes it consistent.
1574
1575         This is necessary for property type inference to perform well. Otherwise, a store of a
1576         constant would change type from the baseline engine to the DFG, which would then cause
1577         a storm of property type invalidations and recompilations.
1578
1579         * bytecompiler/BytecodeGenerator.cpp:
1580         (JSC::BytecodeGenerator::addConstantValue):
1581
1582 2015-09-17  Filip Pizlo  <fpizlo@apple.com>
1583
1584         stress/exit-from-getter.js.ftl-eager occasionally traps in debug
1585         https://bugs.webkit.org/show_bug.cgi?id=149096
1586
1587         Reviewed by Geoffrey Garen.
1588
1589         JS calls to getters/setters in get/put inline caches need to reset SP after the call, as our
1590         calling convention requires.
1591
1592         * bytecode/PolymorphicAccess.cpp:
1593         (JSC::AccessCase::generate): Fix the bug.
1594         * ftl/FTLLink.cpp:
1595         (JSC::FTL::link): Adds some verbiage about why the FTL stack offset logic is correct.
1596         * tests/stress/getter-arity.js: Added. Other tests would flaky crash before the patch. This test instacrashes before the patch.
1597
1598 2015-09-17  Saam barati  <sbarati@apple.com>
1599
1600         Interpreter::unwind() shouldn't be responsible for filtering out uncatchable exceptions
1601         https://bugs.webkit.org/show_bug.cgi?id=149228
1602
1603         Reviewed by Mark Lam.
1604
1605         op_catch is now responsible for filtering exceptions that
1606         aren't catchable. When op_catch encounters an uncatchable
1607         exception, it will call back into genericUnwind and throw
1608         the exception further down the call stack. This is necessary
1609         in a later patch that will implement exception handling
1610         in the DFG, and part of that patch includes exception
1611         handling that doesn't go through genericUnwind. The DFG try/catch
1612         patch will not go through genericUnwind when it knows that
1613         an exception check after a callOperation will be caught inside the 
1614         machine frame or any inlined frames. This patch enables that 
1615         patch by destroying the notion that all exception handling must 
1616         filter through genericUnwind.
1617
1618         This patch maintains compatibility with the debugger and
1619         profiler by ensuring we notify the debugger when an
1620         exception is thrown inside VM::throwException and not
1621         in genericUnwind. It also notifies the profiler that we've
1622         potentially changed call frames inside op_catch.
1623
1624         * debugger/Debugger.cpp:
1625         (JSC::Debugger::pauseIfNeeded):
1626         * interpreter/Interpreter.cpp:
1627         (JSC::unwindCallFrame):
1628         (JSC::getStackFrameCodeType):
1629         (JSC::UnwindFunctor::operator()):
1630         (JSC::Interpreter::unwind):
1631         (JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
1632         (JSC::checkedReturn):
1633         * interpreter/Interpreter.h:
1634         (JSC::SuspendExceptionScope::SuspendExceptionScope):
1635         (JSC::SuspendExceptionScope::~SuspendExceptionScope):
1636         (JSC::Interpreter::sampler):
1637         * jit/JIT.h:
1638         * jit/JITInlines.h:
1639         (JSC::JIT::callOperation):
1640         (JSC::JIT::callOperationNoExceptionCheck):
1641         * jit/JITOpcodes.cpp:
1642         (JSC::JIT::emit_op_catch):
1643         * jit/JITOpcodes32_64.cpp:
1644         (JSC::JIT::emit_op_catch):
1645         * jit/JITOperations.cpp:
1646         * jit/JITOperations.h:
1647         * llint/LLIntSlowPaths.cpp:
1648         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1649         (JSC::LLInt::llint_throw_stack_overflow_error):
1650         * llint/LLIntSlowPaths.h:
1651         * llint/LowLevelInterpreter32_64.asm:
1652         * llint/LowLevelInterpreter64.asm:
1653         * runtime/ExceptionHelpers.cpp:
1654         (JSC::isTerminatedExecutionException):
1655         * runtime/VM.cpp:
1656         (JSC::VM::throwException):
1657         * runtime/VM.h:
1658         (JSC::VM::targetMachinePCForThrowOffset):
1659         (JSC::VM::restorePreviousException):
1660         (JSC::VM::clearException):
1661         (JSC::VM::clearLastException):
1662         (JSC::VM::exception):
1663         (JSC::VM::addressOfException):
1664         (JSC::VM::setException):
1665
1666 2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1667
1668         Calling a float function on x86 in WebAssembly incorrectly returns a double
1669         https://bugs.webkit.org/show_bug.cgi?id=149254
1670
1671         Reviewed by Michael Saboff.
1672
1673         In WebAssembly on x86 (32-bit), when we call a function that returns a
1674         float or a double, we use the FSTP instruction to read the return value
1675         from the FPU register stack. The FSTP instruction converts the value to
1676         single-precision or double-precision floating-point format, depending on
1677         the destination operand. Currently, we always use double as the
1678         destination, which is wrong. This patch uses the correct return type.
1679         This should fix the test errors in tests/stress/wasm-arithmetic-float32.js
1680
1681         * assembler/X86Assembler.h:
1682         (JSC::X86Assembler::fstps):
1683         * wasm/WASMFunctionCompiler.h:
1684         (JSC::WASMFunctionCompiler::appendCallSetResult):
1685         (JSC::WASMFunctionCompiler::callOperation):
1686
1687 2015-09-17  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1688
1689         Save and restore callee save registers in WebAssembly
1690         https://bugs.webkit.org/show_bug.cgi?id=149247
1691
1692         Reviewed by Michael Saboff.
1693
1694         Save callee save registers when entering WebAssembly functions
1695         and restore them when returning.
1696
1697         * jit/RegisterSet.cpp:
1698         (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
1699         * jit/RegisterSet.h:
1700         * wasm/WASMFunctionCompiler.h:
1701         (JSC::WASMFunctionCompiler::startFunction):
1702         (JSC::WASMFunctionCompiler::endFunction):
1703         (JSC::WASMFunctionCompiler::buildReturn):
1704         (JSC::WASMFunctionCompiler::localAddress):
1705         (JSC::WASMFunctionCompiler::temporaryAddress):
1706         (JSC::WASMFunctionCompiler::boxArgumentsAndAdjustStackPointer):
1707         (JSC::WASMFunctionCompiler::callAndUnboxResult):
1708
1709 2015-09-16  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1710
1711         Implement indirect calls in WebAssembly
1712         https://bugs.webkit.org/show_bug.cgi?id=149100
1713
1714         Reviewed by Geoffrey Garen.
1715
1716         This patch implement indirect calls for WebAssembly files generated by
1717         pack-asmjs <https://github.com/WebAssembly/polyfill-prototype-1>.
1718         pack-asmjs uses the same indirect call model as asm.js. In asm.js, an
1719         indirect call looks like this:
1720             t[i & n](...)
1721         where t is a variable referring to an array of functions with the same
1722         signature, i is an integer expression, n is an integer that is equal to
1723         (t.length - 1), and t.length is a power of two. pack-asmjs does not
1724         use the '&' operator nor n in the WebAssembly output, but the semantics
1725         is still the same as asm.js.
1726
1727         * tests/stress/wasm-calls.js:
1728         * tests/stress/wasm/calls.wasm:
1729         * wasm/WASMFormat.h:
1730         * wasm/WASMFunctionCompiler.h:
1731         (JSC::WASMFunctionCompiler::buildCallIndirect):
1732         * wasm/WASMFunctionParser.cpp:
1733         (JSC::WASMFunctionParser::parseExpressionI32):
1734         (JSC::WASMFunctionParser::parseExpressionF32):
1735         (JSC::WASMFunctionParser::parseExpressionF64):
1736         (JSC::WASMFunctionParser::parseCallIndirect):
1737         * wasm/WASMFunctionParser.h:
1738         * wasm/WASMFunctionSyntaxChecker.h:
1739         (JSC::WASMFunctionSyntaxChecker::buildCallIndirect):
1740         * wasm/WASMModuleParser.cpp:
1741         (JSC::WASMModuleParser::parseFunctionPointerTableSection):
1742         (JSC::WASMModuleParser::parseFunctionDefinitionSection):
1743
1744 2015-09-16  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1745
1746         Fix 32-bit build issues in WebAssembly
1747         https://bugs.webkit.org/show_bug.cgi?id=149240
1748
1749         Reviewed by Geoffrey Garen.
1750
1751         Fix the syntax error and replace the instructions that are not available on
1752         64-bit platforms.
1753
1754         * wasm/WASMFunctionCompiler.h:
1755         (JSC::WASMFunctionCompiler::startFunction):
1756         (JSC::WASMFunctionCompiler::endFunction):
1757         (JSC::WASMFunctionCompiler::buildReturn):
1758         (JSC::WASMFunctionCompiler::callAndUnboxResult):
1759         (JSC::WASMFunctionCompiler::loadValueAndConvertToDouble):
1760
1761 2015-09-16  Geoffrey Garen  <ggaren@apple.com>
1762
1763         JavaScriptCore should discard baseline code after some time
1764         https://bugs.webkit.org/show_bug.cgi?id=149220
1765
1766         Reviewed by Saam Barati.
1767
1768         This is a bit more complicated than discarding optimized code because
1769         the engine previously assumed that we would never discard baseline code.
1770
1771         * bytecode/CodeBlock.cpp:
1772         (JSC::CodeBlock::CodeBlock): Record creation time (and compute time since
1773         creation) instead of install time because CodeBlocks can be installed
1774         more than once, and we don't want to have to worry about edge cases
1775         created by CodeBlocks seeming to get younger.
1776
1777         (JSC::CodeBlock::visitAggregate): Be explicit about only doing the 
1778         weak reference fixpoint for optimized CodeBlocks. We used to avoid the
1779         fixpoint for baseline CodeBlocks implicitly, since they would always
1780         visit themselves strongly right away. But now baseline CodeBlocks might
1781         not visit themselves strongly, since they might choose to jettison due
1782         to old age.
1783
1784         (JSC::CodeBlock::shouldVisitStrongly): Add old age as a reason not to
1785         visit ourselves strongly, so that baseline CodeBlocks can jettison due
1786         to old age.
1787
1788         (JSC::CodeBlock::shouldJettisonDueToWeakReference): Be explicit about
1789         only jettisoning optimized CodeBlocks due to weak references so that we
1790         don't confuse ourselves into thinking that we will jettison a baseline
1791         CodeBlock due to weak references.
1792
1793         (JSC::CodeBlock::shouldJettisonDueToOldAge): Updated to use creation time.
1794
1795         (JSC::CodeBlock::visitOSRExitTargets): Clarify a comment and add an
1796         ASSERT to help record some things I discovered while debugging.
1797
1798         (JSC::CodeBlock::jettison): Allow a baseline CodeBlock to jettison. Don't
1799         assume that we have an alternative or a profiler.
1800
1801         (JSC::CodeBlock::install): Deleted.
1802         * bytecode/CodeBlock.h:
1803         (JSC::CodeBlock::releaseAlternative): Deleted.
1804         (JSC::CodeBlock::setInstallTime): Deleted.
1805         (JSC::CodeBlock::timeSinceInstall): Deleted.
1806
1807         * dfg/DFGOSRExitPreparation.cpp:
1808         (JSC::DFG::prepareCodeOriginForOSRExit): Simplified the computation of
1809         baseline CodeBlock.
1810
1811         * dfg/DFGPlan.cpp:
1812         (JSC::DFG::Plan::checkLivenessAndVisitChildren): Be sure to strongly
1813         visit our inline callframes because we assume that an optimized CodeBlock
1814         will keep its OSR exit targets alive, but the CodeBlock object won't be
1815         able to mark them for itself until compilation has completed (since it
1816         won't have a JITCode object yet).
1817
1818         * dfg/DFGToFTLDeferredCompilationCallback.cpp:
1819         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
1820         Updated for interface change.
1821
1822         * jit/JITCode.h:
1823         (JSC::JITCode::timeToLive): Provide a time to live for interpreter and
1824         baseline code, so they will jettison when old. Use seconds in our
1825         code so that we don't need comments. Make DFG 2X interpreter+baseline,
1826         and FTL 2X DFG+interpreter+baseline, also matching the time we allot
1827         before throwing away all code.
1828
1829         * jit/JITToDFGDeferredCompilationCallback.cpp:
1830         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
1831         * llint/LLIntSlowPaths.cpp:
1832         (JSC::LLInt::jitCompileAndSetHeuristics): Updated for interface change.
1833
1834         * runtime/Executable.cpp:
1835         (JSC::ScriptExecutable::installCode): Allow our caller to install nullptr,
1836         since we need to do this when jettisoning a baseline CodeBlock. Require
1837         our caller to specify the details of the installation because we can't
1838         rely on a non-null CodeBlock in order to compute them.
1839
1840         (JSC::ScriptExecutable::newCodeBlockFor):
1841         (JSC::ScriptExecutable::prepareForExecutionImpl):
1842         * runtime/Executable.h:
1843         (JSC::ScriptExecutable::recordParse): Updated for interface change.
1844
1845         * runtime/Options.h: Renamed the CodeBlock liveness option since it now
1846         controls baseline and optimized code.
1847
1848 2015-09-16  Geoffrey Garen  <ggaren@apple.com>
1849
1850         Remove obsolete code for deleting CodeBlocks
1851         https://bugs.webkit.org/show_bug.cgi?id=149231
1852
1853         Reviewed by Mark Lam.
1854
1855         * heap/Heap.cpp:
1856         (JSC::Heap::deleteAllCodeBlocks): ASSERT that we're called in a valid
1857         state, and do the compiler waiting ourselves instead of having our
1858         caller do it. This is more appropriate to our new limited use.
1859
1860         (JSC::Heap::collectImpl):
1861         (JSC::Heap::deleteOldCode): Deleted. Don't call deleteAllCodeBlocks
1862         periodically because it's not such a good idea to delete everything
1863         at once, and CodeBlocks now have a more precise individual policy for
1864         when to delete. Also, this function used to fail all or nearly all of
1865         the time because its invariants that we were not executing or compiling
1866         could not be met.
1867
1868         * heap/Heap.h:
1869
1870         * jsc.cpp:
1871         (GlobalObject::finishCreation):
1872         (functionDeleteAllCompiledCode): Deleted.
1873         * tests/stress/deleteAllCompiledCode.js: Removed. Removed this testing
1874         code because it did not do what it thought it did. All of this code
1875         was guaranteed to no-op since it would run JavaScript to call a function
1876         that would return early because JavaScript was running.
1877
1878         * runtime/VM.cpp:
1879         (JSC::VM::deleteAllCode): This code is simpler now becaue 
1880         heap.deleteAllCodeBlocks does some work for us.
1881
1882         * runtime/VMEntryScope.cpp:
1883         (JSC::VMEntryScope::VMEntryScope): Don't delete code on VM entry. This
1884         policy was old, and it dated back to a time when we 
1885
1886             (a) couldn't run in the interpreter if compilation failed;
1887
1888             (b) didn't reduce the rate of compilation in response to executable
1889             memory pressure;
1890
1891             (c) didn't throw away individual CodeBlocks automatically.
1892
1893 2015-09-16  Michael Saboff  <msaboff@apple.com>
1894
1895         [ES6] Implement tail calls in the LLInt and Baseline JIT
1896         https://bugs.webkit.org/show_bug.cgi?id=148661
1897
1898         Fix for the breakage of Speedometer/Full.html (https://bugs.webkit.org/show_bug.cgi?id=149162).
1899
1900         Reviewed by Filip Pizlo.
1901         Changed SetupVarargsFrame.cpp::emitSetVarargsFrame to align the callframe size to be a
1902         multiple of stackAlignmentRegisters() in addition to the location of the new frame.
1903
1904         Fixed Reviewed by Filip Pizlo.
1905
1906         * CMakeLists.txt:
1907         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1908         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1909         * JavaScriptCore.xcodeproj/project.pbxproj:
1910         * assembler/AbortReason.h:
1911         * assembler/AbstractMacroAssembler.h:
1912         (JSC::AbstractMacroAssembler::Call::Call):
1913         (JSC::AbstractMacroAssembler::repatchNearCall):
1914         (JSC::AbstractMacroAssembler::repatchCompact):
1915         * assembler/CodeLocation.h:
1916         (JSC::CodeLocationNearCall::CodeLocationNearCall):
1917         (JSC::CodeLocationNearCall::callMode):
1918         (JSC::CodeLocationCommon::callAtOffset):
1919         (JSC::CodeLocationCommon::nearCallAtOffset):
1920         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
1921         * assembler/LinkBuffer.h:
1922         (JSC::LinkBuffer::locationOfNearCall):
1923         (JSC::LinkBuffer::locationOf):
1924         * assembler/MacroAssemblerARM.h:
1925         (JSC::MacroAssemblerARM::nearCall):
1926         (JSC::MacroAssemblerARM::nearTailCall):
1927         (JSC::MacroAssemblerARM::call):
1928         (JSC::MacroAssemblerARM::linkCall):
1929         * assembler/MacroAssemblerARM64.h:
1930         (JSC::MacroAssemblerARM64::nearCall):
1931         (JSC::MacroAssemblerARM64::nearTailCall):
1932         (JSC::MacroAssemblerARM64::ret):
1933         (JSC::MacroAssemblerARM64::linkCall):
1934         * assembler/MacroAssemblerARMv7.h:
1935         (JSC::MacroAssemblerARMv7::nearCall):
1936         (JSC::MacroAssemblerARMv7::nearTailCall):
1937         (JSC::MacroAssemblerARMv7::call):
1938         (JSC::MacroAssemblerARMv7::linkCall):
1939         * assembler/MacroAssemblerMIPS.h:
1940         (JSC::MacroAssemblerMIPS::nearCall):
1941         (JSC::MacroAssemblerMIPS::nearTailCall):
1942         (JSC::MacroAssemblerMIPS::call):
1943         (JSC::MacroAssemblerMIPS::linkCall):
1944         (JSC::MacroAssemblerMIPS::repatchCall):
1945         * assembler/MacroAssemblerSH4.h:
1946         (JSC::MacroAssemblerSH4::call):
1947         (JSC::MacroAssemblerSH4::nearTailCall):
1948         (JSC::MacroAssemblerSH4::nearCall):
1949         (JSC::MacroAssemblerSH4::linkCall):
1950         (JSC::MacroAssemblerSH4::repatchCall):
1951         * assembler/MacroAssemblerX86.h:
1952         (JSC::MacroAssemblerX86::linkCall):
1953         * assembler/MacroAssemblerX86Common.h:
1954         (JSC::MacroAssemblerX86Common::breakpoint):
1955         (JSC::MacroAssemblerX86Common::nearTailCall):
1956         (JSC::MacroAssemblerX86Common::nearCall):
1957         * assembler/MacroAssemblerX86_64.h:
1958         (JSC::MacroAssemblerX86_64::linkCall):
1959         * bytecode/BytecodeList.json:
1960         * bytecode/BytecodeUseDef.h:
1961         (JSC::computeUsesForBytecodeOffset):
1962         (JSC::computeDefsForBytecodeOffset):
1963         * bytecode/CallLinkInfo.h:
1964         (JSC::CallLinkInfo::callTypeFor):
1965         (JSC::CallLinkInfo::isVarargsCallType):
1966         (JSC::CallLinkInfo::CallLinkInfo):
1967         (JSC::CallLinkInfo::specializationKind):
1968         (JSC::CallLinkInfo::callModeFor):
1969         (JSC::CallLinkInfo::callMode):
1970         (JSC::CallLinkInfo::isTailCall):
1971         (JSC::CallLinkInfo::isVarargs):
1972         (JSC::CallLinkInfo::registerPreservationMode):
1973         * bytecode/CallLinkStatus.cpp:
1974         (JSC::CallLinkStatus::computeFromLLInt):
1975         * bytecode/CodeBlock.cpp:
1976         (JSC::CodeBlock::dumpBytecode):
1977         (JSC::CodeBlock::CodeBlock):
1978         * bytecompiler/BytecodeGenerator.cpp:
1979         (JSC::BytecodeGenerator::BytecodeGenerator):
1980         (JSC::BytecodeGenerator::emitCallInTailPosition):
1981         (JSC::BytecodeGenerator::emitCallEval):
1982         (JSC::BytecodeGenerator::emitCall):
1983         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
1984         (JSC::BytecodeGenerator::emitConstructVarargs):
1985         * bytecompiler/NodesCodegen.cpp:
1986         (JSC::CallArguments::CallArguments):
1987         (JSC::LabelNode::emitBytecode):
1988         * dfg/DFGByteCodeParser.cpp:
1989         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
1990         * ftl/FTLLowerDFGToLLVM.cpp:
1991         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
1992         * interpreter/Interpreter.h:
1993         (JSC::Interpreter::isCallBytecode):
1994         (JSC::calleeFrameForVarargs):
1995         * jit/CCallHelpers.h:
1996         (JSC::CCallHelpers::jumpToExceptionHandler):
1997         (JSC::CCallHelpers::prepareForTailCallSlow):
1998         * jit/JIT.cpp:
1999         (JSC::JIT::privateCompileMainPass):
2000         (JSC::JIT::privateCompileSlowCases):
2001         * jit/JIT.h:
2002         * jit/JITCall.cpp:
2003         (JSC::JIT::compileOpCall):
2004         (JSC::JIT::compileOpCallSlowCase):
2005         (JSC::JIT::emit_op_call):
2006         (JSC::JIT::emit_op_tail_call):
2007         (JSC::JIT::emit_op_call_eval):
2008         (JSC::JIT::emit_op_call_varargs):
2009         (JSC::JIT::emit_op_tail_call_varargs):
2010         (JSC::JIT::emit_op_construct_varargs):
2011         (JSC::JIT::emitSlow_op_call):
2012         (JSC::JIT::emitSlow_op_tail_call):
2013         (JSC::JIT::emitSlow_op_call_eval):
2014         (JSC::JIT::emitSlow_op_call_varargs):
2015         (JSC::JIT::emitSlow_op_tail_call_varargs):
2016         (JSC::JIT::emitSlow_op_construct_varargs):
2017         * jit/JITCall32_64.cpp:
2018         (JSC::JIT::emitSlow_op_call):
2019         (JSC::JIT::emitSlow_op_tail_call):
2020         (JSC::JIT::emitSlow_op_call_eval):
2021         (JSC::JIT::emitSlow_op_call_varargs):
2022         (JSC::JIT::emitSlow_op_tail_call_varargs):
2023         (JSC::JIT::emitSlow_op_construct_varargs):
2024         (JSC::JIT::emit_op_call):
2025         (JSC::JIT::emit_op_tail_call):
2026         (JSC::JIT::emit_op_call_eval):
2027         (JSC::JIT::emit_op_call_varargs):
2028         (JSC::JIT::emit_op_tail_call_varargs):
2029         (JSC::JIT::emit_op_construct_varargs):
2030         (JSC::JIT::compileOpCall):
2031         (JSC::JIT::compileOpCallSlowCase):
2032         * jit/JITInlines.h:
2033         (JSC::JIT::emitNakedCall):
2034         (JSC::JIT::emitNakedTailCall):
2035         (JSC::JIT::updateTopCallFrame):
2036         * jit/JITOperations.cpp:
2037         * jit/JITOperations.h:
2038         * jit/Repatch.cpp:
2039         (JSC::linkVirtualFor):
2040         (JSC::linkPolymorphicCall):
2041         * jit/SetupVarargsFrame.cpp:
2042         (JSC::emitSetVarargsFrame):
2043         * jit/ThunkGenerators.cpp:
2044         (JSC::throwExceptionFromCallSlowPathGenerator):
2045         (JSC::slowPathFor):
2046         (JSC::linkCallThunkGenerator):
2047         (JSC::virtualThunkFor):
2048         (JSC::arityFixupGenerator):
2049         (JSC::unreachableGenerator):
2050         (JSC::baselineGetterReturnThunkGenerator):
2051         * jit/ThunkGenerators.h:
2052         * llint/LowLevelInterpreter.asm:
2053         * llint/LowLevelInterpreter32_64.asm:
2054         * llint/LowLevelInterpreter64.asm:
2055         * runtime/CommonSlowPaths.h:
2056         (JSC::CommonSlowPaths::arityCheckFor):
2057         (JSC::CommonSlowPaths::opIn):
2058
2059 2015-09-15  Michael Saboff  <msaboff@apple.com>
2060
2061         Rollout r189774 and 189818.
2062
2063         Broke Speedometer/Full.html
2064
2065         Not reviewed.
2066
2067         * CMakeLists.txt:
2068         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2069         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2070         * JavaScriptCore.xcodeproj/project.pbxproj:
2071         * assembler/AbortReason.h:
2072         * assembler/AbstractMacroAssembler.h:
2073         (JSC::AbstractMacroAssembler::Call::Call):
2074         (JSC::AbstractMacroAssembler::repatchNearCall):
2075         (JSC::AbstractMacroAssembler::repatchCompact):
2076         * assembler/CodeLocation.h:
2077         (JSC::CodeLocationNearCall::CodeLocationNearCall):
2078         (JSC::CodeLocationCommon::callAtOffset):
2079         (JSC::CodeLocationCommon::nearCallAtOffset):
2080         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
2081         (JSC::CodeLocationNearCall::callMode): Deleted.
2082         * assembler/LinkBuffer.h:
2083         (JSC::LinkBuffer::locationOfNearCall):
2084         (JSC::LinkBuffer::locationOf):
2085         * assembler/MacroAssemblerARM.h:
2086         (JSC::MacroAssemblerARM::nearCall):
2087         (JSC::MacroAssemblerARM::call):
2088         (JSC::MacroAssemblerARM::linkCall):
2089         (JSC::MacroAssemblerARM::nearTailCall): Deleted.
2090         * assembler/MacroAssemblerARM64.h:
2091         (JSC::MacroAssemblerARM64::nearCall):
2092         (JSC::MacroAssemblerARM64::ret):
2093         (JSC::MacroAssemblerARM64::linkCall):
2094         (JSC::MacroAssemblerARM64::nearTailCall): Deleted.
2095         * assembler/MacroAssemblerARMv7.h:
2096         (JSC::MacroAssemblerARMv7::nearCall):
2097         (JSC::MacroAssemblerARMv7::call):
2098         (JSC::MacroAssemblerARMv7::linkCall):
2099         (JSC::MacroAssemblerARMv7::nearTailCall): Deleted.
2100         * assembler/MacroAssemblerMIPS.h:
2101         (JSC::MacroAssemblerMIPS::nearCall):
2102         (JSC::MacroAssemblerMIPS::call):
2103         (JSC::MacroAssemblerMIPS::linkCall):
2104         (JSC::MacroAssemblerMIPS::repatchCall):
2105         (JSC::MacroAssemblerMIPS::nearTailCall): Deleted.
2106         * assembler/MacroAssemblerSH4.h:
2107         (JSC::MacroAssemblerSH4::call):
2108         (JSC::MacroAssemblerSH4::nearCall):
2109         (JSC::MacroAssemblerSH4::linkCall):
2110         (JSC::MacroAssemblerSH4::repatchCall):
2111         (JSC::MacroAssemblerSH4::nearTailCall): Deleted.
2112         * assembler/MacroAssemblerX86.h:
2113         (JSC::MacroAssemblerX86::linkCall):
2114         * assembler/MacroAssemblerX86Common.h:
2115         (JSC::MacroAssemblerX86Common::breakpoint):
2116         (JSC::MacroAssemblerX86Common::nearCall):
2117         (JSC::MacroAssemblerX86Common::nearTailCall): Deleted.
2118         * assembler/MacroAssemblerX86_64.h:
2119         (JSC::MacroAssemblerX86_64::linkCall):
2120         * bytecode/BytecodeList.json:
2121         * bytecode/BytecodeUseDef.h:
2122         (JSC::computeUsesForBytecodeOffset):
2123         (JSC::computeDefsForBytecodeOffset):
2124         * bytecode/CallLinkInfo.h:
2125         (JSC::CallLinkInfo::callTypeFor):
2126         (JSC::CallLinkInfo::CallLinkInfo):
2127         (JSC::CallLinkInfo::specializationKind):
2128         (JSC::CallLinkInfo::registerPreservationMode):
2129         (JSC::CallLinkInfo::isVarargsCallType): Deleted.
2130         (JSC::CallLinkInfo::callModeFor): Deleted.
2131         (JSC::CallLinkInfo::callMode): Deleted.
2132         (JSC::CallLinkInfo::isTailCall): Deleted.
2133         (JSC::CallLinkInfo::isVarargs): Deleted.
2134         * bytecode/CallLinkStatus.cpp:
2135         (JSC::CallLinkStatus::computeFromLLInt):
2136         * bytecode/CodeBlock.cpp:
2137         (JSC::CodeBlock::dumpBytecode):
2138         (JSC::CodeBlock::CodeBlock):
2139         * bytecompiler/BytecodeGenerator.cpp:
2140         (JSC::BytecodeGenerator::BytecodeGenerator):
2141         (JSC::BytecodeGenerator::emitCallInTailPosition):
2142         (JSC::BytecodeGenerator::emitCallEval):
2143         (JSC::BytecodeGenerator::emitCall):
2144         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
2145         (JSC::BytecodeGenerator::emitConstructVarargs):
2146         * bytecompiler/NodesCodegen.cpp:
2147         (JSC::CallArguments::CallArguments):
2148         (JSC::LabelNode::emitBytecode):
2149         * dfg/DFGByteCodeParser.cpp:
2150         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
2151         * ftl/FTLLowerDFGToLLVM.cpp:
2152         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
2153         * interpreter/Interpreter.h:
2154         (JSC::Interpreter::isCallBytecode):
2155         * jit/CCallHelpers.h:
2156         (JSC::CCallHelpers::jumpToExceptionHandler):
2157         (JSC::CCallHelpers::prepareForTailCallSlow): Deleted.
2158         * jit/JIT.cpp:
2159         (JSC::JIT::privateCompileMainPass):
2160         (JSC::JIT::privateCompileSlowCases):
2161         * jit/JIT.h:
2162         * jit/JITCall.cpp:
2163         (JSC::JIT::compileOpCall):
2164         (JSC::JIT::compileOpCallSlowCase):
2165         (JSC::JIT::emit_op_call):
2166         (JSC::JIT::emit_op_call_eval):
2167         (JSC::JIT::emit_op_call_varargs):
2168         (JSC::JIT::emit_op_construct_varargs):
2169         (JSC::JIT::emitSlow_op_call):
2170         (JSC::JIT::emitSlow_op_call_eval):
2171         (JSC::JIT::emitSlow_op_call_varargs):
2172         (JSC::JIT::emitSlow_op_construct_varargs):
2173         (JSC::JIT::emit_op_tail_call): Deleted.
2174         (JSC::JIT::emit_op_tail_call_varargs): Deleted.
2175         (JSC::JIT::emitSlow_op_tail_call): Deleted.
2176         (JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
2177         * jit/JITCall32_64.cpp:
2178         (JSC::JIT::emitSlow_op_call):
2179         (JSC::JIT::emitSlow_op_call_eval):
2180         (JSC::JIT::emitSlow_op_call_varargs):
2181         (JSC::JIT::emitSlow_op_construct_varargs):
2182         (JSC::JIT::emit_op_call):
2183         (JSC::JIT::emit_op_call_eval):
2184         (JSC::JIT::emit_op_call_varargs):
2185         (JSC::JIT::emit_op_construct_varargs):
2186         (JSC::JIT::compileOpCall):
2187         (JSC::JIT::compileOpCallSlowCase):
2188         (JSC::JIT::emitSlow_op_tail_call): Deleted.
2189         (JSC::JIT::emitSlow_op_tail_call_varargs): Deleted.
2190         (JSC::JIT::emit_op_tail_call): Deleted.
2191         (JSC::JIT::emit_op_tail_call_varargs): Deleted.
2192         * jit/JITInlines.h:
2193         (JSC::JIT::emitNakedCall):
2194         (JSC::JIT::updateTopCallFrame):
2195         (JSC::JIT::emitNakedTailCall): Deleted.
2196         * jit/JITOperations.cpp:
2197         * jit/JITOperations.h:
2198         * jit/Repatch.cpp:
2199         (JSC::linkVirtualFor):
2200         (JSC::linkPolymorphicCall):
2201         * jit/ThunkGenerators.cpp:
2202         (JSC::throwExceptionFromCallSlowPathGenerator):
2203         (JSC::slowPathFor):
2204         (JSC::linkCallThunkGenerator):
2205         (JSC::virtualThunkFor):
2206         (JSC::arityFixupGenerator):
2207         (JSC::baselineGetterReturnThunkGenerator):
2208         (JSC::unreachableGenerator): Deleted.
2209         * jit/ThunkGenerators.h:
2210         * llint/LowLevelInterpreter.asm:
2211         * llint/LowLevelInterpreter32_64.asm:
2212         * llint/LowLevelInterpreter64.asm:
2213         * runtime/CommonSlowPaths.h:
2214         (JSC::CommonSlowPaths::arityCheckFor):
2215         (JSC::CommonSlowPaths::opIn):
2216         * tests/stress/mutual-tail-call-no-stack-overflow.js: Removed.
2217         * tests/stress/tail-call-no-stack-overflow.js: Removed.
2218         * tests/stress/tail-call-recognize.js: Removed.
2219         * tests/stress/tail-call-varargs-no-stack-overflow.js: Removed.
2220         * tests/stress/tail-calls-dont-overwrite-live-stack.js: Removed.
2221
2222 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2223
2224         Implement imported global variables in WebAssembly
2225         https://bugs.webkit.org/show_bug.cgi?id=149206
2226
2227         Reviewed by Filip Pizlo.
2228
2229         Values can now be imported to a WebAssembly module through properties of
2230         the imports object that is passed to loadWebAssembly(). In order to
2231         avoid any side effect when accessing the imports object, we check that
2232         the properties are data properties. We also check that each value is a
2233         primitive and is not a Symbol. According to the ECMA262 6.0 spec,
2234         calling ToNumber() on a primitive that is not a Symbol should not cause
2235         any side effect.[1]
2236
2237         [1]: http://www.ecma-international.org/ecma-262/6.0/#sec-tonumber
2238
2239         * tests/stress/wasm-globals.js:
2240         * tests/stress/wasm/globals.wasm:
2241         * wasm/WASMModuleParser.cpp:
2242         (JSC::WASMModuleParser::parseModule):
2243         (JSC::WASMModuleParser::parseGlobalSection):
2244         * wasm/WASMModuleParser.h:
2245
2246 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2247
2248         Fix asm.js errors in WebAssembly tests
2249         https://bugs.webkit.org/show_bug.cgi?id=149203
2250
2251         Reviewed by Geoffrey Garen.
2252
2253         Our WebAssembly implementation uses asm.js for testing. Using Firefox to
2254         parse asm.js reveals many errors that are not caught by pack-asmjs. For
2255         example,
2256         - asm.js does not allow the use of the multiplication operator (*) to
2257           multiply two integers, because the result can be so large that some
2258           lower bits of precision are lost. Math.imul is used instead.
2259         - an int variable must be coerced to either signed (via x|0) or unsigned
2260           (via x>>>0) before it's returned.
2261
2262         * tests/stress/wasm-arithmetic-int32.js:
2263         * tests/stress/wasm-calls.js:
2264         * tests/stress/wasm-control-flow.js:
2265         * tests/stress/wasm-globals.js:
2266         * tests/stress/wasm-locals.js:
2267         * tests/stress/wasm-relational.js:
2268         * tests/stress/wasm/control-flow.wasm:
2269
2270 2015-09-15  Ryosuke Niwa  <rniwa@webkit.org>
2271
2272         Add ShadowRoot interface and Element.prototype.attachShadow
2273         https://bugs.webkit.org/show_bug.cgi?id=149187
2274
2275         Reviewed by Antti Koivisto.
2276
2277         * Configurations/FeatureDefines.xcconfig:
2278
2279 2015-09-15  Joseph Pecoraro  <pecoraro@apple.com>
2280
2281         Web Inspector: Paused Debugger prevents page reload
2282         https://bugs.webkit.org/show_bug.cgi?id=148174
2283
2284         Reviewed by Brian Burg.
2285
2286         * debugger/Debugger.h:
2287         (JSC::Debugger::suppressAllPauses):
2288         (JSC::Debugger::setSuppressAllPauses):
2289         * debugger/Debugger.cpp:
2290         (JSC::Debugger::Debugger):
2291         (JSC::Debugger::pauseIfNeeded):
2292         * inspector/agents/InspectorDebuggerAgent.h:
2293         * inspector/agents/InspectorDebuggerAgent.cpp:
2294         (Inspector::InspectorDebuggerAgent::setSuppressAllPauses):
2295         Provide a way to suppress pauses.
2296
2297 2015-09-15  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2298
2299         Implement calls to JavaScript functions in WebAssembly
2300         https://bugs.webkit.org/show_bug.cgi?id=149093
2301
2302         Reviewed by Filip Pizlo.
2303
2304         This patch implements calls to JavaScript functions in WebAssembly.
2305         WebAssembly functions can only call JavaScript functions that are
2306         imported to their module via an object that is passed into
2307         loadWebAssembly(). References to JavaScript functions are resolved at
2308         the module's load time, just like asm.js.
2309
2310         * jsc.cpp:
2311         (GlobalObject::finishCreation):
2312         (functionLoadWebAssembly):
2313         * tests/stress/wasm-calls.js:
2314         * tests/stress/wasm/calls.wasm:
2315         * wasm/JSWASMModule.cpp:
2316         (JSC::JSWASMModule::visitChildren):
2317         * wasm/JSWASMModule.h:
2318         (JSC::JSWASMModule::importedFunctions):
2319         * wasm/WASMFunctionCompiler.h:
2320         (JSC::WASMFunctionCompiler::buildCallImport):
2321         * wasm/WASMFunctionParser.cpp:
2322         (JSC::WASMFunctionParser::parseExpressionI32):
2323         (JSC::WASMFunctionParser::parseExpressionF64):
2324         (JSC::WASMFunctionParser::parseCallImport):
2325         * wasm/WASMFunctionParser.h:
2326         * wasm/WASMFunctionSyntaxChecker.h:
2327         (JSC::WASMFunctionSyntaxChecker::buildCallInternal):
2328         (JSC::WASMFunctionSyntaxChecker::buildCallImport):
2329         (JSC::WASMFunctionSyntaxChecker::updateTempStackHeightForCall):
2330         * wasm/WASMModuleParser.cpp:
2331         (JSC::WASMModuleParser::WASMModuleParser):
2332         (JSC::WASMModuleParser::parse):
2333         (JSC::WASMModuleParser::parseModule):
2334         (JSC::WASMModuleParser::parseFunctionImportSection):
2335         (JSC::WASMModuleParser::getImportedValue):
2336         (JSC::parseWebAssembly):
2337         * wasm/WASMModuleParser.h:
2338
2339 2015-09-15  Csaba Osztrogon√°c  <ossy@webkit.org>
2340
2341         Fix the !ENABLE(DFG_JIT) build after r188696
2342         https://bugs.webkit.org/show_bug.cgi?id=149158
2343
2344         Reviewed by Yusuke Suzuki.
2345
2346         * bytecode/GetByIdStatus.cpp:
2347         * bytecode/GetByIdStatus.h:
2348
2349 2015-09-15  Saam barati  <sbarati@apple.com>
2350
2351         functions that use try/catch will allocate a top level JSLexicalEnvironment even when it is not necessary
2352         https://bugs.webkit.org/show_bug.cgi?id=148169
2353
2354         Reviewed by Geoffrey Garen.
2355
2356         We used to do this before we had proper lexical scoping
2357         in the bytecode generator. There is absolutely no reason
2358         why need to allocate a top-level "var" activation when a
2359         function/program uses a "catch" block.
2360
2361         * parser/ASTBuilder.h:
2362         (JSC::ASTBuilder::createTryStatement):
2363         (JSC::ASTBuilder::incConstants):
2364         (JSC::ASTBuilder::usesThis):
2365         (JSC::ASTBuilder::usesArguments):
2366         (JSC::ASTBuilder::usesWith):
2367         (JSC::ASTBuilder::usesEval):
2368         (JSC::ASTBuilder::usesCatch): Deleted.
2369         * parser/Nodes.h:
2370         (JSC::ScopeNode::isStrictMode):
2371         (JSC::ScopeNode::setUsesArguments):
2372         (JSC::ScopeNode::usesThis):
2373         (JSC::ScopeNode::needsActivation):
2374         (JSC::ScopeNode::hasCapturedVariables):
2375         (JSC::ScopeNode::captures):
2376         (JSC::ScopeNode::needsActivationForMoreThanVariables): Deleted.
2377         * parser/ParserModes.h:
2378         * runtime/Executable.h:
2379         (JSC::ScriptExecutable::usesEval):
2380         (JSC::ScriptExecutable::usesArguments):
2381         (JSC::ScriptExecutable::needsActivation):
2382         (JSC::ScriptExecutable::isStrictMode):
2383         (JSC::ScriptExecutable::ecmaMode):
2384
2385 2015-09-15  Michael Saboff  <msaboff@apple.com>
2386
2387         REGRESSION(r189774): CLoop doesn't build after r189774
2388         https://bugs.webkit.org/show_bug.cgi?id=149171
2389
2390         Unreviewed build fix for the C Loop.
2391
2392         Added needed C Loop label opcodes.
2393
2394         * bytecode/BytecodeList.json:
2395
2396 2015-09-15  Andy VanWagoner  <thetalecrafter@gmail.com>
2397
2398         [INTL] Implement supportedLocalesOf on Intl Constructors
2399         https://bugs.webkit.org/show_bug.cgi?id=147599
2400
2401         Reviewed by Benjamin Poulain.
2402
2403         Implements all of the abstract operations used by supportedLocalesOf,
2404         except during canonicalization it does not replace redundant tags,
2405         or subtags with their preferred values.
2406
2407         * icu/unicode/ucal.h: Added.
2408         * icu/unicode/udat.h: Added.
2409         * icu/unicode/umisc.h: Added.
2410         * icu/unicode/unum.h: Added.
2411         * icu/unicode/utypes.h: Clear the U_SHOW_CPLUSPLUS_API flag to prevent C++ headers from being included.
2412         * runtime/CommonIdentifiers.h: Adde localeMatcher.
2413         * runtime/IntlCollatorConstructor.cpp:
2414         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf): Implemented.
2415         * runtime/IntlDateTimeFormatConstructor.cpp:
2416         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): Implemented.
2417         * runtime/IntlNumberFormatConstructor.cpp:
2418         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): Implemented.
2419         * runtime/IntlObject.cpp:
2420         (JSC::canonicalizeLanguageTag):
2421         (JSC::getCanonicalLangTag):
2422         (JSC::getPrivateUseLangTag):
2423         (JSC::getGrandfatheredLangTag):
2424         (JSC::canonicalizeLocaleList):
2425         (JSC::bestAvailableLocale):
2426         (JSC::lookupSupportedLocales):
2427         (JSC::bestFitSupportedLocales):
2428         (JSC::supportedLocales):
2429         (JSC::getIntlStringOption):
2430         (JSC::getIntlBooleanOption):
2431         * runtime/IntlObject.h:
2432         * runtime/JSCJSValue.h: Added toLength.
2433         * runtime/JSCJSValue.cpp: Added toLength.
2434         (JSC::JSValue::toLength): Implement ToLength from ECMA 262 6.0 7.1.15
2435         * runtime/JSGlobalObject.cpp:
2436         (JSC::JSGlobalObject::intlCollatorAvailableLocales): Added lazy locale list.
2437         (JSC::JSGlobalObject::intlDateTimeFormatAvailableLocales): Added lazy locale list.
2438         (JSC::JSGlobalObject::intlNumberFormatAvailableLocales): Added lazy locale list.
2439         * runtime/JSGlobalObject.h:
2440
2441 2015-09-14  Saam barati  <sbarati@apple.com>
2442
2443         rename callFrameForThrow to callFrameForCatch
2444         https://bugs.webkit.org/show_bug.cgi?id=149136
2445
2446         Reviewed by Michael Saboff.
2447
2448         We use "callFrameForThrow" to mean the call frame in
2449         which we're catching the exception. The field name
2450         should accurately represent its purpose by being
2451         named "callFrameForCatch".
2452
2453         * jit/CCallHelpers.h:
2454         (JSC::CCallHelpers::jumpToExceptionHandler):
2455         * jit/JITExceptions.cpp:
2456         (JSC::genericUnwind):
2457         * jit/JITOpcodes.cpp:
2458         (JSC::JIT::emit_op_catch):
2459         * jit/JITOpcodes32_64.cpp:
2460         (JSC::JIT::emit_op_catch):
2461         * jit/JITOperations.cpp:
2462         * llint/LowLevelInterpreter32_64.asm:
2463         * llint/LowLevelInterpreter64.asm:
2464         * runtime/VM.h:
2465         (JSC::VM::exceptionOffset):
2466         (JSC::VM::callFrameForCatchOffset):
2467         (JSC::VM::targetMachinePCForThrowOffset):
2468         (JSC::VM::callFrameForThrowOffset): Deleted.
2469
2470 2015-09-14  Basile Clement  <basile_clement@apple.com>
2471
2472         [ES6] Implement tail calls in the LLInt and Baseline JIT
2473         https://bugs.webkit.org/show_bug.cgi?id=148661
2474
2475         Reviewed by Filip Pizlo.
2476
2477         This patch introduces two new opcodes, op_tail_call and
2478         op_tail_call_varargs, to perform tail calls, and implements them in the
2479         LLInt and baseline JIT. Their use prevents DFG and FTL compilation for
2480         now. They are currently implemented by sliding the call frame and
2481         masquerading as our own caller right before performing an actual call.
2482
2483         This required to change the operationLink family of operation to return
2484         a SlowPathReturnType instead of a char* in order to distinguish between
2485         exception cases and actual call cases. We introduce a new FrameAction
2486         enum that indicates whether to reuse (non-exceptional tail call) or
2487         keep the current call frame (non-tail call, and exceptional cases).
2488
2489         This is also a semantics change, since the Function.caller property is
2490         now leaking tail calls. Since tail calls are only used in strict mode,
2491         which poisons this property, the only way of seeing this semantics
2492         change is when a sloppy function calls a strict function that then
2493         tail-calls a sloppy function. Previously, the second sloppy function's
2494         caller would have been the strict function (i.e. raises a TypeError
2495         when the .caller attribute is accessed), while it is now the first
2496         sloppy function. Tests have been updated to reflect that.
2497
2498         This also changes the assumptions we make about call frames. In order
2499         to be relatively efficient, we want to be able to compute the frame
2500         size based only on the argument count, which was not possible
2501         previously. To enable this, we now enforce at the bytecode generator,
2502         DFG and FTL level that any space reserved for a call frame is
2503         stack-aligned, which allows to easily compute its size when performing
2504         a tail call. In all the "special call cases" (calls from native code,
2505         inlined cache calls, etc.), we are starting the frame at the current
2506         stack pointer and thus will always have a stack-aligned frame size.
2507
2508         Finally, this patch adds a couple of tests to check that tail calls run
2509         in constant stack space, as well as tests checking that tail calls are
2510         recognized correctly. Those tests use the handy aforementioned leaking
2511         of tail calls through Function.caller to detect tail calls. 
2512
2513         Given that this patch only implements tail calls for the LLInt and
2514         Baseline JIT, tail calls are disabled by default.  Until changes are
2515         landed for all tiers, tail call testing and use requires the
2516         --enableTailCalls=true or equivalent.
2517
2518         * CMakeLists.txt:
2519         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2520         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2521         * JavaScriptCore.xcodeproj/project.pbxproj:
2522         * assembler/AbortReason.h:
2523         * assembler/AbstractMacroAssembler.h:
2524         (JSC::AbstractMacroAssembler::Call::Call):
2525         (JSC::AbstractMacroAssembler::repatchNearCall):
2526         (JSC::AbstractMacroAssembler::repatchCompact):
2527         * assembler/CodeLocation.h:
2528         (JSC::CodeLocationNearCall::CodeLocationNearCall):
2529         (JSC::CodeLocationNearCall::callMode):
2530         (JSC::CodeLocationCommon::callAtOffset):
2531         (JSC::CodeLocationCommon::nearCallAtOffset):
2532         (JSC::CodeLocationCommon::dataLabelPtrAtOffset):
2533         * assembler/LinkBuffer.h:
2534         (JSC::LinkBuffer::locationOfNearCall):
2535         (JSC::LinkBuffer::locationOf):
2536         * assembler/MacroAssemblerARM.h:
2537         (JSC::MacroAssemblerARM::nearCall):
2538         (JSC::MacroAssemblerARM::nearTailCall):
2539         (JSC::MacroAssemblerARM::call):
2540         (JSC::MacroAssemblerARM::linkCall):
2541         * assembler/MacroAssemblerARM64.h:
2542         (JSC::MacroAssemblerARM64::nearCall):
2543         (JSC::MacroAssemblerARM64::nearTailCall):
2544         (JSC::MacroAssemblerARM64::ret):
2545         (JSC::MacroAssemblerARM64::linkCall):
2546         * assembler/MacroAssemblerARMv7.h:
2547         (JSC::MacroAssemblerARMv7::nearCall):
2548         (JSC::MacroAssemblerARMv7::nearTailCall):
2549         (JSC::MacroAssemblerARMv7::call):
2550         (JSC::MacroAssemblerARMv7::linkCall):
2551         * assembler/MacroAssemblerMIPS.h:
2552         (JSC::MacroAssemblerMIPS::nearCall):
2553         (JSC::MacroAssemblerMIPS::nearTailCall):
2554         (JSC::MacroAssemblerMIPS::call):
2555         (JSC::MacroAssemblerMIPS::linkCall):
2556         (JSC::MacroAssemblerMIPS::repatchCall):
2557         * assembler/MacroAssemblerSH4.h:
2558         (JSC::MacroAssemblerSH4::call):
2559         (JSC::MacroAssemblerSH4::nearTailCall):
2560         (JSC::MacroAssemblerSH4::nearCall):
2561         (JSC::MacroAssemblerSH4::linkCall):
2562         (JSC::MacroAssemblerSH4::repatchCall):
2563         * assembler/MacroAssemblerX86.h:
2564         (JSC::MacroAssemblerX86::linkCall):
2565         * assembler/MacroAssemblerX86Common.h:
2566         (JSC::MacroAssemblerX86Common::breakpoint):
2567         (JSC::MacroAssemblerX86Common::nearTailCall):
2568         (JSC::MacroAssemblerX86Common::nearCall):
2569         * assembler/MacroAssemblerX86_64.h:
2570         (JSC::MacroAssemblerX86_64::linkCall):
2571         * bytecode/BytecodeList.json:
2572         * bytecode/BytecodeUseDef.h:
2573         (JSC::computeUsesForBytecodeOffset):
2574         (JSC::computeDefsForBytecodeOffset):
2575         * bytecode/CallLinkInfo.h:
2576         (JSC::CallLinkInfo::callTypeFor):
2577         (JSC::CallLinkInfo::isVarargsCallType):
2578         (JSC::CallLinkInfo::CallLinkInfo):
2579         (JSC::CallLinkInfo::specializationKind):
2580         (JSC::CallLinkInfo::callModeFor):
2581         (JSC::CallLinkInfo::callMode):
2582         (JSC::CallLinkInfo::isTailCall):
2583         (JSC::CallLinkInfo::isVarargs):
2584         (JSC::CallLinkInfo::registerPreservationMode):
2585         * bytecode/CallLinkStatus.cpp:
2586         (JSC::CallLinkStatus::computeFromLLInt):
2587         * bytecode/CallMode.cpp: Added.
2588         (WTF::printInternal):
2589         * bytecode/CallMode.h: Added.
2590         * bytecode/CodeBlock.cpp:
2591         (JSC::CodeBlock::dumpBytecode):
2592         (JSC::CodeBlock::CodeBlock):
2593         * bytecompiler/BytecodeGenerator.cpp:
2594         (JSC::BytecodeGenerator::BytecodeGenerator):
2595         (JSC::BytecodeGenerator::emitCallInTailPosition):
2596         (JSC::BytecodeGenerator::emitCallEval):
2597         (JSC::BytecodeGenerator::emitCall):
2598         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
2599         (JSC::BytecodeGenerator::emitConstructVarargs):
2600         * bytecompiler/NodesCodegen.cpp:
2601         (JSC::CallArguments::CallArguments):
2602         (JSC::LabelNode::emitBytecode):
2603         * dfg/DFGByteCodeParser.cpp:
2604         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
2605         * ftl/FTLLowerDFGToLLVM.cpp:
2606         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstruct):
2607         * interpreter/Interpreter.h:
2608         (JSC::Interpreter::isCallBytecode):
2609         * jit/CCallHelpers.h:
2610         (JSC::CCallHelpers::jumpToExceptionHandler):
2611         (JSC::CCallHelpers::prepareForTailCallSlow):
2612         * jit/JIT.cpp:
2613         (JSC::JIT::privateCompileMainPass):
2614         (JSC::JIT::privateCompileSlowCases):
2615         * jit/JIT.h:
2616         * jit/JITCall.cpp:
2617         (JSC::JIT::compileOpCall):
2618         (JSC::JIT::compileOpCallSlowCase):
2619         (JSC::JIT::emit_op_call):
2620         (JSC::JIT::emit_op_tail_call):
2621         (JSC::JIT::emit_op_call_eval):
2622         (JSC::JIT::emit_op_call_varargs):
2623         (JSC::JIT::emit_op_tail_call_varargs):
2624         (JSC::JIT::emit_op_construct_varargs):
2625         (JSC::JIT::emitSlow_op_call):
2626         (JSC::JIT::emitSlow_op_tail_call):
2627         (JSC::JIT::emitSlow_op_call_eval):
2628         (JSC::JIT::emitSlow_op_call_varargs):
2629         (JSC::JIT::emitSlow_op_tail_call_varargs):
2630         (JSC::JIT::emitSlow_op_construct_varargs):
2631         * jit/JITCall32_64.cpp:
2632         (JSC::JIT::emitSlow_op_call):
2633         (JSC::JIT::emitSlow_op_tail_call):
2634         (JSC::JIT::emitSlow_op_call_eval):
2635         (JSC::JIT::emitSlow_op_call_varargs):
2636         (JSC::JIT::emitSlow_op_tail_call_varargs):
2637         (JSC::JIT::emitSlow_op_construct_varargs):
2638         (JSC::JIT::emit_op_call):
2639         (JSC::JIT::emit_op_tail_call):
2640         (JSC::JIT::emit_op_call_eval):
2641         (JSC::JIT::emit_op_call_varargs):
2642         (JSC::JIT::emit_op_tail_call_varargs):
2643         (JSC::JIT::emit_op_construct_varargs):
2644         (JSC::JIT::compileOpCall):
2645         (JSC::JIT::compileOpCallSlowCase):
2646         * jit/JITInlines.h:
2647         (JSC::JIT::emitNakedCall):
2648         (JSC::JIT::emitNakedTailCall):
2649         (JSC::JIT::updateTopCallFrame):
2650         * jit/JITOperations.cpp:
2651         * jit/JITOperations.h:
2652         * jit/Repatch.cpp:
2653         (JSC::linkVirtualFor):
2654         (JSC::linkPolymorphicCall):
2655         * jit/ThunkGenerators.cpp:
2656         (JSC::throwExceptionFromCallSlowPathGenerator):
2657         (JSC::slowPathFor):
2658         (JSC::linkCallThunkGenerator):
2659         (JSC::virtualThunkFor):
2660         (JSC::arityFixupGenerator):
2661         (JSC::unreachableGenerator):
2662         (JSC::baselineGetterReturnThunkGenerator):
2663         * jit/ThunkGenerators.h:
2664         * llint/LowLevelInterpreter.asm:
2665         * llint/LowLevelInterpreter32_64.asm:
2666         * llint/LowLevelInterpreter64.asm:
2667         * runtime/CommonSlowPaths.h:
2668         (JSC::CommonSlowPaths::arityCheckFor):
2669         (JSC::CommonSlowPaths::opIn):
2670         * runtime/Options.h:
2671         * tests/stress/mutual-tail-call-no-stack-overflow.js: Added.
2672         (shouldThrow):
2673         (sloppyCountdown.even):
2674         (sloppyCountdown.odd):
2675         (strictCountdown.even):
2676         (strictCountdown.odd):
2677         (strictCountdown):
2678         (odd):
2679         (even):
2680         * tests/stress/tail-call-no-stack-overflow.js: Added.
2681         (shouldThrow):
2682         (strictLoop):
2683         (strictLoopArityFixup1):
2684         (strictLoopArityFixup2):
2685         * tests/stress/tail-call-recognize.js: Added.
2686         (callerMustBeRun):
2687         (callerMustBeStrict):
2688         (runTests):
2689         * tests/stress/tail-call-varargs-no-stack-overflow.js: Added.
2690         (shouldThrow):
2691         (strictLoop):
2692         * tests/stress/tail-calls-dont-overwrite-live-stack.js: Added.
2693         (tail):
2694         (obj.method):
2695         (obj.get fromNative):
2696         (getThis):
2697
2698 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
2699
2700         LLInt get/put inline caches shouldn't use tons of opcodes
2701         https://bugs.webkit.org/show_bug.cgi?id=149106
2702
2703         Reviewed by Geoffrey Garen.
2704
2705         Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
2706         example, instead of having get_by_id branch on the kind of offset (inline or
2707         out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
2708         But the problem with this approach is that it doesn't scale. In the property type
2709         inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
2710         inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
2711         new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
2712         checks, we'd have 6 * 11 = 66 variants of put_by_id).
2713
2714         So, this patch completely changes the strategy to mostly using branching inside the
2715         opcode implementation. It's unlikely to have a performance effect. For example, the long
2716         road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
2717         and yet nobody noticed. The regression was because the inline cache was in terms of the
2718         structure, not the structure ID, so the code was doing a structure ID table lookup. If we
2719         didn't notice that, then we probably won't notice a couple new branches. (Also, this
2720         patch fixes that regression - the code no longer does such lookups except in the one
2721         unavoidable case in put_by_id transition chain checking.)
2722
2723         This patch also turns the isDirect operand of put_by_id into a flags field. I will use
2724         this flags field to encode the desired type check in bug 148610.
2725
2726         This patch has no effect on performance according to run-jsc-benchmarks.
2727
2728         Relanding this patch with LLInt fixes for non-x86. Previous attempts to fix non-x86 LLInt
2729         build also caused every 64-bit test to crash on every platform. So the patch got rolled
2730         out. This fixes the non-x86 LLInt build while also ensuring that 64-bit platforms don't
2731         crash.
2732
2733         * CMakeLists.txt:
2734         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2735         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2736         * JavaScriptCore.xcodeproj/project.pbxproj:
2737         * bytecode/BytecodeList.json:
2738         * bytecode/BytecodeUseDef.h:
2739         (JSC::computeUsesForBytecodeOffset):
2740         (JSC::computeDefsForBytecodeOffset):
2741         * bytecode/CodeBlock.cpp:
2742         (JSC::CodeBlock::printGetByIdOp):
2743         (JSC::CodeBlock::printGetByIdCacheStatus):
2744         (JSC::CodeBlock::printPutByIdCacheStatus):
2745         (JSC::CodeBlock::dumpBytecode):
2746         (JSC::CodeBlock::CodeBlock):
2747         (JSC::CodeBlock::propagateTransitions):
2748         (JSC::CodeBlock::finalizeLLIntInlineCaches):
2749         * bytecode/CodeBlock.h:
2750         * bytecode/GetByIdStatus.cpp:
2751         (JSC::GetByIdStatus::computeFromLLInt):
2752         * bytecode/Instruction.h:
2753         (JSC::Instruction::Instruction):
2754         * bytecode/PutByIdFlags.cpp: Added.
2755         (WTF::printInternal):
2756         * bytecode/PutByIdFlags.h: Added.
2757         * bytecode/PutByIdStatus.cpp:
2758         (JSC::PutByIdStatus::computeFromLLInt):
2759         * bytecode/UnlinkedCodeBlock.h:
2760         (JSC::UnlinkedInstruction::UnlinkedInstruction):
2761         * bytecompiler/BytecodeGenerator.cpp:
2762         (JSC::BytecodeGenerator::emitPutById):
2763         (JSC::BytecodeGenerator::emitDirectPutById):
2764         * dfg/DFGByteCodeParser.cpp:
2765         (JSC::DFG::ByteCodeParser::parseBlock):
2766         * dfg/DFGCapabilities.cpp:
2767         (JSC::DFG::capabilityLevel):
2768         * jit/JIT.cpp:
2769         (JSC::JIT::privateCompileMainPass):
2770         (JSC::JIT::privateCompileSlowCases):
2771         * jit/JITPropertyAccess.cpp:
2772         (JSC::JIT::emit_op_put_by_id):
2773         * jit/JITPropertyAccess32_64.cpp:
2774         (JSC::JIT::emit_op_put_by_id):
2775         * llint/LLIntSlowPaths.cpp:
2776         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2777         * llint/LowLevelInterpreter32_64.asm:
2778         * llint/LowLevelInterpreter64.asm:
2779
2780 2015-09-14  Commit Queue  <commit-queue@webkit.org>
2781
2782         Unreviewed, rolling out r189751, r189752, and r189754.
2783         https://bugs.webkit.org/show_bug.cgi?id=149143
2784
2785         caused crashes everywhere (Requested by alexchristensen on
2786         #webkit).
2787
2788         Reverted changesets:
2789
2790         "LLInt get/put inline caches shouldn't use tons of opcodes"
2791         https://bugs.webkit.org/show_bug.cgi?id=149106
2792         http://trac.webkit.org/changeset/189751
2793
2794         "Unreviewed, fix non-x86 LLInt build."
2795         http://trac.webkit.org/changeset/189752
2796
2797         "Unreviewed, really fix non-x86 LLInt build without also
2798         breaking everything else."
2799         http://trac.webkit.org/changeset/189754
2800
2801 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
2802
2803         Unreviewed, really fix non-x86 LLInt build without also breaking everything else.
2804
2805         * llint/LowLevelInterpreter64.asm:
2806
2807 2015-09-14  Filip Pizlo  <fpizlo@apple.com>
2808
2809         Unreviewed, fix non-x86 LLInt build.
2810
2811         * llint/LowLevelInterpreter64.asm:
2812
2813 2015-09-13  Filip Pizlo  <fpizlo@apple.com>
2814
2815         LLInt get/put inline caches shouldn't use tons of opcodes
2816         https://bugs.webkit.org/show_bug.cgi?id=149106
2817
2818         Reviewed by Geoffrey Garen.
2819
2820         Our LLInt get/put inline caches currently use separate opcodes to reduce branching. For
2821         example, instead of having get_by_id branch on the kind of offset (inline or
2822         out-of-line), we have two get_by_id instructions: get_by_id and get_by_id_out_of_line.
2823         But the problem with this approach is that it doesn't scale. In the property type
2824         inference work (https://bugs.webkit.org/show_bug.cgi?id=148610), we need each kind of put
2825         inline cache to support 11 different kinds of type checks. It seemed ridiculous to add 60
2826         new put_by_id opcodes (there are currently 6 variants of put_by_id, so after adding type
2827         checks, we'd have 6 * 11 = 66 variants of put_by_id).
2828
2829         So, this patch completely changes the strategy to mostly using branching inside the
2830         opcode implementation. It's unlikely to have a performance effect. For example, the long
2831         road to generational GC caused a seemingly prohibitive regression in LLInt inline caches,
2832         and yet nobody noticed. The regression was because the inline cache was in terms of the
2833         structure, not the structure ID, so the code was doing a structure ID table lookup. If we
2834         didn't notice that, then we probably won't notice a couple new branches. (Also, this
2835         patch fixes that regression - the code no longer does such lookups except in the one
2836         unavoidable case in put_by_id transition chain checking.)
2837
2838         This patch also turns the isDirect operand of put_by_id into a flags field. I will use
2839         this flags field to encode the desired type check in bug 148610.
2840
2841         This patch has no effect on performance according to run-jsc-benchmarks.
2842
2843         * CMakeLists.txt:
2844         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2845         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2846         * JavaScriptCore.xcodeproj/project.pbxproj:
2847         * bytecode/BytecodeList.json:
2848         * bytecode/BytecodeUseDef.h:
2849         (JSC::computeUsesForBytecodeOffset):
2850         (JSC::computeDefsForBytecodeOffset):
2851         * bytecode/CodeBlock.cpp:
2852         (JSC::CodeBlock::printGetByIdOp):
2853         (JSC::CodeBlock::printGetByIdCacheStatus):
2854         (JSC::CodeBlock::printPutByIdCacheStatus):
2855         (JSC::CodeBlock::dumpBytecode):
2856         (JSC::CodeBlock::CodeBlock):
2857         (JSC::CodeBlock::propagateTransitions):
2858         (JSC::CodeBlock::finalizeLLIntInlineCaches):
2859         * bytecode/CodeBlock.h:
2860         * bytecode/GetByIdStatus.cpp:
2861         (JSC::GetByIdStatus::computeFromLLInt):
2862         * bytecode/Instruction.h:
2863         (JSC::Instruction::Instruction):
2864         * bytecode/PutByIdFlags.cpp: Added.
2865         (WTF::printInternal):
2866         * bytecode/PutByIdFlags.h: Added.
2867         * bytecode/PutByIdStatus.cpp:
2868         (JSC::PutByIdStatus::computeFromLLInt):
2869         * bytecode/UnlinkedCodeBlock.h:
2870         (JSC::UnlinkedInstruction::UnlinkedInstruction):
2871         * bytecompiler/BytecodeGenerator.cpp:
2872         (JSC::BytecodeGenerator::emitPutById):
2873         (JSC::BytecodeGenerator::emitDirectPutById):
2874         * dfg/DFGAbstractInterpreterInlines.h:
2875         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2876         * dfg/DFGByteCodeParser.cpp:
2877         (JSC::DFG::ByteCodeParser::parseBlock):
2878         * dfg/DFGCapabilities.cpp:
2879         (JSC::DFG::capabilityLevel):
2880         * jit/JIT.cpp:
2881         (JSC::JIT::privateCompileMainPass):
2882         (JSC::JIT::privateCompileSlowCases):
2883         * jit/JITPropertyAccess.cpp:
2884         (JSC::JIT::emit_op_put_by_id):
2885         * jit/JITPropertyAccess32_64.cpp:
2886         (JSC::JIT::emit_op_put_by_id):
2887         * llint/LLIntSlowPaths.cpp:
2888         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2889         * llint/LowLevelInterpreter32_64.asm:
2890         * llint/LowLevelInterpreter64.asm:
2891
2892 2015-09-14  Alex Christensen  <achristensen@webkit.org>
2893
2894         Progress towards CMake on Mac.
2895         https://bugs.webkit.org/show_bug.cgi?id=149123
2896
2897         Reviewed by Chris Dumez.
2898
2899         * CMakeLists.txt:
2900         Make forwarding headers for the replay subdirectory.
2901         * PlatformMac.cmake:
2902         Make forwarding headers for the generated inspector headers. 
2903         They should eventually either be packaged correctly with JavaScriptCore headers and included correctly.
2904
2905 2015-09-14  Yusuke Suzuki  <utatane.tea@gmail.com>
2906
2907         [ES6] Cache the resolution result in JSModuleRecord
2908         https://bugs.webkit.org/show_bug.cgi?id=148896
2909
2910         Reviewed by Saam Barati.
2911
2912         The resolveExport operation is frequently called. For example,
2913         1. When instantiating the module environment, we call it for each exported name and imported
2914            name.
2915         2. When linking the imported module environment to the code block, we call it to resolve the
2916            resolution.
2917         3. When looking up the property from the namespace object, we call it to look up the original
2918            module for the imported binding.
2919         4. When creating the namespace object, we need to collect all the exported names from the module
2920            and need to resolve them by calling resolveExport.
2921
2922         However, resolveExport takes some cost. It traces the imported modules and resolves the reference
2923         queried by the original module.
2924
2925         The resolveExport operation is pure function; given a module record and an export name,
2926         it always returns the same result. So we cache resolution results in the module record to avoid
2927         repeated resolveExport calls with the same arguments.
2928         Here, we only cache the correctly resolved references, since,
2929         1. We rarely looked up the non-correctly-resolved ones. In the linking phase, attempting to
2930            resolve non-correctly-resolved ones throws a syntax error. So only namespace object creation
2931            phase does it in a syntax valid script.
2932         2. This strategy limits the size of the cache map. The number of the correctly exported bindings
2933            is defined by the modules' code. So the size does not become infinitely large.
2934
2935         Currently, the all modules cannot be linked twice. For example,
2936
2937           graph 1
2938
2939           -> (A) -> (B)
2940
2941           graph 2
2942
2943           -> (C) -> (A) -> (B)
2944
2945         We cannot test the behavior now because when executing the graph 2, (A) and (B) are already linked,
2946         it raises an error in the current loader spec. But it should be allowed[1] since it will occur when
2947         there is multiple module tag in WebCore.
2948
2949         [1]: https://github.com/whatwg/loader/issues/41
2950
2951         * runtime/JSModuleRecord.cpp:
2952         (JSC::JSModuleRecord::ResolveQuery::Hash::hash):
2953         (JSC::JSModuleRecord::ResolveQuery::Hash::equal):
2954         (JSC::JSModuleRecord::cacheResolution):
2955         (JSC::ResolveQueryHash::hash): Deleted.
2956         (JSC::ResolveQueryHash::equal): Deleted.
2957         (JSC::resolveExportLoop): Deleted.
2958         * runtime/JSModuleRecord.h:
2959         * tests/modules/caching-should-not-make-ambiguous.js: Added.
2960         * tests/modules/caching-should-not-make-ambiguous/A.js: Added.
2961         * tests/modules/caching-should-not-make-ambiguous/B.js: Added.
2962         * tests/modules/caching-should-not-make-ambiguous/C.js: Added.
2963         * tests/modules/caching-should-not-make-ambiguous/D.js: Added.
2964         * tests/modules/caching-should-not-make-ambiguous/main.js: Added.
2965         * tests/modules/different-view.js: Added.
2966         (from.string_appeared_here.shouldThrow):
2967         * tests/modules/different-view/A.js: Added.
2968         * tests/modules/different-view/B.js: Added.
2969         * tests/modules/different-view/C.js: Added.
2970         * tests/modules/different-view/D.js: Added.
2971         * tests/modules/different-view/E.js: Added.
2972         * tests/modules/different-view/main.js: Added.
2973         * tests/modules/fallback-ambiguous.js: Added.
2974         (from.string_appeared_here.shouldThrow):
2975         * tests/modules/fallback-ambiguous/A.js: Added.
2976         * tests/modules/fallback-ambiguous/B.js: Added.
2977         * tests/modules/fallback-ambiguous/C.js: Added.
2978         * tests/modules/fallback-ambiguous/D.js: Added.
2979         * tests/modules/fallback-ambiguous/E.js: Added.
2980         * tests/modules/fallback-ambiguous/main.js: Added.
2981         * tests/modules/self-star-link.js: Added.
2982         * tests/modules/self-star-link/A.js: Added.
2983         * tests/modules/self-star-link/B.js: Added.
2984         * tests/modules/self-star-link/C.js: Added.
2985         * tests/modules/self-star-link/D.js: Added.
2986         * tests/modules/self-star-link/E.js: Added.
2987         * tests/modules/uncacheable-when-see-star.js: Added.
2988         * tests/modules/uncacheable-when-see-star/A-pre.js: Added.
2989         * tests/modules/uncacheable-when-see-star/A.js: Added.
2990         * tests/modules/uncacheable-when-see-star/B.js: Added.
2991         * tests/modules/uncacheable-when-see-star/C.js: Added.
2992         * tests/modules/uncacheable-when-see-star/D.js: Added.
2993         * tests/modules/uncacheable-when-see-star/E-pre.js: Added.
2994         * tests/modules/uncacheable-when-see-star/E.js: Added.
2995         * tests/modules/uncacheable-when-see-star/main1.js: Added.
2996         * tests/modules/uncacheable-when-see-star/main2.js: Added.
2997
2998 2015-09-14  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2999
3000         Implement the arithmetic instructions for floats in WebAssembly
3001         https://bugs.webkit.org/show_bug.cgi?id=149102
3002
3003         Reviewed by Geoffrey Garen.
3004
3005         This patch implements the arithmetic instructions for floats (float32)
3006         in WebAssembly by converting the float operands to doubles, performing
3007         the equivalent double instructions, and converting the result back to
3008         float. The asm.js spec says that "As proved in 'When is double rounding
3009         innocuous?' (Figueroa 1995), both the 32- and 64-bit versions of
3010         standard arithmetic operations produce equivalent results when given
3011         32-bit inputs and coerced to 32-bit outputs."
3012         (http://asmjs.org/spec/latest/#floatish)
3013
3014         This patch also pads WebAssembly call frames by maxFrameExtentForSlowPathCall,
3015         so that there is no need to adjust the stack pointer every time we make
3016         a slow path call.
3017
3018         * tests/stress/wasm-arithmetic-float32.js:
3019         * tests/stress/wasm/arithmetic-float32.wasm:
3020         * wasm/WASMFunctionCompiler.h:
3021         (JSC::WASMFunctionCompiler::startFunction):
3022         (JSC::WASMFunctionCompiler::buildUnaryF32):
3023         (JSC::WASMFunctionCompiler::buildBinaryF32):
3024         (JSC::WASMFunctionCompiler::callOperation):
3025         (JSC::WASMFunctionCompiler::callAndUnboxResult):
3026         (JSC::WASMFunctionCompiler::endFunction): Deleted.
3027         (JSC::WASMFunctionCompiler::buildBinaryI32): Deleted.
3028         * wasm/WASMFunctionParser.cpp:
3029         (JSC::WASMFunctionParser::parseExpressionF32):
3030         (JSC::WASMFunctionParser::parseUnaryExpressionF32):
3031         (JSC::WASMFunctionParser::parseBinaryExpressionF32):
3032         * wasm/WASMFunctionParser.h:
3033         * wasm/WASMFunctionSyntaxChecker.h:
3034         (JSC::WASMFunctionSyntaxChecker::buildUnaryF32):
3035         (JSC::WASMFunctionSyntaxChecker::buildBinaryF32):
3036
3037 2015-09-13  Geoffrey Garen  <ggaren@apple.com>
3038
3039         Eden GC should not try to jettison old CodeBlocks in the remembered set
3040         https://bugs.webkit.org/show_bug.cgi?id=149108
3041
3042         Reviewed by Saam Barati.
3043
3044         All we know about objects in the remembered set is that they must be
3045         visited. We don't know whether they're referenced or not because we
3046         won't mark the objects that point to them.
3047
3048         Therefore, it's incorrect for a CodeBlock to consider jettisoning
3049         itself when it's marked as a part of the remembered set: Some
3050         old object might have visited the CodeBlock strongly if given the chance.
3051
3052         I believe this doesn't cause any problems currently because we happen
3053         to visit all strong references to all CodeBlocks elligible for jettison
3054         during every GC.
3055
3056         However, this behavior is a logical oddity that tripped me up, and I
3057         believe it will start causing real problems once we start to jettison
3058         baseline CodeBlocks, since we do not visit all strong references to all
3059         baseline CodeBlocks during every GC.
3060
3061         * heap/CodeBlockSet.cpp:
3062         (JSC::CodeBlockSet::clearMarksForEdenCollection):
3063         (JSC::CodeBlockSet::traceMarked): Be sure to visit the remembered set
3064         strongly, in order to prohibit jettisoning.
3065
3066         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
3067         * heap/CodeBlockSet.h: Track the remembered set during eden GCs.
3068
3069 2015-09-11  Filip Pizlo  <fpizlo@apple.com>
3070
3071         REGRESSION(r189585): run-perf-tests Speedometer fails with a console error
3072         https://bugs.webkit.org/show_bug.cgi?id=149066
3073
3074         Reviewed by Michael Saboff.
3075
3076         The bug here was that the new IC code was calling actionForCell() more than once. That's
3077         illegal, since when actionForCell() returns RetryCacheLater, it means that it changed some
3078         object's Structure. The Repatch code was doing things like "if (actionForCell(blah) ==
3079         AttemptToCache)" in more than one place, so that if the first such expression was false, then
3080         we'd fall through to the next one. It's possible for the first call to return RetryCacheLater,
3081         in which case our view of the world just got clobbered and we need to return, and then the
3082         second call will probably return AttemptToCache because it *thinks* that we had bailed the last
3083         time and we're now in a future IC invocation.
3084
3085         The solution is to cache the actionForCell() result. This is a bit tricky, because we need to
3086         do this after we check if we're in a proxy.
3087
3088         Debugging bugs like these requires adding ad hoc bisection code in various places. We already
3089         had the basic hooks for this. This patch makes those hooks a bit more useful. In the case of
3090         the LLInt->JIT tier-up hooks, it adds a CodeBlock* argument so that we can bisect based on the
3091         CodeBlock. In the case of Repatch, it puts the Options::forceICFailure() check in a helper
3092         function that also takes ExecState*, which allows us to bisect on either CodeBlock or
3093         CodeOrigin.
3094
3095         * jit/Repatch.cpp:
3096         (JSC::actionForCell):
3097         (JSC::forceICFailure):
3098         (JSC::tryCacheGetByID):
3099         (JSC::tryCachePutByID):
3100         (JSC::tryRepatchIn):
3101         * llint/LLIntSlowPaths.cpp:
3102         (JSC::LLInt::shouldJIT):
3103         (JSC::LLInt::jitCompileAndSetHeuristics):
3104         (JSC::LLInt::entryOSR):
3105         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3106         * tests/stress/retry-cache-later.js:
3107
3108 2015-09-11  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3109
3110         Implement the relational instructions for floats in WebAssembly
3111         https://bugs.webkit.org/show_bug.cgi?id=149080
3112
3113         Reviewed by Geoffrey Garen.
3114
3115         This patch implements the relational instructions for floats (float32)
3116         in WebAssembly by converting float operands to doubles and then
3117         comparing them using the existing double comparison instructions in the
3118         macro assembler.
3119
3120         * tests/stress/wasm-relational.js:
3121         * tests/stress/wasm/relational.wasm:
3122         * wasm/WASMFunctionCompiler.h:
3123         (JSC::WASMFunctionCompiler::buildRelationalF32):
3124         * wasm/WASMFunctionParser.cpp:
3125         (JSC::WASMFunctionParser::parseExpressionI32):
3126         (JSC::WASMFunctionParser::parseRelationalF32ExpressionI32):
3127         * wasm/WASMFunctionParser.h:
3128         * wasm/WASMFunctionSyntaxChecker.h:
3129         (JSC::WASMFunctionSyntaxChecker::buildRelationalF32):
3130
3131 2015-09-11  Nan Wang  <n_wang@apple.com>
3132
3133         AX: ARIA 1.1 @aria-current
3134         https://bugs.webkit.org/show_bug.cgi?id=146012
3135
3136         Reviewed by Chris Fleizach.
3137
3138         Updated inspector to support aria-current.
3139
3140         * inspector/protocol/DOM.json:
3141
3142 2015-09-11  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3143
3144         Add initial support for floats in WebAsssembly
3145         https://bugs.webkit.org/show_bug.cgi?id=149062
3146
3147         Reviewed by Geoffrey Garen.
3148
3149         Implement the ConstantPoolIndex, Immediate, GetLocal, and GetGlobal
3150         instructions for floats (float32) in WebAssembly.
3151
3152         * tests/stress/wasm-arithmetic-float32.js: Added.
3153         (shouldBe):
3154         * tests/stress/wasm-globals.js:
3155         * tests/stress/wasm-type-conversion.js:
3156         * tests/stress/wasm/arithmetic-float32.wasm: Added.
3157         * tests/stress/wasm/globals.wasm:
3158         * tests/stress/wasm/type-conversion.wasm:
3159         * wasm/WASMConstants.h:
3160         * wasm/WASMFunctionCompiler.h:
3161         (JSC::WASMFunctionCompiler::buildSetLocal):
3162         (JSC::WASMFunctionCompiler::buildReturn):
3163         (JSC::WASMFunctionCompiler::buildImmediateF32):
3164         (JSC::WASMFunctionCompiler::buildGetLocal):
3165         * wasm/WASMFunctionParser.cpp:
3166         (JSC::WASMFunctionParser::parseExpression):
3167         (JSC::WASMFunctionParser::parseExpressionF32):
3168         (JSC::WASMFunctionParser::parseConstantPoolIndexExpressionF32):
3169         (JSC::WASMFunctionParser::parseImmediateExpressionF32):
3170         (JSC::WASMFunctionParser::parseGetLocalExpressionF32):
3171         (JSC::WASMFunctionParser::parseGetGlobalExpressionF32):
3172         * wasm/WASMFunctionParser.h:
3173         * wasm/WASMFunctionSyntaxChecker.h:
3174         (JSC::WASMFunctionSyntaxChecker::buildImmediateF32):
3175         * wasm/WASMReader.cpp:
3176         (JSC::WASMReader::readOpExpressionF32):
3177         * wasm/WASMReader.h:
3178
3179 2015-09-11  Geoffrey Garen  <ggaren@apple.com>
3180
3181         Try to fix the CLOOP build.
3182
3183         Unreviewed.
3184
3185         * bytecode/CodeBlock.cpp:
3186         (JSC::CodeBlock::finalizeBaselineJITInlineCaches):
3187         (JSC::CodeBlock::finalizeUnconditionally):
3188
3189 2015-09-11  Csaba Osztrogon√°c  <ossy@webkit.org>
3190
3191         [EFL] Fix WASM build
3192         https://bugs.webkit.org/show_bug.cgi?id=149065
3193
3194         Reviewed by Darin Adler.
3195
3196         * wasm/WASMFunctionParser.cpp:
3197
3198 2015-09-11  Geoffrey Garen  <ggaren@apple.com>
3199
3200         JavaScriptCore should discard optimized code after some time
3201         https://bugs.webkit.org/show_bug.cgi?id=149048
3202
3203         Reviewed by Michael Saboff.
3204
3205         This patch adds a new jettison type -- JettisonDueToOldAge -- and starts
3206         using it for DFG and FTL code. Baseline and LLInt code will come in a
3207         follow-up patch.
3208
3209         The primary goal is to save memory. Some popular websites leave about 10MB
3210         of dead code sitting around immediately after they finish loading.
3211
3212         Throwing away code periodically might also save us from profiling
3213         pathologies that lead to performance dead ends.
3214
3215         * bytecode/CodeBlock.cpp:
3216         (JSC::CodeBlock::visitAggregate): Updated for rename, and removed a
3217         stale comment.
3218
3219         (JSC::CodeBlock::shouldVisitStrongly): Renamed to shouldVisitStrongly
3220         because the practical effect of this function is to trigger a call to
3221         visitStrongly.
3222
3223         (JSC::CodeBlock::isKnownToBeLiveDuringGC): Check the
3224         m_visitStronglyHasBeenCalled flag instead of
3225         shouldImmediatelyAssumeLivenessDuringScan / shouldVisitStrongly because
3226         m_visitStronglyHasBeenCalled can be set by anybody even if the CodeBlock
3227         would not otherwise visit itself strongly.
3228
3229         (JSC::CodeBlock::shouldJettisonDueToWeakReference): New helper function
3230         for readability.
3231
3232         (JSC::CodeBlock::shouldJettisonDueToOldAge): New helper function that
3233         tells if a CodeBlock is old enough for deletion.
3234
3235         (JSC::CodeBlock::determineLiveness): There's no need to check
3236         shouldImmediatelyAssumeLivenessDuringScan here because we will not call
3237         this function if shouldImmediatelyAssumeLivenessDuringScan is true.
3238         Also, it's just not clear -- if someone chooses to call this function --
3239         that it would be safe to ignore them simply because
3240         shouldImmediatelyAssumeLivenessDuringScan was true.
3241
3242         (JSC::CodeBlock::finalizeLLIntInlineCaches): Moved code out into a helper
3243         function to make the main function more readable.
3244
3245         (JSC::CodeBlock::finalizeBaselineJITInlineCaches): Ditto.
3246
3247         (JSC::CodeBlock::finalizeUnconditionally): Added code for jettisoning a
3248         CodeBlock if it is too old. Moved large sections of code into helper
3249         functions to aid readability in this function.
3250
3251         (JSC::CodeBlock::jettison): Account for the fact that we might jettison
3252         a CodeBlock without OSR exit and without requiring a stack shoot-down.
3253
3254         * bytecode/CodeBlock.h:
3255         (JSC::CodeBlock::setInstallTime):
3256         (JSC::CodeBlock::timeSinceInstall): Track CodeBlock age to help us
3257         decide when to delete.
3258
3259         * jit/JITCode.h:
3260         (JSC::JITCode::timeToLive): Static limits on CodeBlock lifetime. I got
3261         these numbers from the place where numbers come from. 
3262
3263         * profiler/ProfilerJettisonReason.cpp:
3264         (WTF::printInternal):
3265         * profiler/ProfilerJettisonReason.h: Updated for new jettison type.
3266
3267         * runtime/Executable.cpp:
3268         (JSC::ScriptExecutable::installCode): Record install time so that we
3269         can measure how old a CodeBlock is.
3270
3271 2015-09-11  Andreas Kling  <akling@apple.com>
3272
3273         [JSC] Weak should only accept cell pointees.
3274         <https://webkit.org/b/148955>
3275
3276         Reviewed by Geoffrey Garen.
3277
3278         Since WeakImpls only support pointing to JSCell derived objects,
3279         enforce that at compile time by having the API use JSCell* instead of JSValue.
3280
3281         WeakHandleOwner callbacks now get JSCell& and JSCell*& respectively instead
3282         of wrapping the cell pointer in a Handle<Unknown>.
3283
3284         Also added a static_assert so Weak<T> can't be instantiated with a T that's
3285         not convertible to JSCell.
3286
3287         * API/JSAPIWrapperObject.mm:
3288         (JSAPIWrapperObjectHandleOwner::finalize):
3289         (JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
3290         (JSC::JSAPIWrapperObject::finishCreation):
3291         * API/JSManagedValue.mm:
3292         (JSManagedValueHandleOwner::isReachableFromOpaqueRoots):
3293         (JSManagedValueHandleOwner::finalize):
3294         * builtins/BuiltinExecutables.cpp:
3295         (JSC::BuiltinExecutables::finalize):
3296         * builtins/BuiltinExecutables.h:
3297         * heap/Heap.cpp:
3298         (JSC::Heap::addFinalizer):
3299         (JSC::Heap::FinalizerOwner::finalize):
3300         * heap/Heap.h:
3301         * heap/WeakBlock.cpp:
3302         (JSC::WeakBlock::visit):
3303         (JSC::WeakBlock::reap):
3304         * heap/WeakHandleOwner.cpp:
3305         (JSC::WeakHandleOwner::isReachableFromOpaqueRoots):
3306         (JSC::WeakHandleOwner::finalize):
3307         * heap/WeakHandleOwner.h:
3308         * heap/WeakImpl.h:
3309         (JSC::WeakImpl::WeakImpl):
3310         (JSC::WeakImpl::state):
3311         (JSC::WeakImpl::cell):
3312         (JSC::WeakImpl::asWeakImpl):
3313         (JSC::WeakImpl::jsValue): Deleted.
3314         * heap/WeakInlines.h:
3315         (JSC::Weak<T>::Weak):
3316         (JSC::>):
3317         (JSC::Weak<T>::operator):
3318         (JSC::Weak<T>::get):
3319         (JSC::Weak<T>::was):
3320         * heap/WeakSet.h:
3321         * heap/WeakSetInlines.h:
3322         (JSC::WeakSet::allocate):
3323         (JSC::WeakBlock::finalize):
3324         * jit/JITThunks.cpp:
3325         (JSC::JITThunks::finalize):
3326         * jit/JITThunks.h:
3327         * jsc.cpp:
3328         (WTF::ElementHandleOwner::isReachableFromOpaqueRoots): Deleted.
3329         * runtime/JSCell.h:
3330         (JSC::jsCast):
3331         * runtime/RegExpCache.cpp:
3332         (JSC::RegExpCache::finalize):