dfa69208c676e8ce3b61f8bbfd459a47bf4cc88b
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-10-08  Commit Queue  <commit-queue@webkit.org>
2
3         Unreviewed, rolling out r190716.
4         https://bugs.webkit.org/show_bug.cgi?id=149924
5
6         broke mac build from time to time (Requested by youenn on
7         #webkit).
8
9         Reverted changeset:
10
11         "Automate WebCore JS builtins generation and build system"
12         https://bugs.webkit.org/show_bug.cgi?id=149751
13         http://trac.webkit.org/changeset/190716
14
15 2015-10-08  Csaba Osztrogonác  <ossy@webkit.org>
16
17         Fix the WASM build on Linux
18         https://bugs.webkit.org/show_bug.cgi?id=149919
19
20         Reviewed by Mark Lam.
21
22         * inspector/ScriptCallStackFactory.cpp:
23         * wasm/JSWASMModule.cpp:
24         * wasm/WASMFunctionCompiler.h:
25         (JSC::sizeOfMemoryType):
26         * wasm/WASMFunctionLLVMIRGenerator.h:
27
28 2015-10-08  Csaba Osztrogonác  <ossy@webkit.org>
29
30         Unreviewed CLOOP buildfix after r190718.
31
32         * jit/Repatch.h:
33         (JSC::resetGetByID): Deleted.
34         (JSC::resetPutByID): Deleted.
35         (JSC::resetIn): Deleted.
36
37 2015-10-08  Joseph Pecoraro  <pecoraro@apple.com>
38
39         Remove references to removed class RepatchBuffer
40         https://bugs.webkit.org/show_bug.cgi?id=149909
41
42         Reviewed by Csaba Osztrogonác.
43
44         * assembler/AbstractMacroAssembler.h:
45         * assembler/MacroAssemblerARM.h:
46         * assembler/MacroAssemblerARM64.h:
47         * assembler/MacroAssemblerARMv7.h:
48         * assembler/MacroAssemblerMIPS.h:
49         * assembler/MacroAssemblerSH4.h:
50         * assembler/MacroAssemblerX86.h:
51         * assembler/MacroAssemblerX86_64.h:
52         * jit/JITStubRoutine.h:
53         * jit/Repatch.h:
54
55 2015-10-08  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>
56
57         Automate WebCore JS builtins generation and build system
58         https://bugs.webkit.org/show_bug.cgi?id=149751
59
60         Reviewed by Darin Adler.
61
62         * generate-js-builtins: updating the part related to WebCore JS binding.
63
64 2015-10-07  Joseph Pecoraro  <pecoraro@apple.com>
65
66         Clean up Copied classes
67         https://bugs.webkit.org/show_bug.cgi?id=149863
68
69         Reviewed by Saam Barati.
70
71         * heap/CopiedAllocator.h:
72         (JSC::CopiedAllocator::isValid):
73         * heap/CopiedBlock.h:
74         * heap/CopiedBlockInlines.h:
75         * heap/CopiedSpace.cpp:
76         * heap/CopiedSpace.h:
77         (JSC::CopiedSpace::isInCopyPhase):
78         (JSC::CopiedSpace::shouldDoCopyPhase):
79         * heap/CopiedSpaceInlines.h:
80         * heap/CopyToken.h:
81         * heap/CopyVisitor.cpp:
82         * heap/CopyVisitor.h:
83         * heap/CopyVisitorInlines.h:
84         * heap/CopyWorkList.h:
85         * heap/HandleBlock.h:
86         * heap/HandleSet.h:
87         * heap/HeapHelperPool.cpp:
88         * heap/HeapHelperPool.h:
89
90 2015-10-07  Mark Lam  <mark.lam@apple.com>
91
92         [Follow up 2] Disable tail calls because it is breaking some sites.
93         https://bugs.webkit.org/show_bug.cgi?id=149900
94
95         Rubber stamped by Saam Barati.
96
97         Also need to surpress JSC tail call tests.
98
99         * tests/es6.yaml:
100         * tests/stress/dfg-tail-calls.js:
101         (nonInlinedTailCall.callee):
102         * tests/stress/mutual-tail-call-no-stack-overflow.js:
103         (shouldThrow):
104         * tests/stress/tail-call-in-inline-cache.js:
105         (tail):
106         * tests/stress/tail-call-no-stack-overflow.js:
107         (shouldThrow):
108         * tests/stress/tail-call-recognize.js:
109         (callerMustBeRun):
110         * tests/stress/tail-call-varargs-no-stack-overflow.js:
111         (shouldThrow):
112
113 2015-10-07  Geoffrey Garen  <ggaren@apple.com>
114
115         Unreviewed, rolling back in r190450
116         https://bugs.webkit.org/show_bug.cgi?id=149727
117
118         This time for sure?
119
120         The cause of the leak was an invalidated compilation.
121
122         There was vestigial manual memory management code that eagerly removed
123         a CodeBlock from the set of CodeBlocks if compilation was invalidated.
124         That's not cool since we rely on the set of CodeBlocks when we run
125         destructors.
126
127         The fix is to remove the vestigial code.
128
129         I ran the leaks, correctness, and performance tests locally and did not
130         see any problems.
131
132         Restored changesets:
133
134         "CodeBlock should be a GC object"
135         https://bugs.webkit.org/show_bug.cgi?id=149727
136         http://trac.webkit.org/changeset/190450
137
138 2015-10-07  Mark Lam  <mark.lam@apple.com>
139
140         Disable tail calls because it is breaking some sites.
141         https://bugs.webkit.org/show_bug.cgi?id=149900
142
143         Reviewed by Saam Barati.
144
145         This is until we fix whatever the breakage is.
146
147         * runtime/Options.h:
148
149 2015-10-07  Sukolsak Sakshuwong  <sukolsak@gmail.com>
150
151         Add an LLVM IR generator for WebAssembly
152         https://bugs.webkit.org/show_bug.cgi?id=149486
153
154         Reviewed by Mark Lam.
155
156         This patch adds initial support for an LLVM IR generator in WebAssembly
157         (polyfill-prototype-1 format). All the methods will be implemented in
158         subsequent patches.
159
160         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
161         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
162         * JavaScriptCore.xcodeproj/project.pbxproj:
163         * wasm/WASMFunctionLLVMIRGenerator.h: Added.
164         (JSC::WASMFunctionLLVMIRGenerator::MemoryAddress::MemoryAddress):
165         (JSC::WASMFunctionLLVMIRGenerator::startFunction):
166         (JSC::WASMFunctionLLVMIRGenerator::endFunction):
167         (JSC::WASMFunctionLLVMIRGenerator::buildSetLocal):
168         (JSC::WASMFunctionLLVMIRGenerator::buildSetGlobal):
169         (JSC::WASMFunctionLLVMIRGenerator::buildReturn):
170         (JSC::WASMFunctionLLVMIRGenerator::buildImmediateI32):
171         (JSC::WASMFunctionLLVMIRGenerator::buildImmediateF32):
172         (JSC::WASMFunctionLLVMIRGenerator::buildImmediateF64):
173         (JSC::WASMFunctionLLVMIRGenerator::buildGetLocal):
174         (JSC::WASMFunctionLLVMIRGenerator::buildGetGlobal):
175         (JSC::WASMFunctionLLVMIRGenerator::buildConvertType):
176         (JSC::WASMFunctionLLVMIRGenerator::buildLoad):
177         (JSC::WASMFunctionLLVMIRGenerator::buildStore):
178         (JSC::WASMFunctionLLVMIRGenerator::buildUnaryI32):
179         (JSC::WASMFunctionLLVMIRGenerator::buildUnaryF32):
180         (JSC::WASMFunctionLLVMIRGenerator::buildUnaryF64):
181         (JSC::WASMFunctionLLVMIRGenerator::buildBinaryI32):
182         (JSC::WASMFunctionLLVMIRGenerator::buildBinaryF32):
183         (JSC::WASMFunctionLLVMIRGenerator::buildBinaryF64):
184         (JSC::WASMFunctionLLVMIRGenerator::buildRelationalI32):
185         (JSC::WASMFunctionLLVMIRGenerator::buildRelationalF32):
186         (JSC::WASMFunctionLLVMIRGenerator::buildRelationalF64):
187         (JSC::WASMFunctionLLVMIRGenerator::buildMinOrMaxI32):
188         (JSC::WASMFunctionLLVMIRGenerator::buildMinOrMaxF64):
189         (JSC::WASMFunctionLLVMIRGenerator::buildCallInternal):
190         (JSC::WASMFunctionLLVMIRGenerator::buildCallIndirect):
191         (JSC::WASMFunctionLLVMIRGenerator::buildCallImport):
192         (JSC::WASMFunctionLLVMIRGenerator::appendExpressionList):
193         (JSC::WASMFunctionLLVMIRGenerator::discard):
194         (JSC::WASMFunctionLLVMIRGenerator::linkTarget):
195         (JSC::WASMFunctionLLVMIRGenerator::jumpToTarget):
196         (JSC::WASMFunctionLLVMIRGenerator::jumpToTargetIf):
197         (JSC::WASMFunctionLLVMIRGenerator::startLoop):
198         (JSC::WASMFunctionLLVMIRGenerator::endLoop):
199         (JSC::WASMFunctionLLVMIRGenerator::startSwitch):
200         (JSC::WASMFunctionLLVMIRGenerator::endSwitch):
201         (JSC::WASMFunctionLLVMIRGenerator::startLabel):
202         (JSC::WASMFunctionLLVMIRGenerator::endLabel):
203         (JSC::WASMFunctionLLVMIRGenerator::breakTarget):
204         (JSC::WASMFunctionLLVMIRGenerator::continueTarget):
205         (JSC::WASMFunctionLLVMIRGenerator::breakLabelTarget):
206         (JSC::WASMFunctionLLVMIRGenerator::continueLabelTarget):
207         (JSC::WASMFunctionLLVMIRGenerator::buildSwitch):
208         * wasm/WASMFunctionParser.cpp:
209
210 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
211
212         Get rid of LLInt inline/out-of-line storage helpers, they are unused
213         https://bugs.webkit.org/show_bug.cgi?id=149892
214
215         Reviewed by Mark Lam.
216
217         Just killing dead code.
218
219         * llint/LowLevelInterpreter.asm:
220
221 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
222
223         Don't setOutOfBounds in JIT code for PutByVal, since the C++ slow path already does it
224         https://bugs.webkit.org/show_bug.cgi?id=149885
225
226         Reviewed by Geoffrey Garen.
227
228         This simplifies the slow path code, which will make it easier to put read barriers on all of
229         the butterflies.
230
231         * jit/JITOperations.cpp:
232         (JSC::getByVal):
233         * jit/JITPropertyAccess.cpp:
234         (JSC::JIT::emitSlow_op_put_by_val):
235
236 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
237
238         Get rid of JIT::compilePutDirectOffset
239         https://bugs.webkit.org/show_bug.cgi?id=149884
240
241         Reviewed by Andreas Kling.
242
243         I'm finding more dead code.
244
245         * jit/JIT.h:
246         * jit/JITPropertyAccess.cpp:
247         (JSC::JIT::emitSlow_op_put_by_id):
248         (JSC::JIT::emitVarInjectionCheck):
249         (JSC::JIT::compilePutDirectOffset): Deleted.
250
251 2015-10-07  Joseph Pecoraro  <pecoraro@apple.com>
252
253         Heap::isWriteBarrierEnabled is unused
254         https://bugs.webkit.org/show_bug.cgi?id=149881
255
256         Reviewed by Geoffrey Garen.
257
258         * heap/Heap.h:
259         * heap/HeapInlines.h:
260         (JSC::Heap::isWriteBarrierEnabled): Deleted.
261
262 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
263
264         JIT::emitGetGlobalProperty/emitPutGlobalProperty are only called from one place
265         https://bugs.webkit.org/show_bug.cgi?id=149879
266
267         Reviewed by Saam Barati.
268
269         To simplify my work to insert barriers on loads of the butterfly, I want to reduce the amount
270         of abstraction we have around code that loads the butterfly.
271
272         * jit/JIT.h:
273         * jit/JITPropertyAccess.cpp:
274         (JSC::JIT::emitLoadWithStructureCheck):
275         (JSC::JIT::emitGetVarFromPointer):
276         (JSC::JIT::emit_op_get_from_scope):
277         (JSC::JIT::emitSlow_op_get_from_scope):
278         (JSC::JIT::emitPutGlobalVariable):
279         (JSC::JIT::emit_op_put_to_scope):
280         (JSC::JIT::emitGetGlobalProperty): Deleted.
281         (JSC::JIT::emitPutGlobalProperty): Deleted.
282         * jit/JITPropertyAccess32_64.cpp:
283         (JSC::JIT::emitLoadWithStructureCheck):
284         (JSC::JIT::emitGetVarFromPointer):
285         (JSC::JIT::emit_op_get_from_scope):
286         (JSC::JIT::emitSlow_op_get_from_scope):
287         (JSC::JIT::emitPutGlobalVariable):
288         (JSC::JIT::emit_op_put_to_scope):
289         (JSC::JIT::emitGetGlobalProperty): Deleted.
290         (JSC::JIT::emitPutGlobalProperty): Deleted.
291
292 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
293
294         JIT::compileGetDirectOffset is useless
295         https://bugs.webkit.org/show_bug.cgi?id=149878
296
297         Reviewed by Mark Lam.
298
299         Two of the overloads of this method were never called. The other was called only from one
300         place, in a manner that rendered most of its code dead. This change removes the dead code and
301         folds the method into its one caller.
302
303         * jit/JIT.h:
304         * jit/JITPropertyAccess.cpp:
305         (JSC::JIT::emitSlow_op_get_by_val):
306         (JSC::JIT::emit_op_put_by_val):
307         (JSC::JIT::compilePutDirectOffset):
308         (JSC::JIT::emitVarInjectionCheck):
309         (JSC::JIT::emitGetGlobalProperty):
310         (JSC::JIT::emitGetVarFromPointer):
311         (JSC::JIT::compileGetDirectOffset): Deleted.
312         * jit/JITPropertyAccess32_64.cpp:
313         (JSC::JIT::compilePutDirectOffset):
314         (JSC::JIT::emitVarInjectionCheck):
315         (JSC::JIT::emitGetGlobalProperty):
316         (JSC::JIT::emitGetVarFromPointer):
317         (JSC::JIT::compileGetDirectOffset): Deleted.
318
319 2015-10-06  Filip Pizlo  <fpizlo@apple.com>
320
321         Inline caches should handle out-of-line offsets out-of-line
322         https://bugs.webkit.org/show_bug.cgi?id=149869
323
324         Reviewed by Saam Barati.
325
326         If we want to have a concurrent copying GC, then we need a read barrier on copied space
327         pointers. That makes the convertible load portion of the get_by_id/put_by_id inline caches
328         rather challenging. Currently we have a load instruction that we can turn into an add
329         instruction - the add case is when we have an inline offset, and the load case is when we
330         have an out-of-line offset and we need to load a copied space pointer. But if the load from
331         copied space requires a barrier, then there is no easy way to convert that back to the inline
332         case.
333
334         This patch removes the convertible load. The inline path of get_by_id/put_by_id only handles
335         the inline offsets. Out-of-line offsets are now handled using out-of-line stubs.
336
337         * bytecode/StructureStubInfo.h:
338         * ftl/FTLInlineCacheSize.cpp:
339         (JSC::FTL::sizeOfGetById):
340         (JSC::FTL::sizeOfPutById):
341         * jit/JITInlineCacheGenerator.cpp:
342         (JSC::JITByIdGenerator::finalize):
343         (JSC::JITByIdGenerator::generateFastPathChecks):
344         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
345         (JSC::JITGetByIdGenerator::generateFastPath):
346         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
347         (JSC::JITPutByIdGenerator::generateFastPath):
348         * jit/JITInlineCacheGenerator.h:
349         * jit/Repatch.cpp:
350         (JSC::repatchByIdSelfAccess):
351         (JSC::tryCacheGetByID):
352         (JSC::tryCachePutByID):
353         * runtime/JSObject.h:
354         (JSC::JSObject::butterflyTotalSize):
355         (JSC::indexRelativeToBase):
356         (JSC::offsetRelativeToBase):
357         (JSC::maxOffsetRelativeToBase):
358         (JSC::makeIdentifier):
359         (JSC::offsetRelativeToPatchedStorage): Deleted.
360         (JSC::maxOffsetRelativeToPatchedStorage): Deleted.
361
362 2015-10-07  Commit Queue  <commit-queue@webkit.org>
363
364         Unreviewed, rolling out r190664.
365         https://bugs.webkit.org/show_bug.cgi?id=149877
366
367         mac build is sometimes borken due to missing generated header
368         file (Requested by youenn on #webkit).
369
370         Reverted changeset:
371
372         "Automate WebCore JS builtins generation and build system"
373         https://bugs.webkit.org/show_bug.cgi?id=149751
374         http://trac.webkit.org/changeset/190664
375
376 2015-10-07  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>
377
378         Automate WebCore JS builtins generation and build system
379         https://bugs.webkit.org/show_bug.cgi?id=149751
380
381         Reviewed by Darin Adler.
382
383         * generate-js-builtins: updating the part related to WebCore JS binding.
384
385 2015-10-06  Mark Lam  <mark.lam@apple.com>
386
387         Factoring out op_sub baseline code generation into JITSubGenerator.
388         https://bugs.webkit.org/show_bug.cgi?id=149600
389
390         Reviewed by Geoffrey Garen.
391
392         We're going to factor out baseline code generation into snippet generators so
393         that we can later use them in the DFG and FTL to emit code for to perform the
394         JS operations where the operand types are predicted to be polymorphic.
395         We are starting in this patch with the implementation of op_sub.
396
397         What was done in this patch:
398         1. Created JITSubGenerator based on the baseline implementation of op_sub as
399            expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase().
400            I did not attempt to do write a more optimal version of op_sub.  I'll
401            leave that to a later patch.
402
403         2. Convert the 32-bit op_sub baseline implementation to use the same
404            JITSubGenerator which was based on the 64-bit implementation.  The
405            pre-existing 32-bit baseline op_sub had handling for more optimization cases.
406            However, a benchmark run shows that simply going with the 64-bit version
407            (foregoing those extra optimizations) did not change the performance.
408
409            Also, previously, the 32-bit version was able to move double results directly
410            into the result location on the stack directly.  By using JITSubGenerator,
411            we now always move that result into a pair of GPRs before storing it into
412            the stack location.
413
414         3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs.
415
416         * JavaScriptCore.xcodeproj/project.pbxproj:
417         * jit/AssemblyHelpers.h:
418         (JSC::AssemblyHelpers::boxDouble):
419         (JSC::AssemblyHelpers::unboxDouble):
420         (JSC::AssemblyHelpers::boxBooleanPayload):
421         * jit/JIT.h:
422         (JSC::JIT::linkDummySlowCase):
423         * jit/JITArithmetic.cpp:
424         (JSC::JIT::compileBinaryArithOp):
425         (JSC::JIT::compileBinaryArithOpSlowCase):
426         (JSC::JIT::emitSlow_op_div):
427         (JSC::JIT::emit_op_sub):
428         (JSC::JIT::emitSlow_op_sub):
429         * jit/JITArithmetic32_64.cpp:
430         (JSC::JIT::emitBinaryDoubleOp):
431         (JSC::JIT::emit_op_sub): Deleted.
432         (JSC::JIT::emitSub32Constant): Deleted.
433         (JSC::JIT::emitSlow_op_sub): Deleted.
434         * jit/JITInlines.h:
435         (JSC::JIT::linkSlowCaseIfNotJSCell):
436         (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
437         (JSC::JIT::addSlowCase):
438         (JSC::JIT::emitLoad):
439         (JSC::JIT::emitGetVirtualRegister):
440         (JSC::JIT::emitPutVirtualRegister):
441         * jit/JITSubGenerator.h: Added.
442         (JSC::JITSubGenerator::JITSubGenerator):
443         (JSC::JITSubGenerator::generateFastPath):
444         (JSC::JITSubGenerator::slowPathJumpList):
445
446 2015-10-06  Daniel Bates  <dbates@webkit.org>
447
448         Enable XSLT when building WebKit for iOS using the public iOS SDK
449         https://bugs.webkit.org/show_bug.cgi?id=149827
450
451         Reviewed by Alexey Proskuryakov.
452
453         * Configurations/FeatureDefines.xcconfig:
454
455 2015-10-05  Commit Queue  <commit-queue@webkit.org>
456
457         Unreviewed, rolling out r190599.
458         https://bugs.webkit.org/show_bug.cgi?id=149836
459
460         Made perf tests randomly crash (Requested by ap on #webkit).
461
462         Reverted changeset:
463
464         "GC shouldn't cancel every FTL compilation"
465         https://bugs.webkit.org/show_bug.cgi?id=149821
466         http://trac.webkit.org/changeset/190599
467
468 2015-10-05  Commit Queue  <commit-queue@webkit.org>
469
470         Unreviewed, rolling out r190589.
471         https://bugs.webkit.org/show_bug.cgi?id=149833
472
473         Caused lots of leaks, and possibly crashes (Requested by ap on
474         #webkit).
475
476         Reverted changeset:
477
478         "Unreviewed, rolling back in r190450"
479         https://bugs.webkit.org/show_bug.cgi?id=149727
480         http://trac.webkit.org/changeset/190589
481
482 2015-10-05  Geoffrey Garen  <ggaren@apple.com>
483
484         Remove a few includes from JSGlobalObject.h
485         https://bugs.webkit.org/show_bug.cgi?id=148004
486
487         Reviewed by Saam Barati.
488
489         * parser/VariableEnvironment.cpp:
490         * parser/VariableEnvironment.h:
491         * runtime/JSGlobalObject.h:
492         * runtime/JSString.cpp:
493         (JSC::JSString::createStructure):
494         (JSC::JSRopeString::RopeBuilder::expand):
495         * runtime/JSString.h:
496         (JSC::JSString::canGetIndex):
497         (JSC::JSString::offsetOfLength):
498         (JSC::JSString::offsetOfFlags):
499         (JSC::JSString::createStructure): Deleted.
500         * runtime/Structure.h:
501         * runtime/StructureInlines.h:
502         * runtime/StructureRareDataInlines.h:
503
504 2015-10-05  Filip Pizlo  <fpizlo@apple.com>
505
506         GC shouldn't cancel every FTL compilation
507         https://bugs.webkit.org/show_bug.cgi?id=149821
508
509         Reviewed by Saam Barati.
510
511         During one of the CodeBlock GC refactorings, we messed up the GC's compilation cancellation
512         code. The GC should be able to cancel compilation plans if it determines that the plan will
513         be DOA. But, prior to this fix, that code was killing every FTL compilation. This happened
514         because the meaning of CodeBlock::isKnownToBeLiveDuringGC() changed.
515
516         It's funny that this didn't show up as a bigger slow-down. Basically, those benchmarks that
517         GC a lot usually don't rely on good compilation, while those benchmarks that do rely on good
518         compilation usually don't GC a lot. That's probably why this wasn't super obvious when we
519         broke it.
520
521         This change just changes the cancellation logic so that it only cancels plans if the owning
522         executable is dead. This is safe; in fact the relevant method would be correct even if it
523         always returned true. It would also be correct if it always returned false. So, compared to
524         what we had before we changed isKnownToBeLiveDuringGC(), this new code will cancel fewer
525         compilations. But, that's better than cancelling every compilation. I've filed a bug and
526         written a FIXME for investigating ways to resurrect the old behavior:
527         https://bugs.webkit.org/show_bug.cgi?id=149823
528
529         Nonetheless, this change looks like it might be a 1% speed-up on Octane. It improves earley
530         and gbemu.
531
532         * dfg/DFGPlan.cpp:
533         (JSC::DFG::Plan::isKnownToBeLiveDuringGC):
534
535 2015-10-05  Sukolsak Sakshuwong  <sukolsak@gmail.com>
536
537         [Intl] Change the return type of canonicalizeLocaleList() from JSArray* to Vector<String>
538         https://bugs.webkit.org/show_bug.cgi?id=149807
539
540         Reviewed by Benjamin Poulain.
541
542         From ECMA-402, 9.2.1, the abstract operation CanonicalizeLocaleList
543         returns a List of Strings. From the spec, we never modify the result
544         from CanonicalizeLocaleList(). We never expose it to the user either.
545         This patch changes the return type of canonicalizeLocaleList() from
546         JSArray* to Vector<String>. This should ease the workload of the GC and
547         make the code a bit easier to read.
548
549         * runtime/IntlCollatorConstructor.cpp:
550         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
551         * runtime/IntlDateTimeFormatConstructor.cpp:
552         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
553         * runtime/IntlNumberFormatConstructor.cpp:
554         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
555         * runtime/IntlObject.cpp:
556         (JSC::canonicalizeLocaleList):
557         (JSC::lookupSupportedLocales):
558         (JSC::bestFitSupportedLocales):
559         (JSC::supportedLocales):
560         * runtime/IntlObject.h:
561
562 2015-10-01  Geoffrey Garen  <ggaren@apple.com>
563
564         Unreviewed, rolling back in r190450
565         https://bugs.webkit.org/show_bug.cgi?id=149727
566
567         The cause of the leak was VM shutdown, which happens in workers.
568
569         The fix is for CodeBlockSet to participate in lastChanceToFinalize,
570         since it's responsible for running CodeBlock destructors.
571
572         I ran the leaks tests locally and did not see any CodeBlock-related leaks.
573
574         Restored changesets:
575
576         "CodeBlock should be a GC object"
577         https://bugs.webkit.org/show_bug.cgi?id=149727
578         http://trac.webkit.org/changeset/190450
579
580 2015-10-03  Filip Pizlo  <fpizlo@apple.com>
581
582         Allow an object's marking state to track The Three Colors
583         https://bugs.webkit.org/show_bug.cgi?id=149654
584
585         Reviewed by Geoffrey Garen.
586
587         I want to make GC marking concurrent (see https://bugs.webkit.org/show_bug.cgi?id=149432).
588         Concurrent GC require barriers to be executed during certain heap operations. We already have a
589         generational GC. Generational GCs also need barriers, and we already have those. The generational
590         GC barrier that we use is the "sticky mark bit" barrier. Ordinarily, mark bits get reset after a
591         collection. In our collector, there is a secondary mark bit that "sticks" - i.e. it does not get
592         reset. If the sticky mark bit is set in between two collections, then we know that the object is in
593         old space. This is sufficient to determine when to put things into remembered sets. Additionally,
594         the sticky mark bit is actually a tri-state that can also tell us if the object has been placed on
595         a remembered set.
596
597         This is awfully similar to what you want in a concurrent GC. Concurrent GCs typically want writes
598         to the heap that change the object graph to do different things depending on an object's marking
599         state, which is usually referred to as its color. White means that the object has never been seen
600         by the collector. All white objects are presumed dead at the flip. Grey objects are those that are
601         known to the collector but have not been scanned. Black objects are those that have been scanned,
602         and will not be scanned again. White is exactly just "not being marked", and both grey and black
603         mean "marked" - with "black" meaning "marked but not on any worklist". That's quite a bit like the
604         current "Marked" and "MarkedAndRemembered" states that we have for generational GC.
605         "MarkedAndRemembered" is a lot like "grey", and "Marked" is a lot like "black".
606
607         I want to make a concurrent GC that unifies the generational and concurrent barriers into a single
608         fast path check. Even better if the two barriers are entirely identical. You can do this using
609         Pirinen's technique #2 [1], originally due to Guy Steele [2]: when doing o.f=v where o is black and
610         v is white, turn o grey again. This is like remembering an object, in the sense that our gen GC
611         "rememberes" o when o is old and v is new. It remembers objects by putting them on the mark stack,
612         setting the generational state to MarkedAndRemembered, and doing nothing to the primary mark bit.
613
614         This makes our concurrent GC approach pretty obvious. We want to use one barrier for concurrent and
615         generational, and we want to basically keep our current barriers unchanged. The only things missing
616         are just some small changes to allow the concurrent GC to know precisely when an object is black,
617         and to know during object visiting if we are visiting the object for the first time during a
618         collection or a subsequent time due to barrier re-greying (concurrent GC) or barrier remembering
619         (generational GC). So, this patch does the following:
620
621         - Changes the terminology used for the gcData header byte in JSCell. This changes the name of this
622           to cellState, and introduces a new enumeration called CellState. This new enumeration behaves a
623           lot like the old GCData did. It has the following members, with the following correspondence to
624           the old GCData:
625
626           OldBlack: this is like Marked, with the exception that we ensure that an object becomes OldBlack
627               as soon as the object starts to be scanned. Previously, an object might be
628               MarkedAndRemembered during scanning and we'd turn all MarkedAndRemembered objects into Marked
629               objects during a post-processing step at the end of GC. This patch gets rid of that
630               post-processing. The act of visiting an object unconditionally makes it OldBlack. Note that
631               our definition of "black" is not that the object is done being scanned, but that it is either
632               being scanned right now or it has already been scanned. This is like a combination of
633               Siebert's anthracite and black states [3].
634
635           NewWhite: this is exactly NotMarked. It's the state that objects get when they are allocated.
636               It's impossible for an object to return to this state.
637
638           OldGrey: the object is on the mark stack and will be scanned at some point in the future. This
639               also means that this isn't the first time in this cycle that the object has been grey. In an
640               eden collection, an old object that has been remembered is thought of as being OldGrey, even
641               if this is the first time during this eden collection that it is grey. That's because an eden
642               collection must behave "as if" the grey->black transition for old objects magically happened
643               at the start of GC. Remembered objects are like old objects that underwent a concurrent
644               barrier re-greying just after the magical old object grey->black transition at the start of
645               GC. This state is almost exactly like MarkedAndRemembered, except that an object now
646               transitions from OldGrey to OldBlack at the beginning of visiting, rather than how previously
647               we transitioned from MarkedAndRemembered to Marked at the bitter end of GC.
648
649           NewGray: the object is on the mark stack and will be scanned at some point in the future. This
650               state has no clear relative in the old state system. It means that the object became grey due
651               to ordinary marking. Previously, ordinary marking would make the object Marked.
652
653         - Removal of the post-processing phase that "clears" the remembered set by moving all remembered
654           objects to the Marked state. This now happens magically during visiting, as described above.
655
656         - SlotVisitor now remembers the state that the object did have just before visiting. While visiting
657           that object, it's possible to query what the state was. This is used for copy space decisions and
658           for extra memory usage accounting. We don't want to put the backing store on the copy worklist,
659           and we don't want to count extra memory usage, if the object was OldGrey at the start of
660           visiting. Previously, we would be able to just ask if the object was MarkedAndRemembered since
661           that state wouldn't get cleared until after all marking finished. This change also simplifies
662           some APIs, because there is no need to pass the JSCell* pointer, since these SlotVisitor methods
663           no longer ask the cell for its state - instead they use the saved pre-visiting state.
664
665         - Removal of a bunch of helpers and abstractions. Previously we had various methods for asking if
666           an object was "marked" and if an object was "remembered". We had helpers for adjusting these
667           states, and those helpers would assert that they were being used the right way. This is not very
668           useful for concurrent GC, since now the set of possible state transitions is much larger. Also,
669           the previous use of the word "marked" was pretty bad - for example in Heap, "marked" refers to
670           the primary mark bit (that gets cleared at the flip), while in JSCell, "marked" refers to the
671           sticky mark bit (that does not get cleared, ever). This change gets rid of a lot of those helpers
672           and inlines their logic. This actually makes the code easier and more fun to read, since you can
673           now look at the marking and barrier code and see how that code uses the four CellStates. For
674           example, it's fun to see that the barrier gets fired for o.f=v exactly when o is OldBlack and v
675           is NewWhite.
676
677         This change shouldn't have any effect on performance or GC behavior. It does put our code in a
678         weird state where we now have states and comments referencing a concurrent GC that doesn't exist
679         yet.
680
681         Finally, some thoughts about the concurrent GC barrier and its implications for performance. This
682         barrier exhibits very poor guarantees about collector progress, but maximizes throughput by just
683         reusing the existing barrier code we already emit and optimize. I believe that even our epoch-based
684         barrier insertion DFG phase is correct for the concurrent interpretation of our existing barrier.
685         But, the barrier can regress the progress that the collector has made for two reasons:
686
687         Incremental update: you don't want to use this barrier with a black stack, since that would mean
688         that heap loads of white objects will have to explicitly re-grey the stack. The way you implement
689         this kind of collector is that collector termination will rescan the stack. Termination is reached
690         only if the at-termination re-scan greys no objects. This means that the collector is a fixpoint.
691         Luckily, our collector is already a fixpoint because of opaque roots and structure transitions.
692
693         Marking ain't monotonic: normally, once an object is black, it stays that way. In this collector,
694         black objects may become grey again. I don't have personal experience with such concurrent GCs, but
695         I suspect that this will basically be fine. Concurrent collections finish pretty quickly, and the
696         mutator usually touches only a subset of the heap. Only that subset of the heap that the mutator is
697         touching could be re-greyed. Probably, the GC will have to be hybrid incremental and concurrent,
698         and towards the end of GC when we do the termination stack re-scan, we can ensure that the
699         collector does some minimal amount of marking. If the minimal amount of marking done by the
700         collector is large enough, we can ensure that we reach termination before the mutator can regress
701         progress. The barrier cannot un-terminate the collector; if the collector reaches termination and
702         the barrier re-greys an object then it's actually doing a generational remembering rather than a
703         concurrent re-greying.
704
705         That's sort of the cute thing about the barrier - it is exactly a re-greying barrier during GC and
706         it is exactly a remembering barrier in between GCs.
707
708         [1] http://www.cs.utexas.edu/ftp/garbage/submit/readable/ppirinen11.ps
709         [2] http://dl.acm.org/citation.cfm?id=361005
710         [3] http://www.aicas.com/papers/ISMM132-siebert.pdf
711
712         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
713         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
714         * JavaScriptCore.xcodeproj/project.pbxproj:
715         * bytecode/CodeBlock.cpp:
716         (JSC::CodeBlock::visitChildren):
717         * ftl/FTLAbstractHeapRepository.cpp:
718         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
719         * ftl/FTLAbstractHeapRepository.h:
720         * ftl/FTLLowerDFGToLLVM.cpp:
721         (JSC::FTL::DFG::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIsStillValid):
722         (JSC::FTL::DFG::LowerDFGToLLVM::loadCellState):
723         (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
724         (JSC::FTL::DFG::LowerDFGToLLVM::loadMarkByte): Deleted.
725         * heap/CellState.h: Added.
726         * heap/CodeBlockSet.cpp:
727         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
728         * heap/CopiedBlock.h:
729         * heap/CopiedBlockInlines.h:
730         (JSC::CopiedBlock::reportLiveBytes):
731         (JSC::CopiedBlock::shouldReportLiveBytes): Deleted.
732         * heap/GCLogging.cpp:
733         (JSC::LoggingFunctor::reviveCells):
734         * heap/Heap.cpp:
735         (JSC::Heap::markRoots):
736         (JSC::Heap::visitWeakHandles):
737         (JSC::Heap::updateObjectCounts):
738         (JSC::Heap::addToRememberedSet):
739         (JSC::Heap::clearRememberedSet): Deleted.
740         * heap/Heap.h:
741         * heap/HeapInlines.h:
742         (JSC::Heap::isLive):
743         (JSC::Heap::isMarked):
744         (JSC::Heap::writeBarrier):
745         (JSC::Heap::reportExtraMemoryAllocated):
746         (JSC::Heap::reportExtraMemoryVisited):
747         (JSC::Heap::isRemembered): Deleted.
748         * heap/SlotVisitor.cpp:
749         (JSC::SlotVisitor::append):
750         (JSC::SlotVisitor::visitChildren):
751         (JSC::SlotVisitor::donateKnownParallel):
752         (JSC::SlotVisitor::drain):
753         (JSC::visitChildren): Deleted.
754         * heap/SlotVisitor.h:
755         (JSC::SlotVisitor::childCount):
756         (JSC::SlotVisitor::incrementChildCount):
757         (JSC::SlotVisitor::dataBeforeVisitingCurrentObject):
758         * heap/SlotVisitorInlines.h:
759         (JSC::SlotVisitor::internalAppend):
760         (JSC::SlotVisitor::copyLater):
761         (JSC::SlotVisitor::reportExtraMemoryVisited):
762         (JSC::SlotVisitor::heap):
763         * jit/AssemblyHelpers.h:
764         (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
765         * llint/LowLevelInterpreter.asm:
766         * llint/LowLevelInterpreter32_64.asm:
767         * llint/LowLevelInterpreter64.asm:
768         * runtime/JSCell.h:
769         (JSC::JSCell::cellState):
770         (JSC::JSCell::setCellState):
771         (JSC::JSCell::structureIDOffset):
772         (JSC::JSCell::indexingTypeOffset):
773         (JSC::JSCell::cellStateOffset):
774         (JSC::JSCell::setMarked): Deleted.
775         (JSC::JSCell::setRemembered): Deleted.
776         (JSC::JSCell::isMarked): Deleted.
777         (JSC::JSCell::isRemembered): Deleted.
778         (JSC::JSCell::gcDataOffset): Deleted.
779         * runtime/JSCellInlines.h:
780         (JSC::JSCell::JSCell):
781         * runtime/JSGenericTypedArrayViewInlines.h:
782         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
783         * runtime/JSObject.cpp:
784         (JSC::JSObject::copyBackingStore):
785         * runtime/JSString.cpp:
786         (JSC::JSString::visitChildren):
787         * runtime/StructureIDBlob.h:
788         (JSC::StructureIDBlob::StructureIDBlob):
789         (JSC::StructureIDBlob::operator=):
790         * runtime/WeakMapData.cpp:
791         (JSC::WeakMapData::visitChildren):
792         (JSC::WeakMapData::set):
793         * tests/stress/basic-eden-gc-test.js: Added.
794             Hilariously, an earlier version of this patch that didn't have the NewGrey/OldGrey distinction
795             would only crash super-big tests that GCd twice but it didn't crash any small focused test. All
796             it took to show the need for the NewGrey/OldGrey distinction was this super simple test.
797
798 2015-10-05  Geoffrey Garen  <ggaren@apple.com>
799
800         JSC::SlotVisitor should not be a hot mess
801         https://bugs.webkit.org/show_bug.cgi?id=149798
802
803         Reviewed by Andreas Kling.
804
805         I had to debug JSC::SlotVisitor the other day. It was hard to follow.
806         Let's make it easy to follow.
807
808         * heap/Heap.cpp:
809         (JSC::Heap::markRoots):
810         (JSC::Heap::resetVisitors):
811         (JSC::Heap::objectCount):
812         (JSC::Heap::addToRememberedSet):
813         (JSC::Heap::collectAndSweep):
814         * heap/Heap.h: Deleted the string hash-consing code. It
815         was dead code.
816
817         Since no benchmark noticed the commit that broke this feature, perhaps
818         it's not worth having.
819
820         Either way, the best thing to do with dead code is to delete it.
821         It's still there in svn if we ever want to pick it up again.
822
823         * heap/HeapRootVisitor.h:
824         (JSC::HeapRootVisitor::visit):
825         (JSC::HeapRootVisitor::visitor): Removed the private append functions
826         for unsafe pointers and switched HeapRootVisitor over to the public
827         specially named functions for unsafe pointers.
828
829         In future, we should either remove the public specially named functions
830         or remove HeapRootVisitor, since they serve the same purpose. At least
831         for now we don't have pairs of functions on SlotVisitor that do the
832         exact same thing.
833
834         * heap/SlotVisitor.cpp:
835         (JSC::validate): Moved this static function to the top of the file.
836
837         (JSC::SlotVisitor::SlotVisitor):
838         (JSC::SlotVisitor::didStartMarking):
839         (JSC::SlotVisitor::reset): More hash cons removal.
840
841         (JSC::SlotVisitor::append):
842
843         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
844         (JSC::SlotVisitor::appendToMarkStack): Renamed these functions to 
845         distinguish them from the up-front helper functions that just do type
846         conversions. These are the functions that actually do stuff.
847
848         Moved these functions out of line to make it easier to set breakpoints,
849         and to enable code changes for debugging, like printf and synchronous
850         marking, without recompiling the world.
851
852         setMarkedAndAppendToMarkStack is roughly 258 bytes long (not including
853         function prologue and epilogue), so inlining it was probably not a
854         great idea in the first place.
855
856         (JSC::SlotVisitor::donateKnownParallel):
857         (JSC::SlotVisitor::drain):
858         (JSC::SlotVisitor::drainFromShared): Removed some stack probing code.
859         It was also dead.
860
861         (JSC::SlotVisitor::addOpaqueRoot):
862         (JSC::SlotVisitor::containsOpaqueRoot):
863         (JSC::SlotVisitor::containsOpaqueRootTriState):
864         (JSC::SlotVisitor::opaqueRootCount):
865         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
866         (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable):
867         (JSC::SlotVisitor::donate):
868         (JSC::SlotVisitor::donateAndDrain):
869         (JSC::SlotVisitor::copyLater):
870         (JSC::SlotVisitor::mergeOpaqueRoots):
871         (JSC::SlotVisitor::harvestWeakReferences):
872         (JSC::SlotVisitor::finalizeUnconditionalFinalizers):
873         (JSC::SlotVisitor::dump): Moved more code out-of-line. These code paths
874         are not hot and/or not small, so we need more evidence before we inline
875         them. The SlotVisitor headers are included everywhere, so we should
876         make them include less.
877
878         Removed "internal" from all function names because it wasn't applied in
879         any consistent way that would mean anything.
880
881         (JSC::JSString::tryHashConsLock): Deleted.
882         (JSC::JSString::releaseHashConsLock): Deleted.
883         (JSC::JSString::shouldTryHashCons): Deleted.
884         (JSC::SlotVisitor::internalAppend): Deleted.
885         (JSC::SlotVisitor::validate): Deleted.
886
887         * heap/SlotVisitor.h:
888         (JSC::SlotVisitor::resetChildCount): Deleted.
889         (JSC::SlotVisitor::childCount): Deleted.
890         (JSC::SlotVisitor::incrementChildCount): Deleted. Removed this child
891         count thing. It was dead code.
892
893         * heap/SlotVisitorInlines.h:
894         (JSC::SlotVisitor::appendUnbarrieredPointer):
895         (JSC::SlotVisitor::appendUnbarrieredReadOnlyPointer):
896         (JSC::SlotVisitor::appendUnbarrieredValue):
897         (JSC::SlotVisitor::appendUnbarrieredReadOnlyValue): Some renaming and un-inlining.
898
899         (JSC::SlotVisitor::appendUnbarrieredWeak): Don't null check our input.
900         The one true place where null checking happens is our out-of-line
901         code. All inline functions do only type conversions.
902
903         (JSC::SlotVisitor::append):
904         (JSC::SlotVisitor::appendValues):
905         (JSC::SlotVisitor::addWeakReferenceHarvester):
906         (JSC::SlotVisitor::addUnconditionalFinalizer):
907         (JSC::SlotVisitor::reportExtraMemoryVisited): Some renaming and un-inlining.
908
909         (JSC::SlotVisitor::internalAppend): Deleted.
910         (JSC::SlotVisitor::unconditionallyAppend): Deleted.
911         (JSC::SlotVisitor::addOpaqueRoot): Deleted.
912         (JSC::SlotVisitor::containsOpaqueRoot): Deleted.
913         (JSC::SlotVisitor::containsOpaqueRootTriState): Deleted.
914         (JSC::SlotVisitor::opaqueRootCount): Deleted.
915         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): Deleted.
916         (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable): Deleted.
917         (JSC::SlotVisitor::donate): Deleted.
918         (JSC::SlotVisitor::donateAndDrain): Deleted.
919         (JSC::SlotVisitor::copyLater): Deleted.
920
921         * runtime/JSString.h:
922         (JSC::JSString::finishCreation):
923         (JSC::JSString::setIs8Bit):
924         (JSC::JSString::isHashConsSingleton): Deleted.
925         (JSC::JSString::clearHashConsSingleton): Deleted.
926         (JSC::JSString::setHashConsSingleton): Deleted. More hash cons removal.
927
928         * runtime/VM.cpp:
929         (JSC::VM::VM):
930         * runtime/VM.h:
931         (JSC::VM::currentThreadIsHoldingAPILock):
932         (JSC::VM::apiLock):
933         (JSC::VM::haveEnoughNewStringsToHashCons): Deleted.
934         (JSC::VM::resetNewStringsSinceLastHashCons): Deleted. More hash cons removal.
935
936 2015-10-04  Filip Pizlo  <fpizlo@apple.com>
937
938         Inline cache repatching should be throttled if it happens a lot
939         https://bugs.webkit.org/show_bug.cgi?id=149796
940         rdar://problem/22674436
941
942         Reviewed by Saam Barati.
943
944         We noticed a slight PLT regression from http://trac.webkit.org/changeset/189586. It's because
945         some pages do things that our inline caches mishandle, in the sense that some ICs end up
946         repatching themselves very frequently. The cost of repatching outweighs the speed-up on those
947         pages. There are probably super smart things we could do to tune the IC heuristics to make the
948         ICs do the right thing on those pages. But more fundamentally, we should ensure that our ICs
949         back off from continuous repatching if they repatch a lot. That's what this change does.
950
951         With this change, StructureStubInfo counts the number of repatchings. If that exceeds a
952         threshold, we put the IC into a cool-down mode, where some number of future repatch events do
953         nothing but decrement the cool-down counter. The duration of cool-down increases exponentially
954         every time we have to do it.
955
956         This change also outlines a lot of code. The fact that StructureStubInfo had a lot of inline
957         methods was starting to get on my nerves. Now it only has inline methods for things that need
958         to be inlined. Also, I changed StructureStubInfo to be a class rather than a struct. Maybe
959         with enough such incremental changes, eventually StructureStubInfo will actually behave like a
960         proper class.
961
962         This has no effect on JSC benchmarks. It progresses one of the pages that was hit by the
963         regression by 15%. It's hard to see if this totally fixes the entire PLT regression since the
964         geomean regression was very close to noise.
965
966         * bytecode/CodeBlock.cpp:
967         (JSC::CodeBlock::printGetByIdCacheStatus):
968         (JSC::CodeBlock::printPutByIdCacheStatus):
969         (JSC::CodeBlock::CodeBlock):
970         (JSC::CodeBlock::checkIfOptimizationThresholdReached):
971         * bytecode/CodeBlock.h:
972         * bytecode/GetByIdStatus.cpp:
973         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
974         (JSC::GetByIdStatus::computeFor):
975         * bytecode/PolymorphicAccess.cpp:
976         (JSC::PolymorphicAccess::regenerate):
977         * bytecode/PolymorphicAccess.h:
978         * bytecode/PutByIdStatus.cpp:
979         (JSC::PutByIdStatus::computeForStubInfo):
980         * bytecode/StructureStubClearingWatchpoint.h:
981         * bytecode/StructureStubInfo.cpp:
982         (JSC::StructureStubInfo::StructureStubInfo):
983         (JSC::StructureStubInfo::~StructureStubInfo):
984         (JSC::StructureStubInfo::initGetByIdSelf):
985         (JSC::StructureStubInfo::initPutByIdReplace):
986         (JSC::StructureStubInfo::initStub):
987         (JSC::StructureStubInfo::deref):
988         (JSC::StructureStubInfo::addAccessCase):
989         * bytecode/StructureStubInfo.h:
990         (JSC::StructureStubInfo::considerCaching):
991         (JSC::StructureStubInfo::willRepatch):
992         (JSC::StructureStubInfo::willCoolDown):
993         (JSC::getStructureStubInfoCodeOrigin):
994         (JSC::StructureStubInfo::StructureStubInfo): Deleted.
995         (JSC::StructureStubInfo::initGetByIdSelf): Deleted.
996         (JSC::StructureStubInfo::initPutByIdReplace): Deleted.
997         (JSC::StructureStubInfo::initStub): Deleted.
998         (JSC::StructureStubInfo::seenOnce): Deleted.
999         (JSC::StructureStubInfo::setSeen): Deleted.
1000         * jit/JIT.h:
1001         * jit/JITOperations.cpp:
1002         * jit/Repatch.cpp:
1003         (JSC::tryCacheGetByID):
1004         (JSC::tryCachePutByID):
1005         (JSC::tryRepatchIn):
1006         * runtime/Options.h:
1007
1008 2015-10-04  Filip Pizlo  <fpizlo@apple.com>
1009
1010         CodeBlock.h shouldn't be included from everywhere
1011         https://bugs.webkit.org/show_bug.cgi?id=149785
1012
1013         Reviewed by Andreas Kling.
1014
1015         * JavaScriptCore.xcodeproj/project.pbxproj:
1016         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
1017         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
1018         * interpreter/CallFrame.cpp:
1019         (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
1020         (JSC::CallFrame::callSiteBitsAreCodeOriginIndex):
1021         (JSC::CallFrame::callSiteAsRawBits):
1022         (JSC::CallFrame::callSiteIndex):
1023         (JSC::CallFrame::hasActivation):
1024         (JSC::CallFrame::uncheckedActivation):
1025         (JSC::CallFrame::stack):
1026         * interpreter/CallFrameInlines.h: Removed.
1027         * interpreter/Interpreter.cpp:
1028         * interpreter/StackVisitor.cpp:
1029         * runtime/DirectArguments.cpp:
1030         * runtime/ErrorInstance.cpp:
1031         * runtime/JSArray.cpp:
1032         * runtime/JSCInlines.h:
1033         * runtime/LiteralParser.cpp:
1034         * runtime/NullSetterFunction.cpp:
1035         * tools/JSDollarVMPrototype.cpp:
1036
1037 2015-10-03  Commit Queue  <commit-queue@webkit.org>
1038
1039         Unreviewed, rolling out r190522.
1040         https://bugs.webkit.org/show_bug.cgi?id=149787
1041
1042         Caused a lot of leaks (Requested by ap on #webkit).
1043
1044         Reverted changeset:
1045
1046         "Unreviewed, rolling back in r190450"
1047         https://bugs.webkit.org/show_bug.cgi?id=149727
1048         http://trac.webkit.org/changeset/190522
1049
1050 2015-10-02  Matt Baker  <mattbaker@apple.com>
1051
1052         Web Inspector: Add breakpoint option to ignore n times before stopping
1053         https://bugs.webkit.org/show_bug.cgi?id=147664
1054
1055         Reviewed by Timothy Hatcher.
1056
1057         * debugger/Breakpoint.h:
1058         (JSC::Breakpoint::Breakpoint):
1059         Added ignoreCount and hitCount fields. Cleaned up initializers.
1060
1061         * debugger/Debugger.cpp:
1062         (JSC::Debugger::hasBreakpoint):
1063         If a breakpoint matches the current text position, increment breakpoint hit count and
1064         compare with ignore count before testing the breakpoint condition.
1065
1066         * inspector/ScriptBreakpoint.h:
1067         (Inspector::ScriptBreakpoint::ScriptBreakpoint):
1068         Added ignoreCount field. Cleaned up initializers.
1069
1070         * inspector/ScriptDebugServer.cpp:
1071         (Inspector::ScriptDebugServer::setBreakpoint):
1072         Added ignoreCount field.
1073
1074         * inspector/agents/InspectorDebuggerAgent.cpp:
1075         (Inspector::buildObjectForBreakpointCookie):
1076         (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
1077         (Inspector::InspectorDebuggerAgent::setBreakpoint):
1078         (Inspector::InspectorDebuggerAgent::continueToLocation):
1079         (Inspector::InspectorDebuggerAgent::didParseSource):
1080         Plumbing for ignoreCount property.
1081
1082         * inspector/protocol/Debugger.json:
1083         Added optional ignoreCount property to BreakpointOptions object.
1084
1085 2015-10-02  Filip Pizlo <fpizlo@apple.com> and Mark Lam <mark.lam@apple.com>
1086
1087         We should not add InferredTypeTables to old Structures
1088         https://bugs.webkit.org/show_bug.cgi?id=149767
1089         rdar://problem/22825526
1090
1091         Reviewed by Saam Barati.
1092
1093         Our property type inference has an optimization where the absence of an InferredTypeTable is
1094         taken to mean that all properties are TOP. This is great because most Structures come into
1095         existence through reflective stores, and we don't want to waste time inferring types for
1096         those.
1097
1098         But our code was not obeying this rule properly. If we were doing a transition, we would
1099         assume that this meant that we were creating a new structure, and so we would give it an
1100         InferredTypeTable if we were doing a non-reflective store (i.e. context = PutById). But that
1101         same structure could already have been in use prior to us giving it an InferredTypeTable. At
1102         that point bad things will start to happen because the objects created before we created the
1103         table, and the inline caches compiled before then, will have types that disagree with the new
1104         objects and inline caches despite them sharing the same structure and property names.
1105
1106         * runtime/JSObject.h:
1107         (JSC::JSObject::putDirectInternal):
1108         (JSC::JSObject::putDirectWithoutTransition):
1109         * runtime/Structure.h:
1110         * tests/stress/add-inferred-type-table-to-existing-structure.js: Added.
1111         (foo):
1112         (bar):
1113         (baz):
1114
1115 2015-10-02  Joseph Pecoraro  <pecoraro@apple.com>
1116
1117         Unreviewed, rolling out r190520, some tests assert / crash.
1118
1119         * CMakeLists.txt:
1120         * DerivedSources.make:
1121         * JavaScriptCore.xcodeproj/project.pbxproj:
1122         * heap/Heap.cpp:
1123         (JSC::Heap::willStartCollection): Deleted.
1124         (JSC::Heap::didFinishCollection): Deleted.
1125         * heap/Heap.h:
1126         (JSC::Heap::addObserver): Deleted.
1127         (JSC::Heap::removeObserver): Deleted.
1128         * heap/HeapObserver.h: Removed.
1129         * heap/MarkedSpace.h:
1130         * inspector/InspectorEnvironment.h:
1131         * inspector/JSGlobalObjectInspectorController.cpp:
1132         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1133         (Inspector::JSGlobalObjectInspectorController::vm): Deleted.
1134         * inspector/JSGlobalObjectInspectorController.h:
1135         * inspector/agents/InspectorHeapAgent.cpp: Removed.
1136         * inspector/agents/InspectorHeapAgent.h: Removed.
1137         * inspector/protocol/Heap.json: Removed.
1138
1139 2015-10-01  Geoffrey Garen  <ggaren@apple.com>
1140
1141         Unreviewed, rolling back in r190450
1142         https://bugs.webkit.org/show_bug.cgi?id=149727
1143
1144         The cause of the crash was a CodeBlock, after surviving a call to
1145         deleteAllCode by virtue of being in the remembered set, trying to mark
1146         its inlined CodeBlocks via pointers from its inlined executables.
1147         Since deleteAllCode clears those pointers, the CodeBlock would ASSERT.
1148         (Any other choice to retain a CodeBlock after deleteAllCode -- for
1149         example, conservative marking -- could trigger the same bug.)
1150
1151         The fix is for InlineCallFrame to point directly to its inlined CodeBlock
1152         instead of pointing indirectly via an executable. This guarantees that
1153         CodeBlocks are GC safe regardless of whether we've called deleteAllCode.
1154
1155         Restored changesets:
1156
1157         "CodeBlock should be a GC object"
1158         https://bugs.webkit.org/show_bug.cgi?id=149727
1159         http://trac.webkit.org/changeset/190450
1160
1161 2015-10-02  Joseph Pecoraro  <pecoraro@apple.com>
1162
1163         Web Inspector: Include Garbage Collection Event in Timeline
1164         https://bugs.webkit.org/show_bug.cgi?id=142510
1165
1166         Reviewed by Geoffrey Garen.
1167
1168         * CMakeLists.txt:
1169         * DerivedSources.make:
1170         * JavaScriptCore.xcodeproj/project.pbxproj:
1171
1172         * heap/HeapObserver.h:        
1173         * heap/Heap.cpp:
1174         (JSC::Heap::willStartCollection):
1175         (JSC::Heap::didFinishCollection):
1176         * heap/Heap.h:
1177         (JSC::Heap::addObserver):
1178         (JSC::Heap::removeObserver):
1179         Allow observers on heap to add hooks for starting / ending garbage collection.
1180
1181         * inspector/InspectorEnvironment.h:
1182         * inspector/JSGlobalObjectInspectorController.cpp:
1183         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1184         (Inspector::JSGlobalObjectInspectorController::vm):
1185         * inspector/JSGlobalObjectInspectorController.h:
1186         Access the VM through the InspectorEnvironment as it won't change.
1187
1188         * inspector/agents/InspectorHeapAgent.cpp: Added.
1189         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
1190         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
1191         (Inspector::InspectorHeapAgent::didCreateFrontendAndBackend):
1192         (Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
1193         (Inspector::InspectorHeapAgent::enable):
1194         (Inspector::InspectorHeapAgent::disable):
1195         (Inspector::InspectorHeapAgent::gc):
1196         (Inspector::protocolTypeForHeapOperation):
1197         (Inspector::InspectorHeapAgent::willGarbageCollect):
1198         (Inspector::InspectorHeapAgent::didGarbageCollect):
1199         * inspector/agents/InspectorHeapAgent.h: Added.
1200         * inspector/protocol/Heap.json: Added.
1201         New domain and agent to handle tasks related to the JavaScriptCore heap.
1202
1203 2015-10-01  Geoffrey Garen  <ggaren@apple.com>
1204
1205         Unreviewed, rolling out r190450
1206         https://bugs.webkit.org/show_bug.cgi?id=148560
1207
1208         Crashes seen on el cap wk1 bots.
1209
1210         Reverted changesets:
1211
1212         "CodeBlock should be a GC object"
1213         https://bugs.webkit.org/show_bug.cgi?id=149727
1214         http://trac.webkit.org/changeset/190450
1215
1216         * bytecode/CodeBlock.cpp:
1217         (JSC::CodeBlock::inferredName):
1218         (JSC::CodeBlock::dumpAssumingJITType):
1219         (JSC::CodeBlock::CodeBlock):
1220         (JSC::CodeBlock::~CodeBlock):
1221         (JSC::CodeBlock::setNumParameters):
1222         (JSC::CodeBlock::specialOSREntryBlockOrNull):
1223         (JSC::CodeBlock::visitStrongly):
1224         (JSC::CodeBlock::visitAggregate):
1225         (JSC::CodeBlock::shouldVisitStrongly):
1226         (JSC::CodeBlock::isKnownToBeLiveDuringGC):
1227         (JSC::CodeBlock::shouldJettisonDueToWeakReference):
1228         (JSC::CodeBlock::shouldJettisonDueToOldAge):
1229         (JSC::CodeBlock::determineLiveness):
1230         (JSC::CodeBlock::visitWeakReferences):
1231         (JSC::CodeBlock::finalizeLLIntInlineCaches):
1232         (JSC::CodeBlock::finalizeBaselineJITInlineCaches):
1233         (JSC::CodeBlock::finalizeUnconditionally):
1234         (JSC::CodeBlock::visitOSRExitTargets):
1235         (JSC::CodeBlock::unlinkIncomingCalls):
1236         (JSC::CodeBlock::linkIncomingCall):
1237         (JSC::CodeBlock::newReplacement):
1238         (JSC::ProgramCodeBlock::replacement):
1239         (JSC::ModuleProgramCodeBlock::replacement):
1240         (JSC::EvalCodeBlock::replacement):
1241         (JSC::FunctionCodeBlock::replacement):
1242         (JSC::ProgramCodeBlock::capabilityLevelInternal):
1243         (JSC::ModuleProgramCodeBlock::capabilityLevelInternal):
1244         (JSC::EvalCodeBlock::capabilityLevelInternal):
1245         (JSC::FunctionCodeBlock::capabilityLevelInternal):
1246         (JSC::WebAssemblyCodeBlock::replacement):
1247         (JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
1248         (JSC::CodeBlock::jettison):
1249         (JSC::CodeBlock::capabilityLevel):
1250         (JSC::FunctionCodeBlock::destroy): Deleted.
1251         (JSC::WebAssemblyCodeBlock::destroy): Deleted.
1252         (JSC::ProgramCodeBlock::destroy): Deleted.
1253         (JSC::ModuleProgramCodeBlock::destroy): Deleted.
1254         (JSC::EvalCodeBlock::destroy): Deleted.
1255         (JSC::CodeBlock::finishCreation): Deleted.
1256         (JSC::CodeBlock::setAlternative): Deleted.
1257         (JSC::CodeBlock::visitWeakly): Deleted.
1258         (JSC::CodeBlock::visitChildren): Deleted.
1259         (JSC::timeToLive): Deleted.
1260         (JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences): Deleted.
1261         (JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Deleted.
1262         (JSC::CodeBlock::replacement): Deleted.
1263         (JSC::CodeBlock::computeCapabilityLevel): Deleted.
1264         * bytecode/CodeBlock.h:
1265         (JSC::CodeBlock::unlinkedCodeBlock):
1266         (JSC::CodeBlock::addressOfNumParameters):
1267         (JSC::CodeBlock::offsetOfNumParameters):
1268         (JSC::CodeBlock::alternative):
1269         (JSC::CodeBlock::setAlternative):
1270         (JSC::CodeBlock::forEachRelatedCodeBlock):
1271         (JSC::CodeBlock::specializationKind):
1272         (JSC::CodeBlock::instructionCount):
1273         (JSC::CodeBlock::setJITCode):
1274         (JSC::CodeBlock::hasBaselineJITProfiling):
1275         (JSC::CodeBlock::capabilityLevelState):
1276         (JSC::CodeBlock::addConstant):
1277         (JSC::CodeBlock::appendExceptionHandler):
1278         (JSC::CodeBlock::setConstantRegisters):
1279         (JSC::CodeBlock::replaceConstant):
1280         (JSC::GlobalCodeBlock::GlobalCodeBlock):
1281         (JSC::ProgramCodeBlock::ProgramCodeBlock):
1282         (JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
1283         (JSC::EvalCodeBlock::EvalCodeBlock):
1284         (JSC::EvalCodeBlock::variable):
1285         (JSC::EvalCodeBlock::numVariables):
1286         (JSC::EvalCodeBlock::unlinkedEvalCodeBlock):
1287         (JSC::FunctionCodeBlock::FunctionCodeBlock):
1288         (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
1289         (JSC::ExecState::uncheckedR):
1290         (JSC::CodeBlock::clearMarks):
1291         (JSC::CodeBlockSet::mark):
1292         (JSC::ScriptExecutable::forEachCodeBlock):
1293         (JSC::ProgramCodeBlock::create): Deleted.
1294         (JSC::ProgramCodeBlock::createStructure): Deleted.
1295         (JSC::ModuleProgramCodeBlock::create): Deleted.
1296         (JSC::ModuleProgramCodeBlock::createStructure): Deleted.
1297         (JSC::EvalCodeBlock::create): Deleted.
1298         (JSC::EvalCodeBlock::createStructure): Deleted.
1299         (JSC::FunctionCodeBlock::create): Deleted.
1300         (JSC::FunctionCodeBlock::createStructure): Deleted.
1301         (JSC::WebAssemblyCodeBlock::create): Deleted.
1302         (JSC::WebAssemblyCodeBlock::createStructure): Deleted.
1303         (JSC::CodeBlock::clearVisitWeaklyHasBeenCalled): Deleted.
1304         * bytecode/DeferredCompilationCallback.cpp:
1305         (JSC::DeferredCompilationCallback::DeferredCompilationCallback):
1306         (JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
1307         (JSC::DeferredCompilationCallback::compilationDidComplete):
1308         * bytecode/DeferredCompilationCallback.h:
1309         * bytecode/EvalCodeCache.h:
1310         (JSC::EvalCodeCache::tryGet):
1311         (JSC::EvalCodeCache::getSlow):
1312         * bytecode/PolymorphicAccess.cpp:
1313         (JSC::AccessCase::generate):
1314         (JSC::PolymorphicAccess::regenerate):
1315         * bytecode/StructureStubInfo.cpp:
1316         (JSC::StructureStubInfo::addAccessCase):
1317         * dfg/DFGByteCodeParser.cpp:
1318         (JSC::DFG::ByteCodeParser::parse):
1319         * dfg/DFGDesiredTransitions.cpp:
1320         (JSC::DFG::DesiredTransition::reallyAdd):
1321         * dfg/DFGDesiredWeakReferences.cpp:
1322         (JSC::DFG::DesiredWeakReferences::reallyAdd):
1323         * dfg/DFGDriver.cpp:
1324         (JSC::DFG::compile):
1325         * dfg/DFGGraph.cpp:
1326         (JSC::DFG::Graph::Graph):
1327         * dfg/DFGJITCode.h:
1328         (JSC::DFG::JITCode::osrEntryBlock): Deleted.
1329         (JSC::DFG::JITCode::setOSREntryBlock): Deleted.
1330         (JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
1331         * dfg/DFGJITFinalizer.cpp:
1332         (JSC::DFG::JITFinalizer::finalize):
1333         (JSC::DFG::JITFinalizer::finalizeFunction):
1334         (JSC::DFG::JITFinalizer::finalizeCommon):
1335         * dfg/DFGOSRExitCompilerCommon.cpp:
1336         (JSC::DFG::adjustAndJumpToTarget):
1337         * dfg/DFGOperations.cpp:
1338         * dfg/DFGPlan.cpp:
1339         (JSC::DFG::Plan::Plan):
1340         (JSC::DFG::Plan::reallyAdd):
1341         (JSC::DFG::Plan::notifyReady):
1342         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
1343         (JSC::DFG::Plan::finalizeAndNotifyCallback):
1344         (JSC::DFG::Plan::key):
1345         (JSC::DFG::Plan::clearCodeBlockMarks):
1346         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
1347         (JSC::DFG::Plan::rememberCodeBlocks): Deleted.
1348         * dfg/DFGPlan.h:
1349         * dfg/DFGToFTLDeferredCompilationCallback.cpp:
1350         (JSC::DFG::ToFTLDeferredCompilationCallback::ToFTLDeferredCompilationCallback):
1351         (JSC::DFG::ToFTLDeferredCompilationCallback::~ToFTLDeferredCompilationCallback):
1352         (JSC::DFG::ToFTLDeferredCompilationCallback::create):
1353         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1354         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
1355         * dfg/DFGToFTLDeferredCompilationCallback.h:
1356         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
1357         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
1358         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::~ToFTLForOSREntryDeferredCompilationCallback):
1359         (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
1360         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1361         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
1362         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
1363         * dfg/DFGWorklist.cpp:
1364         (JSC::DFG::Worklist::completeAllPlansForVM):
1365         (JSC::DFG::Worklist::clearCodeBlockMarks):
1366         (JSC::DFG::completeAllPlansForVM):
1367         (JSC::DFG::clearCodeBlockMarks):
1368         (JSC::DFG::Worklist::rememberCodeBlocks): Deleted.
1369         (JSC::DFG::rememberCodeBlocks): Deleted.
1370         * dfg/DFGWorklist.h:
1371         (JSC::DFG::worklistForIndexOrNull):
1372         * ftl/FTLJITFinalizer.cpp:
1373         (JSC::FTL::JITFinalizer::finalizeFunction):
1374         * heap/CodeBlockSet.cpp:
1375         (JSC::CodeBlockSet::~CodeBlockSet):
1376         (JSC::CodeBlockSet::add):
1377         (JSC::CodeBlockSet::clearMarksForFullCollection):
1378         (JSC::CodeBlockSet::clearMarksForEdenCollection):
1379         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced):
1380         (JSC::CodeBlockSet::remove):
1381         (JSC::CodeBlockSet::traceMarked):
1382         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
1383         (JSC::CodeBlockSet::dump):
1384         * heap/CodeBlockSet.h:
1385         * heap/Heap.cpp:
1386         (JSC::Heap::markRoots):
1387         (JSC::Heap::clearLivenessData):
1388         (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
1389         (JSC::Heap::deleteAllCodeBlocks):
1390         (JSC::Heap::deleteAllUnlinkedCodeBlocks):
1391         (JSC::Heap::clearUnmarkedExecutables):
1392         (JSC::Heap::willStartCollection):
1393         * interpreter/Interpreter.cpp:
1394         (JSC::eval):
1395         * jit/GCAwareJITStubRoutine.h:
1396         * jit/JITCode.h:
1397         (JSC::JITCode::isJIT):
1398         (JSC::JITCode::timeToLive):
1399         (JSC::JITCode::isLowerTier):
1400         * jit/JITOpcodes.cpp:
1401         (JSC::JIT::emit_op_enter):
1402         * jit/JITOperations.cpp:
1403         * jit/JITToDFGDeferredCompilationCallback.cpp:
1404         (JSC::JITToDFGDeferredCompilationCallback::create):
1405         (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1406         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
1407         * jit/JITToDFGDeferredCompilationCallback.h:
1408         * jit/Repatch.cpp:
1409         (JSC::tryCacheGetByID):
1410         (JSC::tryCachePutByID):
1411         (JSC::tryRepatchIn):
1412         (JSC::linkFor):
1413         (JSC::linkPolymorphicCall):
1414         * llint/LLIntSlowPaths.cpp:
1415         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1416         (JSC::LLInt::setUpCall):
1417         * runtime/CommonSlowPaths.cpp:
1418         (JSC::SLOW_PATH_DECL):
1419         * runtime/CommonSlowPaths.h:
1420         (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
1421         (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
1422         * runtime/Executable.cpp:
1423         (JSC::ExecutableBase::clearCode):
1424         (JSC::ScriptExecutable::installCode):
1425         (JSC::ScriptExecutable::newCodeBlockFor):
1426         (JSC::ScriptExecutable::newReplacementCodeBlockFor):
1427         (JSC::ScriptExecutable::prepareForExecutionImpl):
1428         (JSC::EvalExecutable::visitChildren):
1429         (JSC::EvalExecutable::clearCode):
1430         (JSC::ProgramExecutable::checkSyntax):
1431         (JSC::ProgramExecutable::visitChildren):
1432         (JSC::ProgramExecutable::clearCode):
1433         (JSC::ModuleProgramExecutable::visitChildren):
1434         (JSC::ModuleProgramExecutable::clearCode):
1435         (JSC::FunctionExecutable::baselineCodeBlockFor):
1436         (JSC::FunctionExecutable::visitChildren):
1437         (JSC::FunctionExecutable::clearCode):
1438         (JSC::FunctionExecutable::fromGlobalCode):
1439         (JSC::WebAssemblyExecutable::visitChildren):
1440         (JSC::WebAssemblyExecutable::clearCode):
1441         (JSC::WebAssemblyExecutable::prepareForExecution):
1442         * runtime/Executable.h:
1443         (JSC::ExecutableBase::generatedJITCodeForCall):
1444         (JSC::ScriptExecutable::prepareForExecution):
1445         (JSC::ExecutableBase::clearCodeVirtual):
1446         * runtime/VM.cpp:
1447         (JSC::VM::VM):
1448         * runtime/VM.h:
1449
1450 2015-10-01  Geoffrey Garen  <ggaren@apple.com>
1451
1452         CodeBlock should be a GC object
1453         https://bugs.webkit.org/show_bug.cgi?id=149727
1454
1455         Reviewed by Filip Pizlo.
1456
1457         We want CodeBlock to be a GC object:
1458
1459         (1) Sane write barriers. Because CodeBlock wasn't a GC object, we couldn't
1460         execute a write barrier on it. This caused us to do weird things that
1461         were hard to reason about, like executing a barrier on a related executable
1462         (even though the executable might stop pointing to the CodeBlock before
1463         the next GC), or pretending that an object had written to itself. Now,
1464         when we write to a CodeBlock, we barrier the CodeBlock, and that's that.
1465
1466         (2) Simpler marking and destruction logic. There's no need to have a
1467         custom remembered set or a destruction fixpoint if we just obey normal
1468         GC rules.
1469
1470         * bytecode/CodeBlock.cpp:
1471         (JSC::FunctionCodeBlock::destroy):
1472         (JSC::WebAssemblyCodeBlock::destroy):
1473         (JSC::ProgramCodeBlock::destroy):
1474         (JSC::ModuleProgramCodeBlock::destroy):
1475         (JSC::EvalCodeBlock::destroy): Add ClassInfo and destroy functions
1476         because our GC object model requires them.
1477
1478         Note that we do not set the needsDestruction flag. Since CodeBlock needs
1479         eager destruction, it runs its destructors through CodeBlockSet,
1480         and not through normal object sweeping.
1481
1482         (JSC::CodeBlock::finishCreation): Factor out finishCreation from the
1483         constructor because our GC object model requires it. Change write
1484         barriers to note the CodeBlock as the owner.
1485
1486         (JSC::CodeBlock::~CodeBlock): Refactor to use the shared
1487         unlinkIncomingCalls() function instead of rolling a copy by hand.
1488
1489         (JSC::CodeBlock::visitWeakly): New helper function for owner executables
1490         to do weak marking that might jettison a CodeBlock. Our new GC logic
1491         says that a CodeBlock pointer is a strong reference by default, and
1492         clients need to opt in if they want to allow a CodeBlock to jettison.
1493         This is easier to get right because it means that only those
1494         specific owners that want jettison behavior need to worry about it,
1495         while all other pointers are valid by default.
1496
1497         (JSC::CodeBlock::visitChildren): The default visit function keeps
1498         everything alive.
1499
1500         (JSC::CodeBlock::shouldVisitStrongly):
1501         (JSC::CodeBlock::isKnownToBeLiveDuringGC): No need to keep special state
1502         anymore. If we're marked, we're live -- just like any other object.
1503
1504         (JSC::timeToLive): Move this code into CodeBlock.cpp so you can mess
1505         with it without recompiling, and also because it's really a CodeBlock
1506         policy.
1507
1508         (JSC::CodeBlock::WeakReferenceHarvester::visitWeakReferences):
1509         (JSC::CodeBlock::UnconditionalFinalizer::finalizeUnconditionally): Use
1510         internal objects for virtual callbacks because GC objects can't have
1511         vtables.
1512
1513         (JSC::CodeBlock::unlinkIncomingCalls): Remove a fast path check that does
1514         not exist in the copy of this code in ~CodeBlock because it is not
1515         actually an optimization.
1516
1517         (JSC::CodeBlock::replacement):
1518         (JSC::CodeBlock::computeCapabilityLevel): Make these functions generic
1519         instead of virtual because GC objects can't have vtables.
1520
1521         (JSC::CodeBlock::visitStrongly): Deleted.
1522         (JSC::CodeBlock::visitAggregate): Deleted.
1523         (JSC::CodeBlock::visitWeakReferences): Deleted.
1524         (JSC::CodeBlock::finalizeUnconditionally): Deleted.
1525         (JSC::ProgramCodeBlock::replacement): Deleted.
1526         (JSC::ModuleProgramCodeBlock::replacement): Deleted.
1527         (JSC::EvalCodeBlock::replacement): Deleted.
1528         (JSC::FunctionCodeBlock::replacement): Deleted.
1529         (JSC::ProgramCodeBlock::capabilityLevelInternal): Deleted.
1530         (JSC::ModuleProgramCodeBlock::capabilityLevelInternal): Deleted.
1531         (JSC::EvalCodeBlock::capabilityLevelInternal): Deleted.
1532         (JSC::FunctionCodeBlock::capabilityLevelInternal): Deleted.
1533         (JSC::WebAssemblyCodeBlock::replacement): Deleted.
1534         (JSC::WebAssemblyCodeBlock::capabilityLevelInternal): Deleted.
1535
1536         * bytecode/CodeBlock.h:
1537         (JSC::CodeBlock::unlinkedCodeBlock):
1538         (JSC::CodeBlock::addressOfNumParameters):
1539         (JSC::CodeBlock::offsetOfNumParameters):
1540         (JSC::CodeBlock::alternative):
1541         (JSC::CodeBlock::forEachRelatedCodeBlock):
1542         (JSC::CodeBlock::specializationKind):
1543         (JSC::CodeBlock::instructionCount):
1544         (JSC::CodeBlock::setJITCode):
1545         (JSC::CodeBlock::hasBaselineJITProfiling):
1546         (JSC::CodeBlock::capabilityLevelState):
1547         (JSC::CodeBlock::addConstant):
1548         (JSC::CodeBlock::appendExceptionHandler):
1549         (JSC::CodeBlock::setConstantRegisters):
1550         (JSC::CodeBlock::replaceConstant):
1551         (JSC::GlobalCodeBlock::GlobalCodeBlock):
1552         (JSC::ProgramCodeBlock::create):
1553         (JSC::ProgramCodeBlock::createStructure):
1554         (JSC::ProgramCodeBlock::ProgramCodeBlock):
1555         (JSC::ModuleProgramCodeBlock::create):
1556         (JSC::ModuleProgramCodeBlock::createStructure):
1557         (JSC::ModuleProgramCodeBlock::ModuleProgramCodeBlock):
1558         (JSC::EvalCodeBlock::create):
1559         (JSC::EvalCodeBlock::createStructure):
1560         (JSC::EvalCodeBlock::variable):
1561         (JSC::EvalCodeBlock::numVariables):
1562         (JSC::EvalCodeBlock::EvalCodeBlock):
1563         (JSC::EvalCodeBlock::unlinkedEvalCodeBlock):
1564         (JSC::FunctionCodeBlock::create):
1565         (JSC::FunctionCodeBlock::createStructure):
1566         (JSC::FunctionCodeBlock::FunctionCodeBlock):
1567         (JSC::WebAssemblyCodeBlock::create):
1568         (JSC::WebAssemblyCodeBlock::createStructure):
1569         (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
1570         (JSC::ExecState::uncheckedR):
1571         (JSC::CodeBlock::clearVisitWeaklyHasBeenCalled):
1572         (JSC::CodeBlockSet::mark):
1573         (JSC::ScriptExecutable::forEachCodeBlock):
1574         (JSC::CodeBlock::setAlternative): Deleted.
1575         (JSC::CodeBlock::clearMarks): Deleted. Lots of mechanical changes to
1576         match the logic changes above.
1577
1578         * bytecode/DeferredCompilationCallback.cpp:
1579         (JSC::DeferredCompilationCallback::DeferredCompilationCallback):
1580         (JSC::DeferredCompilationCallback::~DeferredCompilationCallback):
1581         (JSC::DeferredCompilationCallback::compilationDidComplete):
1582         * bytecode/DeferredCompilationCallback.h: Provide a profiledDFGCodeBlock
1583         to all compilation callbacks instead of requiring the callback to
1584         store the profiledDFGCodeBlock. This is how the rest of compilation
1585         around the callback works anyway, and it is easier to do things this
1586         way than to think about how a non-GC malloc'd object should keep its
1587         CodeBlock alive.
1588
1589         * bytecode/EvalCodeCache.h:
1590         (JSC::EvalCodeCache::tryGet):
1591         (JSC::EvalCodeCache::getSlow):
1592         * bytecode/PolymorphicAccess.cpp:
1593         (JSC::AccessCase::generate):
1594         (JSC::PolymorphicAccess::regenerate):
1595         * bytecode/StructureStubInfo.cpp:
1596         (JSC::StructureStubInfo::addAccessCase): Change the owner for write
1597         barrier purposes to CodeBlock.
1598
1599         * dfg/DFGByteCodeParser.cpp:
1600         (JSC::DFG::ByteCodeParser::parse):
1601         * dfg/DFGDesiredTransitions.cpp:
1602         (JSC::DFG::DesiredTransition::reallyAdd):
1603         * dfg/DFGDesiredWeakReferences.cpp:
1604         (JSC::DFG::DesiredWeakReferences::reallyAdd):
1605         * dfg/DFGDriver.cpp:
1606         (JSC::DFG::compile):
1607         * dfg/DFGGraph.cpp:
1608         (JSC::DFG::Graph::Graph): Ditto.
1609
1610         * dfg/DFGJITCode.h:
1611         (JSC::DFG::JITCode::osrEntryBlock):
1612         (JSC::DFG::JITCode::setOSREntryBlock):
1613         (JSC::DFG::JITCode::clearOSREntryBlock): Use helper functions for 
1614         accessing osrEntryBlock to help with write barrier stuff.
1615
1616         * dfg/DFGJITFinalizer.cpp:
1617         (JSC::DFG::JITFinalizer::finalize):
1618         (JSC::DFG::JITFinalizer::finalizeFunction):
1619         (JSC::DFG::JITFinalizer::finalizeCommon):
1620         * dfg/DFGOSRExitCompilerCommon.cpp:
1621         (JSC::DFG::adjustAndJumpToTarget): Use CodeBlock as owner instead of
1622         executable.
1623
1624         * dfg/DFGOperations.cpp:
1625         * dfg/DFGPlan.cpp:
1626         (JSC::DFG::Plan::Plan):
1627         (JSC::DFG::Plan::reallyAdd):
1628         (JSC::DFG::Plan::notifyReady):
1629         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
1630         (JSC::DFG::Plan::finalizeAndNotifyCallback):
1631         (JSC::DFG::Plan::key):
1632         (JSC::DFG::Plan::rememberCodeBlocks):
1633         (JSC::DFG::Plan::checkLivenessAndVisitChildren):
1634         (JSC::DFG::Plan::clearCodeBlockMarks): Deleted.
1635         * dfg/DFGPlan.h: Use normal GC write barrier concepts to model the fact
1636         that the compiler writes to CodeBlocks.
1637
1638         * dfg/DFGToFTLDeferredCompilationCallback.cpp:
1639         (JSC::DFG::ToFTLDeferredCompilationCallback::ToFTLDeferredCompilationCallback):
1640         (JSC::DFG::ToFTLDeferredCompilationCallback::~ToFTLDeferredCompilationCallback):
1641         (JSC::DFG::ToFTLDeferredCompilationCallback::create):
1642         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1643         (JSC::DFG::ToFTLDeferredCompilationCallback::compilationDidComplete):
1644         * dfg/DFGToFTLDeferredCompilationCallback.h:
1645         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.cpp:
1646         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::ToFTLForOSREntryDeferredCompilationCallback):
1647         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::~ToFTLForOSREntryDeferredCompilationCallback):
1648         (JSC::DFG::Ref<ToFTLForOSREntryDeferredCompilationCallback>ToFTLForOSREntryDeferredCompilationCallback::create):
1649         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1650         (JSC::DFG::ToFTLForOSREntryDeferredCompilationCallback::compilationDidComplete):
1651         * dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h: We always have
1652         a profiledDFGCodeBlock passed to use -- see above.
1653
1654         * dfg/DFGWorklist.cpp:
1655         (JSC::DFG::Worklist::completeAllPlansForVM):
1656         (JSC::DFG::Worklist::rememberCodeBlocks):
1657         (JSC::DFG::completeAllPlansForVM):
1658         (JSC::DFG::rememberCodeBlocks):
1659         (JSC::DFG::Worklist::clearCodeBlockMarks): Deleted.
1660         (JSC::DFG::clearCodeBlockMarks): Deleted.
1661         * dfg/DFGWorklist.h:
1662         (JSC::DFG::worklistForIndexOrNull): Renamed to use remembered set terminology.
1663
1664         * ftl/FTLJITFinalizer.cpp:
1665         (JSC::FTL::JITFinalizer::finalizeFunction):
1666
1667         * heap/CodeBlockSet.cpp:
1668         (JSC::CodeBlockSet::~CodeBlockSet):
1669         (JSC::CodeBlockSet::add):
1670         (JSC::CodeBlockSet::clearMarksForFullCollection):
1671         (JSC::CodeBlockSet::deleteUnmarkedAndUnreferenced): No need for a fixpoint
1672         anymore since the GC can tell us if we are live.
1673
1674         (JSC::CodeBlockSet::remove):
1675         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
1676         (JSC::CodeBlockSet::dump):
1677         (JSC::CodeBlockSet::clearMarksForEdenCollection): Deleted. No need for
1678         this logic anymore since the GC will clear our mark bit.
1679
1680         (JSC::CodeBlockSet::traceMarked): Deleted. No need for this marking
1681         fixpoint anymore either.
1682
1683         * heap/CodeBlockSet.h:
1684
1685         * heap/Heap.cpp:
1686         (JSC::Heap::markRoots): Moved some of this logic around to make the
1687         algorithm clearer. 
1688
1689         (JSC::Heap::deleteAllCodeBlocks): Deleting CodeBlocks can only clear
1690         pointers immediately; they won't fully delete until the next GC and sweep.
1691
1692         * interpreter/Interpreter.cpp:
1693         (JSC::eval):
1694         * jit/GCAwareJITStubRoutine.h: CodeBlock is owner now.
1695
1696         * jit/JITCode.h:
1697         (JSC::JITCode::isJIT):
1698         (JSC::JITCode::isLowerTier):
1699         (JSC::JITCode::timeToLive): Deleted.
1700
1701         * jit/JITOpcodes.cpp:
1702         (JSC::JIT::emit_op_enter): CodeBlock is owner now.
1703
1704         * jit/JITOperations.cpp:
1705         * jit/JITToDFGDeferredCompilationCallback.cpp:
1706         (JSC::JITToDFGDeferredCompilationCallback::create):
1707         (JSC::JITToDFGDeferredCompilationCallback::compilationDidBecomeReadyAsynchronously):
1708         (JSC::JITToDFGDeferredCompilationCallback::compilationDidComplete):
1709         * jit/JITToDFGDeferredCompilationCallback.h:
1710
1711         * jit/Repatch.cpp:
1712         (JSC::tryCacheGetByID):
1713         (JSC::tryCachePutByID):
1714         (JSC::tryRepatchIn):
1715         (JSC::linkFor):
1716         (JSC::linkPolymorphicCall):
1717         * llint/LLIntSlowPaths.cpp:
1718         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1719         (JSC::LLInt::setUpCall):
1720         * runtime/CommonSlowPaths.cpp:
1721         (JSC::SLOW_PATH_DECL): 
1722         * runtime/CommonSlowPaths.h:
1723         (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
1724         (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal): CodeBlock is owner now.
1725
1726         * runtime/Executable.cpp:
1727         (JSC::ExecutableBase::clearCode): Provide a generic clearCode() so that
1728         it can be used on any Executable. This fixes a very subtle bug where
1729         deleteAllCode() does not remove CodeBlocks from non-function executables
1730         that have been saved in stack traces.
1731
1732         (JSC::ScriptExecutable::installCode): WriteBarrier requires special
1733         handling for pointers that may be null.
1734
1735         (JSC::ScriptExecutable::newCodeBlockFor):
1736         (JSC::ScriptExecutable::newReplacementCodeBlockFor):
1737         (JSC::ScriptExecutable::prepareForExecutionImpl): Update for interface
1738         changes.
1739
1740         (JSC::EvalExecutable::visitChildren):
1741         (JSC::ProgramExecutable::visitChildren):
1742         (JSC::ModuleProgramExecutable::visitChildren):
1743         (JSC::FunctionExecutable::visitChildren):
1744         (JSC::WebAssemblyExecutable::visitChildren): Visit weakly because we want
1745         to participate in jettisoning.
1746
1747         (JSC::WebAssemblyExecutable::prepareForExecution):
1748         (JSC::EvalExecutable::clearCode): Deleted.
1749         (JSC::ProgramExecutable::clearCode): Deleted.
1750         (JSC::ModuleProgramExecutable::clearCode): Deleted.
1751         (JSC::FunctionExecutable::clearCode): Deleted.
1752         (JSC::WebAssemblyExecutable::clearCode): Deleted.
1753
1754         * runtime/Executable.h:
1755         (JSC::ExecutableBase::generatedJITCodeForCall):
1756         (JSC::ScriptExecutable::prepareForExecution):
1757         (JSC::ExecutableBase::clearCodeVirtual): Deleted.
1758
1759         * runtime/VM.cpp:
1760         (JSC::VM::VM):
1761         * runtime/VM.h: Provide structures because our GC requires it.
1762
1763 2015-10-01  Mark Lam  <mark.lam@apple.com>
1764
1765         Remove unnecessary SpecialFastCaseProfiles.
1766         https://bugs.webkit.org/show_bug.cgi?id=149729
1767
1768         Reviewed by Saam Barati.
1769
1770         The current baseline code creates special fast case profiles records for
1771         bytecodes that don't need them.  This was done to keep the DFG from crashing when
1772         it searches for such a profile and don't find one.  Instead, we will fix the code
1773         to check for the existence of the profile before dereferencing it to get a count.
1774
1775         * bytecode/CodeBlock.h:
1776         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
1777         (JSC::CodeBlock::couldTakeSpecialFastCase):
1778         (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
1779         (JSC::CodeBlock::numberOfArrayProfiles):
1780         (JSC::CodeBlock::arrayProfiles):
1781         (JSC::CodeBlock::addArrayProfile):
1782         (JSC::CodeBlock::likelyToTakeSpecialFastCase): Deleted.  Not used.
1783         (JSC::CodeBlock::likelyToTakeAnySlowCase): Deleted.   Not used.
1784         * jit/JITArithmetic.cpp:
1785
1786         (JSC::JIT::compileBinaryArithOp):
1787         - Only op_mul needs the profile.  So, only allocate it in the op_mul case.
1788
1789         (JSC::JIT::emit_op_mul):
1790         - These op_mul cases create the profile but never increments its counter.
1791           Hence, we can get rid of these.
1792
1793 2015-10-01  Keith Miller  <keith_miller@apple.com>
1794
1795         [ES6] Add TypedArray.prototype functionality.
1796         https://bugs.webkit.org/show_bug.cgi?id=148035
1797
1798         Reviewed by Geoffrey Garen.
1799
1800         This patch should add most of the functionality for
1801         the prototype properties of TypedArray objects in ES6.
1802         There are a few exceptions to this, which will be added
1803         in upcoming patches:
1804
1805         1) First we do not use the species constructor for some
1806         of the TypedArray prototype functions (namely: map, filter,
1807         slice, and subarray). That will need to be added when
1808         species constructors are finished.
1809
1810         2) TypedArrays still have a length, byteOffset, byteLength,
1811         and buffer are still attached to the TypedArray instance (in
1812         the spec they are on the TypedArray.prototype instance object)
1813         since the JIT currently assumes those properties are fixed.
1814
1815         3) The TypedArray.constructor property is not added yet
1816         as it should point to the TypedArray instance object,
1817         which will be added in a future patch.
1818
1819         * CMakeLists.txt:
1820         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1821         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1822         * JavaScriptCore.xcodeproj/project.pbxproj:
1823         * builtins/TypedArray.prototype.js: Added.
1824         (every):
1825         (find):
1826         (findIndex):
1827         (forEach):
1828         (some):
1829         (sort.min):
1830         (sort.merge):
1831         (sort.mergeSort):
1832         (sort):
1833         (reduce):
1834         (reduceRight):
1835         (map):
1836         (filter):
1837         (toLocaleString):
1838         * runtime/ArrayPrototype.cpp:
1839         * runtime/ArrayPrototype.h:
1840         * runtime/CommonIdentifiers.h:
1841         * runtime/JSGenericTypedArrayView.h:
1842         (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
1843         (JSC::JSGenericTypedArrayView::setRangeToValue):
1844         (JSC::JSGenericTypedArrayView::sort):
1845         (JSC::JSGenericTypedArrayView::purifyArray):
1846         (JSC::JSGenericTypedArrayView::sortComparison):
1847         (JSC::JSGenericTypedArrayView::sortFloat):
1848         * runtime/JSGenericTypedArrayViewInlines.h:
1849         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
1850         (JSC::argumentClampedIndexFromStartOrEnd):
1851         (JSC::genericTypedArrayViewProtoFuncSet):
1852         (JSC::genericTypedArrayViewProtoFuncEntries):
1853         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
1854         (JSC::genericTypedArrayViewProtoFuncFill):
1855         (JSC::genericTypedArrayViewProtoFuncIndexOf):
1856         (JSC::genericTypedArrayViewProtoFuncJoin):
1857         (JSC::genericTypedArrayViewProtoFuncKeys):
1858         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
1859         (JSC::genericTypedArrayViewProtoGetterFuncLength):
1860         (JSC::genericTypedArrayViewProtoGetterFuncByteLength):
1861         (JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
1862         (JSC::genericTypedArrayViewProtoFuncReverse):
1863         (JSC::genericTypedArrayViewPrivateFuncSort):
1864         (JSC::genericTypedArrayViewProtoFuncSlice):
1865         (JSC::genericTypedArrayViewProtoFuncSubarray):
1866         (JSC::typedArrayViewProtoFuncValues):
1867         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
1868         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
1869         (JSC::genericTypedArrayViewProtoFuncSet): Deleted.
1870         (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
1871         * runtime/JSGlobalObject.cpp:
1872         (JSC::JSGlobalObject::init):
1873         * runtime/JSObject.h:
1874         * runtime/JSTypedArrayPrototypes.cpp:
1875         * runtime/JSTypedArrayPrototypes.h:
1876         * runtime/JSTypedArrayViewPrototype.cpp: Added.
1877         (JSC::typedArrayViewPrivateFuncLength):
1878         (JSC::typedArrayViewPrivateFuncSort):
1879         (JSC::typedArrayViewProtoFuncSet):
1880         (JSC::typedArrayViewProtoFuncEntries):
1881         (JSC::typedArrayViewProtoFuncCopyWithin):
1882         (JSC::typedArrayViewProtoFuncFill):
1883         (JSC::typedArrayViewProtoFuncLastIndexOf):
1884         (JSC::typedArrayViewProtoFuncIndexOf):
1885         (JSC::typedArrayViewProtoFuncJoin):
1886         (JSC::typedArrayViewProtoFuncKeys):
1887         (JSC::typedArrayViewProtoGetterFuncLength):
1888         (JSC::typedArrayViewProtoGetterFuncByteLength):
1889         (JSC::typedArrayViewProtoGetterFuncByteOffset):
1890         (JSC::typedArrayViewProtoFuncReverse):
1891         (JSC::typedArrayViewProtoFuncSubarray):
1892         (JSC::typedArrayViewProtoFuncSlice):
1893         (JSC::typedArrayViewProtoFuncValues):
1894         (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
1895         (JSC::JSTypedArrayViewPrototype::finishCreation):
1896         (JSC::JSTypedArrayViewPrototype::create):
1897         (JSC::JSTypedArrayViewPrototype::createStructure):
1898         * runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
1899         * tests/es6.yaml:
1900         * tests/stress/resources/standalone-pre.js: Added.
1901         (description):
1902         (debug):
1903         (escapeString):
1904         (testPassed):
1905         (testFailed):
1906         (areNumbersEqual):
1907         (areArraysEqual):
1908         (isMinusZero):
1909         (isTypedArray):
1910         (isResultCorrect):
1911         (stringify):
1912         (shouldBe):
1913         (dfgShouldBe):
1914         (shouldBeType):
1915         (shouldBeTrue):
1916         (shouldBeFalse):
1917         (shouldBeNaN):
1918         (shouldBeNull):
1919         (shouldBeEqualToString):
1920         (shouldBeUndefined):
1921         (shouldNotThrow):
1922         (shouldThrow):
1923         (dfgCompiled):
1924         (dfgIncrement):
1925         (noInline):
1926         (finishJSTest):
1927         * tests/stress/resources/typedarray-test-helper-functions.js: Added.
1928         (forEachTypedArray):
1929         (isSameFunctionForEachTypedArrayPrototype.eq):
1930         (isSameFunctionForEachTypedArrayPrototype):
1931         (hasSameValues):
1932         (foo):
1933         (testPrototypeFunctionHelper):
1934         (testPrototypeFunctionOnSigned):
1935         (testPrototypeFunctionOnFloat):
1936         (testPrototypeFunction):
1937         (tester):
1938         (testPrototypeReceivesArray):
1939         * tests/stress/typedarray-copyWithin.js: Added.
1940         * tests/stress/typedarray-every.js: Added.
1941         (isBigEnough):
1942         (isBigEnoughAndChange):
1943         (isBigEnoughAndException):
1944         * tests/stress/typedarray-fill.js: Added.
1945         * tests/stress/typedarray-filter.js: Added.
1946         (keepEven):
1947         (keepEvenAndChange):
1948         (isBigEnoughAndException):
1949         * tests/stress/typedarray-find.js: Added.
1950         (keepEven):
1951         (keepEvenAndChange):
1952         (isBigEnoughAndException):
1953         * tests/stress/typedarray-findIndex.js: Added.
1954         (keepEven):
1955         (keepEvenAndChange):
1956         (isBigEnoughAndException):
1957         * tests/stress/typedarray-forEach.js: Added.
1958         (checkCorrect.let.list):
1959         (checkCorrect):
1960         (createChecker):
1961         (foo):
1962         (changeArray):
1963         (isBigEnoughAndException):
1964         * tests/stress/typedarray-indexOf.js: Added.
1965         (keepEven):
1966         * tests/stress/typedarray-lastIndexOf.js: Added.
1967         * tests/stress/typedarray-map.js: Added.
1968         (even):
1969         (evenAndChange):
1970         (isBigEnoughAndException):
1971         * tests/stress/typedarray-reduce.js: Added.
1972         (createArray):
1973         (sum):
1974         (createArrayAndChange):
1975         (isBigEnoughAndException):
1976         * tests/stress/typedarray-reduceRight.js: Added.
1977         (createArray):
1978         (sum):
1979         (createArrayAndChange):
1980         (isBigEnoughAndException):
1981         * tests/stress/typedarray-slice.js: Added.
1982         * tests/stress/typedarray-some.js: Added.
1983         (isBigEnough):
1984         (isBigEnoughAndChange):
1985         (isBigEnoughAndException):
1986         * tests/stress/typedarray-sort.js: Added.
1987         (sortBackwards):
1988         (compareException):
1989
1990 2015-10-01  Yusuke Suzuki  <utatane.tea@gmail.com>
1991
1992         Introduce SymbolUse optimization into CompareEq and CompareStrictEq
1993         https://bugs.webkit.org/show_bug.cgi?id=149616
1994
1995         Reviewed by Saam Barati.
1996
1997         Since ES6 Symbols are used as an enum value[1] (And WebKit inspector do so for Esprima's type of nodes),
1998         optimizing equality comparison for symbols makes much sense.
1999
2000         This patch leverages SymbolUse for CompareEq and CompareStrictEq.
2001         Optimizations for both DFG and FTL are implemented.
2002
2003         [1]: http://www.2ality.com/2014/12/es6-symbols.html
2004
2005         * dfg/DFGAbstractInterpreterInlines.h:
2006         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2007         * dfg/DFGFixupPhase.cpp:
2008         (JSC::DFG::FixupPhase::fixupNode):
2009         * dfg/DFGNode.h:
2010         (JSC::DFG::Node::shouldSpeculateSymbol):
2011         * dfg/DFGSpeculativeJIT.cpp:
2012         (JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
2013         (JSC::DFG::SpeculativeJIT::compare):
2014         (JSC::DFG::SpeculativeJIT::compileStrictEq):
2015         (JSC::DFG::SpeculativeJIT::extractStringImplFromBinarySymbols):
2016         (JSC::DFG::SpeculativeJIT::compileSymbolEquality):
2017         (JSC::DFG::SpeculativeJIT::compilePeepHoleSymbolEquality):
2018         * dfg/DFGSpeculativeJIT.h:
2019         * ftl/FTLCapabilities.cpp:
2020         (JSC::FTL::canCompile):
2021         * ftl/FTLLowerDFGToLLVM.cpp:
2022         (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareEq):
2023         (JSC::FTL::DFG::LowerDFGToLLVM::compileCompareStrictEq):
2024         * tests/stress/symbol-equality.js: Added.
2025         (shouldBe):
2026         (equal):
2027         (strictEqual):
2028         (list.forEach.result.set 1):
2029
2030 2015-10-01  Youenn Fablet  <youenn.fablet@crf.canon.fr>
2031
2032         [Streams API] Add support for private WebCore JS builtins functions
2033         https://bugs.webkit.org/show_bug.cgi?id=149518
2034
2035         Reviewed by Darin Adler.
2036
2037         Adding API to add private identifiers on the fly.
2038         This is used to support private JS Builtin functions/private JS Builtin names in WebCore.
2039
2040         * builtins/BuiltinNames.h:
2041         (JSC::BuiltinNames::appendExternalName):
2042         * runtime/CommonIdentifiers.cpp:
2043         (JSC::CommonIdentifiers::appendExternalName):
2044         * runtime/CommonIdentifiers.h:
2045
2046 2015-09-30  Jaehun Lim  <ljaehun.lim@samsung.com>
2047
2048         Unreviewed, cleanup after r190385
2049
2050         TypedArray.prototype.js is removed at r190385.
2051         Remove it from CMakeLists.txt as well.
2052
2053         * CMakeLists.txt:
2054
2055 2015-09-30  Commit Queue  <commit-queue@webkit.org>
2056
2057         Unreviewed, rolling out r190367 and r190373.
2058         https://bugs.webkit.org/show_bug.cgi?id=149694
2059
2060         Windows build broken (Requested by smfr on #webkit).
2061
2062         Reverted changesets:
2063
2064         "[ES6] Add TypedArray.prototype functionality."
2065         https://bugs.webkit.org/show_bug.cgi?id=148035
2066         http://trac.webkit.org/changeset/190367
2067
2068         "Unreviewed Windows buildfix."
2069         http://trac.webkit.org/changeset/190373
2070
2071 2015-09-30  Keith Miller  <keith_miller@apple.com>
2072
2073         Unreviewed Windows buildfix.
2074
2075         * CMakeLists.txt:
2076
2077 2015-09-30  Michael Saboff  <msaboff@apple.com>
2078
2079         Relanding r190289 with the following two fixes:
2080
2081          1. REGRESSION(r190289): It made Speedometer/Full.html performance test fail
2082             https://bugs.webkit.org/show_bug.cgi?id=149621
2083
2084             Reviewed by Saam Barati.
2085
2086             We need to restore callee saves for both the fast and slow paths before making a
2087             tail call in the FTL.
2088
2089             * ftl/FTLJSCallBase.cpp:
2090             (JSC::FTL::JSCallBase::emit):
2091
2092          2. [ARM] REGRESSION(r190289): It made 374 tests crash on 32 bit ARM Linux
2093             https://bugs.webkit.org/show_bug.cgi?id=149619
2094
2095             Reviewed by Filip Pizlo.
2096
2097             Need to check for ARMv7_TRADITIONAL and ARMv7 in addition to ARM in "if"
2098             statement to handle platforms with a link register.
2099             
2100             * llint/LowLevelInterpreter.asm:
2101             (prepareForTailCall):
2102
2103 2015-09-30  Keith Miller  <keith_miller@apple.com>
2104
2105         [ES6] Add TypedArray.prototype functionality.
2106         https://bugs.webkit.org/show_bug.cgi?id=148035
2107
2108         Reviewed by Geoffrey Garen.
2109
2110         This patch should add most of the functionality for
2111         the prototype properties of TypedArray objects in ES6.
2112         There are a few exceptions to this, which will be added
2113         in upcoming patches:
2114
2115         1) First we do not use the species constructor for some
2116         of the TypedArray prototype functions (namely: map, filter,
2117         slice, and subarray). That will need to be added when
2118         species constructors are finished.
2119
2120         2) TypedArrays still have a length, byteOffset, byteLength,
2121         and buffer are still attached to the TypedArray instance (in
2122         the spec they are on the TypedArray.prototype instance object)
2123         since the JIT currently assumes those properties are fixed.
2124
2125         3) The TypedArray.constructor property is not added yet
2126         as it should point to the TypedArray instance object,
2127         which will be added in a future patch.
2128
2129         * CMakeLists.txt:
2130         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2131         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2132         * JavaScriptCore.xcodeproj/project.pbxproj:
2133         * builtins/TypedArray.prototype.js: Added.
2134         (every):
2135         (find):
2136         (findIndex):
2137         (forEach):
2138         (some):
2139         (sort.min):
2140         (sort.merge):
2141         (sort.mergeSort):
2142         (sort):
2143         (reduce):
2144         (reduceRight):
2145         (map):
2146         (filter):
2147         (toLocaleString):
2148         * runtime/ArrayPrototype.cpp:
2149         * runtime/ArrayPrototype.h:
2150         * runtime/CommonIdentifiers.h:
2151         * runtime/JSGenericTypedArrayView.h:
2152         (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
2153         (JSC::JSGenericTypedArrayView::setRangeToValue):
2154         (JSC::JSGenericTypedArrayView::sort):
2155         (JSC::JSGenericTypedArrayView::purifyArray):
2156         (JSC::JSGenericTypedArrayView::sortComparison):
2157         (JSC::JSGenericTypedArrayView::sortFloat):
2158         * runtime/JSGenericTypedArrayViewInlines.h:
2159         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
2160         (JSC::argumentClampedIndexFromStartOrEnd):
2161         (JSC::genericTypedArrayViewProtoFuncSet):
2162         (JSC::genericTypedArrayViewProtoFuncEntries):
2163         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
2164         (JSC::genericTypedArrayViewProtoFuncFill):
2165         (JSC::genericTypedArrayViewProtoFuncIndexOf):
2166         (JSC::genericTypedArrayViewProtoFuncJoin):
2167         (JSC::genericTypedArrayViewProtoFuncKeys):
2168         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
2169         (JSC::genericTypedArrayViewProtoGetterFuncLength):
2170         (JSC::genericTypedArrayViewProtoGetterFuncByteLength):
2171         (JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
2172         (JSC::genericTypedArrayViewProtoFuncReverse):
2173         (JSC::genericTypedArrayViewPrivateFuncSort):
2174         (JSC::genericTypedArrayViewProtoFuncSlice):
2175         (JSC::genericTypedArrayViewProtoFuncSubarray):
2176         (JSC::typedArrayViewProtoFuncValues):
2177         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
2178         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
2179         (JSC::genericTypedArrayViewProtoFuncSet): Deleted.
2180         (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
2181         * runtime/JSGlobalObject.cpp:
2182         (JSC::JSGlobalObject::init):
2183         * runtime/JSObject.h:
2184         * runtime/JSTypedArrayPrototypes.cpp:
2185         * runtime/JSTypedArrayPrototypes.h:
2186         * runtime/JSTypedArrayViewPrototype.cpp: Added.
2187         (JSC::typedArrayViewPrivateFuncLength):
2188         (JSC::typedArrayViewPrivateFuncSort):
2189         (JSC::typedArrayViewProtoFuncSet):
2190         (JSC::typedArrayViewProtoFuncEntries):
2191         (JSC::typedArrayViewProtoFuncCopyWithin):
2192         (JSC::typedArrayViewProtoFuncFill):
2193         (JSC::typedArrayViewProtoFuncLastIndexOf):
2194         (JSC::typedArrayViewProtoFuncIndexOf):
2195         (JSC::typedArrayViewProtoFuncJoin):
2196         (JSC::typedArrayViewProtoFuncKeys):
2197         (JSC::typedArrayViewProtoGetterFuncLength):
2198         (JSC::typedArrayViewProtoGetterFuncByteLength):
2199         (JSC::typedArrayViewProtoGetterFuncByteOffset):
2200         (JSC::typedArrayViewProtoFuncReverse):
2201         (JSC::typedArrayViewProtoFuncSubarray):
2202         (JSC::typedArrayViewProtoFuncSlice):
2203         (JSC::typedArrayViewProtoFuncValues):
2204         (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
2205         (JSC::JSTypedArrayViewPrototype::finishCreation):
2206         (JSC::JSTypedArrayViewPrototype::create):
2207         (JSC::JSTypedArrayViewPrototype::createStructure):
2208         * runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
2209         * tests/stress/resources/standalone-pre.js: Added.
2210         (description):
2211         (debug):
2212         (escapeString):
2213         (testPassed):
2214         (testFailed):
2215         (areNumbersEqual):
2216         (areArraysEqual):
2217         (isMinusZero):
2218         (isTypedArray):
2219         (isResultCorrect):
2220         (stringify):
2221         (shouldBe):
2222         (dfgShouldBe):
2223         (shouldBeType):
2224         (shouldBeTrue):
2225         (shouldBeFalse):
2226         (shouldBeNaN):
2227         (shouldBeNull):
2228         (shouldBeEqualToString):
2229         (shouldBeUndefined):
2230         (shouldNotThrow):
2231         (shouldThrow):
2232         (dfgCompiled):
2233         (dfgIncrement):
2234         (noInline):
2235         (finishJSTest):
2236         * tests/stress/resources/typedarray-test-helper-functions.js: Added.
2237         (forEachTypedArray):
2238         (isSameFunctionForEachTypedArrayPrototype.eq):
2239         (isSameFunctionForEachTypedArrayPrototype):
2240         (hasSameValues):
2241         (.foo):
2242         (testPrototypeFunctionHelper):
2243         (testPrototypeFunctionOnSigned):
2244         (testPrototypeFunctionOnFloat):
2245         (testPrototypeFunction):
2246         (.tester):
2247         (testPrototypeReceivesArray):
2248         * tests/stress/typedarray-copyWithin.js: Added.
2249         * tests/stress/typedarray-every.js: Added.
2250         (isBigEnough):
2251         (isBigEnoughAndChange):
2252         (isBigEnoughAndException):
2253         * tests/stress/typedarray-fill.js: Added.
2254         * tests/stress/typedarray-filter.js: Added.
2255         (keepEven):
2256         (keepEvenAndChange):
2257         (isBigEnoughAndException):
2258         * tests/stress/typedarray-find.js: Added.
2259         (keepEven):
2260         (keepEvenAndChange):
2261         (isBigEnoughAndException):
2262         * tests/stress/typedarray-findIndex.js: Added.
2263         (keepEven):
2264         (keepEvenAndChange):
2265         (isBigEnoughAndException):
2266         * tests/stress/typedarray-forEach.js: Added.
2267         (.checkCorrect.let.list):
2268         (.checkCorrect):
2269         (createChecker):
2270         (foo):
2271         (changeArray):
2272         (isBigEnoughAndException):
2273         * tests/stress/typedarray-indexOf.js: Added.
2274         (keepEven):
2275         * tests/stress/typedarray-lastIndexOf.js: Added.
2276         * tests/stress/typedarray-map.js: Added.
2277         (even):
2278         (evenAndChange):
2279         (isBigEnoughAndException):
2280         * tests/stress/typedarray-reduce.js: Added.
2281         (createArray):
2282         (sum):
2283         (createArrayAndChange):
2284         (isBigEnoughAndException):
2285         * tests/stress/typedarray-reduceRight.js: Added.
2286         (createArray):
2287         (sum):
2288         (createArrayAndChange):
2289         (isBigEnoughAndException):
2290         * tests/stress/typedarray-slice.js: Added.
2291         * tests/stress/typedarray-some.js: Added.
2292         (isBigEnough):
2293         (isBigEnoughAndChange):
2294         (isBigEnoughAndException):
2295         * tests/stress/typedarray-sort.js: Added.
2296         (sortBackwards):
2297         (compareException):
2298
2299 2015-09-30  Commit Queue  <commit-queue@webkit.org>
2300
2301         Unreviewed, rolling out r190324.
2302         https://bugs.webkit.org/show_bug.cgi?id=149671
2303
2304         Caused flaky crashes, rdar://problem/22916304 (Requested by ap
2305         on #webkit).
2306
2307         Reverted changeset:
2308
2309         "ParallelHelperPool::runFunctionInParallel() shouldn't
2310         allocate, and ParallelHelperPool.h shouldn't be included
2311         everywhere"
2312         https://bugs.webkit.org/show_bug.cgi?id=149635
2313         http://trac.webkit.org/changeset/190324
2314
2315 2015-09-29  Commit Queue  <commit-queue@webkit.org>
2316
2317         Unreviewed, rolling out r190289.
2318         https://bugs.webkit.org/show_bug.cgi?id=149647
2319
2320         Crashing speedometer and some ARM32 tests (Requested by
2321         msaboff on #webkit).
2322
2323         Reverted changeset:
2324
2325         "[ES6] Implement tail calls in the FTL"
2326         https://bugs.webkit.org/show_bug.cgi?id=148664
2327         http://trac.webkit.org/changeset/190289
2328
2329 2015-09-29  Filip Pizlo  <fpizlo@apple.com>
2330
2331         ParallelHelperPool::runFunctionInParallel() shouldn't allocate, and ParallelHelperPool.h shouldn't be included everywhere
2332         https://bugs.webkit.org/show_bug.cgi?id=149635
2333
2334         Reviewed by Saam Barati.
2335
2336         It bugged me that this change caused a whole-world recompile. So, I changed the code so
2337         that ParallelHelperPool.h is only included by Heap.cpp and not by Heap.h.
2338
2339         * heap/Heap.cpp:
2340         (JSC::Heap::Heap):
2341         (JSC::Heap::markRoots):
2342         (JSC::Heap::copyBackingStores):
2343         * heap/Heap.h:
2344
2345 2015-09-29  Filip Pizlo  <fpizlo@apple.com>
2346
2347         GC copy phase spans too many files
2348         https://bugs.webkit.org/show_bug.cgi?id=149586
2349
2350         Reviewed by Andreas Kling.
2351
2352         This puts the core logic of the copy phase into Heap::copyBackingStores(). Now, instead of
2353         using many helpers in many places, the actual algorithm is all in one place.
2354
2355         This lets me do a lot of simplification.
2356
2357         - CopyVisitor no longer requires that you call startCopying() before, and doneCopying() and
2358           WTF::releaseFastMallocFreeMemoryForThisThread() after. The constructor and destructor now
2359           do this for you.
2360
2361         - CopyVisitor no longer contains the algorithm that drives copying. That's all in
2362           Heap::copyBackingStores() now. Basically, copyBackingStores() glues together the new
2363           WTF::ParallelVectorIterator with the copying algorithm that we used to have in
2364           CopyVisitor::copyFromShared().
2365
2366         - Lots of stuff that was in headers is now in .cpp files. That includes all non-hot-path
2367           code in CopyVisitor. Also, the code for copying in HeapInlines.h is now in
2368           ParallelVectorVisotor, and it's only included by Heap.cpp.
2369
2370         Overall, I like this direction for the GC. I don't think it's useful for Heap.cpp to have
2371         calls to algorithms in some other file, unless those algorithms are either reusable or just
2372         very dense. That's not actually true for the copy phase, and it's probably not true for
2373         some other stuff like marking. I'll probably do the same refactoring for marking in another
2374         bug.
2375
2376         This should have no effect on performance.
2377
2378         * heap/CopyVisitor.cpp:
2379         (JSC::CopyVisitor::CopyVisitor):
2380         (JSC::CopyVisitor::~CopyVisitor):
2381         (JSC::CopyVisitor::copyFromShared): Deleted.
2382         * heap/CopyVisitor.h:
2383         * heap/CopyVisitorInlines.h:
2384         (JSC::CopyVisitor::checkIfShouldCopy):
2385         (JSC::CopyVisitor::allocateNewSpaceSlow):
2386         (JSC::CopyVisitor::didCopy):
2387         (JSC::CopyVisitor::visitItem): Deleted.
2388         (JSC::CopyVisitor::startCopying): Deleted.
2389         (JSC::CopyVisitor::doneCopying): Deleted.
2390         * heap/Heap.cpp:
2391         (JSC::Heap::copyBackingStores):
2392         * heap/Heap.h:
2393         * heap/HeapInlines.h:
2394         (JSC::Heap::unregisterWeakGCMap):
2395         (JSC::Heap::getNextBlocksToCopy): Deleted.
2396
2397 2015-09-29  Youenn Fablet  <youenn.fablet@crf.canon.fr>
2398
2399         Add support for WebIDL JSBuiltin attributes
2400         https://bugs.webkit.org/show_bug.cgi?id=149554
2401
2402         Reviewed by Darin Adler.
2403
2404         * runtime/Lookup.cpp:
2405         (JSC::reifyStaticAccessor): Adding support for creating attribute getter from JS builtin functions.
2406         * runtime/Lookup.h:
2407         (JSC::HashTableValue::builtinAccessorGetterGenerator):
2408         (JSC::HashTableValue::builtinAccessorSetterGenerator):
2409         (JSC::reifyStaticProperties): Ensuring that builtin attributes are not treated as Builtin functions.
2410
2411 2015-09-28  Joseph Pecoraro  <pecoraro@apple.com>
2412
2413         Remove unused parseMemoryAmount
2414         https://bugs.webkit.org/show_bug.cgi?id=149611
2415
2416         Reviewed by Mark Lam.
2417
2418         * heap/HeapStatistics.cpp:
2419         (JSC::HeapStatistics::parseMemoryAmount): Deleted.
2420         * heap/HeapStatistics.h:
2421
2422 2015-09-28  Joseph Pecoraro  <pecoraro@apple.com>
2423
2424         Web Inspector: JSGlobalRuntimeAgent unintentionally overrides InspectorRuntimeAgent destruction handling
2425         https://bugs.webkit.org/show_bug.cgi?id=149537
2426
2427         Reviewed by Darin Adler.
2428
2429         * inspector/agents/JSGlobalObjectRuntimeAgent.h:
2430         * inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
2431         (Inspector::JSGlobalObjectRuntimeAgent::willDestroyFrontendAndBackend): Deleted.
2432         Do not override method, super class implementation is sufficient.
2433
2434         * JavaScriptCore.xcodeproj/project.pbxproj:
2435         Fix file ordering.
2436
2437         * inspector/agents/InspectorDebuggerAgent.h:
2438         Remove unused member variable.
2439
2440 2015-09-28  basile_clement@apple.com  <basile_clement@apple.com@268f45cc-cd09-0410-ab3c-d52691b4dbfc>
2441
2442         [ES6] Implement tail calls in the FTL
2443         https://bugs.webkit.org/show_bug.cgi?id=148664
2444
2445         Reviewed by Filip Pizlo.
2446
2447         This patch implements the tail call opcodes in the FTL, making tail
2448         calls available through all tiers. The changes are relatively
2449         straightforward, although the frame shuffler had to be extended to
2450         handle the possibility of running out of stack when spilling or
2451         building a slow path frame. The other tiers always ensure that we have
2452         enough stack space to build the new frame at the bottom of the old one,
2453         but that is not true for the FTL.
2454
2455         Moreover, for efficiency, this adds to the shuffler the ability to
2456         record the state of the TagTypeNumber, and to re-use the same register
2457         when doing several consecutive integer boxings with no spilling in
2458         between.
2459
2460         * JavaScriptCore.xcodeproj/project.pbxproj:
2461         * bytecode/ValueRecovery.h:
2462         (JSC::ValueRecovery::inRegister):
2463         * dfg/DFGByteCodeParser.cpp:
2464         (JSC::DFG::ByteCodeParser::handleInlining):
2465         (JSC::DFG::ByteCodeParser::parseBlock):
2466         * dfg/DFGClobberize.h:
2467         (JSC::DFG::clobberize):
2468         * dfg/DFGNode.h:
2469         (JSC::DFG::Node::isFunctionTerminal):
2470         * dfg/DFGSpeculativeJIT64.cpp:
2471         (JSC::DFG::SpeculativeJIT::emitCall):
2472         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2473         (JSC::DFG::TierUpCheckInjectionPhase::run):
2474         * ftl/FTLCapabilities.cpp:
2475         (JSC::FTL::canCompile):
2476         * ftl/FTLCompile.cpp:
2477         (JSC::FTL::mmAllocateDataSection):
2478         * ftl/FTLInlineCacheSize.cpp:
2479         (JSC::FTL::sizeOfTailCallVarargs):
2480         (JSC::FTL::sizeOfTailCallForwardVarargs):
2481         (JSC::FTL::sizeOfICFor):
2482         * ftl/FTLInlineCacheSize.h:
2483         * ftl/FTLJSCall.cpp:
2484         (JSC::FTL::JSCall::JSCall):
2485         * ftl/FTLJSCallBase.cpp:
2486         (JSC::FTL::JSCallBase::emit):
2487         (JSC::FTL::JSCallBase::link):
2488         * ftl/FTLJSCallBase.h:
2489         * ftl/FTLJSCallVarargs.cpp:
2490         (JSC::FTL::JSCallVarargs::JSCallVarargs):
2491         (JSC::FTL::JSCallVarargs::emit):
2492         * ftl/FTLJSTailCall.cpp: Added.
2493         (JSC::FTL::getRegisterWithAddend):
2494         (JSC::FTL::recoveryFor):
2495         (JSC::FTL::sizeFor):
2496         (JSC::FTL::JSTailCall::JSTailCall):
2497         (JSC::FTL::m_instructionOffset):
2498         (JSC::FTL::JSTailCall::emit):
2499         * ftl/FTLJSTailCall.h: Copied from Source/JavaScriptCore/ftl/FTLJSCallBase.h.
2500         (JSC::FTL::JSTailCall::stackmapID):
2501         (JSC::FTL::JSTailCall::estimatedSize):
2502         (JSC::FTL::JSTailCall::numArguments):
2503         (JSC::FTL::JSTailCall::operator<):
2504         * ftl/FTLLocation.h:
2505         (JSC::FTL::Location::operator bool):
2506         (JSC::FTL::Location::operator!):
2507         * ftl/FTLLowerDFGToLLVM.cpp:
2508         (JSC::FTL::DFG::LowerDFGToLLVM::lower):
2509         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
2510         (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
2511         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
2512         (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
2513         (JSC::FTL::DFG::LowerDFGToLLVM::exitValueForTailCall):
2514         * ftl/FTLState.h:
2515         * jit/AssemblyHelpers.cpp:
2516         (JSC::AssemblyHelpers::emitExceptionCheck):
2517         * jit/CallFrameShuffleData.h:
2518         * jit/CallFrameShuffler.cpp:
2519         (JSC::CallFrameShuffler::CallFrameShuffler):
2520         (JSC::CallFrameShuffler::dump):
2521         (JSC::CallFrameShuffler::spill):
2522         (JSC::CallFrameShuffler::extendFrameIfNeeded):
2523         (JSC::CallFrameShuffler::prepareForSlowPath):
2524         (JSC::CallFrameShuffler::prepareAny):
2525         * jit/CallFrameShuffler.h:
2526         (JSC::CallFrameShuffler::restoreGPR):
2527         (JSC::CallFrameShuffler::getFreeRegister):
2528         (JSC::CallFrameShuffler::getFreeTempGPR):
2529         (JSC::CallFrameShuffler::ensureTempGPR):
2530         (JSC::CallFrameShuffler::addNew):
2531         * jit/CallFrameShuffler64.cpp:
2532         (JSC::CallFrameShuffler::emitBox):
2533         (JSC::CallFrameShuffler::tryAcquireTagTypeNumber):
2534         * jit/JITCall.cpp:
2535         (JSC::JIT::compileOpCall):
2536         * jit/Reg.h:
2537         (JSC::Reg::Reg):
2538         (JSC::Reg::isHashTableDeletedValue):
2539         (JSC::Reg::deleted):
2540         (JSC::RegHash::hash):
2541         (JSC::RegHash::equal):
2542         * test/es6.yaml:
2543
2544 2015-09-28  Keith Miller  <keith_miller@apple.com>
2545
2546         ObjectPropertyConditionSet::mergedWith does not produce a minimal intersection.
2547         https://bugs.webkit.org/show_bug.cgi?id=149598
2548
2549         Reviewed by Michael Saboff.
2550
2551         mergedWith sometimes creates duplicates of an ObjectPropertyCondition, which causes GetByIdVariant
2552         in believe that the condition has more than one slotBaseCondition when only one was necessary.
2553
2554         * bytecode/ObjectPropertyConditionSet.cpp:
2555         (JSC::ObjectPropertyConditionSet::mergedWith):
2556
2557 2015-09-26  Filip Pizlo  <fpizlo@apple.com>
2558
2559         Unreviewed, fix debug tests. Before marking, we need to call registerGCThreads().
2560
2561         * heap/Heap.cpp:
2562         (JSC::Heap::markRoots):
2563
2564 2015-09-24  Filip Pizlo  <fpizlo@apple.com>
2565
2566         VMs should share GC threads
2567         https://bugs.webkit.org/show_bug.cgi?id=149433
2568         rdar://problem/12859344
2569
2570         Reviewed by Geoffrey Garen.
2571
2572         This changes the GC to use a new WTF abstraction for parallelism called ParallelHelperPool.
2573         This allows us to remove GCThread and all of the GCPhase machinery. This kills a lot of
2574         code and also gives our GC magical thread sharing powers. If two GCs in two different VMs
2575         fire at the same time, then they will both get a random subset of the available shared GC
2576         threads. If one GC happens before the other, then it will probably get all of the available
2577         threads. If a GC happens while another VM already started GCing, then it will probably not
2578         get any helper threads. This is probably fine, since in multi-VM scenarios we have no
2579         reason to optimize for anything other than total throughput.
2580
2581         The GC has one static helper pool. This pool is available via JSC::heapHelperPool(). It
2582         would be OK for other parts of JSC to use it in the future for parallel tasks. Each Heap
2583         instance has a helper client attached to the pool.
2584
2585         The marking phase tells the ParallelHelperClient to asynchronously run a function that
2586         joins parallel marking and finishes once marking reaches termination. It uses the
2587         client.setFunction() idiom where the threads share work with each other using a specialized
2588         worklist. The ParallelHelperPool is not involved in deciding when threads should terminate.
2589
2590         The copying phase tells the ParallelHelperClient to run a copying function in parallel. It
2591         uses the client.runFunctionInParallel() idiom. The copying function gets work from the
2592         m_blocksToCopy worklist inside Heap.
2593
2594         To test that multiple VMs work properly, this adds a multi-VM test to testapi.mm. This test
2595         creates five concurrent VMs and has each of them allocate about 30MB of memory before doing
2596         a full GC. I've confirmed that this tests uses only 6 total GC threads on my 8-core
2597         computer (this is correct since we are currently configured for 7-way parallelism).
2598
2599         This shouldn't affect performance on benchmarks, but it will sure help apps with a lot of
2600         VM instances.
2601
2602         * CMakeLists.txt:
2603         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2604         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2605         * JavaScriptCore.xcodeproj/project.pbxproj:
2606         * assembler/AbstractMacroAssembler.h:
2607         * heap/GCThread.cpp: Removed.
2608         * heap/GCThread.h: Removed.
2609         * heap/Heap.cpp:
2610         (JSC::Heap::Heap):
2611         (JSC::Heap::~Heap):
2612         (JSC::Heap::isPagedOut):
2613         (JSC::Heap::markRoots):
2614         (JSC::Heap::copyBackingStores):
2615         (JSC::Heap::resetVisitors):
2616         (JSC::Heap::threadVisitCount):
2617         (JSC::Heap::threadBytesVisited):
2618         (JSC::Heap::threadBytesCopied):
2619         (JSC::Heap::startNextPhase): Deleted.
2620         (JSC::Heap::endCurrentPhase): Deleted.
2621         * heap/Heap.h:
2622         * heap/HeapHelperPool.cpp: Added.
2623         (JSC::heapHelperPool):
2624         * heap/HeapHelperPool.h: Added.
2625         * heap/MarkStack.cpp:
2626         (JSC::MarkStackArray::stealSomeCellsFrom):
2627         * heap/SlotVisitor.cpp:
2628         (JSC::SlotVisitor::didStartMarking):
2629         (JSC::SlotVisitor::reset):
2630         (JSC::SlotVisitor::drainFromShared):
2631         * jit/BinarySwitch.h:
2632         * runtime/CodeCache.h:
2633         * runtime/VM.h:
2634         * runtime/WeakRandom.h: Removed.
2635         * API/tests/testapi.mm:
2636
2637 2015-09-25  Saam barati  <sbarati@apple.com>
2638
2639         DFG should use PhantomLocal instead of Flush as liveness preservation mechanism in LiveCatchVariablesPreservationPhase
2640         https://bugs.webkit.org/show_bug.cgi?id=149575
2641
2642         Reviewed by Geoffrey Garen.
2643
2644         LiveCatchVariablesPreservationPhase is no longer forcing all live-at-catch 
2645         variables to be flushed to the stack. They are now kept alive to OSR exit 
2646         through PhantomLocal. This gives us a speed improvement for try-catch 
2647         programs (especially those that don't throw errors very often) because
2648         we can keep locals in registers instead of forcing them onto the stack.
2649
2650         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2651         (JSC::DFG::LiveCatchVariablePreservationPhase::LiveCatchVariablePreservationPhase):
2652         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
2653         (JSC::DFG::performLiveCatchVariablePreservationPhase):
2654         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::FlushLiveCatchVariablesInsertionPhase): Deleted.
2655         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::handleBlock): Deleted.
2656
2657 2015-09-25  Michael Saboff  <msaboff@apple.com>
2658
2659         FTLOSRExitCompiler incorrectly excludes FPR registers in callee saves loop
2660         https://bugs.webkit.org/show_bug.cgi?id=149540
2661
2662         Reviewed by Saam Barati.
2663
2664         Eliminated the incorrect check that callee saves registers are only GPRs.
2665
2666         * ftl/FTLOSRExitCompiler.cpp:
2667         (JSC::FTL::compileStub):
2668
2669 2015-09-25  Alex Christensen  <achristensen@webkit.org>
2670
2671         [Win] Switch to CMake
2672         https://bugs.webkit.org/show_bug.cgi?id=148111
2673
2674         Reviewed by Brent Fulgham.
2675
2676         * JavaScriptCore.vcxproj/JavaScriptCore.proj:
2677
2678 2015-09-24  Mark Lam  <mark.lam@apple.com>
2679
2680         Remove the use of "Immediate" in JIT function names.
2681         https://bugs.webkit.org/show_bug.cgi?id=149542
2682
2683         Reviewed by Geoffrey Garen.
2684
2685         We will rename the following:
2686             isOperandConstantImmediateDouble => isOperandConstantDouble
2687             isOperandConstantImmediateInt => isOperandConstantInt
2688             isOperandConstantImmediateChar => isOperandConstantChar
2689
2690             getOperandConstantImmediateInt => getOperandConstantInt
2691             getConstantOperandImmediateInt => getOperandConstantInt
2692
2693             emitJumpIfImmediateInteger => emitJumpIfInt
2694             emitJumpIfNotImmediateInteger => emitJumpIfNotInt
2695             emitJumpIfNotImmediateIntegers => emitJumpIfNotInt
2696             emitPatchableJumpIfNotImmediateInteger => emitPatchableJumpIfNotInt
2697             emitJumpSlowCaseIfNotImmediateInteger => emitJumpSlowCaseIfNotInt
2698             emitJumpSlowCaseIfNotImmediateNumber => emitJumpSlowCaseIfNotNumber
2699             emitJumpSlowCaseIfNotImmediateIntegers => emitJumpSlowCaseIfNotInt
2700             emitFastArithReTagImmediate => emitTagInt
2701             emitTagAsBoolImmediate => emitTagBool
2702             emitJumpIfImmediateNumber => emitJumpIfNumber
2703             emitJumpIfNotImmediateNumber => emitJumpIfNotNumber
2704             emitFastArithImmToInt - Deleted because this is an empty function.
2705             emitFastArithIntToImmNoCheck => emitTagInt
2706             emitPutImmediateToCallFrameHeader => emitPutToCallFrameHeader
2707
2708         This is purely a refactoring patch to do the renaming.  There is no behavior
2709         change.
2710
2711         * dfg/DFGJITCompiler.cpp:
2712         (JSC::DFG::JITCompiler::compileEntry):
2713         (JSC::DFG::JITCompiler::compileSetupRegistersForEntry):
2714         * jit/AssemblyHelpers.h:
2715         (JSC::AssemblyHelpers::emitPutToCallFrameHeader):
2716         (JSC::AssemblyHelpers::emitPutImmediateToCallFrameHeader): Deleted.
2717         * jit/JIT.cpp:
2718         (JSC::JIT::privateCompile):
2719         * jit/JIT.h:
2720         (JSC::JIT::emitStoreCell):
2721         (JSC::JIT::getSlowCase):
2722         * jit/JITArithmetic.cpp:
2723         (JSC::JIT::emit_op_negate):
2724         (JSC::JIT::emit_op_lshift):
2725         (JSC::JIT::emit_op_rshift):
2726         (JSC::JIT::emitSlow_op_rshift):
2727         (JSC::JIT::emit_op_urshift):
2728         (JSC::JIT::emitSlow_op_urshift):
2729         (JSC::JIT::emit_op_unsigned):
2730         (JSC::JIT::emit_compareAndJump):
2731         (JSC::JIT::emit_compareAndJumpSlow):
2732         (JSC::JIT::emit_op_bitand):
2733         (JSC::JIT::emit_op_inc):
2734         (JSC::JIT::emit_op_dec):
2735         (JSC::JIT::emit_op_mod):
2736         (JSC::JIT::compileBinaryArithOp):
2737         (JSC::JIT::compileBinaryArithOpSlowCase):
2738         (JSC::JIT::emit_op_add):
2739         (JSC::JIT::emitSlow_op_add):
2740         (JSC::JIT::emit_op_mul):
2741         (JSC::JIT::emitSlow_op_mul):
2742         (JSC::JIT::emit_op_div):
2743         (JSC::JIT::emitSlow_op_div):
2744         * jit/JITArithmetic32_64.cpp:
2745         (JSC::JIT::emit_compareAndJump):
2746         (JSC::JIT::emit_compareAndJumpSlow):
2747         (JSC::JIT::emit_op_lshift):
2748         (JSC::JIT::emitSlow_op_lshift):
2749         (JSC::JIT::emitRightShift):
2750         (JSC::JIT::emitRightShiftSlowCase):
2751         (JSC::JIT::emit_op_bitand):
2752         (JSC::JIT::emitSlow_op_bitand):
2753         (JSC::JIT::emit_op_bitor):
2754         (JSC::JIT::emitSlow_op_bitor):
2755         (JSC::JIT::emit_op_bitxor):
2756         (JSC::JIT::emitSlow_op_bitxor):
2757         (JSC::JIT::emit_op_add):
2758         (JSC::JIT::emitSlow_op_add):
2759         (JSC::JIT::emit_op_sub):
2760         (JSC::JIT::emitSlow_op_sub):
2761         * jit/JITInlines.h:
2762         (JSC::JIT::emitArrayStorageGetByVal):
2763         (JSC::JIT::isOperandConstantDouble):
2764         (JSC::JIT::isOperandConstantChar):
2765         (JSC::JIT::emitJumpSlowCaseIfNotJSCell):
2766         (JSC::JIT::isOperandConstantInt):
2767         (JSC::JIT::getOperandConstantInt):
2768         (JSC::JIT::emitGetVirtualRegisters):
2769         (JSC::JIT::emitLoadInt32ToDouble):
2770         (JSC::JIT::emitJumpIfInt):
2771         (JSC::JIT::emitJumpIfNotInt):
2772         (JSC::JIT::emitPatchableJumpIfNotInt):
2773         (JSC::JIT::emitJumpSlowCaseIfNotInt):
2774         (JSC::JIT::emitJumpSlowCaseIfNotNumber):
2775         (JSC::JIT::emitTagBool):
2776         (JSC::JIT::isOperandConstantImmediateDouble): Deleted.
2777         (JSC::JIT::isOperandConstantImmediateChar): Deleted.
2778         (JSC::JIT::isOperandConstantImmediateInt): Deleted.
2779         (JSC::JIT::getOperandConstantImmediateInt): Deleted.
2780         (JSC::JIT::getConstantOperandImmediateInt): Deleted.
2781         (JSC::JIT::emitJumpIfImmediateInteger): Deleted.
2782         (JSC::JIT::emitJumpIfNotImmediateInteger): Deleted.
2783         (JSC::JIT::emitPatchableJumpIfNotImmediateInteger): Deleted.
2784         (JSC::JIT::emitJumpIfNotImmediateIntegers): Deleted.
2785         (JSC::JIT::emitJumpSlowCaseIfNotImmediateInteger): Deleted.
2786         (JSC::JIT::emitJumpSlowCaseIfNotImmediateIntegers): Deleted.
2787         (JSC::JIT::emitJumpSlowCaseIfNotImmediateNumber): Deleted.
2788         (JSC::JIT::emitFastArithReTagImmediate): Deleted.
2789         (JSC::JIT::emitTagAsBoolImmediate): Deleted.
2790         * jit/JITOpcodes.cpp:
2791         (JSC::JIT::emit_op_is_undefined):
2792         (JSC::JIT::emit_op_is_boolean):
2793         (JSC::JIT::emit_op_is_number):
2794         (JSC::JIT::emit_op_is_string):
2795         (JSC::JIT::emit_op_is_object):
2796         (JSC::JIT::emit_op_jfalse):
2797         (JSC::JIT::emit_op_eq):
2798         (JSC::JIT::emit_op_jtrue):
2799         (JSC::JIT::emit_op_neq):
2800         (JSC::JIT::emit_op_bitxor):
2801         (JSC::JIT::emit_op_bitor):
2802         (JSC::JIT::compileOpStrictEq):
2803         (JSC::JIT::emit_op_to_number):
2804         (JSC::JIT::emit_op_eq_null):
2805         (JSC::JIT::emit_op_neq_null):
2806         (JSC::JIT::emitSlow_op_eq):
2807         (JSC::JIT::emitSlow_op_neq):
2808         (JSC::JIT::emit_op_profile_type):
2809         * jit/JITOpcodes32_64.cpp:
2810         (JSC::JIT::privateCompileCTINativeCall):
2811         * jit/JITPropertyAccess.cpp:
2812         (JSC::JIT::emit_op_get_by_val):
2813         (JSC::JIT::emit_op_put_by_val):
2814         (JSC::JIT::emitGenericContiguousPutByVal):
2815         (JSC::JIT::emit_op_put_by_id):
2816         (JSC::JIT::emitIntTypedArrayPutByVal):
2817         (JSC::JIT::emitFloatTypedArrayPutByVal):
2818         * jit/JSInterfaceJIT.h:
2819         (JSC::JSInterfaceJIT::emitJumpIfNotJSCell):
2820         (JSC::JSInterfaceJIT::emitJumpIfNumber):
2821         (JSC::JSInterfaceJIT::emitJumpIfNotNumber):
2822         (JSC::JSInterfaceJIT::emitLoadDouble):
2823         (JSC::JSInterfaceJIT::emitTagInt):
2824         (JSC::JSInterfaceJIT::emitPutToCallFrameHeader):
2825         (JSC::JSInterfaceJIT::emitJumpIfImmediateNumber): Deleted.
2826         (JSC::JSInterfaceJIT::emitJumpIfNotImmediateNumber): Deleted.
2827         (JSC::JSInterfaceJIT::emitFastArithImmToInt): Deleted.
2828         (JSC::JSInterfaceJIT::emitFastArithIntToImmNoCheck): Deleted.
2829         (JSC::JSInterfaceJIT::emitPutImmediateToCallFrameHeader): Deleted.
2830         * jit/ThunkGenerators.cpp:
2831         (JSC::nativeForGenerator):
2832         * wasm/WASMFunctionCompiler.h:
2833         (JSC::WASMFunctionCompiler::startFunction):
2834         (JSC::WASMFunctionCompiler::endFunction):
2835
2836 2015-09-24  Michael Saboff  <msaboff@apple.com>
2837
2838         [ES6] Implement tail calls in the DFG
2839         https://bugs.webkit.org/show_bug.cgi?id=148663
2840
2841         Reviewed by Filip Pizlo.
2842
2843         jsc-tailcall: Implement the tail call opcodes in the DFG
2844         https://bugs.webkit.org/show_bug.cgi?id=146850
2845
2846         This patch adds support for tail calls in the DFG. This requires a slightly high number of nodes:
2847
2848          - TailCall and TailCallVarargs are straightforward. They are terminal
2849            nodes and have the semantics of an actual tail call.
2850
2851          - TailCallInlinedCaller and TailCallVarargsInlinedCaller are here to perform a
2852            tail call inside an inlined function. They are non terminal nodes,
2853            and are performing the call as a regular call after popping an
2854            appropriate number of inlined tail call frames.
2855
2856          - TailCallForwardVarargs and TailCallForwardVarargsInlinedCaller are the
2857            extension of TailCallVarargs and TailCallVarargsInlinedCaller to enable
2858            the varargs forwarding optimization so that we don't lose
2859            performance with a tail call instead of a regular call.
2860
2861         This also required two broad kind of changes:
2862
2863          - Changes in the JIT itself (DFGSpeculativeJIT) are pretty
2864            straightforward since they are just an extension of the baseline JIT
2865            changes introduced previously.
2866
2867          - Changes in the runtime are mostly related with handling inline call
2868            frames. The idea here is that we have a special TailCall type for
2869            call frames that indicates to the various pieces of code walking the
2870            inline call frame that they should (recursively) skip the caller in
2871            their analysis.
2872
2873         * bytecode/CallMode.h:
2874         (JSC::specializationKindFor):
2875         * bytecode/CodeOrigin.cpp:
2876         (JSC::CodeOrigin::inlineDepthForCallFrame):
2877         (JSC::CodeOrigin::isApproximatelyEqualTo):
2878         (JSC::CodeOrigin::approximateHash):
2879         (JSC::CodeOrigin::inlineStack):
2880         * bytecode/CodeOrigin.h:
2881         * bytecode/InlineCallFrame.cpp:
2882         (JSC::InlineCallFrame::dumpInContext):
2883         (WTF::printInternal):
2884         * bytecode/InlineCallFrame.h:
2885         (JSC::InlineCallFrame::callModeFor):
2886         (JSC::InlineCallFrame::kindFor):
2887         (JSC::InlineCallFrame::varargsKindFor):
2888         (JSC::InlineCallFrame::specializationKindFor):
2889         (JSC::InlineCallFrame::isVarargs):
2890         (JSC::InlineCallFrame::isTail):
2891         (JSC::InlineCallFrame::computeCallerSkippingDeadFrames):
2892         (JSC::InlineCallFrame::getCallerSkippingDeadFrames):
2893         (JSC::InlineCallFrame::getCallerInlineFrameSkippingDeadFrames):
2894         * dfg/DFGAbstractInterpreterInlines.h:
2895         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2896         * dfg/DFGArgumentsEliminationPhase.cpp:
2897         * dfg/DFGBasicBlock.h:
2898         (JSC::DFG::BasicBlock::findTerminal):
2899         * dfg/DFGByteCodeParser.cpp:
2900         (JSC::DFG::ByteCodeParser::inlineCallFrame):
2901         (JSC::DFG::ByteCodeParser::allInlineFramesAreTailCalls):
2902         (JSC::DFG::ByteCodeParser::currentCodeOrigin):
2903         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
2904         (JSC::DFG::ByteCodeParser::addCall):
2905         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
2906         (JSC::DFG::ByteCodeParser::getPrediction):
2907         (JSC::DFG::ByteCodeParser::handleCall):
2908         (JSC::DFG::ByteCodeParser::handleVarargsCall):
2909         (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
2910         (JSC::DFG::ByteCodeParser::inliningCost):
2911         (JSC::DFG::ByteCodeParser::inlineCall):
2912         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
2913         (JSC::DFG::ByteCodeParser::parseBlock):
2914         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2915         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2916         * dfg/DFGCapabilities.cpp:
2917         (JSC::DFG::capabilityLevel):
2918         * dfg/DFGClobberize.h:
2919         (JSC::DFG::clobberize):
2920         * dfg/DFGDoesGC.cpp:
2921         (JSC::DFG::doesGC):
2922         * dfg/DFGFixupPhase.cpp:
2923         (JSC::DFG::FixupPhase::fixupNode):
2924         * dfg/DFGGraph.cpp:
2925         (JSC::DFG::Graph::isLiveInBytecode):
2926         * dfg/DFGGraph.h:
2927         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2928         * dfg/DFGInPlaceAbstractState.cpp:
2929         (JSC::DFG::InPlaceAbstractState::mergeToSuccessors):
2930         * dfg/DFGJITCompiler.cpp:
2931         (JSC::DFG::JITCompiler::willCatchExceptionInMachineFrame):
2932         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2933         (JSC::DFG::FlushLiveCatchVariablesInsertionPhase::willCatchException):
2934         * dfg/DFGNode.h:
2935         (JSC::DFG::Node::hasCallVarargsData):
2936         (JSC::DFG::Node::isTerminal):
2937         (JSC::DFG::Node::hasHeapPrediction):
2938         * dfg/DFGNodeType.h:
2939         * dfg/DFGOSRExitCompilerCommon.cpp:
2940         (JSC::DFG::handleExitCounts):
2941         (JSC::DFG::reifyInlinedCallFrames):
2942         (JSC::DFG::osrWriteBarrier):
2943         * dfg/DFGOSRExitPreparation.cpp:
2944         (JSC::DFG::prepareCodeOriginForOSRExit):
2945         * dfg/DFGOperations.cpp:
2946         * dfg/DFGPreciseLocalClobberize.h:
2947         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
2948         * dfg/DFGPredictionPropagationPhase.cpp:
2949         (JSC::DFG::PredictionPropagationPhase::propagate):
2950         * dfg/DFGSafeToExecute.h:
2951         (JSC::DFG::safeToExecute):
2952         * dfg/DFGSpeculativeJIT32_64.cpp:
2953         (JSC::DFG::SpeculativeJIT::emitCall):
2954         (JSC::DFG::SpeculativeJIT::compile):
2955         * dfg/DFGSpeculativeJIT64.cpp:
2956         (JSC::DFG::SpeculativeJIT::emitCall):
2957         (JSC::DFG::SpeculativeJIT::compile):
2958         * dfg/DFGValidate.cpp:
2959         (JSC::DFG::Validate::validateSSA):
2960         * dfg/DFGVarargsForwardingPhase.cpp:
2961         * interpreter/CallFrame.cpp:
2962         (JSC::CallFrame::bytecodeOffset):
2963         * interpreter/StackVisitor.cpp:
2964         (JSC::StackVisitor::gotoNextFrame):
2965
2966 2015-09-23  Filip Pizlo  <fpizlo@apple.com>
2967
2968         Remove special case code for the no-parallel-GC case
2969         https://bugs.webkit.org/show_bug.cgi?id=149512
2970
2971         Reviewed by Mark Lam.
2972
2973         Make serial GC just a parallel GC where the helper threads don't do anything. Also make the
2974         idle thread calculation a bit more explicit.
2975
2976         The main outcome is that we no longer use Options::numberOfGCMarkers() as much, so the code is
2977         resilient against the number of GC markers changing.
2978
2979         * heap/Heap.h:
2980         * heap/SlotVisitor.cpp:
2981         (JSC::SlotVisitor::donateKnownParallel):
2982         (JSC::SlotVisitor::drain):
2983         (JSC::SlotVisitor::drainFromShared):
2984
2985 2015-09-23  Filip Pizlo  <fpizlo@apple.com>
2986
2987         PolymorphicAccess should remember that it checked an ObjectPropertyCondition with a check on some structure
2988         https://bugs.webkit.org/show_bug.cgi?id=149514
2989
2990         Reviewed by Oliver Hunt.
2991
2992         When we checked an ObjectPropertyCondition using an explicit structure check, we would forget to
2993         note the structure in any weak reference table and we would attempt to regenerate the condition
2994         check even if the condition became invalid.
2995
2996         We need to account for this better and we need to prune AccessCases that have an invalid condition
2997         set. This change does both.
2998
2999         * bytecode/PolymorphicAccess.cpp:
3000         (JSC::AccessGenerationState::addWatchpoint):
3001         (JSC::AccessCase::alternateBase):
3002         (JSC::AccessCase::couldStillSucceed):
3003         (JSC::AccessCase::canReplace):
3004         (JSC::AccessCase::generate):
3005         (JSC::PolymorphicAccess::regenerateWithCases):
3006         (JSC::PolymorphicAccess::visitWeak):
3007         (JSC::PolymorphicAccess::regenerate):
3008         * bytecode/PolymorphicAccess.h:
3009         (JSC::AccessCase::callLinkInfo):
3010         * tests/stress/make-dictionary-repatch.js: Added. This used to crash on a release assert. If we removed the release assert, this would return bad results.
3011
3012 2015-09-24  Mark Lam  <mark.lam@apple.com>
3013
3014         We should only expect a RareCaseProfile to exist if the rare case actually exists.
3015         https://bugs.webkit.org/show_bug.cgi?id=149531
3016
3017         Reviewed by Saam Barati.
3018
3019         The current code that calls rareCaseProfileForBytecodeOffset() assumes that it
3020         will always return a non-null RareCaseProfile.  As a result, op_add in the
3021         baseline JIT is forced to add a dummy slow case that will never be taken, only to
3022         ensure that the RareCaseProfile for that bytecode is created.  This profile will
3023         always produce a counter value of 0 (since that path will never be taken).
3024
3025         Instead, we'll make the callers of rareCaseProfileForBytecodeOffset() check if
3026         the profile actually exist before dereferencing it.
3027
3028         * bytecode/CodeBlock.cpp:
3029         (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
3030         (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
3031         (JSC::CodeBlock::capabilityLevel):
3032         * bytecode/CodeBlock.h:
3033         (JSC::CodeBlock::addRareCaseProfile):
3034         (JSC::CodeBlock::numberOfRareCaseProfiles):
3035         (JSC::CodeBlock::likelyToTakeSlowCase):
3036         (JSC::CodeBlock::couldTakeSlowCase):
3037         (JSC::CodeBlock::likelyToTakeDeepestSlowCase):
3038         (JSC::CodeBlock::likelyToTakeAnySlowCase):
3039         (JSC::CodeBlock::rareCaseProfile): Deleted.
3040         * jit/JITArithmetic.cpp:
3041         (JSC::JIT::emit_op_add):
3042         (JSC::JIT::emitSlow_op_add):
3043         * jit/JITArithmetic32_64.cpp:
3044         (JSC::JIT::emit_op_add):
3045         (JSC::JIT::emitSlow_op_add):
3046
3047 2015-09-24  Ryosuke Niwa  <rniwa@webkit.org>
3048
3049         Ran sort-Xcode-project-file.
3050
3051         * JavaScriptCore.xcodeproj/project.pbxproj:
3052
3053 2015-09-24  Youenn Fablet  <youenn.fablet@crf.canon.fr>
3054
3055         [Streams API] Add support for JS builtins constructor
3056         https://bugs.webkit.org/show_bug.cgi?id=149497
3057
3058         Reviewed by Darin Adler.
3059
3060         * runtime/JSFunction.h: exporting createBuiltinFunction.
3061
3062 2015-09-23  Saam barati  <sbarati@apple.com>
3063
3064         JSC allows invalid var declarations when the declared name is the same as a let/const variable
3065         https://bugs.webkit.org/show_bug.cgi?id=147600
3066
3067         Reviewed by Yusuke Suzuki.
3068
3069         We had an ordering bug where if you first declared a "let"
3070         variable then a "var" variable with the same name, you wouldn't
3071         get a syntax error. But, if you did it in the reverse order,
3072         you would. This patch fixes this syntax error to be order independent.
3073
3074         * parser/Parser.cpp:
3075         (JSC::Parser<LexerType>::parseVariableDeclarationList):
3076         (JSC::Parser<LexerType>::createBindingPattern):
3077         (JSC::Parser<LexerType>::parseFunctionDeclaration):
3078         * parser/Parser.h:
3079         (JSC::Scope::declareVariable):
3080
3081 2015-09-23  Filip Pizlo  <fpizlo@apple.com>
3082
3083         Parallel copy phase synchronization should be simplified
3084         https://bugs.webkit.org/show_bug.cgi?id=149509
3085
3086         Reviewed by Mark Lam.
3087
3088         Before this change, we didn't wait for the copy phase to finish before starting to do things to
3089         copied space that presumed that copying was done. Copied space would "detect" that nobody was
3090         copying anymore by waiting for all loaned blocks to be returned. But that would succeed if some
3091         thread had not yet started copying. So, we had weird hacks to ensure that a block was loaned
3092         before any threads started. It also meant that we had two separate mechanisms for waiting for
3093         copying threads to finish - one mechanism in the Heap phase logic and another in the
3094         CopiedSpace::doneCopying() method.
3095
3096         We can get rid of a lot of the weirdness by just having a sound shutdown sequence:
3097
3098         1) Threads concur on when there is no more work. We already have this; once
3099            Heap::getNextBlocksToCopy() returns no work in any thread, it will also return no work in
3100            any other thread that asks for work.
3101         2) Main thread waits for the threads to not be copying anymore.
3102         3) Do whatever we need to do after copying finishes.
3103
3104         Currently, we do (3) before (2) and so we have weird problems. This just changes the code to do
3105         (3) after (2), and so we can get rid of the synchronization in doneCopying() and we can safely
3106         call startCopying() inside GCThread. This also means that we don't need to make CopyVisitor a
3107         property of GCThread. Instead, GCThread just instantiates its own CopyVisitor when it needs to.
3108
3109         * heap/CopiedSpace.cpp:
3110         (JSC::CopiedSpace::doneCopying):
3111         * heap/GCThread.cpp:
3112         (JSC::GCThread::GCThread):
3113         (JSC::GCThread::slotVisitor):
3114         (JSC::GCThread::waitForNextPhase):
3115         (JSC::GCThread::gcThreadMain):
3116         (JSC::GCThread::copyVisitor): Deleted.
3117         * heap/GCThread.h:
3118         * heap/Heap.cpp:
3119         (JSC::Heap::Heap):
3120         (JSC::Heap::copyBackingStores):
3121         (JSC::Heap::gatherStackRoots):
3122
3123 2015-09-23  Joseph Pecoraro  <pecoraro@apple.com>
3124
3125         Remove unimplemented method Heap::showStatistics
3126         https://bugs.webkit.org/show_bug.cgi?id=149507
3127
3128         Reviewed by Darin Adler.
3129
3130         * heap/Heap.h:
3131
3132 2015-09-23  Tim Horton  <timothy_horton@apple.com>
3133
3134         Hopefully fix the production build.
3135
3136         * JavaScriptCore.xcodeproj/project.pbxproj:
3137         * PlatformWin.cmake:
3138
3139 2015-09-23  Youenn Fablet  <youenn.fablet@crf.canon.fr>
3140
3141         [Streams API] Implement ReadableStream pipeThrough
3142         https://bugs.webkit.org/show_bug.cgi?id=147556
3143
3144         Reviewed by Darin Adler.
3145
3146         Updating BuiltIns infrastructure to make it reusable from WebCore.
3147         Extracting macros from BuiltinNames and createBuiltinExecutable from BuiltinExecutables.
3148         Updated generate-js-builtins to allow generating builtin CPP/H files in WebCore namespace.
3149
3150         * JavaScriptCore.xcodeproj/project.pbxproj:
3151         * builtins/BuiltinExecutables.cpp:
3152         (JSC::BuiltinExecutables::createDefaultConstructor):
3153         (JSC::BuiltinExecutables::createBuiltinExecutable):
3154         (JSC::createBuiltinExecutable):
3155         (JSC::createExecutableInternal):
3156         * builtins/BuiltinExecutables.h:
3157         * builtins/BuiltinNames.h:
3158         (JSC::BuiltinNames::BuiltinNames): Deleted.
3159         * builtins/BuiltinUtils.h: Extracting code from BuiltinNames and BuiltinExecutables.h.
3160         * bytecode/UnlinkedFunctionExecutable.h:
3161         * generate-js-builtins:
3162         (getFunctions):
3163         (writeIncludeDirectives):
3164
3165 2015-09-22  Mark Lam  <mark.lam@apple.com>
3166
3167         Gardening: speculative non-JIT build fix after r189999.
3168
3169         Not reviewed.
3170
3171         * bytecode/ValueRecovery.h:
3172         (JSC::ValueRecovery::jsValueRegs):
3173
3174 2015-09-22  Filip Pizlo  <fpizlo@apple.com>
3175
3176         GCThreadSharedData is just a bad way of saying Heap
3177         https://bugs.webkit.org/show_bug.cgi?id=149435
3178
3179         Reviewed by Mark Lam.
3180
3181         This removes the GCThreadSharedData class and moves its members into Heap. This is a net
3182         simplification since GCThreadSharedData had a 1-to-1 mapping to Heap and the two classes had a
3183         vast contract with a lot of interdependencies. Heap would call a lot of GCThreadSharedData
3184         methods; now a lot of those are inlined since they were only called from the one place in Heap.
3185         This makes it a lot easier to see what is going on. For example, you no longer have to look at
3186         code in two places (Heap and GCThreadSharedData) to figure out the timing and synchronization
3187         of GC phases - all of that code is in Heap now.
3188
3189         This also removes weird indirections in other places. It used to be that a lot of GC helper
3190         classes woud have a pointer to GCThreadSharedData, and then would use that to get to Heap, VM,
3191         and the visitors. Now these helpers just point to Heap.
3192
3193         I think that GCThreadSharedData was only useful for defining the set of things that we need to
3194         know to collect garbage. That's how we decided if something would go into GCThreadSharedData
3195         instead of Heap. But I think that separating things into multiple classes usually makes the
3196         code less hackable, so there should be a very high bar for doing this in a way that produces a
3197         1-to-1 mapping between two classes - where one instance of one of the classes is always paired
3198         with exactly one instance of the other class and vice-versa.
3199
3200         * CMakeLists.txt:
3201         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3202         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3203         * JavaScriptCore.xcodeproj/project.pbxproj:
3204         * heap/CopiedSpace.h:
3205         * heap/CopyVisitor.cpp:
3206         (JSC::CopyVisitor::CopyVisitor):
3207         (JSC::CopyVisitor::copyFromShared):
3208         * heap/CopyVisitor.h:
3209         * heap/CopyVisitorInlines.h:
3210         (JSC::CopyVisitor::allocateNewSpaceSlow):
3211         (JSC::CopyVisitor::startCopying):
3212         (JSC::CopyVisitor::doneCopying):
3213         (JSC::CopyVisitor::didCopy):
3214         * heap/GCThread.cpp:
3215         (JSC::GCThread::GCThread):
3216         (JSC::GCThread::waitForNextPhase):
3217         (JSC::GCThread::gcThreadMain):
3218         * heap/GCThread.h:
3219         * heap/GCThreadSharedData.cpp: Removed.
3220         * heap/GCThreadSharedData.h: Removed.
3221         * heap/Heap.cpp:
3222         (JSC::Heap::Heap):
3223         (JSC::Heap::~Heap):
3224         (JSC::Heap::isPagedOut):
3225         (JSC::Heap::markRoots):
3226         (JSC::Heap::copyBackingStores):
3227         (JSC::Heap::updateObjectCounts):
3228         (JSC::Heap::resetVisitors):
3229         (JSC::Heap::objectCount):
3230         (JSC::Heap::sweepNextLogicallyEmptyWeakBlock):
3231         (JSC::Heap::threadVisitCount):
3232         (JSC::Heap::threadBytesVisited):
3233         (JSC::Heap::threadBytesCopied):
3234         (JSC::Heap::startNextPhase):
3235         (JSC::Heap::endCurrentPhase):
3236         * heap/Heap.h:
3237         * heap/HeapInlines.h:
3238         (JSC::Heap::unregisterWeakGCMap):
3239         (JSC::Heap::getNextBlocksToCopy):
3240         * heap/ListableHandler.h:
3241         * heap/SlotVisitor.cpp:
3242         (JSC::SlotVisitor::SlotVisitor):
3243         (JSC::SlotVisitor::didStartMarking):
3244         (JSC::SlotVisitor::reset):
3245         (JSC::SlotVisitor::donateKnownParallel):
3246         (JSC::SlotVisitor::drain):
3247         (JSC::SlotVisitor::drainFromShared):
3248         (JSC::SlotVisitor::mergeOpaqueRoots):
3249         (JSC::SlotVisitor::harvestWeakReferences):
3250         (JSC::SlotVisitor::finalizeUnconditionalFinalizers):
3251         * heap/SlotVisitor.h:
3252         (JSC::SlotVisitor::markStack):
3253         (JSC::SlotVisitor::isEmpty):
3254         (JSC::SlotVisitor::sharedData): Deleted.
3255         * heap/SlotVisitorInlines.h:
3256         (JSC::SlotVisitor::addWeakReferenceHarvester):
3257         (JSC::SlotVisitor::addUnconditionalFinalizer):
3258         (JSC::SlotVisitor::addOpaqueRoot):
3259         (JSC::SlotVisitor::containsOpaqueRoot):
3260         (JSC::SlotVisitor::containsOpaqueRootTriState):
3261         (JSC::SlotVisitor::opaqueRootCount):
3262         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
3263         (JSC::SlotVisitor::copyLater):
3264         (JSC::SlotVisitor::heap):
3265         (JSC::SlotVisitor::vm):
3266
3267 2015-09-22  Saam barati  <sbarati@apple.com>
3268
3269         Web Inspector: [ES6] Improve Type Profiler Support for Arrow Functions
3270         https://bugs.webkit.org/show_bug.cgi?id=143171
3271
3272         Reviewed by Joseph Pecoraro.
3273
3274         We now need to take into account TypeProfilerSearchDescriptor when
3275         hashing results for type profiler queries. Before, we've gotten
3276         away with not doing this because before we would never have a text 
3277         collision between a return type text offset and a normal expression text
3278         offset. But, with arrow functions, we will have collisions when
3279         the arrow function doesn't have parens around its single parameter.
3280         I.e: "param => { ... };"
3281
3282         * runtime/TypeProfiler.cpp:
3283         (JSC::TypeProfiler::findLocation):
3284         * runtime/TypeProfiler.h:
3285         (JSC::QueryKey::QueryKey):
3286         (JSC::QueryKey::isHashTableDeletedValue):
3287         (JSC::QueryKey::operator==):
3288         (JSC::QueryKey::hash):
3289         * tests/typeProfiler/arrow-functions.js: Added.
3290
3291 2015-09-22  Filip Pizlo  <fpizlo@apple.com>
3292
3293         Get rid of ENABLE(PARALLEL_GC)
3294         https://bugs.webkit.org/show_bug.cgi?id=149436
3295
3296         Reviewed by Mark Lam.
3297
3298         We always enable parallel GC everywhere but Windows, and it doesn't look like it was disabled
3299         there for any good reason. So, get rid of the flag.
3300
3301         The only effect of this change is that parallel GC will now be enabled on Windows, provided
3302         that the CPU detection finds more than one.
3303
3304         * heap/GCThread.cpp:
3305         (JSC::GCThread::gcThreadMain):
3306         * heap/GCThreadSharedData.cpp:
3307         (JSC::GCThreadSharedData::resetChildren):
3308         (JSC::GCThreadSharedData::childBytesCopied):
3309         (JSC::GCThreadSharedData::GCThreadSharedData):
3310         (JSC::GCThreadSharedData::~GCThreadSharedData):
3311         (JSC::GCThreadSharedData::reset):
3312         (JSC::GCThreadSharedData::didStartMarking):
3313         * heap/Heap.cpp:
3314         (JSC::Heap::converge):
3315         (JSC::Heap::visitWeakHandles):
3316         (JSC::Heap::updateObjectCounts):
3317         (JSC::Heap::resetVisitors):
3318         * heap/MarkedBlock.h:
3319         * heap/SlotVisitor.cpp:
3320         (JSC::SlotVisitor::didStartMarking):
3321         (JSC::SlotVisitor::reset):
3322         (JSC::SlotVisitor::drain):
3323         (JSC::SlotVisitor::drainFromShared):
3324         (JSC::SlotVisitor::mergeOpaqueRoots):
3325         (JSC::JSString::tryHashConsLock):
3326         (JSC::JSString::releaseHashConsLock):
3327         * heap/SlotVisitorInlines.h:
3328         (JSC::SlotVisitor::addOpaqueRoot):
3329         (JSC::SlotVisitor::containsOpaqueRoot):
3330         (JSC::SlotVisitor::containsOpaqueRootTriState):
3331         (JSC::SlotVisitor::opaqueRootCount):
3332         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
3333         * runtime/Options.cpp:
3334         (JSC::computeNumberOfGCMarkers):
3335
3336 2015-09-22  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3337
3338         Implement min and max instructions in WebAssembly
3339         https://bugs.webkit.org/show_bug.cgi?id=149454
3340
3341         Reviewed by Geoffrey Garen.
3342
3343         This patch implements min and max instructions in WebAssembly.
3344
3345         * tests/stress/wasm-arithmetic-float64.js:
3346         * tests/stress/wasm-arithmetic-int32.js:
3347         * tests/stress/wasm/arithmetic-float64.wasm:
3348         * tests/stress/wasm/arithmetic-int32.wasm:
3349         * wasm/WASMFunctionCompiler.h:
3350         (JSC::WASMFunctionCompiler::buildMinOrMaxI32):
3351         (JSC::WASMFunctionCompiler::buildMinOrMaxF64):
3352         * wasm/WASMFunctionParser.cpp:
3353         (JSC::WASMFunctionParser::parseExpressionI32):
3354         (JSC::WASMFunctionParser::parseMinOrMaxExpressionI32):
3355         (JSC::WASMFunctionParser::parseExpressionF64):
3356         (JSC::WASMFunctionParser::parseMinOrMaxExpressionF64):
3357         * wasm/WASMFunctionParser.h:
3358         * wasm/WASMFunctionSyntaxChecker.h:
3359         (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxI32):
3360         (JSC::WASMFunctionSyntaxChecker::buildMinOrMaxF64):
3361
3362 2015-09-22  Filip Pizlo  <fpizlo@apple.com>
3363
3364         Get rid of ENABLE(GGC)
3365         https://bugs.webkit.org/show_bug.cgi?id=149472
3366
3367         Reviewed by Mark Hahnenberg and Mark Lam.
3368
3369         Getting rid of this feature flag allows us to remove a lot of yuck.
3370
3371         * bytecode/CodeBlock.h:
3372         (JSC::CodeBlockSet::mark):
3373         (JSC::ScriptExecutable::forEachCodeBlock):
3374         * bytecode/PolymorphicAccess.cpp:
3375         (JSC::AccessCase::generate):
3376         * dfg/DFGOSRExitCompilerCommon.cpp:
3377         (JSC::DFG::reifyInlinedCallFrames):
3378         (JSC::DFG::osrWriteBarrier):
3379         (JSC::DFG::adjustAndJumpToTarget):
3380         * dfg/DFGSpeculativeJIT.cpp:
3381         (JSC::DFG::SpeculativeJIT::linkBranches):
3382         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
3383         (JSC::DFG::SpeculativeJIT::writeBarrier):
3384         * dfg/DFGSpeculativeJIT.h:
3385         (JSC::DFG::SpeculativeJIT::masqueradesAsUndefinedWatchpointIsStillValid):
3386         (JSC::DFG::SpeculativeJIT::selectScratchGPR):
3387         * dfg/DFGSpeculativeJIT32_64.cpp:
3388         (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
3389         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3390         (JSC::DFG::SpeculativeJIT::compile):
3391         (JSC::DFG::SpeculativeJIT::writeBarrier):
3392         (JSC::DFG::SpeculativeJIT::moveTrueTo):
3393         * dfg/DFGSpeculativeJIT64.cpp:
3394         (JSC::DFG::SpeculativeJIT::compileBaseValueStoreBarrier):
3395         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3396         (JSC::DFG::SpeculativeJIT::compile):
3397         (JSC::DFG::SpeculativeJIT::writeBarrier):
3398         (JSC::DFG::SpeculativeJIT::moveTrueTo):
3399         * ftl/FTLLowerDFGToLLVM.cpp:
3400         (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
3401         * heap/CodeBlockSet.cpp:
3402         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
3403         (JSC::CodeBlockSet::dump):
3404         * heap/Heap.cpp:
3405         (JSC::Heap::Heap):
3406         (JSC::Heap::markRoots):
3407         (JSC::Heap::clearRememberedSet):
3408         (JSC::Heap::updateObjectCounts):
3409         (JSC::Heap::flushWriteBarrierBuffer):
3410         (JSC::Heap::shouldDoFullCollection):
3411         (JSC::Heap::addLogicallyEmptyWeakBlock):
3412         * heap/HeapInlines.h:
3413         (JSC::Heap::isWriteBarrierEnabled):
3414         (JSC::Heap::writeBarrier):
3415         (JSC::Heap::reportExtraMemoryAllocated):
3416         (JSC::Heap::reportExtraMemoryVisited):
3417         * heap/MarkedBlock.cpp:
3418         (JSC::MarkedBlock::clearMarks):
3419         * heap/MarkedSpace.cpp:
3420         (JSC::MarkedSpace::resetAllocators):
3421         (JSC::MarkedSpace::visitWeakSets):
3422         * heap/MarkedSpace.h:
3423         (JSC::MarkedSpace::didAllocateInBlock):
3424         (JSC::MarkedSpace::objectCount):
3425         * jit/JITPropertyAccess.cpp:
3426         (JSC::JIT::emitWriteBarrier):
3427         (JSC::JIT::emitIdentifierCheck):
3428         (JSC::JIT::privateCompilePutByVal):
3429         * llint/LLIntOfflineAsmConfig.h:
3430         * llint/LowLevelInterpreter32_64.asm:
3431         * llint/LowLevelInterpreter64.asm:
3432
3433 2015-09-22  Saam barati  <sbarati@apple.com>
3434
3435         the toInt32 operation inside DFGSpeculativeJIT.cpp can't throw so we shouldn't emit an exceptionCheck after it.
3436         https://bugs.webkit.org/show_bug.cgi?id=149467
3437
3438         Reviewed by Mark Lam.
3439
3440         The callOperation for toInt32 won't store a call site index in the call frame.
3441         Therefore, if this is the first callOperation in the current compilation, 
3442         and we emit an exception check inside a try block, we will hit an assertion 
3443         saying that we must have DFGCommonData::codeOrigins.size() be > 0 inside
3444         DFGCommonData::lastCallSite(). Therefore, it is imperative that we don't 
3445         emit exception checks for callOperations that don't throw exceptions and 
3446         don't store a call site index in the call frame.
3447
3448         * dfg/DFGCommonData.cpp:
3449         (JSC::DFG::CommonData::lastCallSite):
3450         * dfg/DFGSpeculativeJIT.cpp:
3451         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
3452         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
3453
3454 2015-09-22  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3455
3456         Implement the conditional instruction in WebAssembly
3457         https://bugs.webkit.org/show_bug.cgi?id=149451
3458
3459         Reviewed by Geoffrey Garen.
3460
3461         This patch implements the conditional (ternary) instruction in WebAssembly.
3462         This is basically "condition ? exp1 : exp2" in JavaScript.
3463         
3464         The use of context.discard() in WASMFunctionParser::parseConditional()
3465         is not ideal. We don't discard anything. We just use it to decrement the
3466         stack top in the WebAssembly baseline JIT. When we optimize the JIT by
3467         storing results directly into the destination like the JavaScript
3468         baseline JIT, the code will look like this:
3469
3470             ContextExpression temp = context.newTemporary();
3471             ContextExpression condition = parseExpressionI32(context);
3472             context.jumpToTargetIf(Context::JumpCondition::Zero, condition, elseTarget);
3473
3474             parseExpression(context, temp, expressionType);
3475             context.jumpToTarget(end);
3476
3477             context.linkTarget(elseTarget);
3478             parseExpression(context, temp, expressionType);
3479             context.linkTarget(end);
3480
3481             return temp;
3482
3483         which looks cleaner than using discard().
3484
3485         * tests/stress/wasm-control-flow.js:
3486         * tests/stress/wasm/control-flow.wasm:
3487         * wasm/WASMFunctionParser.cpp:
3488         (JSC::WASMFunctionParser::parseExpressionI32):
3489         (JSC::WASMFunctionParser::parseExpressionF32):
3490         (JSC::WASMFunctionParser::parseExpressionF64):
3491         (JSC::WASMFunctionParser::parseConditional):
3492         * wasm/WASMFunctionParser.h:
3493
3494 2015-09-22  Commit Queue  <commit-queue@webkit.org>
3495
3496         Unreviewed, rolling out r189616.
3497         https://bugs.webkit.org/show_bug.cgi?id=149456
3498
3499         suspected cause of multiple regressions (Requested by kling on
3500         #webkit).
3501
3502         Reverted changeset:
3503
3504         "[JSC] Weak should only accept cell pointees."
3505         https://bugs.webkit.org/show_bug.cgi?id=148955
3506         http://trac.webkit.org/changeset/189616
3507
3508 2015-09-22  Saam barati  <sbarati@apple.com>
3509
3510         Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script with "class" with default constructor
3511         https://bugs.webkit.org/show_bug.cgi?id=149248
3512
3513         Reviewed by Mark Lam.
3514
3515         We keep track of which functions have and have not
3516         executed so we can show visually, inside the inspector,
3517         which functions have and have not executed. With a default
3518         constructor, our parser parses code that isn't in the actual
3519         JavaScript source code of the user. Our parser would then
3520         give us a range of starting at "1" to "1 + default constructor length"
3521         as being the text range of a function. But, this would then pollute
3522         actual source code that was at these ranges.
3523
3524         Therefore, we should treat these default constructor source 
3525         codes as having "invalid" ranges. We use [UINT_MAX, UINT_MAX] 
3526         as the invalid range. This range has the effect of not polluting 
3527         valid ranges inside the source code.
3528
3529         * bytecode/UnlinkedFunctionExecutable.cpp:
3530         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
3531         (JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets):
3532         * bytecode/UnlinkedFunctionExecutable.h:
3533         * bytecompiler/BytecodeGenerator.cpp:
3534         (JSC::BytecodeGenerator::emitNewDefaultConstructor):
3535
3536 2015-09-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3537
3538         Implement the comma instruction in WebAssembly
3539         https://bugs.webkit.org/show_bug.cgi?id=149425
3540
3541         Reviewed by Geoffrey Garen.
3542
3543         This patch implements the comma instruction in WebAssembly. The comma
3544         instruction evaluates the left operand and then the right operand and
3545         returns the value of the right operand.
3546
3547         * tests/stress/wasm-comma.js: Added.
3548         (shouldBe):
3549         * wasm/WASMFunctionCompiler.h:
3550         (JSC::WASMFunctionCompiler::discard):
3551         * wasm/WASMFunctionParser.cpp:
3552         (JSC::WASMFunctionParser::parseExpressionI32):
3553         (JSC::WASMFunctionParser::parseExpressionF32):
3554         (JSC::WASMFunctionParser::parseExpressionF64):
3555         (JSC::WASMFunctionParser::parseComma):
3556         * wasm/WASMFunctionParser.h:
3557         * wasm/WASMFunctionSyntaxChecker.h:
3558         (JSC::WASMFunctionSyntaxChecker::discard):
3559
3560 2015-09-21  Filip Pizlo  <fpizlo@apple.com>
3561
3562         Always use the compiler's CAS implementation and get rid of ENABLE(COMPARE_AND_SWAP)
3563         https://bugs.webkit.org/show_bug.cgi?id=149438
3564
3565         Reviewed by Mark Lam.
3566
3567         * heap/HeapInlines.h:
3568         (JSC::Heap::reportExtraMemoryVisited):
3569         (JSC::Heap::deprecatedReportExtraMemory):
3570
3571 2015-09-21  Saam barati  <sbarati@apple.com>
3572
3573         functionProtoFuncToString should not rely on typeProfilingEndOffset()
3574         https://bugs.webkit.org/show_bug.cgi?id=149429
3575
3576         Reviewed by Geoffrey Garen.
3577
3578         We should be able to freely change typeProfilingEndOffset()
3579         without worrying we will break Function.prototype.toString.
3580
3581         * runtime/FunctionPrototype.cpp:
3582         (JSC::functionProtoFuncToString):
3583
3584 2015-09-21  Commit Queue  <commit-queue@webkit.org>
3585
3586         Unreviewed, rolling out r190086.
3587         https://bugs.webkit.org/show_bug.cgi?id=149427
3588
3589         Broke LayoutTests/inspector/model/remote-object.htm (Requested
3590         by saamyjoon on #webkit).
3591
3592         Reverted changeset:
3593
3594         "Web Inspector: Basic Block Annotations and Type Profiler
3595         annotations wrong for script with "class" with default
3596         constructor"
3597         https://bugs.webkit.org/show_bug.cgi?id=149248
3598         http://trac.webkit.org/changeset/190086
3599
3600 2015-09-21  Saam barati  <sbarati@apple.com>
3601
3602         Web Inspector: Basic Block Annotations and Type Profiler annotations wrong for script with "class" with default constructor
3603         https://bugs.webkit.org/show_bug.cgi?id=149248
3604
3605         Reviewed by Mark Lam.
3606
3607         We keep track of which functions have and have not
3608         executed so we can show visually, inside the inspector,
3609         which functions have and have not executed. With a default
3610         constructor, our parser parses code that isn't in the actual
3611         JavaScript source code of the user. Our parser would then
3612         give us a range of starting at "1" to "1 + default constructor length"
3613         as being the text range of a function. But, this would then pollute
3614         actual source code that was at these ranges.
3615
3616         Therefore, we should treat these default constructor source 
3617         codes as having "invalid" ranges. We use [UINT_MAX, UINT_MAX] 
3618         as the invalid range. This range has the effect of not polluting 
3619         valid ranges inside the source code.
3620
3621         * bytecode/UnlinkedFunctionExecutable.cpp:
3622         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
3623         (JSC::UnlinkedFunctionExecutable::setInvalidTypeProfilingOffsets):
3624         * bytecode/UnlinkedFunctionExecutable.h:
3625         * bytecompiler/BytecodeGenerator.cpp:
3626         (JSC::BytecodeGenerator::emitNewDefaultConstructor):
3627
3628 2015-09-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3629
3630         Implement call statements and call expressions of type void in WebAssembly
3631         https://bugs.webkit.org/show_bug.cgi?id=149411
3632
3633         Reviewed by Mark Lam.
3634
3635         Call instructions in WebAssembly can be both statements and expressions.
3636         This patch implements call statements. It also implements call
3637         expressions of type void. The only place where call expressions of type
3638         void can occur is the left-hand side of the comma (,) operator, which
3639         will be implemented in a subsequent patch. The comma operator requires
3640         both of its operands to be expressions.
3641
3642         * tests/stress/wasm-calls.js:
3643         * tests/stress/wasm/calls.wasm:
3644         * wasm/WASMConstants.h:
3645         * wasm/WASMFunctionParser.cpp:
3646         (JSC::WASMFunctionParser::parseStatement):
3647         (JSC::WASMFunctionParser::parseExpression):
3648         (JSC::WASMFunctionParser::parseExpressionI32):
3649         (JSC::WASMFunctionParser::parseExpressionF32):
3650         (JSC::WASMFunctionParser::parseExpressionF64):
3651         (JSC::WASMFunctionParser::parseExpressionVoid):
3652         (JSC::WASMFunctionParser::parseCallInternal):
3653         (JSC::WASMFunctionParser::parseCallIndirect):
3654         (JSC::WASMFunctionParser::parseCallImport):
3655         * wasm/WASMFunctionParser.h:
3656         * wasm/WASMReader.cpp:
3657         (JSC::WASMReader::readOpExpressionVoid):
3658         * wasm/WASMReader.h:
3659
3660 2015-09-21  Filip Pizlo  <fpizlo@apple.com>
3661
3662         JSC should infer property types
3663         https://bugs.webkit.org/show_bug.cgi?id=148610
3664
3665         Reviewed by Geoffrey Garen.
3666
3667         This change brings recursive type inference to JavaScript object properties in JSC. We check that a
3668         value being stored into a property obeys a property's type before we do the store. If it doesn't,
3669         we broaden the property's type to include the new value. If optimized code was relying on the old
3670         type, we deoptimize that code.
3671
3672         The type system that this supports includes important primitive types like Int32 and Boolean. But
3673         it goes further and also includes a type kind called ObjectWithStructure, which means that we
3674         expect the property to always point to objects with a particular structure. This only works for
3675         leaf structures (i.e. structures that have a valid transition watchpoint set). Invalidation of the
3676         transition set causes the property type to become Object (meaning an object with any structure).
3677         This capability gives us recursive type inference. It's possible for an expression like "o.f.g.h"
3678         to execute without any type checks if .f and .g are both ObjectWithStructure.
3679
3680         The type inference of a property is tracked by an InferredType instance, which is a JSCell. This
3681         means that it manages its own memory. That's convenient. For example, when the DFG is interested in
3682         one of these, it can just list the InferredType as a weak reference in addition to setting a
3683         watchpoint. This ensures that even if the InferredType is dropped by the owning structure, the DFG
3684         won't read a dangling pointer. A mapping from property name to InferredType is implemented by
3685         InferredTypeTable, which is also a JSCell. Each Structure may point to some InferredTypeTable.
3686
3687         This feature causes programs to be happier (run faster without otherwise doing bad things like
3688         using lots of memory) when four conditions hold:
3689
3690         1) A property converges to one of the types that we support.
3691         2) The property is loaded from more frequently than it is stored to.
3692         3) The stores are all cached, so that we statically emit a type check.
3693         4) We don't allocate a lot of meta-data for the property's type.
3694
3695         We maximize the likelihood of (1) by having a rich type system. But having a rich type system means
3696         that a reflective put to a property has to have a large switch over the inferred type to decide how
3697         to do the type check. That's why we need (3). We ensure (3) by having every reflective property
3698         store (i.e. putDirectInternal in any context that isn't PutById) force the inferred type to become
3699         Top. We don't really worry about ensuring (2); this is statistically true for most programs
3700         already.
3701
3702         Probably the most subtle trickery goes into (4). Logically we'd like to say that each
3703         (Structure, Property) maps to its own InferredType. If structure S1 has a transition edge to S2,
3704         then we could ensure that the InferredType I1 where (S1, Property)->I1 has a data flow constraint
3705         to I2 where (S2, Property)->I2. That would work, but it would involve a lot of memory. And when I1
3706         gets invalidated in some way, it would have to tell I2 about it, and then I2 might tell other
3707         InferredType objects downstream. That's madness. So, the first major compromise that we make here
3708         is to say that if some property has some InferredType at some Structure, then anytime we
3709         transition from that Structure, the new Structure shares the same InferredType for that property.
3710         This unifies the type of the property over the entire transition tree starting at the Structure at
3711         which the property was added. But this would still mean that each Structure would have its own
3712         InferredTypeTable. We don't want that because experience with PropertyTable shows that this can be
3713         a major memory hog. So, we don't create an InferredTypeTable until someone adds a property that is
3714         subject to type inference (i.e. it was added non-reflectively), and we share that InferredTypeTable
3715         with the entire structure transition tree rooted at the Structure that had the first inferred
3716         property. We also drop the InferredTypeTable anytime that we do a dictionary transition, and we
3717         don't allow further property type inference if a structure had ever been a dictionary.
3718
3719         This is a 3% speed-up on Octane and a 12% speed-up on Kraken on my setup. It's not a significant
3720         slow-down on any benchmark I ran.
3721
3722         * CMakeLists.txt:
3723         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3724         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3725         * JavaScriptCore.xcodeproj/project.pbxproj:
3726         * assembler/MacroAssemblerARM64.h:
3727         (JSC::MacroAssemblerARM64::branchTest64):
3728         * assembler/MacroAssemblerX86_64.h:
3729         (JSC::MacroAssemblerX86_64::branchTest64):
3730         (JSC::MacroAssemblerX86_64::test64):
3731         * bytecode/PolymorphicAccess.cpp:
3732         (JSC::AccessCase::generate):
3733         * bytecode/PutByIdFlags.cpp:
3734         (WTF::printInternal):
3735         * bytecode/PutByIdFlags.h:
3736         (JSC::encodeStructureID):
3737         (JSC::decodeStructureID):
3738         * bytecode/PutByIdStatus.cpp:
3739         (JSC::PutByIdStatus::computeFromLLInt):
3740         (JSC::PutByIdStatus::computeFor):
3741         (JSC::PutByIdStatus::computeForStubInfo):
3742         * bytecode/PutByIdVariant.cpp:
3743         (JSC::PutByIdVariant::operator=):
3744         (JSC::PutByIdVariant::replace):
3745         (JSC::PutByIdVariant::transition):
3746         (JSC::PutByIdVariant::setter):
3747         (JSC::PutByIdVariant::attemptToMerge):
3748         (JSC::PutByIdVariant::dumpInContext):
3749         * bytecode/PutByIdVariant.h:
3750         (JSC::PutByIdVariant::newStructure):
3751         (JSC::PutByIdVariant::requiredType):
3752         * bytecode/UnlinkedCodeBlock.h:
3753         (JSC::UnlinkedInstruction::UnlinkedInstruction):
3754         * bytecode/Watchpoint.h:
3755         (JSC::InlineWatchpointSet::touch):
3756         (JSC::InlineWatchpointSet::isBeingWatched):
3757         * bytecompiler/BytecodeGenerator.cpp:
3758         (JSC::BytecodeGenerator::addConstantValue):
3759         (JSC::BytecodeGenerator::emitPutById):
3760         (JSC::BytecodeGenerator::emitDirectPutById):
3761         * dfg/DFGAbstractInterpreter.h:
3762         (JSC::DFG::AbstractInterpreter::filter):
3763         (JSC::DFG::AbstractInterpreter::filterByValue):
3764         * dfg/DFGAbstractInterpreterInlines.h:
3765         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3766         (JSC::DFG::AbstractInterpreter<AbstractStateType>::filter):
3767         * dfg/DFGAbstractValue.cpp:
3768         (JSC::DFG::AbstractValue::setType):
3769         (JSC::DFG::AbstractValue::set):
3770         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
3771         (JSC::DFG::AbstractValue::mergeOSREntryValue):
3772         (JSC::DFG::AbstractValue::isType):
3773         (JSC::DFG::AbstractValue::filter):
3774         (JSC::DFG::AbstractValue::filterValueByType):
3775         * dfg/DFGAbstractValue.h:
3776         (JSC::DFG::AbstractValue::setType):
3777         (JSC::DFG::AbstractValue::isType):
3778         (JSC::DFG::AbstractValue::validate):
3779         * dfg/DFGByteCodeParser.cpp:
3780         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
3781         (JSC::DFG::ByteCodeParser::handleGetByOffset):
3782         (JSC::DFG::ByteCodeParser::handlePutByOffset):
3783         (JSC::DFG::ByteCodeParser::load):
3784         (JSC::DFG::ByteCodeParser::store):
3785         (JSC::DFG::ByteCodeParser::handleGetById):
3786         (JSC::DFG::ByteCodeParser::handlePutById):
3787         * dfg/DFGClobbersExitState.cpp:
3788         (JSC::DFG::clobbersExitState):
3789         * dfg/DFGConstantFoldingPhase.cpp:
3790         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3791         (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
3792         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
3793         (JSC::DFG::ConstantFoldingPhase::addBaseCheck):
3794         * dfg/DFGDesiredInferredType.h: Added.
3795         (JSC::DFG::DesiredInferredType::DesiredInferredType):
3796         (JSC::DFG::DesiredInferredType::operator bool):
3797         (JSC::DFG::DesiredInferredType::object):
3798         (JSC::DFG::DesiredInferredType::expected):
3799         (JSC::DFG::DesiredInferredType::isStillValid):
3800         (JSC::DFG::DesiredInferredType::add):
3801         (JSC::DFG::DesiredInferredType::operator==):
3802         (JSC::DFG::DesiredInferredType::operator!=):
3803         (JSC::DFG::DesiredInferredType::isHashTableDeletedValue):
3804         (JSC::DFG::DesiredInferredType::hash):
3805         (JSC::DFG::DesiredInferredType::dumpInContext):
3806         (JSC::DFG::DesiredInferredType::dump):
3807         (JSC::DFG::DesiredInferredTypeHash::hash):
3808         (JSC::DFG::DesiredInferredTypeHash::equal):
3809         * dfg/DFGDesiredWatchpoints.cpp:
3810         (JSC::DFG::AdaptiveStructureWatchpointAdaptor::add):
3811         (JSC::DFG::InferredTypeAdaptor::add):
3812         (JSC::DFG::DesiredWatchpoints::DesiredWatchpoints):
3813         (JSC::DFG::DesiredWatchpoints::~DesiredWatchpoints):
3814         (JSC::DFG::DesiredWatchpoints::addLazily):
3815         (JSC::DFG::DesiredWatchpoints::consider):
3816         (JSC::DFG::DesiredWatchpoints::reallyAdd):
3817         (JSC::DFG::DesiredWatchpoints::areStillValid):
3818         (JSC::DFG::DesiredWatchpoints::dumpInContext):
3819         * dfg/DFGDesiredWatchpoints.h:
3820         (JSC::DFG::AdaptiveStructureWatchpointAdaptor::dumpInContext):
3821         (JSC::DFG::InferredTypeAdaptor::hasBeenInvalidated):
3822         (JSC::DFG::InferredTypeAdaptor::dumpInContext):
3823         (JSC::DFG::DesiredWatchpoints::isWatched):
3824         * dfg/DFGFixupPhase.cpp:
3825         (JSC::DFG::FixupPhase::fixupNode):
3826         * dfg/DFGGraph.cpp:
3827         (JSC::DFG::Graph::dump):
3828         (JSC::DFG::Graph::isSafeToLoad):
3829         (JSC::DFG::Graph::inferredTypeFor):
3830         (JSC::DFG::Graph::livenessFor):
3831         (JSC::DFG::Graph::tryGetConstantProperty):
3832         (JSC::DFG::Graph::inferredValueForProperty):
3833         (JSC::DFG::Graph::tryGetConstantClosureVar):
3834         * dfg/DFGGraph.h:
3835         (JSC::DFG::Graph::registerInferredType):
3836         (JSC::DFG::Graph::inferredTypeForProperty):
3837         * dfg/DFGInferredTypeCheck.cpp: Added.
3838         (JSC::DFG::insertInferredTypeCheck):
3839         * dfg/DFGInferredTypeCheck.h: Added.
3840         * dfg/DFGNode.h:
3841         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3842         * dfg/DFGPropertyTypeKey.h: Added.
3843         (JSC::DFG::PropertyTypeKey::PropertyTypeKey):
3844         (JSC::DFG::PropertyTypeKey::operator bool):
3845         (JSC::DFG::PropertyTypeKey::structure):
3846         (JSC::DFG::PropertyTypeKey::uid):
3847         (JSC::DFG::PropertyTypeKey::operator==):
3848         (JSC::DFG::PropertyTypeKey::operator!=):
3849         (JSC::DFG::PropertyTypeKey::hash):
3850         (JSC::DFG::PropertyTypeKey::isHashTableDeletedValue):
3851         (JSC::DFG::PropertyTypeKey::dumpInContext):
3852         (JSC::DFG::PropertyTypeKey::dump):
3853         (JSC::DFG::PropertyTypeKey::deletedUID):
3854         (JSC::DFG::PropertyTypeKeyHash::hash):
3855         (JSC::DFG::PropertyTypeKeyHash::equal):
3856         * dfg/DFGSafeToExecute.h:
3857         (JSC::DFG::SafeToExecuteEdge::operator()):
3858         (JSC::DFG::safeToExecute):
3859         * dfg/DFGSpeculativeJIT.cpp:
3860         (JSC::DFG::SpeculativeJIT::compileTypeOf):
3861         (JSC::DFG::SpeculativeJIT::compileCheckStructure):
3862         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
3863         (JSC::DFG::SpeculativeJIT::speculateCell):
3864         (JSC::DFG::SpeculativeJIT::speculateCellOrOther):
3865         (JSC::DFG::SpeculativeJIT::speculateObject):
3866         (JSC::DFG::SpeculativeJIT::speculate):
3867         * dfg/DFGSpeculativeJIT.h:
3868         * dfg/DFGSpeculativeJIT32_64.cpp:
3869         (JSC::DFG::SpeculativeJIT::compile):
3870         * dfg/DFGSpeculativeJIT64.cpp:
3871         (JSC::DFG::SpeculativeJIT::compile):
3872         * dfg/DFGStoreBarrierInsertionPhase.cpp:
3873         * dfg/DFGStructureAbstractValue.h:
3874         (JSC::DFG::StructureAbstractValue::at):
3875         (JSC::DFG::StructureAbstractValue::operator[]):
3876         (JSC::DFG::StructureAbstractValue::onlyStructure):
3877         (JSC::DFG::StructureAbstractValue::forEach):
3878         * dfg/DFGUseKind.cpp:
3879         (WTF::printInternal):
3880         * dfg/DFGUseKind.h:
3881         (JSC::DFG::typeFilterFor):
3882         * dfg/DFGValidate.cpp:
3883         (JSC::DFG::Validate::validate):
3884         * ftl/FTL