Unreviewed, fix all other builds.
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-09-23  Filip Pizlo  <fpizlo@apple.com>
2
3         Unreviewed, fix all other builds.
4
5         * assembler/AbstractMacroAssembler.h:
6
7 2016-09-23  Filip Pizlo  <fpizlo@apple.com>
8
9         Unreviewed, fix cloop.
10
11         * assembler/AbstractMacroAssembler.h:
12         * heap/SlotVisitor.cpp:
13
14 2016-09-22  Filip Pizlo  <fpizlo@apple.com>
15
16         Need a store-load fence between setting cell state and visiting the object in SlotVisitor
17         https://bugs.webkit.org/show_bug.cgi?id=162354
18
19         Reviewed by Mark Lam.
20         
21         This was meant to be a small change, but then it became bigger as I found small
22         opportunities for improving this code. This adds a store-load fence and is performance-
23         neutral. That's probably partly due to other optimizations that I did to visitChildren().
24         
25         Initially, I found that adding an mfence as a store-load fence was terribly expensive. So,
26         I thought that I needed to buffer up a bunch of objects, set their states, do one mfence,
27         and then visit all of them. This seemed like a win, so I went with it. Unfortunately, this
28         made no sense for two reasons:
29         
30         - I shouldn't use mfence. I should use ortop (lock orl $0, (%rsp)) instead. Ortop is
31           basically free, and it's what WTF now uses for storeLoadFence().
32         
33         - My data saying that buffering up objects was not a slow-down was wrong. That was actually
34           almost as expensive as the mfence.
35         
36         But in order to implement that, I made some other improvements that I think we should stick
37         with:
38         
39         - SlotVisitor::visitChildren() now uses a switch on type. This replaces what used to be
40           some nasty ClassInfo look-ups.
41         
42         - We no longer save the object's old CellState. We would do that so that we would know what
43           state the object had been before we blackened it. But I believe that the more logical
44           solution is to have two kinds of black - one for black-for-the-first-time objects and one
45           for repeat offenders. This is a lot easier to reason about, since you can now just figure
46           this out by looking at the cell directly.
47         
48         The latter change meant rewiring a bunch of barriers. It didn't make them any more
49         expensive.
50
51         * ftl/FTLLowerDFGToB3.cpp:
52         (JSC::FTL::DFG::LowerDFGToB3::emitStoreBarrier):
53         * heap/CellState.h:
54         (JSC::blacken):
55         * heap/Heap.cpp:
56         (JSC::Heap::addToRememberedSet):
57         * heap/Heap.h:
58         * heap/HeapInlines.h:
59         (JSC::Heap::writeBarrier):
60         (JSC::Heap::reportExtraMemoryVisited):
61         (JSC::Heap::reportExternalMemoryVisited):
62         * heap/MarkStack.cpp:
63         * heap/MarkStack.h:
64         * heap/SlotVisitor.cpp:
65         (JSC::SlotVisitor::visitChildren):
66         * heap/SlotVisitor.h:
67         * heap/SlotVisitorInlines.h:
68         (JSC::SlotVisitor::reportExtraMemoryVisited):
69         (JSC::SlotVisitor::reportExternalMemoryVisited):
70         * jit/AssemblyHelpers.h:
71         (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
72         * llint/LLIntData.cpp:
73         (JSC::LLInt::Data::performAssertions):
74         * llint/LowLevelInterpreter.asm:
75         * llint/LowLevelInterpreter32_64.asm:
76         * llint/LowLevelInterpreter64.asm:
77         * runtime/JSObject.h:
78         (JSC::isJSFinalObject):
79
80 2016-09-23  Csaba Osztrogon√°c  <ossy@webkit.org>
81
82         ARM EABI buildfix after r206289
83         https://bugs.webkit.org/show_bug.cgi?id=162486
84
85         Unreviewed buildfix.
86
87         * jit/CCallHelpers.h:
88         (JSC::CCallHelpers::setupArgumentsWithExecState):
89
90 2016-09-23  Antoine Quint  <graouts@apple.com>
91
92         Add a new runtime flag for work on modern media controls (off by default)
93         https://bugs.webkit.org/show_bug.cgi?id=162420
94         <rdar://problem/27989489>
95
96         Reviewed by Eric Carlson.
97
98         * runtime/CommonIdentifiers.h:
99
100 2016-09-23  Carlos Garcia Campos  <cgarcia@igalia.com>
101
102         REGRESSION(r194387): Crash on github.com in IntlDateTimeFormat::resolvedOptions in C locale
103         https://bugs.webkit.org/show_bug.cgi?id=162139
104
105         Reviewed by Michael Catanzaro.
106
107         The crash happens in unix ports because the resolved locale is empty when system locale is "C". IntlObject
108         considers any language tag with a size < 2 to be an invalid language, so "C" is not a valid language to resolve
109         the locale. We should ensure that WTF::platformUserPreferredLanguages() never returns invalid languages, but
110         that's not enough, because languages can be overriden from the public API, so we need to handle those cases and
111         throw exceptions instead of crashing.
112
113         * runtime/IntlCollator.cpp:
114         (JSC::IntlCollator::initializeCollator): Throw a exception when we fail to resolve the locale.
115         * runtime/IntlDateTimeFormat.cpp:
116         (JSC::IntlDateTimeFormat::initializeDateTimeFormat): Ditto.
117         * runtime/IntlNumberFormat.cpp:
118         (JSC::IntlNumberFormat::initializeNumberFormat): Ditto.
119
120 2016-09-22  Benjamin Poulain  <bpoulain@apple.com>
121
122         [JSC] Use an inline cache to generate op_negate
123         https://bugs.webkit.org/show_bug.cgi?id=162371
124
125         Reviewed by Saam Barati.
126
127         Use an inline cache to reduce the amount of code
128         required to implement op_negate.
129
130         For pure integer negate, the generated asm shrinks
131         from 147 bytes to 125 bytes (14%).
132         For double negate, the generated asm shrinks
133         to 130 bytes (11%).
134         The average size on Sunspider is 100bytes, this is due
135         to the op_negates that are never executed and do not
136         generate much.
137
138         * bytecode/ArithProfile.h:
139         (JSC::ArithProfile::ArithProfile):
140         (JSC::ArithProfile::observeLHS):
141         (JSC::ArithProfile::observeLHSAndRHS):
142         * bytecode/BytecodeList.json:
143         * bytecode/CodeBlock.cpp:
144         (JSC::CodeBlock::addJITNegIC):
145         * bytecode/CodeBlock.h:
146         * bytecompiler/BytecodeGenerator.cpp:
147         (JSC::BytecodeGenerator::emitUnaryOp):
148         * bytecompiler/BytecodeGenerator.h:
149         * bytecompiler/NodesCodegen.cpp:
150         (JSC::UnaryOpNode::emitBytecode):
151         * dfg/DFGSpeculativeJIT.cpp:
152         (JSC::DFG::SpeculativeJIT::compileMathIC):
153         * dfg/DFGSpeculativeJIT.h:
154         * ftl/FTLLowerDFGToB3.cpp:
155         (JSC::FTL::DFG::LowerDFGToB3::compileMathIC):
156         * jit/CCallHelpers.h:
157         (JSC::CCallHelpers::setupArgumentsWithExecState):
158         * jit/JIT.h:
159         * jit/JITArithmetic.cpp:
160         (JSC::JIT::emit_op_negate):
161         (JSC::JIT::emitSlow_op_negate):
162         (JSC::JIT::emitMathICFast):
163         (JSC::JIT::emitMathICSlow):
164         * jit/JITInlines.h:
165         (JSC::JIT::callOperation):
166         * jit/JITMathIC.h:
167         (JSC::JITMathIC::generateInline):
168         (JSC::canGenerateWithBinaryProfile):
169         (JSC::canGenerateWithUnaryProfile):
170         * jit/JITMathICForwards.h:
171         * jit/JITNegGenerator.cpp:
172         (JSC::JITNegGenerator::generateInline):
173         (JSC::JITNegGenerator::generateFastPath):
174         * jit/JITNegGenerator.h:
175         (JSC::JITNegGenerator::JITNegGenerator):
176         (JSC::JITNegGenerator::arithProfile):
177         (JSC::JITNegGenerator::didEmitFastPath): Deleted.
178         (JSC::JITNegGenerator::endJumpList): Deleted.
179         (JSC::JITNegGenerator::slowPathJumpList): Deleted.
180         * jit/JITOperations.cpp:
181         * jit/JITOperations.h:
182         * llint/LowLevelInterpreter.asm:
183         * llint/LowLevelInterpreter32_64.asm:
184         * llint/LowLevelInterpreter64.asm:
185         * runtime/CommonSlowPaths.cpp:
186         (JSC::updateArithProfileForUnaryArithOp):
187         (JSC::SLOW_PATH_DECL):
188
189 2016-09-22  Mark Lam  <mark.lam@apple.com>
190
191         Removed unused hasErrorInfo().
192         https://bugs.webkit.org/show_bug.cgi?id=162473
193
194         Reviewed by Saam Barati.
195
196         * JavaScriptCore.order:
197         * runtime/Error.cpp:
198         (JSC::hasErrorInfo): Deleted.
199         * runtime/Error.h:
200
201 2016-09-22  Mark Lam  <mark.lam@apple.com>
202
203         Array.prototype.join should do overflow checks on string joins.
204         https://bugs.webkit.org/show_bug.cgi?id=162459
205
206         Reviewed by Saam Barati.
207
208         Change the 2 JSRopeString::create() functions that do joins to be private, and
209         force all clients of it to go through the jsString() utility functions that do
210         overflow checks before creating the ropes.
211
212         * dfg/DFGOperations.cpp:
213         * runtime/ArrayPrototype.cpp:
214         (JSC::slowJoin):
215         * runtime/JSString.h:
216         * runtime/Operations.h:
217         (JSC::jsString):
218
219 2016-09-22  Filip Pizlo  <fpizlo@apple.com>
220
221         Fences on x86 should be a lot cheaper
222         https://bugs.webkit.org/show_bug.cgi?id=162417
223
224         Reviewed by Mark Lam and Geoffrey Garen.
225
226         It turns out that:
227         
228             lock; orl $0, (%rsp)
229         
230         does everything that we wanted from:
231         
232             mfence
233         
234         And it's a lot faster. When I tried mfence for making object visiting concurrent-GC-TSO-
235         friendly, it was a 9% regression on Octane/splay. But when I tried ortop, it was neutral.
236         So, we should use ortop from now on.
237         
238         This part of the change is for the JITs. MacroAssembler::memoryFence() appears to always
239         mean something like an acqrel fence, so it's safe to make this use ortop. Since B3's Fence
240         compiles to Air MemoryFence, which is just MacroAssembler::memoryFence(), this also changes
241         B3 codegen.
242
243         * assembler/MacroAssemblerX86Common.h:
244         (JSC::MacroAssemblerX86Common::memoryFence):
245         * assembler/X86Assembler.h:
246         (JSC::X86Assembler::lock):
247         * b3/testb3.cpp:
248         (JSC::B3::testX86MFence):
249         (JSC::B3::testX86CompilerFence):
250
251 2016-09-22  Joseph Pecoraro  <pecoraro@apple.com>
252
253         test262: Function length should be number of parameters before parameters with default values
254         https://bugs.webkit.org/show_bug.cgi?id=162377
255
256         Reviewed by Saam Barati.
257
258         https://tc39.github.io/ecma262/#sec-function-definitions-static-semantics-expectedargumentcount
259
260         > NOTE: The ExpectedArgumentCount of a FormalParameterList is the number of
261         > FormalParameters to the left of either the rest parameter or the first
262         > FormalParameter with an Initializer. A FormalParameter without an
263         > initializer is allowed after the first parameter with an initializer
264         > but such parameters are considered to be optional with undefined as
265         > their default value.
266
267         Alongside the parameterCount value, maintain a separate count,
268         functionLength, which will be the count before seeing a rest parameter
269         or parameter with a default value. This will be the function's length.
270
271         * bytecode/UnlinkedCodeBlock.h:
272         * bytecode/UnlinkedFunctionExecutable.cpp:
273         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
274         * bytecode/UnlinkedFunctionExecutable.h:
275         * parser/ASTBuilder.h:
276         (JSC::ASTBuilder::createFunctionMetadata):
277         * parser/Nodes.cpp:
278         (JSC::FunctionMetadataNode::FunctionMetadataNode):
279         * parser/Nodes.h:
280         * parser/Parser.cpp:
281         (JSC::Parser<LexerType>::isArrowFunctionParameters):
282         (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
283         (JSC::Parser<LexerType>::parseFormalParameters):
284         (JSC::Parser<LexerType>::parseFunctionBody):
285         (JSC::Parser<LexerType>::parseFunctionParameters):
286         (JSC::Parser<LexerType>::parseFunctionInfo):
287         * parser/Parser.h:
288         * parser/ParserFunctionInfo.h:
289         * parser/SourceProviderCacheItem.h:
290         (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
291         * parser/SyntaxChecker.h:
292         (JSC::SyntaxChecker::createFunctionMetadata):
293         * runtime/Executable.h:
294         * runtime/JSFunction.cpp:
295         (JSC::JSFunction::createBuiltinFunction):
296         (JSC::JSFunction::reifyLength):
297
298 2016-09-22  Joseph Pecoraro  <pecoraro@apple.com>
299
300         Remove a bunch of unnecessary includes
301         https://bugs.webkit.org/show_bug.cgi?id=162376
302
303         Reviewed by Mark Lam.
304
305 2016-09-21  Keith Miller  <keith_miller@apple.com>
306
307         Fix build for future versions of Clang.
308         https://bugs.webkit.org/show_bug.cgi?id=162346
309
310         Reviewed by Filip Pizlo.
311
312         This fixes issues with the WebCore build where inline
313         template-class function definitions are marked as exported. This
314         genereates a weak external symobl that our build does not like.
315
316
317         * runtime/VM.h:
318         (JSC::VM::setGlobalConstRedeclarationShouldThrow):
319
320 2016-09-21  Joseph Pecoraro  <pecoraro@apple.com>
321
322         Inline function only used in one place
323         https://bugs.webkit.org/show_bug.cgi?id=162363
324
325         Reviewed by Saam Barati.
326
327         * bytecompiler/NodesCodegen.cpp:
328         (JSC::ForInNode::emitBytecode):
329         (JSC::ForInNode::emitMultiLoopBytecode):
330         * parser/Nodes.h:
331         No need for the extra function, it adds no clarification.
332
333 2016-09-21  Commit Queue  <commit-queue@webkit.org>
334
335         Unreviewed, rolling out r206222 and r206227.
336         https://bugs.webkit.org/show_bug.cgi?id=162361
337
338         "broke the windows build" (Requested by keith_mi_ on #webkit).
339
340         Reverted changesets:
341
342         "Fix build for future versions of Clang."
343         https://bugs.webkit.org/show_bug.cgi?id=162346
344         http://trac.webkit.org/changeset/206222
345
346         "Attempt to fix windows build after r206222."
347         http://trac.webkit.org/changeset/206227
348
349 2016-09-21  Filip Pizlo  <fpizlo@apple.com>
350
351         Add a Fence opcode to B3
352         https://bugs.webkit.org/show_bug.cgi?id=162343
353
354         Reviewed by Geoffrey Garen.
355         
356         This adds the most basic fence support to B3. Currently, this is optimal on x86 and correct
357         on ARM. It also happens to be sufficient and optimal for what we'll do in the concurrent GC.
358         
359         The idea of Fence is that it can represent any standalone fence instruction by having two
360         additional params: a read range and a write range. If the write range is empty, this is
361         taken to be a store-store fence, which turns into zero code on x86 and a cheaper fence on
362         ARM.
363         
364         It turns out that this is powerful enough to express store-load and store-store fences. For
365         load-store and load-load fences, you wouldn't have wanted to use any code on x86 and you
366         wouldn't have wanted a standalone barrier on ARM. For those cases, you'd want either a
367         fenced load (load acquire) or a dependency. See bug 162349 and bug 162350, respectively.
368         
369         This isn't yet optimized for store-store fences on ARM because we don't have the
370         MacroAssembler support. Also, the support for "dmb ish" is not really what we want (it seems
371         to use a heavier fence). I don't think that this is urgent because of how the concurrent GC
372         will use this facility. I've left that to bug 162342.
373
374         * CMakeLists.txt:
375         * JavaScriptCore.xcodeproj/project.pbxproj:
376         * assembler/MacroAssemblerCodeRef.cpp:
377         (JSC::MacroAssemblerCodeRef::tryToDisassemble):
378         (JSC::MacroAssemblerCodeRef::disassembly):
379         * assembler/MacroAssemblerCodeRef.h:
380         (JSC::MacroAssemblerCodeRef::size): Deleted.
381         (JSC::MacroAssemblerCodeRef::tryToDisassemble): Deleted.
382         * b3/B3Compilation.h:
383         (JSC::B3::Compilation::codeRef):
384         (JSC::B3::Compilation::disassembly):
385         (JSC::B3::Compilation::code): Deleted.
386         * b3/B3Effects.h:
387         * b3/B3FenceValue.cpp: Added.
388         (JSC::B3::FenceValue::~FenceValue):
389         (JSC::B3::FenceValue::cloneImpl):
390         (JSC::B3::FenceValue::FenceValue):
391         * b3/B3FenceValue.h: Added.
392         * b3/B3LowerToAir.cpp:
393         (JSC::B3::Air::LowerToAir::lower):
394         * b3/B3Opcode.cpp:
395         (WTF::printInternal):
396         * b3/B3Opcode.h:
397         * b3/B3Validate.cpp:
398         * b3/B3Value.cpp:
399         (JSC::B3::Value::effects):
400         * b3/air/AirOpcode.opcodes:
401         * b3/testb3.cpp:
402         (JSC::B3::checkUsesInstruction):
403         (JSC::B3::checkDoesNotUseInstruction):
404         (JSC::B3::testX86MFence):
405         (JSC::B3::testX86CompilerFence):
406         (JSC::B3::run):
407
408 2016-09-21  Keith Miller  <keith_miller@apple.com>
409
410         Fix build for future versions of Clang.
411         https://bugs.webkit.org/show_bug.cgi?id=162346
412
413         Reviewed by Filip Pizlo.
414
415         This fixes issues with the WebCore build where inline
416         template-class function definitions are marked as exported. This
417         genereates a weak external symobl that our build does not like.
418
419
420         * runtime/VM.h:
421         (JSC::VM::setGlobalConstRedeclarationShouldThrow):
422
423 2016-09-21  Chris Dumez  <cdumez@apple.com>
424
425         Object.getOwnPropertyDescriptor() does not work correctly cross origin
426         https://bugs.webkit.org/show_bug.cgi?id=162311
427
428         Reviewed by Gavin Barraclough.
429
430         Add a CustomGetterSetter field to PropertySlot that gets populated
431         by getOwnPropertySlot() and use it in getOwnPropertyDescriptor()
432         to properly populate the descriptor. We used to rely on reifying
433         the properties and then call getDirect() in order to get the
434         CustomGetterSetter. However, this hack was insufficient to support
435         the cross-origin case because we need to control more precisely
436         the visibility of the getter and the setter. For example, Location's
437         href property has both a getter and a setter in the same origin
438         case but only has a setter in the cross-origin case.
439
440         In the future, we can extend the use of PropertySlot's
441         customGetterSetter field to the same origin case and get rid of the
442         reification + getDirect() hack in getOwnPropertyDescriptor().
443
444         * runtime/JSObject.cpp:
445         (JSC::JSObject::getOwnPropertyDescriptor):
446         * runtime/PropertySlot.cpp:
447         (JSC::PropertySlot::customAccessorGetter):
448         * runtime/PropertySlot.h:
449
450 2016-09-21  Michael Saboff  <msaboff@apple.com>
451
452         FTL needs to reserve callee stack space in bytes
453         https://bugs.webkit.org/show_bug.cgi?id=162324
454
455         Reviewed by Geoffrey Garen.
456
457         Changed two instances where we call B3::Procedure::requestCallArgAreaSize() with the
458         number of JSValue sized objects of stack space instead of bytes.  The correct units
459         to use is bytes.
460
461         Renamed both the Air and B3 related callArgAreaSize() to callArgAreaSizeInBytes().
462
463         No new tests as this doesn't surface as an issue when arguments are passed on the stack.
464
465         * b3/B3Procedure.cpp:
466         (JSC::B3::Procedure::callArgAreaSizeInBytes):
467         (JSC::B3::Procedure::requestCallArgAreaSizeInBytes):
468         (JSC::B3::Procedure::callArgAreaSize): Deleted.
469         (JSC::B3::Procedure::requestCallArgAreaSize): Deleted.
470         * b3/B3Procedure.h:
471         * b3/air/AirAllocateStack.cpp:
472         (JSC::B3::Air::allocateStack):
473         * b3/air/AirCCallingConvention.cpp:
474         (JSC::B3::Air::computeCCallingConvention):
475         * b3/air/AirCode.h:
476         (JSC::B3::Air::Code::callArgAreaSizeInBytes):
477         (JSC::B3::Air::Code::requestCallArgAreaSizeInBytes):
478         (JSC::B3::Air::Code::callArgAreaSize): Deleted.
479         (JSC::B3::Air::Code::requestCallArgAreaSize): Deleted.
480         * ftl/FTLLowerDFGToB3.cpp:
481         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
482         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
483         (JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
484
485 2016-09-21  Csaba Osztrogon√°c  <ossy@webkit.org>
486
487         [ARM] Unreviewed buildfix after r206136.
488
489         * assembler/MacroAssembler.h:
490         * assembler/MacroAssemblerARM.h:
491         (JSC::MacroAssemblerARM::branchPtr): Added.
492
493 2016-09-20  Alex Christensen  <achristensen@webkit.org>
494
495         Require WTFMove for String::adopt
496         https://bugs.webkit.org/show_bug.cgi?id=162313
497
498         Reviewed by Yusuke Suzuki.
499
500         * runtime/JSStringBuilder.h:
501         (JSC::JSStringBuilder::build):
502
503 2016-09-20  Joseph Pecoraro  <pecoraro@apple.com>
504
505         REGRESSION(r205692): Minified builds have broken inspector
506         https://bugs.webkit.org/show_bug.cgi?id=162327
507         <rdar://problem/28370137>
508
509         Reviewed by Matt Baker.
510
511         * Scripts/cssmin.py:
512         (cssminify):
513         Converge on the newer cssmin that we mistakenly dropped in r205692.
514         This knows how to handle more cases.
515
516 2016-09-20  Filip Pizlo  <fpizlo@apple.com>
517
518         DFG::StoreBarrierInsertionPhase should assume that any epoch increment may make objects older
519         https://bugs.webkit.org/show_bug.cgi?id=162319
520
521         Reviewed by Saam Barati.
522         
523         The store barrier phase needs to be aware of the fact that an object that is not in the
524         OldBlack state may be concurrently brought into that state. That means that:
525         
526         - We cannot reason about the relative ages of objects. An object is either new, in which
527           case we can store to it without barriers, or it's not in which case it needs a barrier.
528         
529         - After we insert a barrier on an object, the object is no longer new, because now the GC
530           knows about it and the GC may do things to it, like make it OldBlack.
531         
532         This is a perf-neutral change. These optimizations were never particularly profitable.
533
534         * dfg/DFGStoreBarrierInsertionPhase.cpp:
535
536 2016-09-20  Filip Pizlo  <fpizlo@apple.com>
537
538         Rename MarkedSpace::version/MarkedBlock::version to MarkedSpace::markingVersion/MarkedBlock::markingVersion
539         https://bugs.webkit.org/show_bug.cgi?id=162310
540
541         Reviewed by Geoffrey Garen.
542         
543         In bug 162309, which is part of my concurrent GC work, I'll need to introduce a second
544         version-based flip. This one will be for newlyAllocated bits. This will allow me to
545         cheaply preserve per-object live state during marking. MarkedBlock::aboutToMarkSlow() will
546         do this instead of clearMarks():
547         
548             - Walk the mark bits, simultaneously counting the number of set bits and clearing
549               them.
550             - If the count is zero, then we're done.
551             - If the count is equal to the max number of cells in the block, then set the
552               allocated bit for the block.
553             - If the count is something else, create a newlyAllocated vector.
554         
555         The hope is that the last mode is going to be rare, since most blocks are not fragmented
556         at end of GC. Usually, we will fill them in with objects by allocating! But if we do
557         create newlyAllocated bits then we need to have some way of blowing them away later.
558         
559         This is where a second version comes in. We can have a version for newlyAllocated bits,
560         which we increment at the end of marking, at around the same time that we clear all
561         allocated bits.
562         
563         This means that the MarkedBlock will have two different version-based flips, so terms like
564         "flip" and "version" aren't enough.
565         
566         This patch gets rid of the term "flip" entirely. It's a term of art in GCs that refers to
567         the state change at the beginning or end of GC. It refers to the logical state change, not
568         the physical one. It doesn't actually make sense to speak of a block being flipped
569         independently of other blocks. It's true that our implementation of the flip makes some
570         state updates happen lazily, but the block updating itself in some way (like clearing mark
571         bits) isn't the flip - the flip already happened when the version was incremented.
572         
573         We no longer refer to a version without qualifying what kind of version it is. The type is
574         HeapVersion. All of the version members were renamed to markingVersion, to reflect the
575         fact that this version is just used for doing things to marking state. Instead of asking
576         if the block needsFlip(), we ask if areMarksStale().
577         
578         This will let us introduce a second version for newlyAllocated, and will let us speak of
579         the two versions unambiguously.
580
581         * heap/CellContainer.h:
582         * heap/CellContainerInlines.h:
583         (JSC::CellContainer::isMarked):
584         (JSC::CellContainer::isMarkedOrNewlyAllocated):
585         (JSC::CellContainer::aboutToMark):
586         (JSC::CellContainer::areMarksStale):
587         (JSC::CellContainer::needsFlip): Deleted.
588         * heap/ConservativeRoots.cpp:
589         (JSC::ConservativeRoots::genericAddPointer):
590         (JSC::ConservativeRoots::genericAddSpan):
591         * heap/HeapInlines.h:
592         (JSC::Heap::isMarked):
593         (JSC::Heap::isMarkedConcurrently):
594         (JSC::Heap::testAndSetMarked):
595         * heap/HeapUtil.h:
596         (JSC::HeapUtil::findGCObjectPointersForMarking):
597         * heap/MarkedAllocator.cpp:
598         (JSC::MarkedAllocator::isPagedOut):
599         * heap/MarkedBlock.cpp:
600         (JSC::MarkedBlock::MarkedBlock):
601         (JSC::MarkedBlock::Handle::specializedSweep):
602         (JSC::MarkedBlock::Handle::sweepHelperSelectSweepMode):
603         (JSC::MarkedBlock::Handle::sweepHelperSelectMarksMode):
604         (JSC::MarkedBlock::aboutToMarkSlow):
605         (JSC::MarkedBlock::clearMarks):
606         (JSC::MarkedBlock::assertMarksNotStale):
607         (JSC::MarkedBlock::areMarksStale):
608         (JSC::MarkedBlock::Handle::areMarksStale):
609         (JSC::MarkedBlock::isMarked):
610         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
611         (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
612         (JSC::MarkedBlock::markCount):
613         (JSC::MarkedBlock::Handle::isLive):
614         (JSC::MarkedBlock::Handle::isLiveCell):
615         (JSC::MarkedBlock::Handle::sweepHelperSelectFlipMode): Deleted.
616         (JSC::MarkedBlock::assertFlipped): Deleted.
617         (JSC::MarkedBlock::needsFlip): Deleted.
618         (JSC::MarkedBlock::Handle::needsFlip): Deleted.
619         * heap/MarkedBlock.h:
620         (JSC::MarkedBlock::areMarksStale):
621         (JSC::MarkedBlock::aboutToMark):
622         (JSC::MarkedBlock::assertMarksNotStale):
623         (JSC::MarkedBlock::Handle::assertMarksNotStale):
624         (JSC::MarkedBlock::isMarked):
625         (JSC::MarkedBlock::isMarkedConcurrently):
626         (JSC::MarkedBlock::testAndSetMarked):
627         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
628         (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
629         (JSC::MarkedBlock::needsFlip): Deleted.
630         (JSC::MarkedBlock::assertFlipped): Deleted.
631         (JSC::MarkedBlock::Handle::assertFlipped): Deleted.
632         * heap/MarkedBlockInlines.h:
633         (JSC::MarkedBlock::Handle::isLive):
634         (JSC::MarkedBlock::Handle::isLiveCell):
635         (JSC::MarkedBlock::resetMarkingVersion):
636         (JSC::MarkedBlock::resetVersion): Deleted.
637         * heap/MarkedSpace.cpp:
638         (JSC::MarkedSpace::beginMarking):
639         * heap/MarkedSpace.h:
640         (JSC::MarkedSpace::markingVersion):
641         (JSC::MarkedSpace::version): Deleted.
642         * heap/SlotVisitor.cpp:
643         (JSC::SlotVisitor::SlotVisitor):
644         (JSC::SlotVisitor::didStartMarking):
645         (JSC::SlotVisitor::appendJSCellOrAuxiliary):
646         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
647         (JSC::SlotVisitor::markAuxiliary):
648         * heap/SlotVisitor.h:
649         (JSC::SlotVisitor::markingVersion):
650         (JSC::SlotVisitor::version): Deleted.
651         * heap/WeakBlock.cpp:
652         (JSC::WeakBlock::specializedVisit):
653         (JSC::WeakBlock::reap):
654
655 2016-09-20  Ryan Haddad  <ryanhaddad@apple.com>
656
657         Rebaseline builtins generator tests after r206155.
658
659         Unreviewed test gardening.
660
661         * Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:
662
663 2016-09-20  Filip Pizlo  <fpizlo@apple.com>
664
665         Unreviewed, fix cloop build.
666
667         * runtime/VM.h:
668
669 2016-09-20  Filip Pizlo  <fpizlo@apple.com>
670
671         Make MarkedBlock state tracking support overlapped allocation and marking state
672         https://bugs.webkit.org/show_bug.cgi?id=161581
673
674         Reviewed by Geoffrey Garen.
675         
676         Concurrent GCs must allow for mutation and allocation during collection. We already know
677         how to mutate during collection. We have a write barrier for that. Allocation during
678         collection is more involved: the collector modifies the the mark bits, as well as other
679         kinds of MarkedBlock state, in-place during a collection. The allocator uses that same
680         MarkedBlock state to decide which regions of memory are free. This works if the allocator
681         never runs while the collector is running, but if we want to allow them to run at the same
682         time, then we need to have two versions of the state: one version built up by the
683         collector and another consumed by the allocator. We clear the collector state at the
684         beginning of collection, and splat the collector state onto the allocator state after
685         collection.
686         
687         This could be super expensive, but we can make it cheap with some cleverness. The biggest
688         observation is just that most of the state is a handful of bits per block: is the block
689         free-listed? is it completely full? completely empty? in the incremental sweeper's
690         snapshot? is it retired? is it in eden? There is also state inside blocks, like the mark
691         bits, but I have a solid plan there and I'll save it for another patch. Once we view the
692         state of blocks as bits, we can put that state into bitvectors, so that if the collector
693         needs to transform the state of some blocks, it can do it with a single operation over
694         bitvectors. I like to think of this as 32-way parallelizing block operations, since
695         doing one operation on a 32-bit word in one of those bitvectors instantly affects 32
696         blocks.
697         
698         This change converts all previous collections of MarkedBlocks, along with the MarkedBlock
699         state, into 8 bitvectors (live, empty, allocated, canAllocateButNotEmpty, eden, unswept,
700         markingNotEmpty, and markingRetired). The bitvectors separate allocator state (empty,
701         allocated, canAllocateButNotEmpty) from marking state (markingNotEmpty, markingRetired).
702         
703         As a nice side-effect of switching to bitvectors, we get size class rebalancing for free.
704         It used to be that if a MarkedAllocator had an empty block, we would only allow that
705         memory to be reused by a different MarkedAllocator if we did an incremental sweep or a
706         full eager sweep. Now we hunt down all destructorless empty blocks before allocating new
707         MarkedBlocks. It would be relatively easy to also hunt down destructor empty blocks, but
708         the theory is that those might be expensive to sweep, so it might still be better to leave
709         those to the incremental sweeper.
710         
711         This change is perf-neutral all around. I did some tests with two different kinds of
712         allocation strategies - something that is somewhat easier to do now that you can look for
713         blocks that are candidates for allocation by just scanning some bitvectors. I tried two
714         variants:
715         
716         - Allocate out of non-empty blocks first, leaving empty blocks for last in case a
717           different allocator needed them. This is sort of a best-fit strategy. I tried this
718           first, and it can be expressed as:
719           
720           m_allocationCursor = m_canAllocateButNotEmpty.findBit(m_allocationCursor, true)
721         
722         - Allocate out of lower-indexed blocks first, treating empty and canAllocateButNotEmpty
723           blocks equally. This is sort of a first-fit strategy. This is what I ended up settling
724           on, and it can be expressed as:
725           
726           m_allocationCursor = (m_canAllocateButNotEmpty | m_empty).findBit(m_allocationCursor, true)
727         
728         The best-fit strategy meant 1% regressions in LongSpider and Octane overall, and a 11%
729         regression on Octane/earley. First-fit means perf-neutrality. Most great allocators skew
730         towards first-fit because it's empirically better, so this result is not surprising.
731         
732         Overall, the performance of this patch on my machine is as follows, where "neutral" means
733         less than 1% and not statistically significant.
734         
735         run-jsc-benchmarks:
736             SunSpider: neutral
737             LongSpider: 0.6% slower
738             V8Spider: neutral
739             Octane: neutral
740             Kraken: neutral
741             Microbenchmarks: 0.37% slower
742             AsmBench: neutral
743             CompressionBench: maybe 1% faster
744         
745         For browser benchmarks, I report the ratio of means (bigger / smaller) along with a T-test
746         from Mathematica reported as % chance of not [sic] the null hypothesis. Note that we
747         normally consider anything less than 95% confidence to be inconclusive.
748         
749         Browser benchmarks:
750             PLT3: 0.3% faster with 67% confidence
751             membuster:
752                 Snap2FinishedLoadingPost: 0.68% more memory with 50% confidence
753                 Snap3EndPost: 2.4% more memory with 61% confidence
754             JetStream: 0.2% slower with 32% confidence
755             Speedometer: 0.7% faster with 82% confidence
756         
757         Additionally, Octane/splay's heap capacity goes down to ~180KB from ~200KB, so about a 10%
758         progression. This is due to the allocator rebalancing feature.
759         
760         Finally, this breaks --useImmortalObjects. It was already broken as far as I can tell. I
761         filed a bug to reimplement it (bug 162296). Unless someone urgently needs this internal
762         tool, it's probably best to reimplement it after I'm done refactoring MarkedSpace. 
763
764         * JavaScriptCore.xcodeproj/project.pbxproj:
765         * debugger/Debugger.cpp:
766         * heap/CellContainer.h:
767         * heap/CellContainerInlines.h:
768         (JSC::CellContainer::vm):
769         (JSC::CellContainer::heap):
770         (JSC::CellContainer::isMarkedOrNewlyAllocated):
771         (JSC::CellContainer::aboutToMark):
772         (JSC::CellContainer::isMarked): Deleted.
773         (JSC::CellContainer::flipIfNecessary): Deleted.
774         * heap/ConservativeRoots.cpp:
775         * heap/Heap.cpp:
776         (JSC::Heap::beginMarking):
777         (JSC::Heap::endMarking):
778         (JSC::Heap::collectAllGarbage):
779         (JSC::Heap::collectImpl):
780         (JSC::Heap::snapshotMarkedSpace):
781         (JSC::Heap::prepareForAllocation):
782         (JSC::Heap::zombifyDeadObjects):
783         (JSC::MarkedBlockSnapshotFunctor::MarkedBlockSnapshotFunctor): Deleted.
784         (JSC::MarkedBlockSnapshotFunctor::operator()): Deleted.
785         (JSC::Heap::resetAllocators): Deleted.
786         * heap/Heap.h:
787         * heap/HeapInlines.h:
788         (JSC::Heap::isMarked):
789         (JSC::Heap::isMarkedConcurrently):
790         (JSC::Heap::testAndSetMarked):
791         * heap/HeapStatistics.cpp:
792         * heap/HeapUtil.h:
793         (JSC::HeapUtil::findGCObjectPointersForMarking):
794         (JSC::HeapUtil::isPointerGCObjectJSCell):
795         * heap/HeapVerifier.cpp:
796         * heap/IncrementalSweeper.cpp:
797         (JSC::IncrementalSweeper::IncrementalSweeper):
798         (JSC::IncrementalSweeper::doSweep):
799         (JSC::IncrementalSweeper::sweepNextBlock):
800         (JSC::IncrementalSweeper::startSweeping):
801         (JSC::IncrementalSweeper::willFinishSweeping):
802         * heap/IncrementalSweeper.h:
803         * heap/LargeAllocation.h:
804         (JSC::LargeAllocation::isMarked):
805         (JSC::LargeAllocation::isMarkedConcurrently):
806         (JSC::LargeAllocation::isMarkedOrNewlyAllocated):
807         (JSC::LargeAllocation::aboutToMark):
808         (JSC::LargeAllocation::isMarkedDuringWeakVisiting): Deleted.
809         (JSC::LargeAllocation::flipIfNecessary): Deleted.
810         (JSC::LargeAllocation::flipIfNecessaryDuringMarking): Deleted.
811         * heap/MarkedAllocator.cpp:
812         (JSC::MarkedAllocator::MarkedAllocator):
813         (JSC::MarkedAllocator::isPagedOut):
814         (JSC::MarkedAllocator::findEmptyBlock):
815         (JSC::MarkedAllocator::tryAllocateWithoutCollectingImpl):
816         (JSC::MarkedAllocator::allocateIn):
817         (JSC::MarkedAllocator::tryAllocateIn):
818         (JSC::MarkedAllocator::allocateSlowCaseImpl):
819         (JSC::MarkedAllocator::tryAllocateBlock):
820         (JSC::MarkedAllocator::addBlock):
821         (JSC::MarkedAllocator::removeBlock):
822         (JSC::MarkedAllocator::stopAllocating):
823         (JSC::MarkedAllocator::prepareForAllocation):
824         (JSC::MarkedAllocator::lastChanceToFinalize):
825         (JSC::MarkedAllocator::resumeAllocating):
826         (JSC::MarkedAllocator::beginMarkingForFullCollection):
827         (JSC::MarkedAllocator::endMarking):
828         (JSC::MarkedAllocator::snapshotForEdenCollection):
829         (JSC::MarkedAllocator::snapshotForFullCollection):
830         (JSC::MarkedAllocator::findBlockToSweep):
831         (JSC::MarkedAllocator::sweep):
832         (JSC::MarkedAllocator::shrink):
833         (JSC::MarkedAllocator::assertSnapshotEmpty):
834         (JSC::MarkedAllocator::dump):
835         (JSC::MarkedAllocator::dumpBits):
836         (JSC::MarkedAllocator::retire): Deleted.
837         (JSC::MarkedAllocator::filterNextBlock): Deleted.
838         (JSC::MarkedAllocator::setNextBlockToSweep): Deleted.
839         (JSC::MarkedAllocator::reset): Deleted.
840         * heap/MarkedAllocator.h:
841         (JSC::MarkedAllocator::forEachBitVector):
842         (JSC::MarkedAllocator::forEachBitVectorWithName):
843         (JSC::MarkedAllocator::nextAllocator):
844         (JSC::MarkedAllocator::setNextAllocator):
845         (JSC::MarkedAllocator::forEachBlock):
846         (JSC::MarkedAllocator::resumeAllocating): Deleted.
847         * heap/MarkedBlock.cpp:
848         (JSC::MarkedBlock::tryCreate):
849         (JSC::MarkedBlock::Handle::Handle):
850         (JSC::MarkedBlock::Handle::~Handle):
851         (JSC::MarkedBlock::MarkedBlock):
852         (JSC::MarkedBlock::Handle::specializedSweep):
853         (JSC::MarkedBlock::Handle::sweep):
854         (JSC::MarkedBlock::Handle::sweepHelperSelectScribbleMode):
855         (JSC::MarkedBlock::Handle::sweepHelperSelectEmptyMode):
856         (JSC::MarkedBlock::Handle::sweepHelperSelectHasNewlyAllocated):
857         (JSC::MarkedBlock::Handle::sweepHelperSelectSweepMode):
858         (JSC::MarkedBlock::Handle::sweepHelperSelectFlipMode):
859         (JSC::MarkedBlock::Handle::unsweepWithNoNewlyAllocated):
860         (JSC::MarkedBlock::Handle::setIsFreeListed):
861         (JSC::MarkedBlock::Handle::stopAllocating):
862         (JSC::MarkedBlock::Handle::lastChanceToFinalize):
863         (JSC::MarkedBlock::Handle::resumeAllocating):
864         (JSC::MarkedBlock::aboutToMarkSlow):
865         (JSC::MarkedBlock::clearMarks):
866         (JSC::MarkedBlock::isMarked):
867         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
868         (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
869         (JSC::MarkedBlock::Handle::didConsumeFreeList):
870         (JSC::MarkedBlock::markCount):
871         (JSC::MarkedBlock::Handle::isEmpty):
872         (JSC::MarkedBlock::noteMarkedSlow):
873         (JSC::MarkedBlock::Handle::removeFromAllocator):
874         (JSC::MarkedBlock::Handle::didAddToAllocator):
875         (JSC::MarkedBlock::Handle::didRemoveFromAllocator):
876         (JSC::MarkedBlock::Handle::isLive):
877         (JSC::MarkedBlock::Handle::isLiveCell):
878         (JSC::MarkedBlock::Handle::sweepHelperSelectStateAndSweepMode): Deleted.
879         (JSC::MarkedBlock::flipIfNecessary): Deleted.
880         (JSC::MarkedBlock::Handle::flipIfNecessary): Deleted.
881         (JSC::MarkedBlock::flipIfNecessarySlow): Deleted.
882         (JSC::MarkedBlock::flipIfNecessaryDuringMarkingSlow): Deleted.
883         (JSC::MarkedBlock::Handle::willRemoveBlock): Deleted.
884         (WTF::printInternal): Deleted.
885         * heap/MarkedBlock.h:
886         (JSC::MarkedBlock::Handle::isFreeListed):
887         (JSC::MarkedBlock::Handle::index):
888         (JSC::MarkedBlock::aboutToMark):
889         (JSC::MarkedBlock::isMarked):
890         (JSC::MarkedBlock::isMarkedConcurrently):
891         (JSC::MarkedBlock::Handle::isMarkedOrNewlyAllocated):
892         (JSC::MarkedBlock::isMarkedOrNewlyAllocated):
893         (JSC::MarkedBlock::Handle::isOnBlocksToSweep): Deleted.
894         (JSC::MarkedBlock::Handle::setIsOnBlocksToSweep): Deleted.
895         (JSC::MarkedBlock::Handle::state): Deleted.
896         (JSC::MarkedBlock::flipIfNecessary): Deleted.
897         (JSC::MarkedBlock::flipIfNecessaryDuringMarking): Deleted.
898         (JSC::MarkedBlock::Handle::flipIfNecessary): Deleted.
899         (JSC::MarkedBlock::Handle::flipIfNecessaryDuringMarking): Deleted.
900         (JSC::MarkedBlock::Handle::flipForEdenCollection): Deleted.
901         (JSC::MarkedBlock::isMarkedDuringWeakVisiting): Deleted.
902         (JSC::MarkedBlock::Handle::isLive): Deleted.
903         (JSC::MarkedBlock::Handle::isLiveCell): Deleted.
904         (JSC::MarkedBlock::Handle::forEachLiveCell): Deleted.
905         (JSC::MarkedBlock::Handle::forEachDeadCell): Deleted.
906         (JSC::MarkedBlock::Handle::needsSweeping): Deleted.
907         (JSC::MarkedBlock::Handle::isAllocated): Deleted.
908         (JSC::MarkedBlock::Handle::isMarked): Deleted.
909         * heap/MarkedBlockInlines.h: Added.
910         (JSC::MarkedBlock::Handle::isLive):
911         (JSC::MarkedBlock::Handle::isLiveCell):
912         (JSC::MarkedBlock::Handle::forEachLiveCell):
913         (JSC::MarkedBlock::Handle::forEachDeadCell):
914         (JSC::MarkedBlock::resetVersion):
915         * heap/MarkedSpace.cpp:
916         (JSC::MarkedSpace::MarkedSpace):
917         (JSC::MarkedSpace::allocate):
918         (JSC::MarkedSpace::tryAllocate):
919         (JSC::MarkedSpace::sweep):
920         (JSC::MarkedSpace::prepareForAllocation):
921         (JSC::MarkedSpace::shrink):
922         (JSC::MarkedSpace::clearNewlyAllocated):
923         (JSC::MarkedSpace::beginMarking):
924         (JSC::MarkedSpace::endMarking):
925         (JSC::MarkedSpace::didAllocateInBlock):
926         (JSC::MarkedSpace::findEmptyBlock):
927         (JSC::MarkedSpace::snapshot):
928         (JSC::MarkedSpace::assertSnapshotEmpty):
929         (JSC::MarkedSpace::dumpBits):
930         (JSC::MarkedSpace::zombifySweep): Deleted.
931         (JSC::MarkedSpace::resetAllocators): Deleted.
932         (JSC::VerifyMarked::operator()): Deleted.
933         (JSC::MarkedSpace::flip): Deleted.
934         * heap/MarkedSpace.h:
935         (JSC::MarkedSpace::nextVersion):
936         (JSC::MarkedSpace::firstAllocator):
937         (JSC::MarkedSpace::allocatorForEmptyAllocation):
938         (JSC::MarkedSpace::forEachAllocator):
939         (JSC::MarkedSpace::blocksWithNewObjects): Deleted.
940         (JSC::MarkedSpace::setIsMarking): Deleted.
941         (JSC::MarkedSpace::forEachLiveCell): Deleted.
942         (JSC::MarkedSpace::forEachDeadCell): Deleted.
943         * heap/MarkedSpaceInlines.h: Added.
944         (JSC::MarkedSpace::forEachLiveCell):
945         (JSC::MarkedSpace::forEachDeadCell):
946         * heap/SlotVisitor.cpp:
947         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
948         (JSC::SlotVisitor::markAuxiliary):
949         (JSC::SlotVisitor::visitChildren):
950         * heap/Weak.h:
951         (WTF::HashTraits<JSC::Weak<T>>::emptyValue):
952         (WTF::HashTraits<JSC::Weak<T>>::peek):
953         * heap/WeakBlock.cpp:
954         (JSC::WeakBlock::specializedVisit):
955         (JSC::WeakBlock::reap):
956         * heap/WeakInlines.h:
957         (WTF::HashTraits<JSC::Weak<T>>::emptyValue): Deleted.
958         (WTF::HashTraits<JSC::Weak<T>>::peek): Deleted.
959         * jit/JITThunks.h:
960         * runtime/JSGlobalObject.cpp:
961         * runtime/PrototypeMap.h:
962         * runtime/SamplingProfiler.cpp:
963         * runtime/WeakGCMap.h:
964         * tools/JSDollarVMPrototype.cpp:
965
966 2016-09-20  Jonathan Bedard  <jbedard@apple.com>
967
968         Undefined behavior: Left shift negative number
969         https://bugs.webkit.org/show_bug.cgi?id=161866
970
971         Reviewed by Keith Miller.
972
973         Left shifting a negative number is undefined behavior in C/C++, although most implementations do define it. Explicitly clarifying the intended behavior due to shifting negative number in some cases.
974
975         * dfg/DFGAbstractHeap.h:
976         (JSC::DFG::AbstractHeap::encode): Explicitly cast signed integer for left shift.
977
978 2016-09-20  Saam Barati  <sbarati@apple.com>
979
980         Unreviewed fix for 32-bit DFG x86 implementation of HasOwnProperty.
981
982         Fixup phase is always setting ObjectUse on child1() of HasOwnProperty.
983         However, on x86 32-bit, I omitted a call to speculateObject() on child1().
984
985         * dfg/DFGSpeculativeJIT32_64.cpp:
986         (JSC::DFG::SpeculativeJIT::compile):
987
988 2016-09-20  Yusuke Suzuki  <utatane.tea@gmail.com>
989
990         [JSC] Add `typeof value === "symbol"` handling to bytecode compiler
991         https://bugs.webkit.org/show_bug.cgi?id=162253
992
993         Reviewed by Sam Weinig.
994
995         Add `typeof value === "symbol"` handling to the bytecode compiler.
996         The effect is tiny, but it keeps consistency since the bytecode compiler
997         already has the similar optimization for "string" case.
998
999         * bytecode/SpeculatedType.cpp:
1000         (JSC::speculationFromJSType):
1001         * bytecompiler/BytecodeGenerator.cpp:
1002         (JSC::BytecodeGenerator::emitEqualityOp):
1003
1004 2016-09-19  Saam Barati  <sbarati@apple.com>
1005
1006         Make HasOwnProperty faster
1007         https://bugs.webkit.org/show_bug.cgi?id=161708
1008
1009         Reviewed by Geoffrey Garen.
1010
1011         This patch adds a cache for HasOwnProperty. The cache holds tuples
1012         of {StructureID, UniquedStringImpl*, boolean} where the boolean indicates
1013         the result of performing hasOwnProperty on an object with StructureID and
1014         UniquedStringImpl*. If the cache contains an item, we can be guaranteed
1015         that it contains the same result as performing hasOwnProperty on an
1016         object O with a given structure and key. To guarantee this, we only add
1017         items into the cache when the Structure of the given item is cacheable.
1018
1019         The caching strategy is simple: when adding new items into the cache,
1020         we will evict any item that was in the location that the new item
1021         is hashed into. We also clear the cache on every GC. This strategy
1022         proves to be successful on speedometer, which sees a cache hit rate
1023         over 90%. This caching strategy is now inlined into the DFG/FTL JITs
1024         by now recognizing hasOwnProperty as an intrinsic with the corresponding
1025         HasOwnProperty node. The goal of the node is to emit inlined code for
1026         the cache lookup to prevent the overhead of the call for the common
1027         case where we get a cache hit.
1028
1029         I'm seeing around a 1% to 1.5% percent improvement on Speedometer on
1030         my machine. Hopefully the perf bots agree with my machine.
1031
1032         This patch also speeds up the microbenchmark I added by 2.5x.
1033
1034         * JavaScriptCore.xcodeproj/project.pbxproj:
1035         * dfg/DFGAbstractInterpreterInlines.h:
1036         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1037         * dfg/DFGByteCodeParser.cpp:
1038         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1039         * dfg/DFGClobberize.h:
1040         (JSC::DFG::clobberize):
1041         * dfg/DFGDoesGC.cpp:
1042         (JSC::DFG::doesGC):
1043         * dfg/DFGFixupPhase.cpp:
1044         (JSC::DFG::FixupPhase::fixupNode):
1045         * dfg/DFGNodeType.h:
1046         * dfg/DFGOperations.cpp:
1047         * dfg/DFGOperations.h:
1048         * dfg/DFGPredictionPropagationPhase.cpp:
1049         * dfg/DFGSafeToExecute.h:
1050         (JSC::DFG::safeToExecute):
1051         * dfg/DFGSpeculativeJIT.h:
1052         (JSC::DFG::SpeculativeJIT::callOperation):
1053         (JSC::DFG::SpeculateCellOperand::SpeculateCellOperand):
1054         * dfg/DFGSpeculativeJIT32_64.cpp:
1055         (JSC::DFG::SpeculativeJIT::compile):
1056         * dfg/DFGSpeculativeJIT64.cpp:
1057         (JSC::DFG::SpeculativeJIT::compile):
1058         * dfg/DFGValidate.cpp:
1059         * ftl/FTLAbstractHeapRepository.h:
1060         * ftl/FTLCapabilities.cpp:
1061         (JSC::FTL::canCompile):
1062         * ftl/FTLLowerDFGToB3.cpp:
1063         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1064         (JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
1065         * heap/Heap.cpp:
1066         (JSC::Heap::collectImpl):
1067         * jit/JITOperations.h:
1068         * runtime/HasOwnPropertyCache.h: Added.
1069         (JSC::HasOwnPropertyCache::Entry::offsetOfStructureID):
1070         (JSC::HasOwnPropertyCache::Entry::offsetOfImpl):
1071         (JSC::HasOwnPropertyCache::Entry::offsetOfResult):
1072         (JSC::HasOwnPropertyCache::operator delete):
1073         (JSC::HasOwnPropertyCache::create):
1074         (JSC::HasOwnPropertyCache::hash):
1075         (JSC::HasOwnPropertyCache::get):
1076         (JSC::HasOwnPropertyCache::tryAdd):
1077         (JSC::HasOwnPropertyCache::clear):
1078         (JSC::VM::ensureHasOwnPropertyCache):
1079         * runtime/Intrinsic.h:
1080         * runtime/JSObject.h:
1081         * runtime/JSObjectInlines.h:
1082         (JSC::JSObject::hasOwnProperty):
1083         * runtime/ObjectPrototype.cpp:
1084         (JSC::ObjectPrototype::finishCreation):
1085         (JSC::objectProtoFuncHasOwnProperty):
1086         * runtime/Symbol.h:
1087         * runtime/VM.cpp:
1088         * runtime/VM.h:
1089         (JSC::VM::hasOwnPropertyCache):
1090
1091 2016-09-19  Benjamin Poulain  <bpoulain@apple.com>
1092
1093         [JSC] Make the rounding-related nodes support any type
1094         https://bugs.webkit.org/show_bug.cgi?id=161895
1095
1096         Reviewed by Geoffrey Garen.
1097
1098         This patch changes ArithRound, ArithFloor, ArithCeil and ArithTrunc
1099         to support polymorphic input without exiting on entry.
1100
1101         * dfg/DFGAbstractInterpreterInlines.h:
1102         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1103         * dfg/DFGByteCodeParser.cpp:
1104         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1105         The 4 functions ignore any input past the first argument. It is okay
1106         to use the nodes with the first argument and let the Phantoms keep
1107         the remaining arguments live.
1108
1109         * dfg/DFGClobberize.h:
1110         (JSC::DFG::clobberize):
1111         * dfg/DFGFixupPhase.cpp:
1112         (JSC::DFG::FixupPhase::fixupNode):
1113         Our fixup had the issue we have seen on previous nodes: unaryArithShouldSpeculateInt32()
1114         prevents us from picking a good type if we do not see any double.
1115
1116         * dfg/DFGNodeType.h:
1117         * dfg/DFGOperations.cpp:
1118         * dfg/DFGOperations.h:
1119         * dfg/DFGPredictionPropagationPhase.cpp:
1120         Prediction propagation of those nodes are fully determined
1121         from their flags and results's prediction. They are moved
1122         to the invariant processing.
1123
1124         * dfg/DFGSpeculativeJIT.cpp:
1125         (JSC::DFG::SpeculativeJIT::compileArithRounding):
1126         * ftl/FTLLowerDFGToB3.cpp:
1127         (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
1128         (JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
1129         (JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
1130         (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
1131
1132 2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1133
1134         Unreviewed, build fix for Win64
1135         https://bugs.webkit.org/show_bug.cgi?id=162132
1136
1137         In Windows 64bit, t3 register in LLInt is not r[a-d]x.
1138         It means that this cannot be used for byte operation.
1139
1140         * llint/LowLevelInterpreter64.asm:
1141
1142 2016-09-19  Daniel Bates  <dabates@apple.com>
1143
1144         Remove ENABLE(TEXT_AUTOSIZING) automatic text size adjustment code
1145         https://bugs.webkit.org/show_bug.cgi?id=162167
1146
1147         Reviewed by Simon Fraser.
1148
1149         * Configurations/FeatureDefines.xcconfig:
1150
1151 2016-09-19  Keith Miller  <keith_miller@apple.com>
1152
1153         Update WASM towards 0xc
1154         https://bugs.webkit.org/show_bug.cgi?id=162067
1155
1156         Reviewed by Geoffrey Garen.
1157
1158         This patch updates some of the core parts of the WASM frontend to the 0xc standard.
1159         First, it changes the section names from strings to bytecodes. It also adds support
1160         for inline block signatures. This is a change from the old version that used to have
1161         each branch indicate the arity. Finally, this patch updates all the tests and deletes
1162         a duplicate test.
1163
1164         * CMakeLists.txt:
1165         * JavaScriptCore.xcodeproj/project.pbxproj:
1166         * testWASM.cpp:
1167         (runWASMTests):
1168         * wasm/WASMB3IRGenerator.cpp:
1169         * wasm/WASMFormat.h:
1170         * wasm/WASMFunctionParser.h:
1171         (JSC::WASM::FunctionParser<Context>::FunctionParser):
1172         (JSC::WASM::FunctionParser<Context>::parseBlock):
1173         (JSC::WASM::FunctionParser<Context>::parseExpression):
1174         * wasm/WASMModuleParser.cpp:
1175         (JSC::WASM::ModuleParser::parse):
1176         * wasm/WASMSections.cpp: Removed.
1177         (JSC::WASM::Sections::lookup): Deleted.
1178         * wasm/WASMSections.h:
1179         (JSC::WASM::Sections::validateOrder):
1180
1181 2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1182
1183         [JSC] Use is_cell_with_type for @isRegExpObject, @isMap, and @isSet
1184         https://bugs.webkit.org/show_bug.cgi?id=162142
1185
1186         Reviewed by Michael Saboff.
1187
1188         Use is_cell_with_type for @isRegExpObject, @isMap and @isSet.
1189         Previously, they were implemented as functions and only @isRegExpObject was handled in the DFG and FTL.
1190         The recently added op_is_cell_with_type bytecode and DFG IsCellWithType node allows us to simplify the above checks in all JIT tiers.
1191         Changed these checks to bytecode intrinsics using op_is_cell_with_type.
1192
1193         * builtins/BuiltinNames.h:
1194         * bytecode/BytecodeIntrinsicRegistry.h:
1195         * bytecode/SpeculatedType.cpp:
1196         (JSC::speculationFromJSType):
1197         * bytecompiler/BytecodeGenerator.h:
1198         (JSC::BytecodeGenerator::emitIsRegExpObject):
1199         (JSC::BytecodeGenerator::emitIsMap):
1200         (JSC::BytecodeGenerator::emitIsSet):
1201         (JSC::BytecodeGenerator::emitIsProxyObject): Deleted.
1202         * bytecompiler/NodesCodegen.cpp:
1203         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isRegExpObject):
1204         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isMap):
1205         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isSet):
1206         * dfg/DFGByteCodeParser.cpp:
1207         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1208         * runtime/ECMAScriptSpecInternalFunctions.cpp:
1209         (JSC::esSpecIsRegExpObject): Deleted.
1210         * runtime/ECMAScriptSpecInternalFunctions.h:
1211         * runtime/Intrinsic.h:
1212         * runtime/JSGlobalObject.cpp:
1213         (JSC::JSGlobalObject::init):
1214         * runtime/MapPrototype.cpp:
1215         (JSC::privateFuncIsMap): Deleted.
1216         * runtime/MapPrototype.h:
1217         * runtime/SetPrototype.cpp:
1218         (JSC::privateFuncIsSet): Deleted.
1219         * runtime/SetPrototype.h:
1220
1221 2016-09-19  Brian Burg  <bburg@apple.com>
1222
1223         Web Replay: teach the replay inputs generator to encode and decode OptionSet<T>
1224         https://bugs.webkit.org/show_bug.cgi?id=162107
1225
1226         Reviewed by Anders Carlsson.
1227
1228         Add a new type flag OPTION_SET. This means that the type is a typechecked enum class
1229         declaration, but it's stored in an OptionSet object and can contain multiple
1230         distinct enumeration values like an untyped enum declaration.
1231
1232         Do some cleanup since the generator now supports three different enumerable types:
1233         'enum', 'enum class', and 'OptionSet<T>' where T is an enum class.
1234
1235         Also clean up some sloppy variable names. Using an 'enum_' prefix is really confusing now.
1236
1237         * replay/scripts/CodeGeneratorReplayInputs.py:
1238         (Type.is_enum_declaration):
1239         (Type.is_enum_class_declaration):
1240         (Type.is_option_set):
1241         (Type):
1242         (Type.is_enumerable):
1243         When we want all enumerable types, this property includes all three variants.
1244
1245         (Type.declaration_kind): Forward-declare OptionSet's type parameter as an enum class.
1246         (VectorType.is_enum_declaration): Renamed from is_enum().
1247         (VectorType.is_enum_class_declaration): Renamed from is_enum_class().
1248         (VectorType.is_option_set): Added.
1249         (InputsModel.enumerable_types): Added.
1250         (InputsModel.parse_type_with_framework):
1251         (Generator.generate_header):
1252         (Generator.generate_implementation):
1253         (Generator.generate_includes):
1254         (Generator.generate_type_forward_declarations):
1255         (Generator.generate_enumerable_type_trait_declaration):
1256         (Generator.generate_enum_trait_declaration): Renamed.
1257         (Generator.generate_enum_trait_implementation): Renamed.
1258
1259         * replay/scripts/CodeGeneratorReplayInputsTemplates.py:
1260         Add new templates for OptionSet types. Clean up parameter names and simplify the
1261         enumerable type declaration template, which is the same for all enumerable type variants.
1262
1263         * replay/scripts/tests/expected/fail-on-c-style-enum-no-storage.json-error:
1264         * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.cpp:
1265         (JSC::EncodingTraits<Test::PlatformEvent::OtherType>::encodeValue):
1266         (JSC::EncodingTraits<Test::PlatformEvent::OtherType>::decodeValue):
1267         * replay/scripts/tests/expected/generate-enum-encoding-helpers.json-TestReplayInputs.h:
1268         * replay/scripts/tests/expected/generate-enum-with-guard.json-TestReplayInputs.h:
1269         Rebaseline test results.
1270
1271         * replay/scripts/tests/generate-enum-encoding-helpers.json:
1272         Add a new type for OptionSet<PlatformEvent::Modifier> to capture generated encode/decode methods.
1273
1274 2016-09-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1275
1276         [JSC][LLInt] Introduce is_cell_with_type
1277         https://bugs.webkit.org/show_bug.cgi?id=162132
1278
1279         Reviewed by Sam Weinig.
1280
1281         In this patch, we introduce is_cell_with_type bytecode. This bytecode can unify the following predicates,
1282         op_is_string, op_is_jsarray, op_is_proxy_object, and op_is_derived_array!
1283         And we now drop DFG node IsString since we can use IsCellWithType instead.
1284         This automatically offers optimization to previous IsString node: dropping cell check by using CellUse edge filter.
1285
1286         Later, we are planning to use this is_cell_with_type to optimize @isRegExpObject, @isSet, and @isMap[1].
1287
1288         The performance results are neutral.
1289
1290         [1]: https://bugs.webkit.org/show_bug.cgi?id=162142
1291
1292         * bytecode/BytecodeList.json:
1293         * bytecode/BytecodeUseDef.h:
1294         (JSC::computeUsesForBytecodeOffset):
1295         (JSC::computeDefsForBytecodeOffset):
1296         * bytecode/CodeBlock.cpp:
1297         (JSC::CodeBlock::dumpBytecode):
1298         * bytecode/SpeculatedType.cpp:
1299         (JSC::speculationFromJSType):
1300         * bytecode/SpeculatedType.h:
1301         * bytecompiler/BytecodeGenerator.cpp:
1302         (JSC::BytecodeGenerator::emitEqualityOp):
1303         (JSC::BytecodeGenerator::emitIsCellWithType):
1304         * bytecompiler/BytecodeGenerator.h:
1305         (JSC::BytecodeGenerator::emitIsJSArray):
1306         (JSC::BytecodeGenerator::emitIsProxyObject):
1307         (JSC::BytecodeGenerator::emitIsDerivedArray):
1308         * dfg/DFGAbstractInterpreterInlines.h:
1309         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1310         * dfg/DFGByteCodeParser.cpp:
1311         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1312         (JSC::DFG::ByteCodeParser::parseBlock):
1313         * dfg/DFGCapabilities.cpp:
1314         (JSC::DFG::capabilityLevel):
1315         * dfg/DFGClobberize.h:
1316         (JSC::DFG::clobberize):
1317         * dfg/DFGDoesGC.cpp:
1318         (JSC::DFG::doesGC):
1319         * dfg/DFGFixupPhase.cpp:
1320         (JSC::DFG::FixupPhase::fixupNode):
1321         (JSC::DFG::FixupPhase::fixupIsCellWithType):
1322         * dfg/DFGNode.h:
1323         (JSC::DFG::Node::speculatedTypeForQuery):
1324         * dfg/DFGNodeType.h:
1325         * dfg/DFGPredictionPropagationPhase.cpp:
1326         * dfg/DFGSafeToExecute.h:
1327         (JSC::DFG::safeToExecute):
1328         * dfg/DFGSpeculativeJIT32_64.cpp:
1329         (JSC::DFG::SpeculativeJIT::compile):
1330         * dfg/DFGSpeculativeJIT64.cpp:
1331         (JSC::DFG::SpeculativeJIT::compile):
1332         * ftl/FTLCapabilities.cpp:
1333         (JSC::FTL::canCompile):
1334         * ftl/FTLLowerDFGToB3.cpp:
1335         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1336         (JSC::FTL::DFG::LowerDFGToB3::compileIsString): Deleted.
1337         * jit/JIT.cpp:
1338         (JSC::JIT::privateCompileMainPass):
1339         * jit/JIT.h:
1340         * jit/JITOpcodes.cpp:
1341         (JSC::JIT::emit_op_is_cell_with_type):
1342         (JSC::JIT::emitIsCellWithType): Deleted.
1343         (JSC::JIT::emit_op_is_string): Deleted.
1344         (JSC::JIT::emit_op_is_jsarray): Deleted.
1345         (JSC::JIT::emit_op_is_proxy_object): Deleted.
1346         (JSC::JIT::emit_op_is_derived_array): Deleted.
1347         * jit/JITOpcodes32_64.cpp:
1348         (JSC::JIT::emit_op_is_cell_with_type):
1349         (JSC::JIT::emitIsCellWithType): Deleted.
1350         (JSC::JIT::emit_op_is_string): Deleted.
1351         (JSC::JIT::emit_op_is_jsarray): Deleted.
1352         (JSC::JIT::emit_op_is_proxy_object): Deleted.
1353         (JSC::JIT::emit_op_is_derived_array): Deleted.
1354         * llint/LLIntData.cpp:
1355         (JSC::LLInt::Data::performAssertions):
1356         * llint/LowLevelInterpreter32_64.asm:
1357         * llint/LowLevelInterpreter64.asm:
1358
1359 2016-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1360
1361         [JSC] Assert length of LLInt opcodes using isCellWithType is 3
1362         https://bugs.webkit.org/show_bug.cgi?id=162134
1363
1364         Reviewed by Saam Barati.
1365
1366         * llint/LLIntData.cpp:
1367         (JSC::LLInt::Data::performAssertions):
1368
1369 2016-09-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1370
1371         [JSC] Do not need to use defineProperty to define methods for object literals
1372         https://bugs.webkit.org/show_bug.cgi?id=162111
1373
1374         Reviewed by Saam Barati.
1375
1376         When we receive the following code,
1377
1378             var object = { method() { } };
1379
1380         currently, we use defineProperty to define "method" function for "object".
1381         This patch replaces it with the ordinary put_by_id_direct / put_by_val_direct
1382         because the following 2 conditions are met.
1383
1384         1. While methods in classes have special attributes ({configurable: true, writable: true, enumerable: false}),
1385            the attributes of methods in object literals is just the same to the other normal properties ({configurable: true, writable: true, enumerable: true}).
1386            This means that we can use the usual put_by_id_direct / put_by_val_direct to define method properties for object literals.
1387
1388         2. Furthermore, all the own properties that can reside in objects created by object literals have {configurable: true}.
1389            So there is no need to check conflict by defineProperty. Always overwriting is OK.
1390
1391                 let name = 'method';
1392                 var object = { get [name]() { }, method() { } };
1393                 // Latter method wins.
1394
1395             On the other hand, in class syntax, conflict check is necessary since "prototype" own property is defined as {configurable: false}.
1396
1397                 class Hello { static prototype() { } }  // Should throw error by defineProperty's check.
1398
1399             This means that conflict check done in defneProperty is not necessary for object literals' properties.
1400
1401         * bytecompiler/NodesCodegen.cpp:
1402         (JSC::PropertyListNode::emitPutConstantProperty):
1403
1404 2016-09-16  Yusuke Suzuki  <utatane.tea@gmail.com>
1405
1406         [DFG] Introduce IsCellWithType node and unify IsJSArray, IsRegExpObject and newly added IsProxyObject
1407         https://bugs.webkit.org/show_bug.cgi?id=162000
1408
1409         Reviewed by Filip Pizlo.
1410
1411         Sampling profiler tells that ES6SampleBench/Basic frequently calls Array.isArray(). This function is introduced in
1412         ES5 and it is well-used to distinguish Array from the other objects. Moreover, this function is used in Array.prototype.xxx
1413         methods as @isArray. So it's worth optimizing.
1414
1415         The difference between Array.isArray and @isJSArray is that Array.isArray need to consider about ProxyObject while
1416         @isJSArray builtin intrinsic does not. So in this patch, we leverage the existing @isJSArray to implement Array.isArray.
1417         Array.isArray is written in builtin JS code using @isJSArray and newly added @isProxyObject(). That allow us to inline
1418         Array.isArray() code and the inlined code uses existing DFG nodes well.
1419
1420         Another problem is RuntimeArray and ArrayPrototype. They inherit JSArray and their JSType is ObjectType. But Array.isArray need
1421         to return true for those types. While optimizing type checking in generic way by type display is nice, RuntimeArray and
1422         ArrayPrototype are a bit tricky and it is super rare that these functions are passed to Array.isArray(). So instead of introducing
1423         type display in this patch, we just introduce a new JSType, DerivedArrayType and use it in the above 2 use classes. Since
1424         Array.isArray is specially handled in the spec (while we don't have any Date.isDate() like functions, only Array.isArray
1425         is specified in the spec because we frequently want to distinguish Arrays from other Objects), optimizing Array.isArray specially
1426         by introducing special DerivedArrayType is reasonable.
1427
1428         In LLInt level, we add a new opcode, op_is_proxy_object and op_is_derived_array. This works similar to op_is_jsarray.
1429         And we also perform LLInt code cleanup by introducing a macro isCellWithType.
1430
1431         In baseline, we perform some clean up for op_is_proxy_object etc. Now duplicate code is reduced.
1432
1433         In DFG, we unify IsJSArray, IsRegExpObject, IsProxyObject, and IsDerivedArray into one IsCellWithType node. And we clean up
1434         some AI code related to IsJSArray and IsRegExpObject since SpeculatedType now recognizes ProxyObject. IsJSArray and IsRegExpObject
1435         does not do anything special for proxy objects.
1436
1437         The above change simplify things to create a new IsXXX DFG handling and paves the way for optimizing @isMap & @isSet in DFG.
1438         Furthermore, introducing @isProxyObject() is nice for the first step to optimize ProxyObject handling.
1439
1440         Here is microbenchmark result. We can see stable performance improvement (Even if we use Proxies!).
1441
1442                                                     baseline                  patched
1443
1444             is-array-for-array                   2.5156+-0.0288     ^      2.0668+-0.0285        ^ definitely 1.2171x faster
1445             is-array-for-mixed-case              4.7787+-0.0755     ^      4.4722+-0.0789        ^ definitely 1.0686x faster
1446             is-array-for-non-array-object        2.3596+-0.0368     ^      1.8178+-0.0262        ^ definitely 1.2980x faster
1447             is-array-for-proxy                   4.0469+-0.0437     ^      3.3845+-0.0404        ^ definitely 1.1957x faster
1448
1449         And ES6SampleBench/Basic reports 5.2% perf improvement. And now sampling result in ES6SampleBench/Basic does not pose Array.isArray.
1450
1451             Benchmark             First Iteration        Worst 2%               Steady State
1452             baseline:Basic        28.59 ms +- 1.03 ms    15.08 ms +- 0.28 ms    1656.96 ms +- 18.02 ms
1453             patched:Basic         27.82 ms +- 0.44 ms    14.59 ms +- 0.16 ms    1574.65 ms +- 8.44 ms
1454
1455         * builtins/ArrayConstructor.js:
1456         (isArray):
1457         (from): Deleted.
1458         * builtins/BuiltinNames.h:
1459         * bytecode/BytecodeIntrinsicRegistry.h:
1460         * bytecode/BytecodeList.json:
1461         * bytecode/BytecodeUseDef.h:
1462         (JSC::computeUsesForBytecodeOffset):
1463         (JSC::computeDefsForBytecodeOffset):
1464         * bytecode/CodeBlock.cpp:
1465         (JSC::CodeBlock::dumpBytecode):
1466         * bytecode/SpeculatedType.cpp:
1467         (JSC::dumpSpeculation):
1468         (JSC::speculationFromClassInfo):
1469         (JSC::speculationFromStructure):
1470         * bytecode/SpeculatedType.h:
1471         (JSC::isProxyObjectSpeculation):
1472         (JSC::isDerivedArraySpeculation):
1473         * bytecompiler/BytecodeGenerator.h:
1474         (JSC::BytecodeGenerator::emitIsProxyObject):
1475         (JSC::BytecodeGenerator::emitIsDerivedArray):
1476         (JSC::BytecodeGenerator::emitIsJSArray): Deleted.
1477         * bytecompiler/NodesCodegen.cpp:
1478         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isProxyObject):
1479         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isDerivedArray):
1480         * dfg/DFGAbstractInterpreterInlines.h:
1481         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1482         * dfg/DFGByteCodeParser.cpp:
1483         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1484         (JSC::DFG::ByteCodeParser::parseBlock):
1485         * dfg/DFGCapabilities.cpp:
1486         (JSC::DFG::capabilityLevel):
1487         * dfg/DFGClobberize.h:
1488         (JSC::DFG::clobberize):
1489         * dfg/DFGDoesGC.cpp:
1490         (JSC::DFG::doesGC):
1491         * dfg/DFGFixupPhase.cpp:
1492         (JSC::DFG::FixupPhase::fixupNode):
1493         (JSC::DFG::FixupPhase::fixupIsCellWithType):
1494         * dfg/DFGGraph.cpp:
1495         (JSC::DFG::Graph::dump):
1496         * dfg/DFGNode.h:
1497         (JSC::DFG::Node::hasQueriedType):
1498         (JSC::DFG::Node::queriedType):
1499         (JSC::DFG::Node::hasSpeculatedTypeForQuery):
1500         (JSC::DFG::Node::speculatedTypeForQuery):
1501         (JSC::DFG::Node::shouldSpeculateProxyObject):
1502         (JSC::DFG::Node::shouldSpeculateDerivedArray):
1503         (JSC::DFG::Node::loadVarargsData): Deleted.
1504         (JSC::DFG::Node::shouldSpeculateArray): Deleted.
1505         * dfg/DFGNodeType.h:
1506         * dfg/DFGPredictionPropagationPhase.cpp:
1507         * dfg/DFGSafeToExecute.h:
1508         (JSC::DFG::SafeToExecuteEdge::operator()):
1509         (JSC::DFG::safeToExecute):
1510         * dfg/DFGSpeculativeJIT.cpp:
1511         (JSC::DFG::SpeculativeJIT::compileIsCellWithType):
1512         (JSC::DFG::SpeculativeJIT::speculateProxyObject):
1513         (JSC::DFG::SpeculativeJIT::speculateDerivedArray):
1514         (JSC::DFG::SpeculativeJIT::speculate):
1515         (JSC::DFG::SpeculativeJIT::compileIsJSArray): Deleted.
1516         (JSC::DFG::SpeculativeJIT::compileIsRegExpObject): Deleted.
1517         * dfg/DFGSpeculativeJIT.h:
1518         * dfg/DFGSpeculativeJIT32_64.cpp:
1519         (JSC::DFG::SpeculativeJIT::compile):
1520         * dfg/DFGSpeculativeJIT64.cpp:
1521         (JSC::DFG::SpeculativeJIT::compile):
1522         * dfg/DFGUseKind.cpp:
1523         (WTF::printInternal):
1524         * dfg/DFGUseKind.h:
1525         (JSC::DFG::typeFilterFor):
1526         (JSC::DFG::isCell):
1527         * ftl/FTLCapabilities.cpp:
1528         (JSC::FTL::canCompile):
1529         * ftl/FTLLowerDFGToB3.cpp:
1530         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1531         (JSC::FTL::DFG::LowerDFGToB3::compileIsCellWithType):
1532         (JSC::FTL::DFG::LowerDFGToB3::speculate):
1533         (JSC::FTL::DFG::LowerDFGToB3::isCellWithType):
1534         (JSC::FTL::DFG::LowerDFGToB3::speculateProxyObject):
1535         (JSC::FTL::DFG::LowerDFGToB3::speculateDerivedArray):
1536         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): Deleted.
1537         (JSC::FTL::DFG::LowerDFGToB3::compileIsRegExpObject): Deleted.
1538         (JSC::FTL::DFG::LowerDFGToB3::isArray): Deleted.
1539         (JSC::FTL::DFG::LowerDFGToB3::isRegExpObject): Deleted.
1540         * jit/JIT.cpp:
1541         (JSC::JIT::privateCompileMainPass):
1542         * jit/JIT.h:
1543         * jit/JITOpcodes.cpp:
1544         (JSC::JIT::emitIsCellWithType):
1545         (JSC::JIT::emit_op_is_string):
1546         (JSC::JIT::emit_op_is_jsarray):
1547         (JSC::JIT::emit_op_is_proxy_object):
1548         (JSC::JIT::emit_op_is_derived_array):
1549         * jit/JITOpcodes32_64.cpp:
1550         (JSC::JIT::emitIsCellWithType):
1551         (JSC::JIT::emit_op_is_string):
1552         (JSC::JIT::emit_op_is_jsarray):
1553         (JSC::JIT::emit_op_is_proxy_object):
1554         (JSC::JIT::emit_op_is_derived_array):
1555         * jsc.cpp:
1556         (WTF::RuntimeArray::createStructure):
1557         * llint/LLIntData.cpp:
1558         (JSC::LLInt::Data::performAssertions):
1559         * llint/LowLevelInterpreter.asm:
1560         * llint/LowLevelInterpreter32_64.asm:
1561         * llint/LowLevelInterpreter64.asm:
1562         * runtime/ArrayConstructor.cpp:
1563         (JSC::ArrayConstructor::finishCreation):
1564         (JSC::isArraySlowInline):
1565         (JSC::isArraySlow):
1566         (JSC::arrayConstructorPrivateFuncIsArraySlow):
1567         (JSC::arrayConstructorIsArray): Deleted.
1568         * runtime/ArrayConstructor.h:
1569         (JSC::isArray):
1570         * runtime/ArrayPrototype.h:
1571         (JSC::ArrayPrototype::createStructure):
1572         * runtime/JSArray.h:
1573         (JSC::JSArray::finishCreation):
1574         * runtime/JSGlobalObject.cpp:
1575         (JSC::JSGlobalObject::init):
1576         * runtime/JSType.h:
1577
1578 2016-09-16  Yusuke Suzuki  <utatane.tea@gmail.com>
1579
1580         [DFG] Introduce ArrayUse
1581         https://bugs.webkit.org/show_bug.cgi?id=162063
1582
1583         Reviewed by Keith Miller.
1584
1585         ArrayUse is particularly useful: for IsJSArray.
1586         We can drop IsJSArray in fixup phase by setting ArrayUse edge filter.
1587
1588         Since @isJSArray user is limited (Array.prototype.concat), the effect of this patch is small.
1589         But later, I'll update {@isArray, Array.isArray} to use @isJSArray[1]. In that patch, we are planning
1590         to implement more aggressive optimization like, setting CellUse edge filter to avoid cell check in
1591         SpeculativeJIT::compileIsJSArray.
1592
1593         In the benchmark using Array.prototype.concat, we can see perf improvement since we can drop IsJSArray in fixup phase.
1594
1595                                                      baseline                  patched
1596
1597             lazy-array-species-watchpoints       25.0911+-0.0516     ^     24.7687+-0.0767        ^ definitely 1.0130x faster
1598
1599         [1]: https://bugs.webkit.org/show_bug.cgi?id=162000
1600
1601         * dfg/DFGFixupPhase.cpp:
1602         (JSC::DFG::FixupPhase::fixupNode):
1603         * dfg/DFGSafeToExecute.h:
1604         (JSC::DFG::SafeToExecuteEdge::operator()):
1605         * dfg/DFGSpeculativeJIT.cpp:
1606         (JSC::DFG::SpeculativeJIT::speculateArray):
1607         (JSC::DFG::SpeculativeJIT::speculate):
1608         * dfg/DFGSpeculativeJIT.h:
1609         * dfg/DFGUseKind.cpp:
1610         (WTF::printInternal):
1611         * dfg/DFGUseKind.h:
1612         (JSC::DFG::typeFilterFor):
1613         (JSC::DFG::isCell):
1614         * ftl/FTLCapabilities.cpp:
1615         (JSC::FTL::canCompile):
1616         * ftl/FTLLowerDFGToB3.cpp:
1617         (JSC::FTL::DFG::LowerDFGToB3::speculate):
1618         (JSC::FTL::DFG::LowerDFGToB3::speculateArray):
1619         (JSC::FTL::DFG::LowerDFGToB3::speculateObject): Deleted.
1620
1621 2016-09-16  Joseph Pecoraro  <pecoraro@apple.com>
1622
1623         test262: Various Constructors length properties should be configurable
1624         https://bugs.webkit.org/show_bug.cgi?id=161998
1625
1626         Reviewed by Saam Barati.
1627
1628         https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects
1629         Unless otherwise specified, the length property of a built-in Function
1630         object has the attributes:
1631         { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }.
1632
1633         * runtime/ErrorConstructor.cpp:
1634         (JSC::ErrorConstructor::finishCreation):
1635         * runtime/JSPromiseConstructor.cpp:
1636         (JSC::JSPromiseConstructor::finishCreation):
1637         * runtime/MapConstructor.cpp:
1638         (JSC::MapConstructor::finishCreation):
1639         * runtime/NativeErrorConstructor.cpp:
1640         (JSC::NativeErrorConstructor::finishCreation):
1641         * runtime/ProxyConstructor.cpp:
1642         (JSC::ProxyConstructor::finishCreation):
1643         * runtime/SetConstructor.cpp:
1644         (JSC::SetConstructor::finishCreation):
1645         * runtime/WeakMapConstructor.cpp:
1646         (JSC::WeakMapConstructor::finishCreation):
1647         * runtime/WeakSetConstructor.cpp:
1648         (JSC::WeakSetConstructor::finishCreation):
1649
1650 2016-09-16  Youenn Fablet  <youenn@apple.com>
1651
1652         Custom promise-returning functions should not throw if callee has not the expected type
1653         https://bugs.webkit.org/show_bug.cgi?id=162011
1654
1655         Reviewed by Sam Weinig.
1656
1657         * JavaScriptCore.xcodeproj/project.pbxproj: Making JSPromiseConstructor.h private
1658
1659 2016-09-15  Filip Pizlo  <fpizlo@apple.com>
1660
1661         REGRESSION (r205462): Lot of leaks
1662         https://bugs.webkit.org/show_bug.cgi?id=161946
1663
1664         Reviewed by Saam Barati.
1665         
1666         We were forgetting to delete LargeAllocations on VM exit!
1667
1668         * heap/MarkedSpace.cpp:
1669         (JSC::MarkedSpace::~MarkedSpace):
1670
1671 2016-09-15  Keith Miller  <keith_miller@apple.com>
1672
1673
1674         Pragma out undefined-var-template warnings in JSC for JSObjects that are templatized
1675         https://bugs.webkit.org/show_bug.cgi?id=161985
1676
1677         Reviewed by Alex Christensen.
1678
1679         I started a true fix for this in
1680         https://bugs.webkit.org/show_bug.cgi?id=161979, however the fix
1681         for this issue is not sustainable. Since the scope of this issue
1682         is just limited to the static const ClassInfo member it is
1683         simpler to just pragma out this warning. This works because
1684         COMDAT will, AFAIK, pick the actual specialization.  If, in the
1685         future, we want to expose these classes to WebCore we will need to
1686         do what we do for JSGenericTypedArrayViews and create a custom
1687         info() function with a switch.
1688
1689         This patch also fixes a bunch of weak external symbols due to one of:
1690         1) out of line template member definitions functions not being marked inline.
1691         2) inline member functions definitions being marked as exported.
1692         3) missing header file includes for forward function declarations.
1693
1694         * API/JSCallbackObject.h:
1695         * b3/B3ValueInlines.h:
1696         (JSC::B3::Value::as):
1697         * runtime/HashMapImpl.cpp:
1698         (JSC::getHashMapBucketKeyClassInfo):
1699         (JSC::getHashMapBucketKeyValueClassInfo):
1700         (JSC::getHashMapImplKeyClassInfo):
1701         (JSC::getHashMapImplKeyValueClassInfo):
1702         * runtime/HashMapImpl.h:
1703         (JSC::HashMapBucket::info):
1704         (JSC::HashMapImpl::info):
1705         * runtime/JSCJSValue.h:
1706         (JSC::toUInt32): Deleted.
1707         * runtime/JSGenericTypedArrayView.h:
1708         (JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
1709         * runtime/JSGenericTypedArrayViewConstructor.h:
1710         * runtime/JSGenericTypedArrayViewPrototype.h:
1711         * runtime/MathCommon.h:
1712         (JSC::toUInt32):
1713         * runtime/TypedArrayAdaptors.h:
1714         * runtime/VM.h:
1715         (JSC::VM::watchdog):
1716         (JSC::VM::heapProfiler):
1717         (JSC::VM::samplingProfiler):
1718
1719 2016-09-14  Filip Pizlo  <fpizlo@apple.com>
1720
1721         There is no good reason for WeakBlock to care about newly allocated objects
1722         https://bugs.webkit.org/show_bug.cgi?id=162006
1723
1724         Reviewed by Geoffrey Garen.
1725
1726         WeakBlock scans itself in two modes:
1727
1728         visit: if a Weak in the block belongs to an unmarked object, ask the Weak to consider whether
1729             it should do things.
1730         
1731         reap: if a Weak in a block belongs to an unmarked object, delete the Weak.
1732
1733         Except that "unmarked" has a peculiar meaning: WeakBlock defines it as
1734         !markedOrNewlyAllocated. So, a newly allocated object will never be consulted about anything. 
1735         That sounds scary until you realize that newlyAllocated must have been cleared before we even
1736         got here.
1737
1738         So, we were paying the price of checking newlyAllocated for no reason. This switches the code
1739         to using isMarked(). I don't know why the code previously checked newlyAllocated, but I do
1740         trust my reasoning.
1741
1742         * heap/LargeAllocation.h:
1743         (JSC::LargeAllocation::isMarkedDuringWeakVisiting):
1744         (JSC::LargeAllocation::isMarkedOrNewlyAllocatedDuringWeakVisiting): Deleted.
1745         * heap/MarkedBlock.h:
1746         (JSC::MarkedBlock::isMarkedDuringWeakVisiting):
1747         (JSC::MarkedBlock::isMarkedOrNewlyAllocatedDuringWeakVisiting): Deleted.
1748         * heap/WeakBlock.cpp:
1749         (JSC::WeakBlock::specializedVisit):
1750         (JSC::WeakBlock::reap):
1751
1752 2016-09-15  Commit Queue  <commit-queue@webkit.org>
1753
1754         Unreviewed, rolling out r205931.
1755         https://bugs.webkit.org/show_bug.cgi?id=162021
1756
1757         Tests for this change fail on 32-bit JSC bots (Requested by
1758         ryanhaddad on #webkit).
1759
1760         Reverted changeset:
1761
1762         "[JSC] Make the rounding-related nodes support any type"
1763         https://bugs.webkit.org/show_bug.cgi?id=161895
1764         http://trac.webkit.org/changeset/205931
1765
1766 2016-09-15  Joseph Pecoraro  <pecoraro@apple.com>
1767
1768         test262: Should be a SyntaxError for duplicate parameter names in function with default parameters
1769         https://bugs.webkit.org/show_bug.cgi?id=162013
1770
1771         Reviewed by Saam Barati.
1772
1773         https://tc39.github.io/ecma262/#sec-function-definitions-static-semantics-early-errors
1774         It is a Syntax Error if IsSimpleParameterList of FormalParameterList is
1775         false and BoundNames of FormalParameterList contains any duplicate elements.
1776
1777         Non-simple parameter lists include rest parameters, destructuring,
1778         and default parameters.
1779
1780         * parser/Parser.cpp:
1781         (JSC::Parser<LexerType>::parseFormalParameters):
1782         Previously, we were not failing if there were default parameters
1783         early in the parameter list that were not yet identified as duplicates
1784         and simple parameters later were duplicates. Now, we fail if there
1785         are default parameters anywhere in the parameter list with a duplicate.
1786
1787 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
1788
1789         ASSERT_NOT_REACHED when using spread inside an array literal with Function.prototype.apply
1790         https://bugs.webkit.org/show_bug.cgi?id=162003
1791
1792         Reviewed by Saam Barati.
1793
1794         * bytecompiler/NodesCodegen.cpp:
1795         (JSC::ArrayNode::isSimpleArray):
1796         Don't treat an Array that has a spread expression inside it as simple.
1797         This avoids a fast path for f.apply(x, simpleArray) that was not handling
1798         spread expressions within arrays, and instead taking a path that can
1799         handle the spreading.
1800
1801 2016-09-14  Commit Queue  <commit-queue@webkit.org>
1802
1803         Unreviewed, rolling out r205933 and r205936.
1804         https://bugs.webkit.org/show_bug.cgi?id=162002
1805
1806         broke the build (Requested by keith_miller on #webkit).
1807
1808         Reverted changesets:
1809
1810         "Pragma out undefined-var-template warnings in JSC for
1811         JSObjects that are templatized"
1812         https://bugs.webkit.org/show_bug.cgi?id=161985
1813         http://trac.webkit.org/changeset/205933
1814
1815         "Unreviewed, fix the Windows build."
1816         http://trac.webkit.org/changeset/205936
1817
1818 2016-09-14  Chris Dumez  <cdumez@apple.com>
1819
1820         REGRESSION (r205670): ASSERTION FAILED: methodTable(vm)->toThis(this, exec, NotStrictMode) == this
1821         https://bugs.webkit.org/show_bug.cgi?id=161982
1822
1823         Reviewed by Saam Barati.
1824
1825         Update JSProxy::setPrototype() to return false unconditionally instead
1826         of forwarding the call to its target. We used to forward to the target
1827         and then the JSDOMWindow's [[SetPrototypeOf]] would return false.
1828         However, the JSC tests use a different GlobalObject and forwarding
1829         the setPrototypeOf() call to the GlobalObject lead to hitting an
1830         assertion. This patch aligns the behavior of the GlobalObject used by
1831         the JSC tests with JSDOMWindow.
1832
1833         * runtime/JSProxy.cpp:
1834         (JSC::JSProxy::setPrototype):
1835
1836 2016-09-14  Michael Saboff  <msaboff@apple.com>
1837
1838         YARR doesn't check for invalid flags for literal regular expressions
1839         https://bugs.webkit.org/show_bug.cgi?id=161995
1840
1841         Reviewed by Mark Lam.
1842
1843         Added a new error and a check that the flags are valid when we create a
1844         literal regular expression.
1845
1846         * runtime/RegExp.cpp:
1847         (JSC::RegExp::finishCreation):
1848         * yarr/YarrPattern.cpp:
1849         (JSC::Yarr::YarrPattern::errorMessage):
1850         (JSC::Yarr::YarrPattern::compile):
1851         * yarr/YarrPattern.h:
1852
1853 2016-09-14  Keith Miller  <keith_miller@apple.com>
1854
1855         Unreviewed, fix the Windows build.
1856
1857         * runtime/HashMapImpl.cpp:
1858
1859 2016-09-14  Keith Miller  <keith_miller@apple.com>
1860
1861         Pragma out undefined-var-template warnings in JSC for JSObjects that are templatized
1862         https://bugs.webkit.org/show_bug.cgi?id=161985
1863
1864         Reviewed by Geoffrey Garen.
1865
1866         I started a true fix for this in
1867         https://bugs.webkit.org/show_bug.cgi?id=161979, however the fix
1868         for this issue is not sustainable. Since the scope of this issue
1869         is just limited to the static const ClassInfo member it is
1870         simpler to just pragma out this warning. This works because
1871         COMDAT will, AFAIK, pick the actual specialization.  If, in the
1872         future, we want to expose these classes to WebCore we will need to
1873         do what we do for JSGenericTypedArrayViews and create a custom
1874         info() function with a switch.
1875
1876         This patch also fixes a bunch of weak external symbols due to one of:
1877         1) out of line template member definitions functions not being marked inline.
1878         2) inline member functions definitions being marked as exported.
1879         3) missing header file includes for forward function declarations.
1880
1881         * API/JSCallbackObject.h:
1882         * b3/B3ValueInlines.h:
1883         (JSC::B3::Value::as):
1884         * runtime/HashMapImpl.h:
1885         * runtime/JSCJSValue.h:
1886         (JSC::toUInt32): Deleted.
1887         * runtime/JSGenericTypedArrayView.h:
1888         (JSC::JSGenericTypedArrayView::setIndexQuicklyToDouble):
1889         * runtime/JSGenericTypedArrayViewConstructor.h:
1890         * runtime/JSGenericTypedArrayViewPrototype.h:
1891         * runtime/MathCommon.h:
1892         (JSC::toUInt32):
1893         * runtime/TypedArrayAdaptors.h:
1894         * runtime/VM.h:
1895         (JSC::VM::watchdog):
1896         (JSC::VM::heapProfiler):
1897         (JSC::VM::samplingProfiler):
1898
1899 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
1900
1901         test262: TypedArray constructors length should be 3 and configurable
1902         https://bugs.webkit.org/show_bug.cgi?id=161955
1903
1904         Reviewed by Mark Lam.
1905
1906         https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects
1907         Unless otherwise specified, the length property of a built-in Function
1908         object has the attributes:
1909         { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: true }.
1910
1911         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1912         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
1913
1914 2016-09-14  Benjamin Poulain  <bpoulain@apple.com>
1915
1916         [JSC] Make the rounding-related nodes support any type
1917         https://bugs.webkit.org/show_bug.cgi?id=161895
1918
1919         Reviewed by Geoffrey Garen.
1920
1921         This patch changes ArithRound, ArithFloor, ArithCeil and ArithTrunc
1922         to support polymorphic input without exiting on entry.
1923
1924         * dfg/DFGAbstractInterpreterInlines.h:
1925         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1926         * dfg/DFGByteCodeParser.cpp:
1927         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1928         The 4 functions ignore any input past the first argument. It is okay
1929         to use the nodes with the first argument and let the Phantoms keep
1930         the remaining arguments live.
1931
1932         * dfg/DFGClobberize.h:
1933         (JSC::DFG::clobberize):
1934         * dfg/DFGFixupPhase.cpp:
1935         (JSC::DFG::FixupPhase::fixupNode):
1936         Our fixup had the issue we have seen on previous nodes: unaryArithShouldSpeculateInt32()
1937         prevents us from picking a good type if we do not see any double.
1938
1939         * dfg/DFGNodeType.h:
1940         * dfg/DFGOperations.cpp:
1941         * dfg/DFGOperations.h:
1942         * dfg/DFGPredictionPropagationPhase.cpp:
1943         Prediction propagation of those nodes are fully determined
1944         from their flags and results's prediction. They are moved
1945         to the invariant processing.
1946
1947         * dfg/DFGSpeculativeJIT.cpp:
1948         (JSC::DFG::SpeculativeJIT::compileArithRounding):
1949         * ftl/FTLLowerDFGToB3.cpp:
1950         (JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
1951         (JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
1952         (JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
1953         (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
1954
1955 2016-09-14  Filip Pizlo  <fpizlo@apple.com>
1956
1957         Remove Heap::setMarked()
1958
1959         Rubber stamped by Keith Miller.
1960         
1961         Nobody uses this function.
1962
1963         * heap/Heap.h:
1964         * heap/HeapInlines.h:
1965         (JSC::Heap::setMarked): Deleted.
1966         * heap/LargeAllocation.h:
1967         (JSC::LargeAllocation::testAndSetMarked):
1968         (JSC::LargeAllocation::setMarked): Deleted.
1969         * heap/MarkedBlock.h:
1970
1971 2016-09-14  Mark Lam  <mark.lam@apple.com>
1972
1973         Use Options::validateExceptionChecks() instead of VM::m_verifyExceptionEvents.
1974         https://bugs.webkit.org/show_bug.cgi?id=161975
1975
1976         Reviewed by Keith Miller.
1977
1978         This makes it less burdensome (no longer needs a rebuild to enable checks) to do
1979         incremental work towards enabling checks all the time.
1980
1981         * runtime/Options.h:
1982         * runtime/VM.cpp:
1983         (JSC::VM::verifyExceptionCheckNeedIsSatisfied):
1984         * runtime/VM.h:
1985
1986 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
1987
1988         TaggedTemplateString function calls should emit tail position calls
1989         https://bugs.webkit.org/show_bug.cgi?id=161948
1990
1991         Reviewed by Yusuke Suzuki.
1992
1993         * bytecompiler/NodesCodegen.cpp:
1994         (JSC::TaggedTemplateNode::emitBytecode):
1995         The tagged template string function call can be a tail call:
1996         https://tc39.github.io/ecma262/#sec-tagged-templates-runtime-semantics-evaluation
1997
1998 2016-09-14  Joseph Pecoraro  <pecoraro@apple.com>
1999
2000         test262: Array.prototype.slice should always set length
2001         https://bugs.webkit.org/show_bug.cgi?id=161953
2002
2003         Reviewed by Mark Lam.
2004
2005         * runtime/ArrayPrototype.cpp:
2006         (JSC::arrayProtoFuncSplice):
2007
2008 2016-09-13  Michael Saboff  <msaboff@apple.com>
2009
2010         Promises aren't resolved properly when making a ObjC API callback
2011         https://bugs.webkit.org/show_bug.cgi?id=161929
2012
2013         Reviewed by Geoffrey Garen.
2014
2015         When we go to call out to an Objective C function registered via the API,
2016         we first drop all JSC locks to make the call.  As part of dropping the locks,
2017         we drain the microtask queue that is used among other things for handling deferred
2018         promise resolution.  The DropAllLocks scope class that drops the locks while in
2019         scope, resets the current thread's AtomicStringTable to the default table.  This
2020         is wrong for two reasons, first it happens before we drain the microtask queue and
2021         second it isn't needed as JSLock::willReleaseLock() restores the current thread's
2022         AtomicStringTable to the table before the lock was acquired.
2023
2024         In fact, the manipulation of the current thread's AtomicStringTable is already 
2025         properly handled as a stack in JSLock::didAcquireLock() and willReleaseLock().
2026         Therefore the manipulation of the AtomicStringTable in DropAllLocks constructor
2027         and destructor should be removed.
2028
2029         * API/tests/testapi.mm:
2030         (testObjectiveCAPIMain): Added a new test.
2031         * runtime/JSLock.cpp:
2032         (JSC::JSLock::DropAllLocks::DropAllLocks):
2033         (JSC::JSLock::DropAllLocks::~DropAllLocks):
2034
2035 2016-09-13  Filip Pizlo  <fpizlo@apple.com>
2036
2037         Remove Heap::isLive()
2038         https://bugs.webkit.org/show_bug.cgi?id=161933
2039
2040         Reviewed by Mark Lam.
2041         
2042         Before I put any more effort into maintaining this weird function, I decided to check how it
2043         was used. It turns out it's not.
2044
2045         * heap/Heap.h:
2046         * heap/HeapInlines.h:
2047         (JSC::Heap::isLive): Deleted.
2048
2049 2016-09-13  Mark Lam  <mark.lam@apple.com>
2050
2051         DFG NewArrayBuffer node should watch for "have a bad time" state change.
2052         https://bugs.webkit.org/show_bug.cgi?id=161927
2053         <rdar://problem/27995222>
2054
2055         Reviewed by Geoffrey Garen.
2056
2057         * dfg/DFGFixupPhase.cpp:
2058         (JSC::DFG::FixupPhase::fixupNode):
2059
2060 2016-09-13  JF Bastien  <jfbastien@apple.com>
2061
2062         Support jsc shell builtin `read`
2063         https://bugs.webkit.org/show_bug.cgi?id=161662
2064
2065         Reviewed by Keith Miller.
2066
2067         The jsc shell currently supports a `readFile` method which returns
2068         a string. SpiderMonkey's js shell and V8's d8 shell both support
2069         similar file-to-string functions, as well as a
2070         binary-file-to-Uint8Array function. jsc should support a similar
2071         binary file method to simplify testing, including testing of
2072         WebAssembly blobs.
2073
2074         Emscripten's shell.js (which is also used for some WebAssembly
2075         things) has a polyfill [1] for a builtin called `read`. jsc should
2076         therefore have a builtin with the same name if we want things to
2077         "Just Work".
2078
2079           [1]: https://github.com/kripken/emscripten/blob/5f0918409a1407dd168f57cfa34b109cd1770a8a/src/shell.js#L138
2080
2081         * jsc.cpp:
2082         (GlobalObject::finishCreation): add `read`, make `readFile` take up to 2 arguments.
2083         (functionReadFile): support binary files, as per SpiderMonkey.
2084         * runtime/Error.h:
2085         (JSC::throwVMError): convenience function, I'll add more uses in a follow-up
2086         * runtime/JSTypedArrays.cpp:
2087         (JSC::createUint8TypedArray): JS private export of JSUint8Array::create.
2088         * runtime/JSTypedArrays.h: expose private export.
2089
2090 2016-09-12  Skachkov Oleksandr  <gskachkov@gmail.com>
2091
2092         ES6: Classes: Should be allowed to create a static method with name "arguments"
2093         https://bugs.webkit.org/show_bug.cgi?id=152985
2094
2095         Reviewed by Keith Miller.
2096
2097         Current patch covered 16.2 Forbidden Extensions - first topic 
2098         (https://tc39.github.io/ecma262/#sec-forbidden-extensions) ECMAScript Functions 
2099         should not have own properties named "caller" or "arguments".
2100         Also added possibility to declare static methods and getters with 
2101         name 'arguments' and 'caller' for classes. i.e.:
2102         class A { static arguments() { return 'value'; } }
2103         A.arguments() === 'value';
2104         To implement this patch 'caller' and 'arguments' were put to the FunctionPrototype
2105         object. Also was changed approach to init throwTypeErrorArgumentsCalleeAndCallerGetterSetter
2106         property from Lazy to common because it necessary to use execState during init of the accessors 
2107         properties.
2108
2109         * runtime/Executable.h:
2110         * runtime/FunctionPrototype.cpp:
2111         (JSC::FunctionPrototype::initRestrictedProperties):
2112         (JSC::FunctionPrototype::addFunctionProperties): Deleted.
2113         * runtime/FunctionPrototype.h:
2114         * runtime/JSFunction.cpp:
2115         (JSC::JSFunction::getOwnPropertySlot):
2116         (JSC::JSFunction::getOwnNonIndexPropertyNames):
2117         (JSC::JSFunction::put):
2118         (JSC::JSFunction::deleteProperty):
2119         (JSC::JSFunction::defineOwnProperty):
2120         * runtime/JSGlobalObject.cpp:
2121         (JSC::JSGlobalObject::init):
2122         (JSC::JSGlobalObject::visitChildren):
2123         * runtime/JSGlobalObject.h:
2124         (JSC::JSGlobalObject::throwTypeErrorArgumentsCalleeAndCallerGetterSetter):
2125
2126 2016-09-12  Filip Pizlo  <fpizlo@apple.com>
2127
2128         MarkedBlock should be able to use flipIfNecessary() as the "I'm not empty" trigger
2129         https://bugs.webkit.org/show_bug.cgi?id=161869
2130
2131         Reviewed by Saam Barati.
2132         
2133         In bug 161581, I'm going to use flipIfNecessary() during marking to trigger the "I'm not
2134         empty" hook, which will set a bit in the markingNotEmpty bitvector.
2135         
2136         For this to work, we need to ensure that nobody else uses flipIfNecessary() during marking.
2137         If anyone else does it but they aren't marking new objects, then this prevents
2138         flipIfNecessary() from triggering when the first object is marked, which means we won't
2139         always detect when a block became non-empty.
2140         
2141         I addressed this by adding a isMarking flag, and asserting in flipIfNecessary() that the flag
2142         isn't set. flipIfNecessaryDuringMarking() is used only on the marking path, so that code
2143         knows that it can trigger something like noteMarked(). The only places that were using
2144         flipIfNecessary() should have been using needsFlip() anyway.
2145
2146         * heap/CellContainer.h:
2147         * heap/CellContainerInlines.h:
2148         (JSC::CellContainer::needsFlip):
2149         * heap/Heap.cpp:
2150         (JSC::Heap::markRoots):
2151         (JSC::Heap::beginMarking):
2152         (JSC::Heap::endMarking):
2153         (JSC::Heap::clearLivenessData): Deleted.
2154         (JSC::Heap::converge): Deleted.
2155         (JSC::Heap::resetVisitors): Deleted.
2156         * heap/Heap.h:
2157         * heap/HeapInlines.h:
2158         (JSC::Heap::testAndSetMarked):
2159         * heap/LargeAllocation.h:
2160         (JSC::LargeAllocation::flipIfNecessaryDuringMarking):
2161         (JSC::LargeAllocation::flipIfNecessaryConcurrently): Deleted.
2162         * heap/MarkedBlock.cpp:
2163         (JSC::MarkedBlock::flipIfNecessarySlow):
2164         (JSC::MarkedBlock::flipIfNecessaryDuringMarkingSlow):
2165         (JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow): Deleted.
2166         * heap/MarkedBlock.h:
2167         (JSC::MarkedBlock::flipIfNecessaryDuringMarking):
2168         (JSC::MarkedBlock::Handle::flipIfNecessaryDuringMarking):
2169         (JSC::MarkedBlock::flipIfNecessaryConcurrently): Deleted.
2170         (JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently): Deleted.
2171         * heap/MarkedSpace.h:
2172         (JSC::MarkedSpace::isMarking):
2173         (JSC::MarkedSpace::setIsMarking):
2174         (JSC::MarkedSpace::largeAllocationsForThisCollectionSize): Deleted.
2175         * heap/SlotVisitor.cpp:
2176         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
2177         * heap/WeakBlock.cpp:
2178         (JSC::WeakBlock::visit):
2179
2180 2016-09-12  Saam Barati  <sbarati@apple.com>
2181
2182         HashMapImpl should take into account m_deleteCount in its load factor and it should be able to rehash the table to be smaller
2183         https://bugs.webkit.org/show_bug.cgi?id=161640
2184
2185         Reviewed by Geoffrey Garen.
2186
2187         HashMapImpl now takes into account m_deleteCount in its load factor.
2188         It now knows how to rehash to either decrease its capacity, stay at
2189         the same capacity, or increase its capacity. The reason we can sometimes
2190         stay at the same capacity is that we can reduce the load factor enough
2191         by rehashing that growing isn't warranted. The reason for this is that
2192         anytime we rehash, we remove all deleted sentinels from the buffer.
2193         Therefore, staying at the same same capacity, when there are deleted entries,
2194         can still reduce the load factor because it removes all deleted sentinels.
2195
2196         * runtime/HashMapImpl.h:
2197         (JSC::HashMapBuffer::create):
2198         (JSC::HashMapBuffer::reset):
2199         (JSC::HashMapImpl::HashMapImpl):
2200         (JSC::HashMapImpl::add):
2201         (JSC::HashMapImpl::remove):
2202         (JSC::HashMapImpl::size):
2203         (JSC::HashMapImpl::clear):
2204         (JSC::HashMapImpl::approximateSize):
2205         (JSC::HashMapImpl::shouldRehashAfterAdd):
2206         (JSC::HashMapImpl::shouldShrink):
2207         (JSC::HashMapImpl::rehash):
2208         (JSC::HashMapImpl::checkConsistency):
2209         (JSC::HashMapImpl::makeAndSetNewBuffer):
2210         (JSC::HashMapImpl::assertBufferIsEmpty):
2211
2212 2016-09-12  Benjamin Poulain  <bpoulain@apple.com>
2213
2214         [JSC] Use GetArrayLength for JSArray.length even when the array type is undecided
2215         https://bugs.webkit.org/show_bug.cgi?id=161671
2216
2217         Reviewed by Geoffrey Garen.
2218
2219         UndecidedShape is a type with storage. When we allocate an uninitialized JSArray,
2220         it gets a butterfly with its length.
2221         When we were querying that length, we were generating a generic GetById with inline cache.
2222
2223         This patch adds the missing bits to treat Undecided like the other types with storage.
2224
2225         * dfg/DFGArrayMode.cpp:
2226         (JSC::DFG::canBecomeGetArrayLength):
2227         (JSC::DFG::ArrayMode::refine):
2228         * dfg/DFGArrayMode.h:
2229         (JSC::DFG::ArrayMode::usesButterfly):
2230         (JSC::DFG::ArrayMode::lengthNeedsStorage):
2231         * dfg/DFGClobberize.h:
2232         (JSC::DFG::clobberize):
2233         * dfg/DFGFixupPhase.cpp:
2234         (JSC::DFG::FixupPhase::checkArray):
2235         * dfg/DFGSpeculativeJIT.cpp:
2236         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
2237         * ftl/FTLCapabilities.cpp:
2238         (JSC::FTL::canCompile):
2239         * ftl/FTLLowerDFGToB3.cpp:
2240         (JSC::FTL::DFG::LowerDFGToB3::compileGetArrayLength):
2241
2242 2016-09-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2243
2244         [DFG][FTL] Add ArithTan
2245         https://bugs.webkit.org/show_bug.cgi?id=161857
2246
2247         Reviewed by Filip Pizlo.
2248
2249         While ArithSin and ArithCos are supported, ArithTan is not supported yet.
2250         And we also find that Math.tan is included in MotionMark's Multiply benchmark.
2251
2252         This patch adds ArithTan support in DFG and FTL. And it also cleans up the
2253         existing ArithSin, ArithCos, and ArithLog compilations by unifying them.
2254         The microbenchmark shows the 9% perf improvement.
2255
2256             tan    322.4819+-0.3766     ^    295.8700+-0.3094        ^ definitely 1.0899x faster
2257
2258         * dfg/DFGAbstractInterpreterInlines.h:
2259         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2260         * dfg/DFGByteCodeParser.cpp:
2261         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2262         * dfg/DFGClobberize.h:
2263         (JSC::DFG::clobberize):
2264         * dfg/DFGDoesGC.cpp:
2265         (JSC::DFG::doesGC):
2266         * dfg/DFGFixupPhase.cpp:
2267         (JSC::DFG::FixupPhase::fixupNode):
2268         * dfg/DFGNodeType.h:
2269         * dfg/DFGOperations.cpp:
2270         * dfg/DFGOperations.h:
2271         * dfg/DFGPredictionPropagationPhase.cpp:
2272         * dfg/DFGSafeToExecute.h:
2273         (JSC::DFG::safeToExecute):
2274         * dfg/DFGSpeculativeJIT.cpp:
2275         (JSC::DFG::SpeculativeJIT::compileArithDoubleUnaryOp):
2276         (JSC::DFG::SpeculativeJIT::compileArithCos):
2277         (JSC::DFG::SpeculativeJIT::compileArithTan):
2278         (JSC::DFG::SpeculativeJIT::compileArithSin):
2279         (JSC::DFG::SpeculativeJIT::compileArithLog):
2280         * dfg/DFGSpeculativeJIT.h:
2281         * dfg/DFGSpeculativeJIT32_64.cpp:
2282         (JSC::DFG::SpeculativeJIT::compile):
2283         * dfg/DFGSpeculativeJIT64.cpp:
2284         (JSC::DFG::SpeculativeJIT::compile):
2285         * ftl/FTLCapabilities.cpp:
2286         (JSC::FTL::canCompile):
2287         * ftl/FTLLowerDFGToB3.cpp:
2288         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2289         (JSC::FTL::DFG::LowerDFGToB3::compileArithTan):
2290         * ftl/FTLOutput.cpp:
2291         (JSC::FTL::Output::doubleTan):
2292         * ftl/FTLOutput.h:
2293         * runtime/Intrinsic.h:
2294         * runtime/MathObject.cpp:
2295         (JSC::MathObject::finishCreation):
2296
2297 2016-09-12  Saam Barati  <sbarati@apple.com>
2298
2299         MapHash should do constant folding when it has a constant argument and its legal to hash that value
2300         https://bugs.webkit.org/show_bug.cgi?id=161639
2301
2302         Reviewed by Filip Pizlo.
2303
2304         We now constant fold the MapHash node. We're careful to not resolve
2305         ropes from the compiler thread, and to only hash strings if they're
2306         not too large. The microbenchmark I added runs about 12% faster with
2307         this patch.
2308
2309         * dfg/DFGAbstractInterpreterInlines.h:
2310         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2311         * runtime/HashMapImpl.h:
2312         (JSC::wangsInt64Hash):
2313         (JSC::jsMapHash):
2314         (JSC::concurrentJSMapHash):
2315
2316 2016-09-11  Filip Pizlo  <fpizlo@apple.com>
2317
2318         DFG::forAllKilledOperands() could use a faster bitvector scan in the same-inline-stack fast path
2319         https://bugs.webkit.org/show_bug.cgi?id=161849
2320
2321         Reviewed by Saam Barati.
2322         
2323         This is a fairly obvious change. This turns a loop that would query each bit individually
2324         into a loop that will process a word at a time. I would expect a very tiny progression in
2325         DFG compile times.
2326         
2327         This also gave me an opportunity to test and fix the new FastBitVector functionality.
2328
2329         * dfg/DFGForAllKills.h:
2330         (JSC::DFG::forAllKilledOperands):
2331
2332 2016-09-11  Filip Pizlo  <fpizlo@apple.com>
2333
2334         FastBitVector should have efficient and easy-to-use vector-vector operations
2335         https://bugs.webkit.org/show_bug.cgi?id=161847
2336
2337         Reviewed by Saam Barati.
2338         
2339         Adapt existing users of FastBitVector to the new API.
2340
2341         * bytecode/BytecodeLivenessAnalysis.cpp:
2342         (JSC::BytecodeLivenessAnalysis::computeKills):
2343         (JSC::BytecodeLivenessAnalysis::dumpResults):
2344         * bytecode/BytecodeLivenessAnalysisInlines.h:
2345         (JSC::operandThatIsNotAlwaysLiveIsLive):
2346         (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::stepOverInstruction):
2347         (JSC::BytecodeLivenessPropagation<DerivedAnalysis>::runLivenessFixpoint):
2348         * bytecode/CodeBlock.cpp:
2349         (JSC::CodeBlock::validate):
2350         * dfg/DFGByteCodeParser.cpp:
2351         (JSC::DFG::ByteCodeParser::flushForTerminal):
2352         * dfg/DFGForAllKills.h:
2353         (JSC::DFG::forAllKilledOperands):
2354         * dfg/DFGGraph.h:
2355         (JSC::DFG::Graph::forAllLocalsLiveInBytecode):
2356         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
2357         (JSC::DFG::LiveCatchVariablePreservationPhase::willCatchException):
2358         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlock):
2359         * dfg/DFGNaturalLoops.cpp:
2360         (JSC::DFG::NaturalLoops::NaturalLoops):
2361         * dfg/DFGPlan.cpp:
2362         (JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
2363
2364 2016-09-10  Chris Dumez  <cdumez@apple.com>
2365
2366         parseHTMLInteger() should take a StringView in parameter
2367         https://bugs.webkit.org/show_bug.cgi?id=161669
2368
2369         Reviewed by Ryosuke Niwa.
2370
2371         * runtime/DateConversion.cpp:
2372         (JSC::formatDateTime):
2373         Explicitly construct a String from the const WCHAR* on Windows because
2374         it is ambiguous otherwise now that there is a StringBuilder::append()
2375         overload taking an AtomicString in.
2376
2377 2016-09-08  Keith Miller  <keith_miller@apple.com>
2378
2379         WASM should support if-then-else
2380         https://bugs.webkit.org/show_bug.cgi?id=161778
2381
2382         Reviewed by Michael Saboff.
2383
2384         This patch makes some major changes to the way that the WASM
2385         function parser works. First, the control stack has been moved
2386         from the parser's context to the parser itself. This simplifies
2387         the way that the parser works and allows us to make the decoder
2388         iterative rather than recursive. Since the control stack has been
2389         moved to the parser, any context operation that refers to some
2390         block now receives that block by reference.
2391
2392         For any if block, regardless of whether or not it is an
2393         if-then-else or not, we will allocate both the entire control flow
2394         diamond. This is not a major issue in the if-then case since B3
2395         will immediately cleanup these blocks. In order to support if-then
2396         and if-then-else we needed to be able to distinguish what the type
2397         of the top block on the control stack is. This will be necessary
2398         when validating the else opcode in the future. In the B3 IR
2399         generator we decide to the type of the block strictly by the
2400         shape.
2401
2402         Currently, if blocks don't handle passed and returned stack values
2403         correctly. I plan to fix this when I add support for the block
2404         signatures. See: https://github.com/WebAssembly/design/pull/765
2405
2406         * testWASM.cpp:
2407         (runWASMTests):
2408         * wasm/WASMB3IRGenerator.cpp:
2409         (dumpProcedure):
2410         (JSC::WASM::parseAndCompile):
2411         * wasm/WASMB3IRGenerator.h:
2412         * wasm/WASMFunctionParser.h:
2413         (JSC::WASM::FunctionParser<Context>::parseBlock):
2414         (JSC::WASM::FunctionParser<Context>::parseExpression):
2415         (JSC::WASM::FunctionParser<Context>::parseUnreachableExpression):
2416         * wasm/WASMOps.h:
2417
2418 2016-09-09  Filip Pizlo  <fpizlo@apple.com>
2419
2420         jsc.cpp should call initializeMainThread() to make sure that GC thread assertions work
2421         https://bugs.webkit.org/show_bug.cgi?id=161801
2422
2423         Reviewed by Keith Miller.
2424         
2425         The GC has debug assertions that certain things don't happen on GC threads. Those assertions
2426         are no-ops unless initializeGCThreads() is called, and I think the most canonical way to do
2427         that is to call initializeMainThread().
2428
2429         * jsc.cpp:
2430         (jscmain):
2431
2432 2016-09-09  Saam Barati  <sbarati@apple.com>
2433
2434         Make hasOwnProperty ALWAYS_INLINE
2435         https://bugs.webkit.org/show_bug.cgi?id=161775
2436
2437         Reviewed by Ryosuke Niwa.
2438
2439         Speedometer spends around 2.5% of its time in hasOwnProperty.
2440         Let's reduce the overhead of calling that function by marking
2441         it as inline. Also, it's likely that the function will call into
2442         JSObject::getOwnPropertySlot. I added a check to see if that's
2443         the function we're calling, if it is, we do a direct call instead
2444         of an indirect call.
2445
2446         * runtime/JSObject.cpp:
2447         (JSC::JSObject::hasOwnProperty): Deleted.
2448         * runtime/JSObjectInlines.h:
2449         (JSC::JSObject::hasOwnProperty):
2450
2451 2016-09-09  Filip Pizlo  <fpizlo@apple.com>
2452
2453         HashMapImpl needs to m_buffer.clear() in its constructor
2454         https://bugs.webkit.org/show_bug.cgi?id=161796
2455
2456         Reviewed by Keith Miller.
2457         
2458         This is the second time that I'm fixing a bug because AuxiliaryBarrier does not initialize
2459         itself. That seemed like a good idea because maybe sometimes the user knows better how to
2460         initialize it. But, it's not worth it if it's a constant source of bugs.
2461         
2462         So, I'm fixing it for good by making AuxiliaryBarrier::AuxiliaryBarrier() initialize its
2463         m_value.
2464
2465         * runtime/AuxiliaryBarrier.h:
2466         (JSC::AuxiliaryBarrier::AuxiliaryBarrier):
2467         * runtime/DirectArguments.cpp:
2468         (JSC::DirectArguments::DirectArguments):
2469
2470 2016-09-09  Youenn Fablet  <youenn@apple.com>
2471
2472         ASSERTION FAILED: promise.inherits(JSPromise::info())
2473         https://bugs.webkit.org/show_bug.cgi?id=161632
2474         <rdar://problem/28184743>
2475
2476         Reviewed by Mark Lam.
2477
2478         * runtime/JSPromiseDeferred.cpp:
2479         (JSC::JSPromiseDeferred::create): Returning null if promise object is not created.
2480
2481 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
2482
2483         Heap::isMarked() shouldn't pay the price of concurrent lazy flipping
2484         https://bugs.webkit.org/show_bug.cgi?id=161760
2485
2486         Reviewed by Mark Lam.
2487         
2488         To fix a race condition in marking, I made Heap::isMarked() and Heap::isLive() atomic by
2489         using flipIfNecessaryConcurrently() instead of flipIfNecessary().
2490         
2491         This introduces three unnecessary overheads:
2492         
2493         - isLive() is not called by marking, so that change was not necessary.
2494         
2495         - isMarked() gets calls many times outside of marking, so it shouldn't always do the
2496           concurrent thing. This adds isMarkedConcurrently() for use in marking, and reverts
2497           isMarked().
2498         
2499         - isMarked() and isMarkedConcurrently() don't actually have to do the lazy flip. They can
2500           return false if the flip is necessary.
2501         
2502         I added a bunch of debug assertions to make sure that isLive() and isMarked() are not called
2503         during marking.
2504         
2505         If we needed to, we could remove most of the calls to isMarkedConcurrently(). As a kind of
2506         optimization, CodeBlock does an initial fixpoint iteration during marking, and so all of the
2507         code called from CodeBlock's fixpoint iterator needs to use isMarkedConcurrently(). But we
2508         could probably arrange for CodeBlock only do fixpoint iterating during the weak reference
2509         thing.
2510
2511         * bytecode/CodeBlock.cpp:
2512         (JSC::CodeBlock::visitWeakly):
2513         (JSC::CodeBlock::shouldJettisonDueToOldAge):
2514         (JSC::shouldMarkTransition):
2515         (JSC::CodeBlock::propagateTransitions):
2516         (JSC::CodeBlock::determineLiveness):
2517         * bytecode/PolymorphicAccess.cpp:
2518         (JSC::AccessCase::propagateTransitions):
2519         * heap/Heap.h:
2520         * heap/HeapInlines.h:
2521         (JSC::Heap::isLive):
2522         (JSC::Heap::isMarked):
2523         (JSC::Heap::isMarkedConcurrently):
2524         * heap/MarkedBlock.cpp:
2525         (JSC::MarkedBlock::flipIfNecessarySlow):
2526         (JSC::MarkedBlock::flipIfNecessaryConcurrentlySlow):
2527         (JSC::MarkedBlock::needsFlip):
2528         * heap/MarkedBlock.h:
2529         (JSC::MarkedBlock::needsFlip):
2530         (JSC::MarkedBlock::flipIfNecessary):
2531         (JSC::MarkedBlock::flipIfNecessaryConcurrently):
2532         * heap/SlotVisitor.cpp:
2533         (JSC::SlotVisitor::appendToMarkStack):
2534         (JSC::SlotVisitor::markAuxiliary):
2535         (JSC::SlotVisitor::visitChildren):
2536         * runtime/Structure.cpp:
2537         (JSC::Structure::isCheapDuringGC):
2538         (JSC::Structure::markIfCheap):
2539
2540 2016-09-08  Saam Barati  <sbarati@apple.com>
2541
2542         We should inline operationConvertJSValueToBoolean into JIT code
2543         https://bugs.webkit.org/show_bug.cgi?id=161729
2544
2545         Reviewed by Filip Pizlo.
2546
2547         This patch introduces an AssemblyHelpers emitter function
2548         that replaces operationConvertJSValueToBoolean. This operation
2549         was showing up when I was doing performance analysis for the
2550         speedometer benchmark. I saw that it was spending about 1% of
2551         its time in this function. Hopefully this patch can help us speedup
2552         up speedometer by a little bit.
2553
2554         * dfg/DFGSpeculativeJIT32_64.cpp:
2555         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2556         (JSC::DFG::SpeculativeJIT::emitBranch):
2557         * dfg/DFGSpeculativeJIT64.cpp:
2558         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2559         (JSC::DFG::SpeculativeJIT::emitBranch):
2560         * jit/AssemblyHelpers.cpp:
2561         (JSC::AssemblyHelpers::emitConvertValueToBoolean):
2562         * jit/AssemblyHelpers.h:
2563         (JSC::AssemblyHelpers::emitAllocateDestructibleObject): Deleted.
2564         * jit/JIT.cpp:
2565         (JSC::JIT::privateCompileSlowCases):
2566         * jit/JIT.h:
2567         * jit/JITOpcodes.cpp:
2568         (JSC::JIT::emit_op_jfalse):
2569         (JSC::JIT::emit_op_jtrue):
2570         (JSC::JIT::emitSlow_op_jfalse): Deleted.
2571         (JSC::JIT::emitSlow_op_jtrue): Deleted.
2572         * jit/JITOpcodes32_64.cpp:
2573         (JSC::JIT::emit_op_jfalse):
2574         (JSC::JIT::emit_op_jtrue):
2575         (JSC::JIT::emitSlow_op_jfalse): Deleted.
2576         (JSC::JIT::emitSlow_op_jtrue): Deleted.
2577         * jit/JITOperations.cpp:
2578         * jit/JITOperations.h:
2579
2580 2016-09-08  Chris Dumez  <cdumez@apple.com>
2581
2582         Align proto getter / setter behavior with other browsers
2583         https://bugs.webkit.org/show_bug.cgi?id=161455
2584
2585         Reviewed by Saam Barati.
2586
2587         Drop allowsAccessFrom from the methodTable and delegate cross-origin
2588         checking to the DOM bindings for [[SetPrototypeOf]] / [[GetPrototypeOf]].
2589         This is more consistent with other operations (e.g. [[GetOwnProperty]]).
2590
2591         * jsc.cpp:
2592         * runtime/JSGlobalObject.cpp:
2593         * runtime/JSGlobalObject.h:
2594         * runtime/JSGlobalObjectFunctions.cpp:
2595         (JSC::globalFuncProtoGetter):
2596         (JSC::globalFuncProtoSetter):
2597         (JSC::globalFuncBuiltinLog): Deleted.
2598         * runtime/JSGlobalObjectFunctions.h:
2599         * runtime/JSObject.cpp:
2600         (JSC::JSObject::setPrototypeWithCycleCheck):
2601         Remove check added in r197648. This check was added to match
2602         the latest EcmaScript spec:
2603         - https://tc39.github.io/ecma262/#sec-ordinarysetprototypeof (step 8)
2604         This check allowed for [[Prototype]] chain cycles if the prototype
2605         chain includes objects that do not use the ordinary object definitions
2606         for [[GetPrototypeOf]] and [[SetPrototypeOf]].
2607         The issue is that the rest of our code base does not properly handle
2608         such cycles and we can end up in infinite loops. This became obvious
2609         because this patch updates Window / Location so that they no longer
2610         use the default [[GetPrototypeOf]] / [[SetPrototypeOf]]. If I do not
2611         remove this check, I get an infinite loop in
2612         Structure::anyObjectInChainMayInterceptIndexedAccesses(), which is
2613         called from JSObject::setPrototypeDirect(), when running the following
2614         layout test:
2615         - html/browsers/history/the-location-interface/allow_prototype_cycle_through_location.sub.html
2616         I filed https://bugs.webkit.org/show_bug.cgi?id=161534 to track this
2617         issue.
2618
2619         * runtime/JSObject.h:
2620         (JSC::JSObject::getArrayLength): Deleted.
2621         * runtime/JSProxy.cpp:
2622         (JSC::JSProxy::setPrototype):
2623         (JSC::JSProxy::getPrototype):
2624         * runtime/JSProxy.h:
2625         * runtime/ObjectConstructor.cpp:
2626         (JSC::objectConstructorGetPrototypeOf):
2627         (JSC::objectConstructorSetPrototypeOf):
2628         (JSC::objectConstructorGetOwnPropertyDescriptor): Deleted.
2629         (JSC::objectConstructorGetOwnPropertyDescriptors): Deleted.
2630         * runtime/ObjectConstructor.h:
2631         * runtime/ReflectObject.cpp:
2632         (JSC::reflectObjectGetPrototypeOf):
2633         (JSC::reflectObjectSetPrototypeOf):
2634
2635 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
2636
2637         Remove CopiedSpace and use MarkedSpace instead
2638         https://bugs.webkit.org/show_bug.cgi?id=159658
2639
2640         Reviewed by Keith Miller.
2641         
2642         This removes the final client of CopiedSpace, the overrides array of DirectArguments. That
2643         is a simple change.
2644         
2645         Then this stubs out some remaining internal debugging code that referenced CopiedSpace in
2646         JSDollarVM and HeapVerifier. I filed FIXMEs to restore that debugging functionality.
2647         
2648         The rest of this patch is deleting CopiedSpace.
2649
2650         * API/JSObjectRef.cpp:
2651         * CMakeLists.txt:
2652         * JavaScriptCore.xcodeproj/project.pbxproj:
2653         * dfg/DFGOperations.cpp:
2654         * heap/ConservativeRoots.cpp:
2655         (JSC::ConservativeRoots::genericAddPointer):
2656         * heap/CopiedAllocator.h: Removed.
2657         * heap/CopiedBlock.cpp: Removed.
2658         * heap/CopiedBlock.h: Removed.
2659         * heap/CopiedBlockInlines.h: Removed.
2660         * heap/CopiedSpace.cpp: Removed.
2661         * heap/CopiedSpace.h: Removed.
2662         * heap/CopiedSpaceInlines.h: Removed.
2663         * heap/CopyBarrier.h: Removed.
2664         * heap/CopyToken.h: Removed.
2665         * heap/CopyVisitor.cpp: Removed.
2666         * heap/CopyVisitor.h: Removed.
2667         * heap/CopyVisitorInlines.h: Removed.
2668         * heap/CopyWorkList.h: Removed.
2669         * heap/Heap.cpp:
2670         (JSC::Heap::Heap):
2671         (JSC::Heap::isPagedOut):
2672         (JSC::Heap::updateObjectCounts):
2673         (JSC::Heap::size):
2674         (JSC::Heap::capacity):
2675         (JSC::Heap::collectImpl):
2676         (JSC::Heap::stopAllocation):
2677         (JSC::Heap::updateAllocationLimits):
2678         (JSC::Heap::copyBackingStores): Deleted.
2679         (JSC::Heap::threadBytesCopied): Deleted.
2680         * heap/Heap.h:
2681         (JSC::Heap::objectSpace):
2682         (JSC::Heap::allocatorForAuxiliaryData):
2683         (JSC::Heap::storageSpace): Deleted.
2684         (JSC::Heap::storageAllocator): Deleted.
2685         * heap/HeapCellInlines.h:
2686         * heap/HeapInlines.h:
2687         (JSC::Heap::tryAllocateStorage): Deleted.
2688         (JSC::Heap::tryReallocateStorage): Deleted.
2689         * heap/HeapVerifier.cpp:
2690         (JSC::HeapVerifier::verifyButterflyIsInStorageSpace):
2691         (JSC::HeapVerifier::reportObject):
2692         (JSC::getButterflyDetails): Deleted.
2693         * heap/SlotVisitor.cpp:
2694         (JSC::SlotVisitor::copyLater): Deleted.
2695         * heap/SlotVisitor.h:
2696         * jit/AssemblyHelpers.h:
2697         * jit/JITOpcodes.cpp:
2698         * jsc.cpp:
2699         * runtime/ArrayConstructor.cpp:
2700         * runtime/ArrayPrototype.cpp:
2701         * runtime/Butterfly.h:
2702         * runtime/ButterflyInlines.h:
2703         (JSC::Butterfly::createUninitializedDuringCollection): Deleted.
2704         * runtime/ClassInfo.h:
2705         * runtime/DirectArguments.cpp:
2706         (JSC::DirectArguments::visitChildren):
2707         (JSC::DirectArguments::overrideThings):
2708         (JSC::DirectArguments::copyBackingStore): Deleted.
2709         * runtime/DirectArguments.h:
2710         * runtime/JSArray.cpp:
2711         * runtime/JSCell.cpp:
2712         (JSC::JSCell::copyBackingStore): Deleted.
2713         * runtime/JSCell.h:
2714         * runtime/JSLexicalEnvironment.h:
2715         * runtime/JSObject.cpp:
2716         * runtime/JSTypedArrays.cpp:
2717         * runtime/LiteralParser.cpp:
2718         * runtime/ObjectConstructor.cpp:
2719         * runtime/RegExpObject.cpp:
2720         * runtime/StringPrototype.cpp:
2721         * runtime/WeakMapData.cpp:
2722         * tools/JSDollarVMPrototype.cpp:
2723         (JSC::JSDollarVMPrototype::isInStorageSpace):
2724
2725 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
2726
2727         Heap version should be 32-bit
2728         https://bugs.webkit.org/show_bug.cgi?id=161751
2729
2730         Reviewed by Mark Lam.
2731         
2732         32-bit devices are probably getting hurt by the 64-bit version number. The reason why I made
2733         it 64-bit initially is so that I wouldn't have to worry about wrap-around. But wrap-around is
2734         easy to handle.
2735
2736         * heap/CellContainer.h:
2737         * heap/CellContainerInlines.h:
2738         (JSC::CellContainer::flipIfNecessary):
2739         * heap/ConservativeRoots.cpp:
2740         (JSC::ConservativeRoots::genericAddPointer):
2741         (JSC::ConservativeRoots::genericAddSpan):
2742         * heap/ConservativeRoots.h:
2743         * heap/Heap.h:
2744         * heap/HeapInlines.h:
2745         (JSC::Heap::testAndSetMarked):
2746         * heap/HeapUtil.h:
2747         (JSC::HeapUtil::findGCObjectPointersForMarking):
2748         * heap/MarkedBlock.cpp:
2749         (JSC::MarkedBlock::MarkedBlock):
2750         * heap/MarkedBlock.h:
2751         (JSC::MarkedBlock::flipIfNecessary):
2752         (JSC::MarkedBlock::flipIfNecessaryConcurrently):
2753         (JSC::MarkedBlock::Handle::flipIfNecessary):
2754         (JSC::MarkedBlock::Handle::flipIfNecessaryConcurrently):
2755         * heap/MarkedSpace.cpp:
2756         (JSC::MarkedSpace::flip):
2757         * heap/MarkedSpace.h:
2758         (JSC::MarkedSpace::version):
2759         * heap/SlotVisitor.cpp:
2760         (JSC::SlotVisitor::SlotVisitor):
2761         * heap/SlotVisitor.h:
2762
2763 2016-09-08  Mark Lam  <mark.lam@apple.com>
2764
2765         Add support for a ternary sub32 emitter for ARM64 and 32-bit ARM.
2766         https://bugs.webkit.org/show_bug.cgi?id=161724
2767
2768         Reviewed by Filip Pizlo.
2769
2770         ARM architectures support ternary sub instructions.  We should make use of them
2771         in emitAllocateWithNonNullAllocator().
2772
2773         * assembler/MacroAssemblerARM.h:
2774         (JSC::MacroAssemblerARM::sub32):
2775         * assembler/MacroAssemblerARM64.h:
2776         (JSC::MacroAssemblerARM64::sub32):
2777         * assembler/MacroAssemblerARMv7.h:
2778         (JSC::MacroAssemblerARMv7::sub32):
2779         * assembler/MacroAssemblerSH4.h:
2780         (JSC::MacroAssemblerSH4::sub32):
2781         * assembler/MacroAssemblerX86Common.h:
2782         (JSC::MacroAssemblerX86Common::sub32):
2783         * b3/air/AirOpcode.opcodes:
2784         * b3/testb3.cpp:
2785         (JSC::B3::testTernarySubInstructionSelection):
2786         (JSC::B3::run):
2787         * jit/AssemblyHelpers.h:
2788         (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
2789
2790 2016-09-08  Filip Pizlo  <fpizlo@apple.com>
2791
2792         Move JSMap/JSSet over to Auxiliary MarkedSpace
2793         https://bugs.webkit.org/show_bug.cgi?id=161744
2794
2795         Reviewed by Saam Barati.
2796         
2797         This moves the buffer out of CopiedSpace and into Auxiliary MarkedSpace.
2798         
2799         Also removes MapData.h/MapDataInlines.h since they are not used anywhere, but they still
2800         speak of CopiedSpace.
2801         
2802         This is a purely mechanical change.
2803
2804         * JavaScriptCore.xcodeproj/project.pbxproj:
2805         * heap/CopyToken.h:
2806         * runtime/HashMapImpl.cpp:
2807         (JSC::HashMapImpl<HashMapBucket>::visitChildren):
2808         (JSC::HashMapImpl<HashMapBucket>::copyBackingStore): Deleted.
2809         * runtime/HashMapImpl.h:
2810         (JSC::HashMapBuffer::create):
2811         * runtime/JSMapIterator.cpp:
2812         * runtime/JSMapIterator.h:
2813         * runtime/JSSetIterator.cpp:
2814         * runtime/JSSetIterator.h:
2815         * runtime/MapBase.cpp:
2816         * runtime/MapData.h: Removed.
2817         * runtime/MapDataInlines.h: Removed.
2818         * runtime/MapPrototype.cpp:
2819         * runtime/SetConstructor.cpp:
2820         * runtime/SetPrototype.cpp:
2821         * runtime/VM.cpp:
2822
2823 2016-09-06  Filip Pizlo  <fpizlo@apple.com>
2824
2825         Typed arrays should use MarkedSpace instead of CopiedSpace
2826         https://bugs.webkit.org/show_bug.cgi?id=161100
2827
2828         Reviewed by Geoffrey Garen.
2829         
2830         This moves typed array backing stores out of CopiedSpace and into Auxiliary MarkedSpace.
2831         
2832         This is a purely mechanical change since Auxiliary MarkedSpace already knows how to do
2833         everything that typed arrays want.
2834
2835         * dfg/DFGOperations.cpp:
2836         (JSC::DFG::newTypedArrayWithSize):
2837         * dfg/DFGOperations.h:
2838         (JSC::DFG::operationNewTypedArrayWithSizeForType):
2839         * dfg/DFGSpeculativeJIT.cpp:
2840         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
2841         * dfg/DFGSpeculativeJIT.h:
2842         (JSC::DFG::SpeculativeJIT::callOperation):
2843         (JSC::DFG::SpeculativeJIT::emitAllocateBasicStorage): Deleted.
2844         * ftl/FTLLowerDFGToB3.cpp:
2845         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2846         (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
2847         (JSC::FTL::DFG::LowerDFGToB3::splatWords):
2848         (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorageAndGetEnd): Deleted.
2849         (JSC::FTL::DFG::LowerDFGToB3::allocateBasicStorage): Deleted.
2850         * heap/CopyToken.h:
2851         * heap/SlotVisitor.cpp:
2852         (JSC::SlotVisitor::markAuxiliary):
2853         * jit/JITOperations.h:
2854         * runtime/JSArrayBufferView.cpp:
2855         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
2856         (JSC::JSArrayBufferView::JSArrayBufferView):
2857         * runtime/JSArrayBufferView.h:
2858         * runtime/JSGenericTypedArrayView.h:
2859         * runtime/JSGenericTypedArrayViewInlines.h:
2860         (JSC::JSGenericTypedArrayView<Adaptor>::createWithFastVector):
2861         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
2862         (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
2863         (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore): Deleted.
2864
2865 2016-09-08  Per Arne Vollan  <pvollan@apple.com>
2866
2867         [Win64] Compile fixes.
2868         https://bugs.webkit.org/show_bug.cgi?id=161682
2869
2870         Reviewed by Brent Fulgham.
2871
2872         * dfg/DFGSpeculativeJIT64.cpp:
2873         (JSC::DFG::SpeculativeJIT::emitCall):
2874         * jit/JITCall.cpp:
2875         (JSC::JIT::compileOpCall):
2876         * runtime/ArrayConventions.cpp:
2877         (JSC::clearArrayMemset):
2878
2879 2016-09-08  Per Arne Vollan  <pvollan@apple.com>
2880
2881         [Win] Exception fuzz tests fail
2882         https://bugs.webkit.org/show_bug.cgi?id=140928
2883
2884         Reviewed by Mark Lam.
2885
2886         Flush stdout when throwing the exception to make sure the output comes before output in the exception handler.
2887         The tests depend on the output to stdout being written in the correct order.
2888
2889         * runtime/ExceptionFuzz.cpp:
2890         (JSC::doExceptionFuzzing):
2891
2892 2016-09-07  Simon Fraser  <simon.fraser@apple.com>
2893
2894         Enable the <meter> element on iOS
2895         https://bugs.webkit.org/show_bug.cgi?id=161714
2896         rdar://problem/8978410
2897
2898         Reviewed by Tim Horton.
2899
2900         Define ENABLE_METER_ELEMENT unconditionally now.
2901
2902         * Configurations/FeatureDefines.xcconfig:
2903
2904 2016-09-07  Joseph Pecoraro  <pecoraro@apple.com>
2905
2906         Modernize Debugger to use nullptr
2907         https://bugs.webkit.org/show_bug.cgi?id=161718
2908
2909         Reviewed by Mark Lam.
2910
2911         * debugger/Debugger.cpp:
2912         (JSC::Debugger::Debugger):
2913         (JSC::Debugger::~Debugger):
2914         (JSC::Debugger::detach):
2915         (JSC::Debugger::stepOutOfFunction):
2916         (JSC::Debugger::updateCallFrameAndPauseIfNeeded):
2917         * debugger/Debugger.h:
2918
2919 2016-09-07  Joseph Pecoraro  <pecoraro@apple.com>
2920
2921         Web Inspector: Remove always false case in Debugger
2922         https://bugs.webkit.org/show_bug.cgi?id=161717
2923
2924         Reviewed by Brian Burg.
2925
2926         * debugger/Debugger.cpp:
2927         (JSC::Debugger::didExecuteProgram):
2928         We would have earlier returned a few statements ago if this case was true.
2929         And we would have crashed in the previous statement if this case was true.
2930
2931 2016-09-07  Yusuke Suzuki  <utatane.tea@gmail.com>
2932
2933         Unreviewed, build fix after r205569
2934
2935         Tweak CMakeLists.txt
2936
2937         * CMakeLists.txt:
2938
2939 2016-09-07  Mark Lam  <mark.lam@apple.com>
2940
2941         Add CatchScope and force all exception checks to be via ThrowScope or CatchScope.
2942         https://bugs.webkit.org/show_bug.cgi?id=161498
2943
2944         Reviewed by Geoffrey Garen.
2945
2946         This patch refactors the ThrowScope class, and introduces a base ExceptionScope
2947         that ThrowScope extends.  A CatchScope which extends the ExceptionScope is also
2948         introduced.
2949
2950         ENABLE(THROW_SCOPE_VERIFICATION) is now renamed to ENABLE(EXCEPTION_SCOPE_VERIFICATION)
2951         which is a more suitable name now.
2952
2953         Note: exception scope verification is still disabled by default.  There are still
2954         many places that need to be fixed up or re-expressed in a way that is friendly
2955         to the verification.  I'll address those in subsequent patches.
2956
2957         After this patch, the code will statically enforce that:
2958         1. all calls to throwException() go through a ThrowScope.
2959         2. all calls to clearException() go through a CatchScope.
2960         3. all exception checks go through an ExceptionScope in the form of a ThrowScope
2961            or CatchScope.
2962
2963         A Summary of how to use ExceptionScopes
2964         =======================================
2965         1. If a function can throw a JS exception, it should declare a ThrowScope at the
2966            top of the function (as early as possible).
2967
2968         2. If a function can clear JS exceptions, it should declare a CatchScope at the
2969            top of the function (as early as possible).
2970
2971         Declaring a ThrowScope in a function means that the function may throw an exception
2972         that its caller will have to handle.  Declaring a CatchScope in a function means
2973         that the function intends to clear pending exceptions before returning to its
2974         caller. 
2975
2976         For more details, see the notes below.
2977         
2978         Everything you may want to know about ExceptionScopes
2979         =====================================================
2980         ExceptionScope verification works to simulate exception throws and detect cases
2981         where exception checks are missing.  The notes below will cover:
2982
2983             1. The VM::m_needExceptionCheck bit
2984             2. ThrowScopes and CatchScopes
2985             3. Verification of needed exception checks
2986             3. Checking Exceptions
2987             4. Simulating throws
2988             5. Using ThrowScope::release()
2989             6. Checking exceptions with ThrowScope::exception() / CatchScope::exception()
2990             7. Checking exceptions by checking callee results
2991             8. Debugging verification errors
2992
2993         1. The VM::m_needExceptionCheck bit
2994
2995            The VM has a m_needExceptionCheck bit that indicates when an exception may be
2996            thrown.  You can think of the m_needExceptionCheck bit being set as a simulated
2997            throw.
2998
2999         2. ThrowScopes and CatchScopes
3000
3001            Only ThrowScopes may throwException.  Only CatchScopes may catchException.
3002
3003            Every throw site must declare a ThrowScope instance using DECLARE_THROW_SCOPE
3004            at the top of its function (as early as possible) e.g.
3005  
3006                 void foo(...)
3007                 {
3008                     auto scope = DECLARE_THROW_SCOPE(vm);
3009                     ...
3010                     throwException(exec, scope, ...);
3011                 }
3012
3013            Note: by convention, every throw helper function must take a ThrowScope argument
3014            instead of instantiating its own ThrowScope.  This allows the throw to be
3015            attributed to the client code rather than the throw helper itself.
3016
3017            Every catch site (i.e. a site that calls clearException()) must declare a
3018            CatchScope instance using DECLARE_CATCH_SCOPE at the top of its function.
3019
3020            If a function can both throw or clear exceptions, then the ThrowScope should
3021            be declared first so that it can simulate a throw to the function's caller.
3022
3023            Note: ThrowScope and CatchScope both extend ExceptionScope so that ThrowScopes
3024            can be aware if there's an enclosing CatchScope between it and the point where
3025            C++ code returns to JS code.  This is needed to determine if the ThrowScope
3026            should simulate a re-throw or not.  See (4) below for more details on returning
3027            to JS code.
3028
3029         3. Verification of needed exception checks
3030
3031            a. On construction, each ThrowScope and CatchScope will verify that
3032               VM::m_needExceptionCheck is not set.
3033  
3034               This ensures that the caller of the current function has checked for exceptions
3035               where needed before doing more work which lead to calling the current function.
3036
3037            b. On destruction, each ThrowScope and CatchScope will verify that
3038               VM::m_needExceptionCheck is not set. This verification will be skipped if
3039               the ThrowScope has been released (see (5) below).
3040
3041               This ensures that the function that owns this exception scope is not missing
3042               any exception checks before returning.
3043
3044            c. When throwing an exception, the ThrowScope will verify that VM::m_needExceptionCheck
3045               is not already set, unless it's been ask to rethrow the same Exception object.
3046
3047         4. Simulating throws
3048
3049            Throws are simulated by setting the m_needExceptionCheck bit.
3050
3051            The bit will only be set in the ThrowScope destructor except when the ThrowScope
3052            detects the caller is a LLInt or JIT function.  LLInt or JIT functions will always
3053            check for exceptions after a host C++ function returns to it.  However, they will
3054            not clear the m_needExceptionCheck bit.
3055
3056            Hence, if the ThrowScope destructor detects the caller is a LLInt or JIT function,
3057            it will just skip the setting of the bit.
3058
3059            Note: it is not needed nor correct to set the m_needExceptionCheck bit in the
3060            throwException methods.  This is because, in practice, we always return
3061            immediately after throwing an exception.  It doesn't make sense to set the bit in
3062            the throw just to have to clear it immediately after before we do verification in
3063            the ThrowScope destructor.
3064
3065         5. Using ThrowScope::release()
3066
3067            Calling release() means that the scope is released from its obligation to
3068            verify the VM::m_needExceptionCheck bit on destruction.
3069
3070            release() should only be used at the bottom of a function if:
3071
3072            a. This function is going to let its caller check and handle the exception, e.g.
3073
3074                 void foo(...)
3075                 {
3076                     auto scope = DECLARE_THROW_SCOPE(vm);
3077                     auto result = goo(); // may throw.
3078
3079                     ... // Code that will are not affected by a pending exceptions.
3080
3081                     scope.release(); // tell the ThrowScope that the caller will handle the exception.
3082                     return result;
3083                 }
3084
3085            b. This function is going to do a tail call that may throw.
3086
3087                 void foo(...)
3088                 {
3089                     auto scope = DECLARE_THROW_SCOPE(vm);
3090                     ...
3091                     scope.release(); // tell the ThrowScope that the caller will handle the exception.
3092                     return goo(); // may throw.
3093                 }
3094
3095               release() should not be used in code paths that branch. For example:
3096
3097                 void foo(...)
3098                 {
3099                     auto scope = DECLARE_THROW_SCOPE(vm);
3100
3101                     auto result = goo1(); // may throw.
3102                     scope.release(); // WRONG !!! Don't do this.
3103                     if (result)
3104                         return;
3105
3106                     result = goo2(); // may throw.
3107                     ...
3108                     return result;
3109                 }
3110
3111             The above will result in a verification error in goo2()'s ThrowScope.  The
3112             proper way to fix this verification is to do either (6) or (7) below.
3113
3114          6. Checking exceptions with ThrowScope::exception() / CatchScope::exception()
3115
3116             ThrowScope/CatchScope::exception() returns the thrown Exception object if
3117             there is one pending.  Else, it returns nullptr.
3118
3119             It also clears the m_needExceptionCheck bit thereby indicating that we've
3120             satisfied the needed exception check.  For example,
3121
3122                 void foo(...)
3123                 {
3124                     auto scope = DECLARE_THROW_SCOPE(vm);
3125
3126                     auto result = goo1(); // may throw.
3127                     if (scope.exception())
3128                         return;
3129
3130                     result = goo2(); // may throw.
3131                     ...
3132                     return result;
3133                 }
3134
3135             But sometimes, for optimization reasons, we may choose to test the result of
3136             the callee function instead doing a load of the VM exception value.  See (7)
3137             below.
3138
3139          7. Checking exceptions by checking callee results
3140
3141             This approach should only be applied when it makes a difference to performance.
3142             If we need to do this, we should add an ASSERT() that invokes the scope's
3143             exception() method to verify the result.  Since exception scope verification
3144             is only done on DEBUG builds, this ASSERT will satisfy the verification
3145             requirements without impacting performance.  For example,
3146
3147                 void foo(...)
3148                 {
3149                     auto scope = DECLARE_THROW_SCOPE(vm);
3150
3151                     bool failed = goo1(); // may throw.
3152                     ASSERT(!!scope.exception() == failed)
3153                     if (failed)
3154                         return;
3155
3156                     result = goo2(); // may throw.
3157                     ...
3158                     return result;
3159                 }
3160
3161          8. Debugging verification errors
3162
3163             a. When verification fails, you will see a message followed by an assertion
3164                failure.  For example:
3165
3166             ERROR: Unchecked JS exception:
3167                 This scope can throw a JS exception: setUpCall @ /Volumes/Data/ws6/OpenSource/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1245
3168                     (ExceptionScope::m_recursionDepth was ...)
3169                 But the exception was unchecked as of this scope: varargsSetup @ /Volumes/Data/ws6/OpenSource/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:1398
3170                     (ExceptionScope::m_recursionDepth was ...)
3171                 [ backtrace here ]
3172
3173                The message tells you that failure was detected at in varargsSetup() at
3174                LLIntSlowPaths.cpp line 1398, and that the missing exception check should
3175                have happened somewhere between the call to setUpCall() at LLIntSlowPaths.cpp
3176                line 1245 and it.
3177
3178                If that is insufficient information, you can ...
3179
3180             b. Dump simulated throws
3181
3182                Re-run the test case with JSC_dumpSimulatedThrows=true.  You will also see
3183                back traces at each simulated throw.
3184
3185             c. Narrowing down the source of a simulated throw
3186
3187                Another technique for narrowing down the source of simulated throws is by
3188                further dividing a function to smaller regions by separating each region
3189                with additional local throw scopes.  For example,
3190
3191                 ... // Region 1
3192                 { auto scope = DECLARE_THROW_SCOPE(vm); }
3193                 ... // Region 2
3194                 { auto scope = DECLARE_THROW_SCOPE(vm); }
3195                 ... // Region 3
3196
3197         * API/APIUtils.h:
3198         (handleExceptionIfNeeded):
3199         * CMakeLists.txt:
3200         * JavaScriptCore.xcodeproj/project.pbxproj:
3201         * bindings/ScriptFunctionCall.cpp:
3202         (Deprecated::ScriptFunctionCall::call):
3203         * bindings/ScriptValue.cpp:
3204         (Deprecated::ScriptValue::toString):
3205         * debugger/Debugger.cpp:
3206         (JSC::Debugger::pauseIfNeeded):
3207         * debugger/DebuggerCallFrame.cpp:
3208         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
3209         * dfg/DFGOSRExitCompiler.cpp:
3210         * dfg/DFGOperations.cpp:
3211         (JSC::DFG::operationPutByValInternal):
3212         * inspector/InjectedScriptManager.cpp:
3213         (Inspector::InjectedScriptManager::createInjectedScript):
3214         * inspector/JSGlobalObjectInspectorController.cpp:
3215         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
3216         * inspector/JSInjectedScriptHost.cpp:
3217         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
3218         (Inspector::JSInjectedScriptHost::getInternalProperties):
3219         (Inspector::JSInjectedScriptHost::weakMapEntries):
3220         (Inspector::JSInjectedScriptHost::weakSetEntries):
3221         (Inspector::JSInjectedScriptHost::iteratorEntries):
3222         * inspector/JSJavaScriptCallFrame.cpp:
3223         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
3224         * inspector/ScriptCallStackFactory.cpp:
3225         (Inspector::extractSourceInformationFromException):
3226         * interpreter/CachedCall.h:
3227         (JSC::CachedCall::CachedCall):
3228         * interpreter/CallFrame.h:
3229         (JSC::ExecState::clearException): Deleted.
3230         (JSC::ExecState::exception): Deleted.
3231         (JSC::ExecState::hadException): Deleted.
3232         (JSC::ExecState::lastException): Deleted.
3233         (JSC::ExecState::clearLastException): Deleted.
3234         * interpreter/Interpreter.cpp:
3235         (JSC::eval):
3236         (JSC::sizeOfVarargs):
3237         (JSC::notifyDebuggerOfUnwinding):
3238         (JSC::Interpreter::unwind):
3239         (JSC::Interpreter::execute):
3240         (JSC::Interpreter::executeCall):
3241         (JSC::Interpreter::executeConstruct):
3242         (JSC::Interpreter::prepareForRepeatCall):
3243         (JSC::Interpreter::debug):
3244         * interpreter/Interpreter.h:
3245         (JSC::SuspendExceptionScope::SuspendExceptionScope):
3246         * interpreter/ShadowChicken.cpp:
3247         (JSC::ShadowChicken::functionsOnStack):
3248         * jit/JITCode.cpp:
3249         (JSC::JITCode::execute):
3250         * jit/JITExceptions.cpp:
3251         (JSC::genericUnwind):
3252         * jit/JITOperations.cpp:
3253         (JSC::getByVal):
3254         * jsc.cpp:
3255         (WTF::ImpureGetter::getOwnPropertySlot):
3256         (GlobalObject::moduleLoaderResolve):
3257         (GlobalObject::moduleLoaderFetch):
3258         (functionCreateElement):
3259         (functionRun):
3260         (functionRunString):
3261         (functionLoad):
3262         (functionLoadString):
3263         (functionReadFile):
3264         (functionCheckSyntax):
3265         (functionSetRandomSeed):
3266         (functionLoadModule):
3267         (functionCreateBuiltin):
3268         (functionCheckModuleSyntax):
3269         (functionGenerateHeapSnapshot):
3270         (functionSamplingProfilerStackTraces):
3271         (dumpException):
3272         (checkUncaughtException):
3273         (runWithScripts):
3274         (runInteractive):
3275         * llint/LLIntExceptions.cpp:
3276         (JSC::LLInt::returnToThrow):
3277         (JSC::LLInt::callToThrow):
3278         * llint/LLIntSlowPaths.cpp:
3279         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3280         * profiler/ProfilerBytecodeSequence.cpp:
3281         (JSC::Profiler::BytecodeSequence::addSequenceProperties):
3282         * profiler/ProfilerCompilation.cpp:
3283         (JSC::Profiler::Compilation::toJS):
3284         * profiler/ProfilerDatabase.cpp:
3285         (JSC::Profiler::Database::toJS):
3286         * profiler/ProfilerOSRExitSite.cpp:
3287         (JSC::Profiler::OSRExitSite::toJS):
3288         * profiler/ProfilerOriginStack.cpp:
3289         (JSC::Profiler::OriginStack::toJS):
3290         * runtime/ArrayPrototype.cpp:
3291         (JSC::speciesConstructArray):
3292         (JSC::shift):
3293         (JSC::unshift):
3294         (JSC::arrayProtoFuncToString):
3295         (JSC::arrayProtoFuncToLocaleString):
3296         (JSC::slowJoin):
3297         (JSC::fastJoin):
3298         (JSC::arrayProtoFuncJoin):
3299         (JSC::arrayProtoFuncPop):
3300         (JSC::arrayProtoFuncPush):
3301         (JSC::arrayProtoFuncReverse):
3302         (JSC::arrayProtoFuncShift):
3303         (JSC::arrayProtoFuncSlice):
3304         (JSC::arrayProtoFuncSplice):
3305         (JSC::arrayProtoFuncUnShift):
3306         (JSC::arrayProtoFuncIndexOf):
3307         (JSC::arrayProtoFuncLastIndexOf):
3308         (JSC::moveElements):
3309         (JSC::concatAppendOne):
3310         (JSC::arrayProtoPrivateFuncConcatMemcpy):
3311         * runtime/BooleanConstructor.cpp:
3312         (JSC::constructWithBooleanConstructor):
3313         * runtime/CallData.cpp:
3314         (JSC::call):
3315         * runtime/CatchScope.cpp: Added.
3316         (JSC::CatchScope::CatchScope):
3317         (JSC::CatchScope::~CatchScope):
3318         * runtime/CatchScope.h: Added.