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