3e85a6cc0226adcccc5d150f38cea31410881a94
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-10-19  Csaba Osztrogonác  <ossy@webkit.org>
2
3         Fix the ENABLE(WEBASSEMBLY) build after r190827
4         https://bugs.webkit.org/show_bug.cgi?id=150330
5
6         Reviewed by Geoffrey Garen.
7
8         * bytecode/CodeBlock.cpp:
9         (JSC::CodeBlock::CodeBlock): Removed the duplicated VM argument.
10         * bytecode/CodeBlock.h:
11         (JSC::WebAssemblyCodeBlock::create): Added new parameters to finishCreation() calls.
12         (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock): Change VM parameter to pointer to match *CodeBlock classes.
13         * runtime/Executable.cpp:
14         (JSC::WebAssemblyExecutable::prepareForExecution): Removed extra ")" and pass pointer as it is expected.
15
16 2015-10-19  Mark Lam  <mark.lam@apple.com>
17
18         DoubleRep fails to convert SpecBoolean values.
19         https://bugs.webkit.org/show_bug.cgi?id=150313
20
21         Reviewed by Geoffrey Garen.
22
23         This was uncovered by the op_sub stress test on 32-bit builds.  On 32-bit builds,
24         DoubleRep will erroneously convert 'true' to a 'NaN' instead of a double 1.
25         On 64-bit, the same issue exists but is masked by another bug in DoubleRep where
26         boolean values will always erroneously trigger a BadType OSR exit.
27
28         The erroneous conversion of 'true' to 'NaN' is because the 'true' case in
29         compileDoubleRep() is missing a jump to the "done" destination.  Instead, it
30         fall through to the "isUndefined" case where it produces a NaN.
31
32         The 64-bit erroneous BadType OSR exit is due to the boolean type check being
33         implemented incorrectly.  It was checking if any bits other than bit 0 were set.
34         However, boolean JS values always have TagBitBool (the 3rd bit) set.  Hence, the
35         check will always fail if we have a boolean value.
36
37         This patch fixes both of these issues.
38
39         No new test is needed because these issues are already covered by scenarios in
40         the op_sub.js stress test.  This patch also fixes the op_sub.js test to throw an
41         exception if any failures are encountered (as expected by the stress test
42         harness).  This patch also re-worked the test code to provide more accurate
43         descriptions of each test scenario for error reporting.
44
45         * dfg/DFGSpeculativeJIT.cpp:
46         (JSC::DFG::SpeculativeJIT::compileDoubleRep):
47
48         * tests/stress/op_sub.js:
49         (generateScenarios):
50         (func):
51         (initializeTestCases):
52         (runTest):
53         (stringify): Deleted.
54
55 2015-10-19  Yusuke Suzuki  <utatane.tea@gmail.com>
56
57         Drop !newTarget check since it always becomes true
58         https://bugs.webkit.org/show_bug.cgi?id=150308
59
60         Reviewed by Geoffrey Garen.
61
62         In a context of calling a constructor, `newTarget` should not become JSEmpty.
63         So `!newTarget` always becomes true. This patch drops this unneccessary check.
64         And to ensure the implementation of the constructor is only called under
65         the context of calling it as a constructor, we change these functions to
66         static and only use them for constructor implementations of InternalFunction.
67
68         * runtime/IntlCollatorConstructor.cpp:
69         (JSC::constructIntlCollator):
70         (JSC::callIntlCollator):
71         * runtime/IntlCollatorConstructor.h:
72         * runtime/IntlDateTimeFormatConstructor.cpp:
73         (JSC::constructIntlDateTimeFormat):
74         (JSC::callIntlDateTimeFormat):
75         * runtime/IntlDateTimeFormatConstructor.h:
76         * runtime/IntlNumberFormatConstructor.cpp:
77         (JSC::constructIntlNumberFormat):
78         (JSC::callIntlNumberFormat):
79         * runtime/IntlNumberFormatConstructor.h:
80         * runtime/JSPromiseConstructor.cpp:
81         (JSC::constructPromise):
82
83 2015-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
84
85         Promise constructor should throw when not called with "new"
86         https://bugs.webkit.org/show_bug.cgi?id=149380
87
88         Reviewed by Darin Adler.
89
90         Implement handling new.target in Promise constructor. And
91         prohibiting Promise constructor call without "new".
92
93         * runtime/JSPromiseConstructor.cpp:
94         (JSC::constructPromise):
95         (JSC::callPromise):
96         (JSC::JSPromiseConstructor::getCallData):
97         * tests/es6.yaml:
98         * tests/stress/promise-cannot-be-called.js: Added.
99         (shouldBe):
100         (shouldThrow):
101         (Deferred):
102         (super):
103
104 2015-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
105
106         [ES6] Handle asynchronous tests in tests/es6
107         https://bugs.webkit.org/show_bug.cgi?id=150293
108
109         Reviewed by Darin Adler.
110
111         Since JSC can handle microtasks, some of ES6 Promise tests can be executed under the JSC shell.
112         Some of them still fail because it uses setTimeout that invokes macrotasks with explicit delay.
113
114         * tests/es6.yaml:
115         * tests/es6/Promise_Promise.all.js:
116         (test.asyncTestPassed):
117         (test):
118         * tests/es6/Promise_Promise.all_generic_iterables.js:
119         (test.asyncTestPassed):
120         (test):
121         * tests/es6/Promise_Promise.race.js:
122         (test.asyncTestPassed):
123         (test):
124         * tests/es6/Promise_Promise.race_generic_iterables.js:
125         (test.asyncTestPassed):
126         (test):
127         * tests/es6/Promise_basic_functionality.js:
128         (test.asyncTestPassed):
129         (test):
130         * tests/es6/Promise_is_subclassable_Promise.all.js:
131         (test.asyncTestPassed):
132         (test):
133         * tests/es6/Promise_is_subclassable_Promise.race.js:
134         (test.asyncTestPassed):
135         (test):
136         * tests/es6/Promise_is_subclassable_basic_functionality.js:
137         (test.asyncTestPassed):
138         (test):
139
140 2015-10-18  Sungmann Cho  <sungmann.cho@navercorp.com>
141
142         [Win] Fix the Windows builds.
143         https://bugs.webkit.org/show_bug.cgi?id=150300
144
145         Reviewed by Darin Adler.
146
147         Add missing files to JavaScriptCore.vcxproj.
148
149         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
150         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
151
152 2015-10-17  Filip Pizlo  <fpizlo@apple.com>
153
154         Fix some generational heap growth pathologies
155         https://bugs.webkit.org/show_bug.cgi?id=150270
156
157         Reviewed by Andreas Kling.
158
159         When doing generational copying, we would pretend that the size of old space was increased
160         just by the amount of bytes we copied. In reality, it would be increased by the number of
161         bytes used by the copied blocks we created. This is a larger number, and in some simple
162         pathological programs, the difference can be huge.
163
164         Fixing this bug was relatively easy, and the only really meaningful change here is in
165         Heap::updateAllocationLimits(). But to convince myself that the change was valid, I had to
166         add some debugging code and I had to refactor some stuff so that it made more sense.
167
168         This change does obviate the need for m_totalBytesCopied, because we no longer use it in
169         release builds to decide how much heap we are using at the end of collection. But I added a
170         FIXME about how we could restore our use of m_totalBytesCopied. So, I kept the logic, for
171         now. The FIXME references https://bugs.webkit.org/show_bug.cgi?id=150268.
172
173         Relanding with build fix.
174
175         * CMakeLists.txt:
176         * JavaScriptCore.xcodeproj/project.pbxproj:
177         * heap/CopiedBlock.cpp: Added.
178         (JSC::CopiedBlock::createNoZeroFill):
179         (JSC::CopiedBlock::destroy):
180         (JSC::CopiedBlock::create):
181         (JSC::CopiedBlock::zeroFillWilderness):
182         (JSC::CopiedBlock::CopiedBlock):
183         * heap/CopiedBlock.h:
184         (JSC::CopiedBlock::didSurviveGC):
185         (JSC::CopiedBlock::createNoZeroFill): Deleted.
186         (JSC::CopiedBlock::destroy): Deleted.
187         (JSC::CopiedBlock::create): Deleted.
188         (JSC::CopiedBlock::zeroFillWilderness): Deleted.
189         (JSC::CopiedBlock::CopiedBlock): Deleted.
190         * heap/CopiedSpaceInlines.h:
191         (JSC::CopiedSpace::startedCopying):
192         * heap/Heap.cpp:
193         (JSC::Heap::updateObjectCounts):
194         (JSC::Heap::resetVisitors):
195         (JSC::Heap::capacity):
196         (JSC::Heap::protectedGlobalObjectCount):
197         (JSC::Heap::collectImpl):
198         (JSC::Heap::willStartCollection):
199         (JSC::Heap::updateAllocationLimits):
200         (JSC::Heap::didFinishCollection):
201         (JSC::Heap::sizeAfterCollect): Deleted.
202         * heap/Heap.h:
203         * heap/HeapInlines.h:
204         (JSC::Heap::shouldCollect):
205         (JSC::Heap::isBusy):
206         (JSC::Heap::collectIfNecessaryOrDefer):
207         * heap/MarkedBlock.cpp:
208         (JSC::MarkedBlock::create):
209         (JSC::MarkedBlock::destroy):
210
211 2015-10-17  Commit Queue  <commit-queue@webkit.org>
212
213         Unreviewed, rolling out r191240.
214         https://bugs.webkit.org/show_bug.cgi?id=150281
215
216         Broke 32-bit builds (Requested by smfr on #webkit).
217
218         Reverted changeset:
219
220         "Fix some generational heap growth pathologies"
221         https://bugs.webkit.org/show_bug.cgi?id=150270
222         http://trac.webkit.org/changeset/191240
223
224 2015-10-17  Sungmann Cho  <sungmann.cho@navercorp.com>
225
226         [Win] Fix the Windows build.
227         https://bugs.webkit.org/show_bug.cgi?id=150278
228
229         Reviewed by Brent Fulgham.
230
231         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
232         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
233
234 2015-10-17  Mark Lam  <mark.lam@apple.com>
235
236         Fixed typos from r191224.
237
238         Not reviewed.
239
240         * jit/JITSubGenerator.h:
241         (JSC::JITSubGenerator::generateFastPath):
242
243 2015-10-17  Filip Pizlo  <fpizlo@apple.com>
244
245         Fix some generational heap growth pathologies
246         https://bugs.webkit.org/show_bug.cgi?id=150270
247
248         Reviewed by Andreas Kling.
249
250         When doing generational copying, we would pretend that the size of old space was increased
251         just by the amount of bytes we copied. In reality, it would be increased by the number of
252         bytes used by the copied blocks we created. This is a larger number, and in some simple
253         pathological programs, the difference can be huge.
254
255         Fixing this bug was relatively easy, and the only really meaningful change here is in
256         Heap::updateAllocationLimits(). But to convince myself that the change was valid, I had to
257         add some debugging code and I had to refactor some stuff so that it made more sense.
258
259         This change does obviate the need for m_totalBytesCopied, because we no longer use it in
260         release builds to decide how much heap we are using at the end of collection. But I added a
261         FIXME about how we could restore our use of m_totalBytesCopied. So, I kept the logic, for
262         now. The FIXME references https://bugs.webkit.org/show_bug.cgi?id=150268.
263
264         * CMakeLists.txt:
265         * JavaScriptCore.xcodeproj/project.pbxproj:
266         * heap/CopiedBlock.cpp: Added.
267         (JSC::CopiedBlock::createNoZeroFill):
268         (JSC::CopiedBlock::destroy):
269         (JSC::CopiedBlock::create):
270         (JSC::CopiedBlock::zeroFillWilderness):
271         (JSC::CopiedBlock::CopiedBlock):
272         * heap/CopiedBlock.h:
273         (JSC::CopiedBlock::didSurviveGC):
274         (JSC::CopiedBlock::createNoZeroFill): Deleted.
275         (JSC::CopiedBlock::destroy): Deleted.
276         (JSC::CopiedBlock::create): Deleted.
277         (JSC::CopiedBlock::zeroFillWilderness): Deleted.
278         (JSC::CopiedBlock::CopiedBlock): Deleted.
279         * heap/CopiedSpaceInlines.h:
280         (JSC::CopiedSpace::startedCopying):
281         * heap/Heap.cpp:
282         (JSC::Heap::updateObjectCounts):
283         (JSC::Heap::resetVisitors):
284         (JSC::Heap::capacity):
285         (JSC::Heap::protectedGlobalObjectCount):
286         (JSC::Heap::collectImpl):
287         (JSC::Heap::willStartCollection):
288         (JSC::Heap::updateAllocationLimits):
289         (JSC::Heap::didFinishCollection):
290         (JSC::Heap::sizeAfterCollect): Deleted.
291         * heap/Heap.h:
292         * heap/HeapInlines.h:
293         (JSC::Heap::shouldCollect):
294         (JSC::Heap::isBusy):
295         (JSC::Heap::collectIfNecessaryOrDefer):
296         * heap/MarkedBlock.cpp:
297         (JSC::MarkedBlock::create):
298         (JSC::MarkedBlock::destroy):
299
300 2015-10-16  Yusuke Suzuki  <utatane.tea@gmail.com>
301
302         [ES6] Implement String.prototype.normalize
303         https://bugs.webkit.org/show_bug.cgi?id=150094
304
305         Reviewed by Geoffrey Garen.
306
307         This patch implements String.prototype.normalize leveraging ICU.
308         It can provide the feature applying {NFC, NFD, NFKC, NFKD} normalization to a given string.
309
310         * runtime/StringPrototype.cpp:
311         (JSC::StringPrototype::finishCreation):
312         (JSC::normalize):
313         (JSC::stringProtoFuncNormalize):
314         * tests/es6.yaml:
315         * tests/stress/string-normalize.js: Added.
316         (unicode):
317         (shouldBe):
318         (shouldThrow):
319         (normalizeTest):
320
321 2015-10-16  Geoffrey Garen  <ggaren@apple.com>
322
323         Update JavaScriptCore API docs
324         https://bugs.webkit.org/show_bug.cgi?id=150262
325
326         Reviewed by Mark Lam.
327
328         Apply some edits for clarity. These came out of a docs review.
329
330         * API/JSContext.h:
331         * API/JSExport.h:
332         * API/JSManagedValue.h:
333         * API/JSValue.h:
334
335 2015-10-16  Keith Miller  <keith_miller@apple.com>
336
337         Unreviewed. Fix typo in TypeError messages in TypedArray.prototype.forEach/filter.
338
339         * builtins/TypedArray.prototype.js:
340         (forEach):
341         (filter):
342
343 2015-10-16  Mark Lam  <mark.lam@apple.com>
344
345         Use JITSubGenerator to support UntypedUse operands for op_sub in the DFG.
346         https://bugs.webkit.org/show_bug.cgi?id=150038
347
348         Reviewed by Geoffrey Garen.
349
350         * bytecode/SpeculatedType.h:
351         (JSC::isUntypedSpeculationForArithmetic): Added
352         - Also fixed some comments.
353         
354         * dfg/DFGAbstractInterpreterInlines.h:
355         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
356
357         * dfg/DFGAbstractValue.cpp:
358         (JSC::DFG::AbstractValue::resultType):
359         * dfg/DFGAbstractValue.h:
360         - Added function to compute the ResultType of an operand from its SpeculatedType.
361
362         * dfg/DFGFixupPhase.cpp:
363         (JSC::DFG::FixupPhase::fixupNode):
364         - Fix up ArithSub to speculate its operands to be numbers.  But if an OSR exit
365           due to a BadType was seen at this node, we'll fix it up to expect UntypedUse
366           operands.  This gives the generated code a change to run fast if it only
367           receives numeric operands.
368
369         * dfg/DFGNode.h:
370         (JSC::DFG::Node::shouldSpeculateUntypedForArithmetic):
371
372         * dfg/DFGOperations.cpp:
373         * dfg/DFGOperations.h:
374         - Add the C++ runtime function to implement op_sub when we really encounter the
375           hard types in the operands.
376
377         * dfg/DFGSpeculativeJIT.cpp:
378         (JSC::DFG::SpeculativeJIT::compileArithSub):
379         - Added support for UntypedUse operands using the JITSubGenerator.
380
381         * dfg/DFGSpeculativeJIT.h:
382         (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
383         (JSC::DFG::SpeculativeJIT::pickCanTrample):
384         (JSC::DFG::SpeculativeJIT::callOperation):
385
386         * ftl/FTLCapabilities.cpp:
387         (JSC::FTL::canCompile):
388         - Just refuse to FTL compile functions with UntypedUse op_sub operands for now.
389
390         * jit/AssemblyHelpers.h:
391         (JSC::AssemblyHelpers::boxDouble):
392         (JSC::AssemblyHelpers::unboxDoubleNonDestructive):
393         (JSC::AssemblyHelpers::unboxDouble):
394         (JSC::AssemblyHelpers::boxBooleanPayload):
395         * jit/JITArithmetic.cpp:
396         (JSC::JIT::emit_op_sub):
397
398         * jit/JITSubGenerator.h:
399         (JSC::JITSubGenerator::generateFastPath):
400         (JSC::JITSubGenerator::endJumpList):
401         - Added some asserts to document the contract that this generator expects in
402           terms of its incoming registers.
403
404           Also fixed the generated code to not be destructive with regards to incoming
405           registers.  The DFG expects this.
406
407           Also added an endJumpList so that we don't have to jump twice for the fast
408           path where both operands are ints.
409
410         * parser/ResultType.h:
411         (JSC::ResultType::ResultType):
412         - Make the internal Type bits and the constructor private.  Clients should only
413           create ResultType values using one of the provided factory methods.
414
415         * tests/stress/op_sub.js: Added.
416         (o1.valueOf):
417         (stringify):
418         (generateScenarios):
419         (printScenarios):
420         (testCases.func):
421         (func):
422         (initializeTestCases):
423         (runTest):
424         - test op_sub results by comparing one LLINT result against the output of
425           multiple LLINT, and JIT runs.  This test assume that we'll at least get the
426           right result some of the time (if not all the time), and confirms that the
427           various engines produce consistent results for all the various value pairs
428           being tested.
429
430 2015-10-15  Filip Pizlo  <fpizlo@apple.com>
431
432         CopyBarrier must be avoided for slow TypedArrays
433         https://bugs.webkit.org/show_bug.cgi?id=150217
434         rdar://problem/23128791
435
436         Reviewed by Michael Saboff.
437
438         Change how we access array buffer views so that we don't fire the barrier slow path, and
439         don't mask off the spaceBits, if the view is not FastTypedArray. That's because in that case
440         m_vector could be misaligned and so have meaningful non-space data in the spaceBits. Also in
441         that case, m_vector does not point into copied space.
442
443         * dfg/DFGSpeculativeJIT.cpp:
444         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
445         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
446         * ftl/FTLLowerDFGToLLVM.cpp:
447         (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorWithBarrier):
448         (JSC::FTL::DFG::LowerDFGToLLVM::copyBarrier):
449         (JSC::FTL::DFG::LowerDFGToLLVM::isInToSpace):
450         (JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyReadOnly):
451         (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorReadOnly):
452         (JSC::FTL::DFG::LowerDFGToLLVM::removeSpaceBits):
453         (JSC::FTL::DFG::LowerDFGToLLVM::isFastTypedArray):
454         (JSC::FTL::DFG::LowerDFGToLLVM::baseIndex):
455         * heap/CopyBarrier.h:
456         (JSC::CopyBarrierBase::getWithoutBarrier):
457         (JSC::CopyBarrierBase::getPredicated):
458         (JSC::CopyBarrierBase::get):
459         (JSC::CopyBarrierBase::copyState):
460         (JSC::CopyBarrier::get):
461         (JSC::CopyBarrier::getPredicated):
462         (JSC::CopyBarrier::set):
463         * heap/Heap.cpp:
464         (JSC::Heap::copyBarrier):
465         * jit/AssemblyHelpers.cpp:
466         (JSC::AssemblyHelpers::branchIfNotType):
467         (JSC::AssemblyHelpers::branchIfFastTypedArray):
468         (JSC::AssemblyHelpers::branchIfNotFastTypedArray):
469         (JSC::AssemblyHelpers::loadTypedArrayVector):
470         (JSC::AssemblyHelpers::purifyNaN):
471         * jit/AssemblyHelpers.h:
472         (JSC::AssemblyHelpers::branchStructure):
473         (JSC::AssemblyHelpers::branchIfToSpace):
474         (JSC::AssemblyHelpers::branchIfNotToSpace):
475         (JSC::AssemblyHelpers::removeSpaceBits):
476         (JSC::AssemblyHelpers::addressForByteOffset):
477         * jit/JITPropertyAccess.cpp:
478         (JSC::JIT::emitIntTypedArrayGetByVal):
479         (JSC::JIT::emitFloatTypedArrayGetByVal):
480         (JSC::JIT::emitIntTypedArrayPutByVal):
481         (JSC::JIT::emitFloatTypedArrayPutByVal):
482         * runtime/JSArrayBufferView.h:
483         (JSC::JSArrayBufferView::vector):
484         (JSC::JSArrayBufferView::length):
485         * runtime/JSArrayBufferViewInlines.h:
486         (JSC::JSArrayBufferView::byteOffset):
487         * runtime/JSGenericTypedArrayView.h:
488         (JSC::JSGenericTypedArrayView::typedVector):
489         * runtime/JSGenericTypedArrayViewInlines.h:
490         (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore):
491         (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
492         * tests/stress/misaligned-int8-view-byte-offset.js: Added.
493         * tests/stress/misaligned-int8-view-read.js: Added.
494         * tests/stress/misaligned-int8-view-write.js: Added.
495
496 2015-10-16  Keith Miller  <keith_miller@apple.com>
497
498         Unreviewed. Build fix for 191215.
499
500         * jit/IntrinsicEmitter.cpp:
501
502 2015-10-16  Keith Miller  <keith@Keiths-MacBook-Pro-5.local>
503
504         Add Intrinsic Getters and use them to fix performance on the getters of TypedArray properties.
505         https://bugs.webkit.org/show_bug.cgi?id=149687
506
507         Reviewed by Geoffrey Garen.
508
509         Add the ability to create intrinsic getters in both the inline cache and the DFG/FTL. When the
510         getter fetched by a GetById has an intrinsic we know about we add a new intrinsic access case.
511         Once we get to the DFG, we observe that the access case was an intrinsic and add an appropriate
512         GetByIdVariant. We then parse the intrinsic into an appropriate DFG node.
513
514         The first intrinsics are the new TypedArray prototype getters length, byteLength, and byteOffset.
515
516         * CMakeLists.txt:
517         * JavaScriptCore.xcodeproj/project.pbxproj:
518         * bytecode/GetByIdStatus.cpp:
519         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
520         (JSC::GetByIdStatus::computeFor):
521         * bytecode/GetByIdVariant.cpp:
522         (JSC::GetByIdVariant::GetByIdVariant):
523         (JSC::GetByIdVariant::operator=):
524         (JSC::GetByIdVariant::canMergeIntrinsicStructures):
525         (JSC::GetByIdVariant::attemptToMerge):
526         (JSC::GetByIdVariant::dumpInContext):
527         * bytecode/GetByIdVariant.h:
528         (JSC::GetByIdVariant::intrinsicFunction):
529         (JSC::GetByIdVariant::intrinsic):
530         (JSC::GetByIdVariant::callLinkStatus): Deleted.
531         * bytecode/PolymorphicAccess.cpp:
532         (JSC::AccessGenerationState::addWatchpoint):
533         (JSC::AccessGenerationState::restoreScratch):
534         (JSC::AccessGenerationState::succeed):
535         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
536         (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
537         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
538         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
539         (JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
540         (JSC::AccessGenerationState::originalExceptionHandler):
541         (JSC::AccessGenerationState::originalCallSiteIndex):
542         (JSC::AccessCase::getIntrinsic):
543         (JSC::AccessCase::clone):
544         (JSC::AccessCase::visitWeak):
545         (JSC::AccessCase::generate):
546         (WTF::printInternal):
547         (JSC::AccessCase::AccessCase): Deleted.
548         (JSC::AccessCase::get): Deleted.
549         (JSC::AccessCase::replace): Deleted.
550         (JSC::AccessCase::transition): Deleted.
551         * bytecode/PolymorphicAccess.h:
552         (JSC::AccessCase::isGet):
553         (JSC::AccessCase::isPut):
554         (JSC::AccessCase::isIn):
555         (JSC::AccessCase::intrinsicFunction):
556         (JSC::AccessCase::intrinsic):
557         (JSC::AccessGenerationState::AccessGenerationState):
558         (JSC::AccessGenerationState::liveRegistersForCall):
559         (JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
560         (JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation):
561         (JSC::AccessGenerationState::needsToRestoreRegistersIfException):
562         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
563         * bytecode/PutByIdVariant.h:
564         (JSC::PutByIdVariant::intrinsic):
565         * dfg/DFGAbstractInterpreterInlines.h:
566         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
567         * dfg/DFGArrayMode.cpp:
568         (JSC::DFG::ArrayMode::alreadyChecked):
569         (JSC::DFG::arrayTypeToString):
570         (JSC::DFG::toTypedArrayType):
571         (JSC::DFG::refineTypedArrayType):
572         (JSC::DFG::permitsBoundsCheckLowering):
573         * dfg/DFGArrayMode.h:
574         (JSC::DFG::ArrayMode::supportsLength):
575         (JSC::DFG::ArrayMode::isSomeTypedArrayView):
576         * dfg/DFGByteCodeParser.cpp:
577         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
578         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
579         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
580         (JSC::DFG::ByteCodeParser::load):
581         (JSC::DFG::ByteCodeParser::handleGetById):
582         (JSC::DFG::ByteCodeParser::presenceLike): Deleted.
583         (JSC::DFG::ByteCodeParser::store): Deleted.
584         * dfg/DFGClobberize.h:
585         (JSC::DFG::clobberize):
586         * dfg/DFGFixupPhase.cpp:
587         (JSC::DFG::FixupPhase::fixupNode):
588         (JSC::DFG::FixupPhase::convertToGetArrayLength): Deleted.
589         (JSC::DFG::FixupPhase::prependGetArrayLength): Deleted.
590         (JSC::DFG::FixupPhase::fixupChecksInBlock): Deleted.
591         * dfg/DFGGraph.cpp:
592         (JSC::DFG::Graph::tryGetFoldableView):
593         * dfg/DFGPredictionPropagationPhase.cpp:
594         (JSC::DFG::PredictionPropagationPhase::propagate):
595         * dfg/DFGSpeculativeJIT.cpp:
596         (JSC::DFG::SpeculativeJIT::checkArray):
597         (JSC::DFG::SpeculativeJIT::compileGetArrayLength):
598         * ftl/FTLCapabilities.cpp:
599         (JSC::FTL::canCompile):
600         * ftl/FTLLowerDFGToLLVM.cpp:
601         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetArrayLength):
602         * jit/IntrinsicEmitter.cpp: Added.
603         (JSC::AccessCase::canEmitIntrinsicGetter):
604         (JSC::AccessCase::emitIntrinsicGetter):
605         * jit/Repatch.cpp:
606         (JSC::tryCacheGetByID):
607         * runtime/Intrinsic.h:
608         * runtime/JSArrayBufferView.cpp:
609         (JSC::JSArrayBufferView::put):
610         (JSC::JSArrayBufferView::defineOwnProperty):
611         (JSC::JSArrayBufferView::deleteProperty):
612         (JSC::JSArrayBufferView::getOwnNonIndexPropertyNames):
613         (JSC::JSArrayBufferView::getOwnPropertySlot): Deleted.
614         (JSC::JSArrayBufferView::finalize): Deleted.
615         * runtime/JSDataView.cpp:
616         (JSC::JSDataView::getOwnPropertySlot):
617         (JSC::JSDataView::put):
618         (JSC::JSDataView::defineOwnProperty):
619         (JSC::JSDataView::deleteProperty):
620         (JSC::JSDataView::getOwnNonIndexPropertyNames):
621         * runtime/JSDataView.h:
622         * runtime/JSFunction.h:
623         * runtime/JSFunctionInlines.h:
624         (JSC::JSFunction::intrinsic):
625         * runtime/JSGenericTypedArrayView.h:
626         * runtime/JSGenericTypedArrayViewInlines.h:
627         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
628         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
629         (JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
630         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex): Deleted.
631         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Deleted.
632         * runtime/JSObject.cpp:
633         (JSC::JSObject::putDirectNativeIntrinsicGetter):
634         * runtime/JSObject.h:
635         * runtime/JSTypedArrayViewPrototype.cpp:
636         (JSC::JSTypedArrayViewPrototype::finishCreation):
637         * tests/stress/typedarray-add-property-to-base-object.js: Added.
638         (body.foo):
639         (body):
640         * tests/stress/typedarray-bad-getter.js: Added.
641         (body.foo):
642         (body.get Bar):
643         (body):
644         * tests/stress/typedarray-getter-on-self.js: Added.
645         (body.foo):
646         (body.bar):
647         (body.baz):
648         (body.get for):
649         (body):
650         * tests/stress/typedarray-intrinsic-getters-change-prototype.js: Added.
651         (body.foo):
652         (body.bar):
653         (body.baz):
654         (body):
655
656 2015-10-16  Keith Miller  <keith_miller@apple.com>
657
658         Fix some issues with TypedArrays
659         https://bugs.webkit.org/show_bug.cgi?id=150216
660
661         Reviewed by Geoffrey Garen.
662
663         This fixes a couple of issues:
664         1) The DFG had a separate case for creating new typedarrays in the dfg when the first argument is an object.
665            Since the code for creating a Typedarray in the dfg is almost the same as the code in Baseline/LLInt
666            the two cases have been merged.
667         2) If the length property on an object was unset then the construction could crash.
668         3) The TypedArray.prototype.set function and the TypedArray constructor should not call [[Get]] for the
669            length of the source object when the source object is a TypedArray.
670         4) The conditions that were used to decide if the iterator could be skipped were incorrect.
671            Instead of checking for have a bad time we should have checked the Indexing type did not allow for
672            indexed accessors.
673
674         * dfg/DFGOperations.cpp:
675         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
676         (JSC::constructGenericTypedArrayViewWithArguments):
677         (JSC::constructGenericTypedArrayView):
678         (JSC::constructGenericTypedArrayViewWithFirstArgument): Deleted.
679
680 2015-10-16  Anders Carlsson  <andersca@apple.com>
681
682         Fix Windows build.
683
684         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
685         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
686
687 2015-10-16  Michael Saboff  <msaboff@apple.com>
688
689         REGRESSION (r191175): Still crashing when clicking back button on netflix.com
690         https://bugs.webkit.org/show_bug.cgi?id=150251
691
692         Rubber stamped by Filip Pizlo.
693
694         Turning off Tail Calls and disabling tests until the crash is fixed.
695
696         * runtime/Options.h:
697         * tests/es6.yaml:
698         * tests/stress/dfg-tail-calls.js:
699         (nonInlinedTailCall.callee):
700         * tests/stress/mutual-tail-call-no-stack-overflow.js:
701         (shouldThrow):
702         * tests/stress/tail-call-in-inline-cache.js:
703         (tail):
704         * tests/stress/tail-call-no-stack-overflow.js:
705         (shouldThrow):
706         * tests/stress/tail-call-recognize.js:
707         (callerMustBeRun):
708         * tests/stress/tail-call-varargs-no-stack-overflow.js:
709         (shouldThrow):
710
711 2015-10-16  Mark Lam  <mark.lam@apple.com>
712
713         Add MacroAssembler::callProbe() for supporting lambda JIT probes.
714         https://bugs.webkit.org/show_bug.cgi?id=150186
715
716         Reviewed by Geoffrey Garen.
717
718         With callProbe(), we can now make probes that are lambdas.  For example, we can
719         now conveniently add probes like so: 
720
721             // When you know exactly which register you want to inspect:
722             jit.callProbe([] (MacroAssembler::ProbeContext* context) {
723                 intptr_t value = reinterpret_cast<intptr_t>(context->cpu.eax);
724                 dataLogF("eax %p\n", context->cpu.eax); // Inspect the register.
725                 ASSERT(value > 10); // Add test code for debugging.
726             });
727
728             // When you want to inspect whichever register the JIT allocated:
729             auto reg = op1.gpr();
730             jit.callProbe([reg] (MacroAssembler::ProbeContext* context) {
731                 intptr_t value = reinterpret_cast<intptr_t>(context->gpr(reg));
732                 dataLogF("reg %s: %ld\n", context->gprName(reg), value);
733                 ASSERT(value > 10);
734             });
735
736         callProbe() is only meant to be used for debugging sessions.  It is not
737         appropriate to use it in permanent code (even for debug builds).
738         This is because:
739         1. The probe mechanism saves and restores all (and I really mean "all")
740            registers, and is inherently slow.
741         2. callProbe() currently works by allocating (via new) a std::function to
742            guarantee that it is persisted for the duration that the JIT generated code is
743            live.  We don't currently delete it ever i.e. it leaks a bit of memory each
744            time the JIT generates code that contains such a lambda probe.
745
746         These limitations are acceptable for a debugging session (assuming you're not
747         debugging a memory leak), but not for deployment code.  If there's a need, we can
748         plug that leak in another patch.
749
750         * assembler/AbstractMacroAssembler.h:
751         (JSC::AbstractMacroAssembler::CPUState::fpr):
752         - Removed an unnecessary empty line.
753         (JSC::AbstractMacroAssembler::ProbeContext::gpr):
754         (JSC::AbstractMacroAssembler::ProbeContext::fpr):
755         (JSC::AbstractMacroAssembler::ProbeContext::gprName):
756         (JSC::AbstractMacroAssembler::ProbeContext::fprName):
757         - Added some convenience functions that will make using the probe mechanism
758           easier.
759
760         * assembler/MacroAssembler.cpp:
761         (JSC::StdFunctionData::StdFunctionData):
762         (JSC::stdFunctionCallback):
763         (JSC::MacroAssembler::callProbe):
764         * assembler/MacroAssembler.h:
765
766 2015-10-16  Andreas Kling  <akling@apple.com>
767
768         Remove unused StructureRareData::m_cachedGenericPropertyNameEnumerator.
769         <https://webkit.org/b/150244>
770
771         Reviewed by Geoffrey Garen.
772
773         Remove an unused field from StructureRareData.
774
775         * runtime/StructureRareData.cpp:
776         (JSC::StructureRareData::visitChildren): Deleted.
777         * runtime/StructureRareData.h:
778
779 2015-10-16  Keith Miller  <keith_miller@apple.com>
780
781         Unreviewed, rolling out r191190.
782
783         Patch needs some design changes.
784
785         Reverted changeset:
786
787         "Fix some issues with TypedArrays"
788         https://bugs.webkit.org/show_bug.cgi?id=150216
789         http://trac.webkit.org/changeset/191190
790
791 2015-10-16  Mark Lam  <mark.lam@apple.com>
792
793         Move all the probe trampolines into their respective MacroAssembler files.
794         https://bugs.webkit.org/show_bug.cgi?id=150239
795
796         Reviewed by Saam Barati.
797
798         This patch does not introduce any behavior changes.  It only moves the
799         ctiMasmProbeTrampoline implementations from the respective JITStubs<CPU>.h
800         files to the corresponding MacroAssembler<CPU>.cpp files. 
801
802         I also had to make some minor changes to get the code to build after this move:
803         1. Added #include <wtf/InlineASM.h> in the MacroAssembler<CPU>.cpp files
804            because the ctiMasmProbeTrampoline is an inline assembly blob.
805         2. In the moved code, convert MacroAssembler:: qualifiers to the CPU specific
806            MacroAssembler equivalent.  The referenced entities were always defined in
807            the CPU specific MacroAssembler anyway, and indirectly referenced through
808            the generic MacroAssembler.
809
810         With this, we can get rid of all the JITStubs<CPU>.cpp files.  There is one
811         exception: JITStubsMSVC64.asm.  However, that one is unrelated to the probe
812         mechanism.  So, I'll leave it as is.
813
814         We can also remove JITStubs.cpp and JITStubs.h which are now empty except for
815         some stale unused code.
816
817         This patch has been build tested for x86, x86_64, armv7, and arm64.
818
819         * CMakeLists.txt:
820         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
821         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
822         * JavaScriptCore.xcodeproj/project.pbxproj:
823         * assembler/MacroAssemblerARM.cpp:
824         (JSC::MacroAssemblerARM::probe):
825         * assembler/MacroAssemblerARM64.cpp:
826         (JSC::arm64ProbeTrampoline):
827         (JSC::MacroAssemblerARM64::probe):
828         * assembler/MacroAssemblerARMv7.cpp:
829         (JSC::MacroAssemblerARMv7::probe):
830         * assembler/MacroAssemblerX86Common.cpp:
831         * bytecode/CodeBlock.cpp:
832         * ftl/FTLCompile.cpp:
833         * ftl/FTLLink.cpp:
834         * jit/JITArithmetic.cpp:
835         * jit/JITArithmetic32_64.cpp:
836         * jit/JITCode.h:
837         * jit/JITExceptions.cpp:
838         * jit/JITStubs.cpp: Removed.
839         * jit/JITStubs.h: Removed.
840         * jit/JITStubsARM.h: Removed.
841         * jit/JITStubsARM64.h: Removed.
842         * jit/JITStubsARMv7.h: Removed.
843         * jit/JITStubsX86.h: Removed.
844         * jit/JITStubsX86Common.h: Removed.
845         * jit/JITStubsX86_64.h: Removed.
846         * jit/JSInterfaceJIT.h:
847         * llint/LLIntOffsetsExtractor.cpp:
848         * runtime/CommonSlowPaths.cpp:
849
850 2015-10-16  Keith Miller  <keith_miller@apple.com>
851
852         Fix some issues with TypedArrays
853         https://bugs.webkit.org/show_bug.cgi?id=150216
854
855         Reviewed by Michael Saboff.
856
857         This fixes a couple of issues:
858         1) The DFG had a separate case for creating new typedarrays in the dfg when the first argument is an object.
859            Since the code for creating a Typedarray in the dfg is almost the same as the code in Baseline/LLInt
860            the two cases have been merged.
861         2) If the length property on an object was unset then the construction could crash.
862         3) The TypedArray.prototype.set function and the TypedArray constructor should not call [[Get]] for the
863            length of the source object when the source object is a TypedArray.
864         4) The conditions that were used to decide if the iterator could be skipped were incorrect.
865            Instead of checking for have a bad time we should have checked the Indexing type did not allow for
866            indexed accessors.
867
868         * dfg/DFGOperations.cpp:
869         (JSC::DFG::newTypedArrayWithOneArgument): Deleted.
870         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
871         (JSC::constructGenericTypedArrayViewFromIterator):
872         (JSC::constructGenericTypedArrayViewWithFirstArgument):
873         (JSC::constructGenericTypedArrayView):
874         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
875         (JSC::genericTypedArrayViewProtoFuncSet):
876         * tests/stress/typedarray-construct-iterator.js: Added.
877         (iterator.return.next):
878         (iterator):
879         (body):
880
881 2015-10-15  Michael Saboff  <msaboff@apple.com>
882
883         REGRESSION (r190289): Repro crash clicking back button on netflix.com
884         https://bugs.webkit.org/show_bug.cgi?id=150220
885
886         Reviewed by Geoffrey Garen.
887
888         Since constructors check for a valid new "this" object and return it, we can't make
889         a tail call to another function from within a constructor.
890
891         Re-enabled the tail calls and the related tail call tests.
892
893         Did some other miscellaneous clean up in the tail call code as part of the debugging.
894
895         * bytecompiler/BytecodeGenerator.cpp:
896         (JSC::BytecodeGenerator::BytecodeGenerator):
897         * ftl/FTLLowerDFGToLLVM.cpp:
898         (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
899         * interpreter/Interpreter.h:
900         (JSC::calleeFrameForVarargs):
901         * runtime/Options.h:
902         * tests/es6.yaml:
903         * tests/stress/dfg-tail-calls.js:
904         (nonInlinedTailCall.callee):
905         * tests/stress/mutual-tail-call-no-stack-overflow.js:
906         (shouldThrow):
907         * tests/stress/tail-call-in-inline-cache.js:
908         (tail):
909         * tests/stress/tail-call-no-stack-overflow.js:
910         (shouldThrow):
911         * tests/stress/tail-call-recognize.js:
912         (callerMustBeRun):
913         * tests/stress/tail-call-varargs-no-stack-overflow.js:
914         (shouldThrow):
915
916 2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>
917
918         Unreviewed. Attempted EFL build fix 2 after r191159.
919
920         * PlatformEfl.cmake:
921
922 2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>
923
924         Unreviewed. Attempted EFL build fix after r191159.
925
926         * PlatformEfl.cmake:
927
928 2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>
929
930         Unreviewed. Build fix after r191160.
931
932         * inspector/agents/InspectorHeapAgent.cpp:
933         (Inspector::InspectorHeapAgent::didGarbageCollect):
934
935 2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>
936
937         Unreviewed. Revert part of r191159 which caused ASSERTs.
938
939         A review comment suggested using WeakPtr. It is not suitable
940         here and causes ASSERTs across threads. Will address separately.
941
942         * inspector/agents/InspectorHeapAgent.h:
943         * inspector/agents/InspectorHeapAgent.cpp:
944         (Inspector::InspectorHeapAgent::didGarbageCollect):
945         (Inspector::InspectorHeapAgent::InspectorHeapAgent): Deleted.
946
947 2015-10-14  Joseph Pecoraro  <pecoraro@apple.com>
948
949         Web Inspector: Include Garbage Collection Event in Timeline
950         https://bugs.webkit.org/show_bug.cgi?id=142510
951
952         Reviewed by Geoffrey Garen and Brian Burg.
953
954         * CMakeLists.txt:
955         * DerivedSources.make:
956         * JavaScriptCore.xcodeproj/project.pbxproj:
957         Include new files in the build.
958
959         * heap/HeapObserver.h:
960         (JSC::HeapObserver::~HeapObserver):
961         * heap/Heap.cpp:
962         (JSC::Heap::willStartCollection):
963         (JSC::Heap::didFinishCollection):
964         * heap/Heap.h:
965         (JSC::Heap::addObserver):
966         (JSC::Heap::removeObserver):
967         Allow observers on heap to add hooks for starting / ending garbage collection.
968
969         * inspector/InspectorEnvironment.h:
970         * inspector/JSGlobalObjectInspectorController.cpp:
971         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
972         (Inspector::JSGlobalObjectInspectorController::vm):
973         * inspector/JSGlobalObjectInspectorController.h:
974         Access the VM through the InspectorEnvironment as it won't change.
975
976         * inspector/agents/InspectorHeapAgent.cpp: Added.
977         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
978         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
979         (Inspector::InspectorHeapAgent::didCreateFrontendAndBackend):
980         (Inspector::InspectorHeapAgent::willDestroyFrontendAndBackend):
981         (Inspector::InspectorHeapAgent::enable):
982         (Inspector::InspectorHeapAgent::disable):
983         (Inspector::InspectorHeapAgent::gc):
984         (Inspector::protocolTypeForHeapOperation):
985         (Inspector::InspectorHeapAgent::willGarbageCollect):
986         (Inspector::InspectorHeapAgent::didGarbageCollect):
987         * inspector/agents/InspectorHeapAgent.h: Added.
988         * inspector/protocol/Heap.json: Added.
989         New domain and agent to handle tasks related to the JavaScriptCore heap.
990
991 2015-10-15  Commit Queue  <commit-queue@webkit.org>
992
993         Unreviewed, rolling out r191135.
994         https://bugs.webkit.org/show_bug.cgi?id=150197
995
996         This patch causes 50+ LayoutTest crashes related to the
997         inspector (Requested by ryanhaddad on #webkit).
998
999         Reverted changeset:
1000
1001         "Web Inspector: JavaScriptCore should parse sourceURL and
1002         sourceMappingURL directives"
1003         https://bugs.webkit.org/show_bug.cgi?id=150096
1004         http://trac.webkit.org/changeset/191135
1005
1006 2015-10-15  Geoffrey Garen  <ggaren@apple.com>
1007
1008         Unreviewed, rolling out r191003.
1009         https://bugs.webkit.org/show_bug.cgi?id=150042
1010
1011         We're seeing some crashes in GC beneath speculationFromCell. Maybe this
1012         patch caused them?
1013
1014         Reverted changeset:
1015
1016         CodeBlock write barriers should be precise
1017         https://bugs.webkit.org/show_bug.cgi?id=150042
1018         http://trac.webkit.org/changeset/191003
1019
1020 2015-10-15  Joseph Pecoraro  <pecoraro@apple.com>
1021
1022         Web Inspector: JavaScriptCore should parse sourceURL and sourceMappingURL directives
1023         https://bugs.webkit.org/show_bug.cgi?id=150096
1024
1025         Reviewed by Geoffrey Garen.
1026
1027         * inspector/ContentSearchUtilities.cpp:
1028         (Inspector::ContentSearchUtilities::scriptCommentPattern): Deleted.
1029         (Inspector::ContentSearchUtilities::findScriptSourceURL): Deleted.
1030         (Inspector::ContentSearchUtilities::findScriptSourceMapURL): Deleted.
1031         * inspector/ContentSearchUtilities.h:
1032         No longer need to search script content.
1033
1034         * inspector/ScriptDebugServer.cpp:
1035         (Inspector::ScriptDebugServer::dispatchDidParseSource):
1036         Carry over the sourceURL and sourceMappingURL from the SourceProvider.
1037
1038         * inspector/agents/InspectorDebuggerAgent.cpp:
1039         (Inspector::InspectorDebuggerAgent::sourceMapURLForScript):
1040         (Inspector::InspectorDebuggerAgent::didParseSource):
1041         No longer do content searching.
1042
1043         * parser/Lexer.cpp:
1044         (JSC::Lexer<T>::setCode):
1045         (JSC::Lexer<T>::skipWhitespace):
1046         (JSC::Lexer<T>::parseCommentDirective):
1047         (JSC::Lexer<T>::parseCommentDirectiveValue):
1048         (JSC::Lexer<T>::consume):
1049         (JSC::Lexer<T>::lex):
1050         * parser/Lexer.h:
1051         (JSC::Lexer::sourceURL):
1052         (JSC::Lexer::sourceMappingURL):
1053         (JSC::Lexer::sourceProvider): Deleted.
1054         Give lexer the ability to detect script comment directives.
1055         This just consumes characters in single line comments and
1056         ultimately sets the sourceURL or sourceMappingURL found.
1057
1058         * parser/Parser.h:
1059         (JSC::Parser<LexerType>::parse):
1060         * parser/SourceProvider.h:
1061         (JSC::SourceProvider::url):
1062         (JSC::SourceProvider::sourceURL):
1063         (JSC::SourceProvider::sourceMappingURL):
1064         (JSC::SourceProvider::setSourceURL):
1065         (JSC::SourceProvider::setSourceMappingURL):
1066         After parsing a script, update the Source Provider with the
1067         value of directives that may have been found in the script.
1068
1069 2015-10-15  Filip Pizlo  <fpizlo@apple.com>
1070
1071         InferredTypeTable should ref its keys
1072         https://bugs.webkit.org/show_bug.cgi?id=150138
1073         rdar://problem/23080555
1074
1075         Reviewed by Michael Saboff.
1076
1077         InferredTypeTable was incorrectly using a key hash traits that caused the underlying HashTable to
1078         store keys as UniquedStringImpl* rather than RefPtr<UniquedStringImpl>, even though the HashMap's
1079         nominal key type was RefPtr<UniquedStringImpl>. This arose because I copy-pasted the HashMap type
1080         instantiation from other places and then made random changes to adapt it to my needs, rather than
1081         actually thinking about what I was doing. The solution is to remove the key hash traits argument,
1082         since all it accomplishes is to produce this bug.
1083
1084         The way this bug manifested is probably best described in http://webkit.org/b/150008. After a while
1085         the InferredTypeTable would have dangling references to its strings, if some recompilation or other
1086         thing caused us to drop all other references to those strings. InferredTypeTable is particularly
1087         susceptible to this because it is designed to know about a superset of the property names that its
1088         client Structures know about. The debug assert would then happen when we rehashed the
1089         InferredTypeTable's HashMap, because we'd try to get the hashes of strings that were already
1090         deleted. AFAICT, we didn't have release crashes arising from those strings' memory being returned
1091         to the OS - but it's totally possible that this could have happened. So, we definitely should treat
1092         this bug as more than just a debug issue.
1093
1094         Interestingly, we could have also solved this problem by changing the hash function to use PtrHash.
1095         In all other ways, it's OK for InferredTypeTable to hold dangling references, since it uses the
1096         address of the UniquedStringImpl as a way to name an abstract heap. It's fine if the name of an
1097         abstract heap is a bogus memory address, and it's also fine if that name referred to an entirely
1098         different UniquedStringImpl at some point in the past. That's a nice benefit of any data structure
1099         that keys by abstract heap - if two of them get unified then it's no big deal. I've filed another
1100         bug, http://webkit.org/b/150137 about changing all of our UniquedStringImpl* hashing to use
1101         PtrHash.
1102
1103         * runtime/Identifier.h: Add a comment about http://webkit.org/b/150137.
1104         * runtime/InferredTypeTable.h: Fix the bug.
1105         * tests/stress/inferred-type-table-stale-identifiers.js: Added. I couldn't get this to cause a crash before my change, but it's an interesting test nonetheless.
1106
1107 2015-10-15  Mark Lam  <mark.lam@apple.com>
1108
1109         Add MASM_PROBE support for ARM64.
1110         https://bugs.webkit.org/show_bug.cgi?id=150128
1111
1112         Reviewed by Michael Saboff.
1113
1114         * JavaScriptCore.xcodeproj/project.pbxproj:
1115         * assembler/ARM64Assembler.h:
1116         - Convert the ARM64 registers enum list into a macro list so that we can use
1117           it elsewhere e.g. to declare fields in the probe CPUState.
1118           Also de-tabbed the contents of the ARM64Registers namespace since the enum
1119           list change touches almost all of it anyway. This reduces the amount of
1120           complaints from the style checker.
1121
1122         * assembler/AbstractMacroAssembler.h:
1123         (JSC::AbstractMacroAssembler::CPUState::registerName):
1124         (JSC::AbstractMacroAssembler::CPUState::registerValue):
1125         - Change CPUState methods to allow for registers ID that do not map to one of
1126           its fields. This is needed because ARM64's registers include aliases for some
1127           register names. The CPUState will not allocate separate storage for the
1128           aliases. 
1129
1130         * assembler/MacroAssemblerARM64.cpp: Added.
1131         (JSC::arm64ProbeTrampoline):
1132         - Unlike the probe mechanism for other CPUs, the ARM64 implementation does not
1133           allow the probe function to modify the sp and pc registers.  We insert this
1134           wrapper function between ctiMasmProbeTrampoline() and the user's probe function
1135           so that we can check if the user tried to modify sp and pc.  If so, we will
1136           print an error message so that we can alert the user that we don't support
1137           that on ARM64.
1138
1139           See the comment in ctiMasmProbeTrampoline() in JITStubsARM64.h for details
1140           on why we cannot support sp and pc modifications by the probe function.
1141
1142         (JSC::MacroAssemblerARM64::probe):
1143
1144         * assembler/MacroAssemblerARM64.h:
1145         (JSC::MacroAssemblerARM64::repatchCall):
1146         (JSC::MacroAssemblerARM64::makeBranch):
1147         * jit/JITStubs.cpp:
1148         * jit/JITStubsARM64.h: Added.
1149
1150 2015-10-15  Mark Lam  <mark.lam@apple.com>
1151
1152         Fix some typos in comments.
1153         https://bugs.webkit.org/show_bug.cgi?id=150181
1154
1155         Rubber stamped by Michael Saboff.
1156
1157         * jit/JITStubsARM.h:
1158         * jit/JITStubsARMv7.h:
1159
1160 2015-10-15  Mark Lam  <mark.lam@apple.com>
1161
1162         Refactoring: give the MASM probe CPUState methods shorter names.
1163         https://bugs.webkit.org/show_bug.cgi?id=150177
1164
1165         Reviewed by Michael Saboff.
1166
1167         The existing names are longer than they need to be.  Renaming them as follows:
1168             For GPR, registerName ==> gprName
1169             For GPR, registerValue ==> gpr
1170             For FPR, registerName ==> fprName
1171             For FPR, registerValue ==> fpr
1172
1173         * assembler/AbstractMacroAssembler.h:
1174         (JSC::AbstractMacroAssembler::CPUState::gprName):
1175         (JSC::AbstractMacroAssembler::CPUState::fprName):
1176         (JSC::AbstractMacroAssembler::CPUState::gpr):
1177         (JSC::AbstractMacroAssembler::CPUState::fpr):
1178         (JSC::AbstractMacroAssembler::CPUState::registerName): Deleted.
1179         (JSC::AbstractMacroAssembler::CPUState::registerValue): Deleted.
1180
1181         * assembler/MacroAssemblerPrinter.cpp:
1182         (JSC::printRegister):
1183         (JSC::printMemory):
1184         - Updated to use the new names.
1185
1186 2015-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
1187
1188         [ES6] Class expression should have lexical environment that has itself as an imutable binding
1189         https://bugs.webkit.org/show_bug.cgi?id=150089
1190
1191         Reviewed by Geoffrey Garen.
1192
1193         According to ES6 spec, class expression has its own lexical environment that holds itself
1194         as an immutable binding[1] (section 14.5.14 step 2, 3, 4, 23)
1195
1196         As a result, even if the binding declared in the outer scope is overridden, methods inside
1197         class expression can refer its class by the class name.
1198
1199         [1]: http://ecma-international.org/ecma-262/6.0/#sec-runtime-semantics-classdefinitionevaluation
1200
1201         * bytecompiler/NodesCodegen.cpp:
1202         (JSC::ClassExprNode::emitBytecode):
1203         * parser/ASTBuilder.h:
1204         (JSC::ASTBuilder::createClassExpr):
1205         * parser/NodeConstructors.h:
1206         (JSC::ClassExprNode::ClassExprNode):
1207         * parser/Nodes.h:
1208         * parser/Parser.cpp:
1209         (JSC::Parser<LexerType>::parseClass):
1210         * parser/SyntaxChecker.h:
1211         (JSC::SyntaxChecker::createClassExpr):
1212         * tests/es6.yaml:
1213         * tests/stress/class-expression-generates-environment.js: Added.
1214         (shouldBe):
1215         (shouldThrow):
1216         (prototype.method):
1217         (staticMethod):
1218         (A.prototype.method):
1219         (A.staticMethod):
1220         (A):
1221         * tests/stress/class-expression-should-be-tdz-in-heritage.js: Added.
1222         (shouldThrow):
1223         (shouldThrow.A):
1224
1225 2015-10-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1226
1227         [ES6] Class method should not declare any variables to upper scope.
1228         https://bugs.webkit.org/show_bug.cgi?id=150115
1229
1230         Reviewed by Geoffrey Garen.
1231
1232         In the current implementation, class methods attempt to declare variables to an upper scope with their method names.
1233         But this is not specified behavior in the ES6 spec.
1234
1235         And as a result, previously, we attempted to declare variables with invalid identifiers.
1236         For example, `class A { 1() { } }` attempt to declare a variable with name `1`.
1237         This (declaring variables with incorrect names) is not allowed in the lexical environment.
1238         And it fires assertions in https://bugs.webkit.org/show_bug.cgi?id=150089.
1239
1240         * parser/Parser.cpp:
1241         (JSC::Parser<LexerType>::parseClass): Deleted.
1242         * tests/stress/class-method-does-not-declare-variable-to-upper-scope.js: Added.
1243         (shouldBe):
1244         (A.prototype.method):
1245         (A.staticMethod):
1246         (A):
1247
1248 2015-10-14  Joseph Pecoraro  <pecoraro@apple.com>
1249
1250         REGRESSION: Web Inspector hangs for many seconds when trying to reload page
1251         https://bugs.webkit.org/show_bug.cgi?id=150065
1252
1253         Reviewed by Mark Lam.
1254
1255         When debugging Web Pages, the same Debugger (PageScriptDebugServer) is
1256         attached to each of the different JSGlobalObjects on the page. This could
1257         mean multiple frames or isolated scripting contexts. Therefore we should
1258         only need to send sourceParsed events to the frontend for scripts within
1259         this new JSGlobalObject, not any JSGlobalObject that has this debugger.
1260
1261         * debugger/Debugger.cpp:
1262         (JSC::Debugger::attach):
1263         Only send sourceParsed events for Scripts in this JSGlobalObject.
1264
1265 2015-10-14  Joseph Pecoraro  <pecoraro@apple.com>
1266
1267         Remove unimplemented methods in CopiedSpace
1268         https://bugs.webkit.org/show_bug.cgi?id=150143
1269
1270         Reviewed by Andreas Kling.
1271
1272         * heap/CopiedSpace.h:
1273
1274 2015-10-14  Brent Fulgham  <bfulgham@apple.com>
1275
1276         [Win] Enforce launcher/library naming scheme
1277         https://bugs.webkit.org/show_bug.cgi?id=150124
1278
1279         Reviewed by Alex Christensen.
1280
1281         * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Look for
1282         {name}Lib.dll instead of {name}.dll.
1283         (wWinMain):
1284         * shell/PlatformWin.cmake: Add 'Lib' suffix to DLLs.
1285
1286 2015-10-14  Keith Miller  <keith_miller@apple.com>
1287
1288         ES6 Fix TypedArray constructors.
1289         https://bugs.webkit.org/show_bug.cgi?id=149975
1290
1291         Reviewed by Geoffrey Garen.
1292
1293         The ES6 spec requires that any object argument passed to a TypedArray constructor that is not a TypedArray
1294         and has an iterator should use the iterator to construct the TypedArray. To avoid performance regressions related
1295         to iterating we check if the iterator attached to the object points to the generic array iterator and length is a value.
1296         If so, we do not use the iterator since there should be no observable difference. Another other interesting note is
1297         that the ES6 spec has the of and from functions on a shared constructor between all the TypedArray constructors.
1298         When the TypedArray is constructed the expectation is to crawl the prototype chain of the this value
1299         passed to the function. If the function finds a known TypedArray constructor (Int32Array, Float64Array,...) then
1300         it creates a TypedArray of that type. This is implemented by adding a private function (@allocateTypedArray) to each
1301         of the constructors that can be called in order to construct the array. By using the private functions the JIT should
1302         hopefully be able to optimize this to a direct call.
1303
1304         * CMakeLists.txt:
1305         * JavaScriptCore.xcodeproj/project.pbxproj:
1306         * builtins/TypedArrayConstructor.js: Added.
1307         (of):
1308         (from):
1309         (allocateInt8Array):
1310         (allocateInt16Array):
1311         (allocateInt32Array):
1312         (allocateUint32Array):
1313         (allocateUint16Array):
1314         (allocateUint8Array):
1315         (allocateUint8ClampedArray):
1316         (allocateFloat32Array):
1317         (allocateFloat64Array):
1318         * runtime/CommonIdentifiers.h:
1319         * runtime/JSDataView.cpp:
1320         (JSC::JSDataView::setIndex):
1321         * runtime/JSDataView.h:
1322         * runtime/JSGenericTypedArrayView.h:
1323         (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
1324         * runtime/JSGenericTypedArrayViewConstructor.h:
1325         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1326         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
1327         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::create):
1328         (JSC::constructGenericTypedArrayViewFromIterator):
1329         (JSC::constructGenericTypedArrayView):
1330         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1331         (JSC::genericTypedArrayViewProtoFuncIndexOf):
1332         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
1333         * runtime/JSGlobalObject.cpp:
1334         (JSC::JSGlobalObject::init):
1335         * runtime/JSTypedArrayViewConstructor.cpp: Added.
1336         (JSC::JSTypedArrayViewConstructor::JSTypedArrayViewConstructor):
1337         (JSC::JSTypedArrayViewConstructor::finishCreation):
1338         (JSC::JSTypedArrayViewConstructor::create):
1339         (JSC::JSTypedArrayViewConstructor::createStructure):
1340         (JSC::constructTypedArrayView):
1341         (JSC::JSTypedArrayViewConstructor::getConstructData):
1342         (JSC::JSTypedArrayViewConstructor::getCallData):
1343         * runtime/JSTypedArrayViewConstructor.h: Copied from Source/JavaScriptCore/runtime/JSGenericTypedArrayViewConstructor.h.
1344         * runtime/JSTypedArrayViewPrototype.cpp:
1345         (JSC::JSTypedArrayViewPrototype::create):
1346         * tests/es6.yaml:
1347         * tests/stress/resources/typedarray-constructor-helper-functions.js: Added.
1348         (forEachTypedArray):
1349         (hasSameValues):
1350         (foo):
1351         (testConstructorFunction):
1352         (testConstructor):
1353         * tests/stress/typedarray-constructor.js: Added.
1354         (A):
1355         (iterator.return.next):
1356         (iterator):
1357         (obj.valueOf):
1358         (iterator2.return.next):
1359         (iterator2):
1360         * tests/stress/typedarray-from.js: Added.
1361         (even):
1362         (isBigEnoughAndException):
1363         * tests/stress/typedarray-of.js: Added.
1364
1365 2015-10-14  Mark Lam  <mark.lam@apple.com>
1366
1367         Rename some JSC option names to be more uniform.
1368         https://bugs.webkit.org/show_bug.cgi?id=150127
1369
1370         Reviewed by Geoffrey Garen.
1371
1372         Renaming JSC_enableXXX options to JSC_useXXX, and JSC_showXXX options to JSC_dumpXXX.
1373         Also will renaming a few other miscellaneous to options, to abide by this scheme.
1374
1375         Also renaming some functions to match the option names where relevant.
1376
1377         * API/tests/ExecutionTimeLimitTest.cpp:
1378         (testExecutionTimeLimit):
1379         * assembler/AbstractMacroAssembler.h:
1380         (JSC::optimizeForARMv7IDIVSupported):
1381         (JSC::optimizeForARM64):
1382         (JSC::optimizeForX86):
1383         * assembler/LinkBuffer.cpp:
1384         (JSC::shouldDumpDisassemblyFor):
1385         (JSC::LinkBuffer::finalizeCodeWithoutDisassembly):
1386         (JSC::shouldShowDisassemblyFor): Deleted.
1387         * assembler/LinkBuffer.h:
1388         * bytecode/CodeBlock.cpp:
1389         (JSC::CodeBlock::jettison):
1390         * bytecode/CodeBlockJettisoningWatchpoint.cpp:
1391         (JSC::CodeBlockJettisoningWatchpoint::fireInternal):
1392         * bytecompiler/BytecodeGenerator.cpp:
1393         (JSC::BytecodeGenerator::BytecodeGenerator):
1394         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
1395         (JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::fire):
1396         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
1397         (JSC::DFG::AdaptiveStructureWatchpoint::fireInternal):
1398         * dfg/DFGByteCodeParser.cpp:
1399         (JSC::DFG::ByteCodeParser::handleInlining):
1400         (JSC::DFG::ByteCodeParser::handleGetById):
1401         (JSC::DFG::ByteCodeParser::handlePutById):
1402         (JSC::DFG::ByteCodeParser::parse):
1403         * dfg/DFGCommon.h:
1404         (JSC::DFG::leastUpperBound):
1405         (JSC::DFG::shouldDumpDisassembly):
1406         (JSC::DFG::shouldShowDisassembly): Deleted.
1407         * dfg/DFGDriver.cpp:
1408         (JSC::DFG::compileImpl):
1409         * dfg/DFGJITCompiler.cpp:
1410         (JSC::DFG::JITCompiler::JITCompiler):
1411         (JSC::DFG::JITCompiler::disassemble):
1412         * dfg/DFGJumpReplacement.cpp:
1413         (JSC::DFG::JumpReplacement::fire):
1414         * dfg/DFGOSREntry.cpp:
1415         (JSC::DFG::prepareOSREntry):
1416         * dfg/DFGOSRExitCompiler.cpp:
1417         * dfg/DFGOSRExitFuzz.h:
1418         (JSC::DFG::doOSRExitFuzzing):
1419         * dfg/DFGPlan.cpp:
1420         (JSC::DFG::Plan::compileInThreadImpl):
1421         * dfg/DFGSpeculativeJIT.cpp:
1422         (JSC::DFG::SpeculativeJIT::compileArithSqrt):
1423         * dfg/DFGTierUpCheckInjectionPhase.cpp:
1424         (JSC::DFG::TierUpCheckInjectionPhase::run):
1425         * ftl/FTLCompile.cpp:
1426         (JSC::FTL::mmAllocateDataSection):
1427         * ftl/FTLJITCode.cpp:
1428         (JSC::FTL::JITCode::~JITCode):
1429         * ftl/FTLLowerDFGToLLVM.cpp:
1430         (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
1431         * ftl/FTLOSRExitCompiler.cpp:
1432         (JSC::FTL::compileStub):
1433         (JSC::FTL::compileFTLOSRExit):
1434         * ftl/FTLState.h:
1435         (JSC::FTL::verboseCompilationEnabled):
1436         (JSC::FTL::shouldDumpDisassembly):
1437         (JSC::FTL::shouldShowDisassembly): Deleted.
1438         * heap/Heap.cpp:
1439         (JSC::Heap::addToRememberedSet):
1440         (JSC::Heap::didFinishCollection):
1441         (JSC::Heap::shouldDoFullCollection):
1442         * heap/Heap.h:
1443         (JSC::Heap::isDeferred):
1444         (JSC::Heap::structureIDTable):
1445         * heap/HeapStatistics.cpp:
1446         (JSC::StorageStatistics::storageCapacity):
1447         (JSC::HeapStatistics::dumpObjectStatistics):
1448         (JSC::HeapStatistics::showObjectStatistics): Deleted.
1449         * heap/HeapStatistics.h:
1450         * interpreter/StackVisitor.cpp:
1451         (JSC::StackVisitor::Frame::createArguments):
1452         * jit/AssemblyHelpers.cpp:
1453         (JSC::AssemblyHelpers::callExceptionFuzz):
1454         * jit/ExecutableAllocationFuzz.cpp:
1455         (JSC::doExecutableAllocationFuzzing):
1456         * jit/ExecutableAllocationFuzz.h:
1457         (JSC::doExecutableAllocationFuzzingIfEnabled):
1458         * jit/JIT.cpp:
1459         (JSC::JIT::privateCompile):
1460         * jit/JITCode.cpp:
1461         (JSC::JITCodeWithCodeRef::~JITCodeWithCodeRef):
1462         * jit/PolymorphicCallStubRoutine.cpp:
1463         (JSC::PolymorphicCallNode::unlink):
1464         (JSC::PolymorphicCallNode::clearCallLinkInfo):
1465         (JSC::PolymorphicCallStubRoutine::PolymorphicCallStubRoutine):
1466         * jit/Repatch.cpp:
1467         (JSC::linkFor):
1468         (JSC::unlinkFor):
1469         (JSC::linkVirtualFor):
1470         * jsc.cpp:
1471         (functionEnableExceptionFuzz):
1472         (jscmain):
1473         * llvm/InitializeLLVM.cpp:
1474         (JSC::initializeLLVMImpl):
1475         * runtime/ExceptionFuzz.cpp:
1476         (JSC::doExceptionFuzzing):
1477         * runtime/ExceptionFuzz.h:
1478         (JSC::doExceptionFuzzingIfEnabled):
1479         * runtime/JSGlobalObject.cpp:
1480         (JSC::JSGlobalObject::init):
1481         * runtime/Options.cpp:
1482         (JSC::recomputeDependentOptions):
1483         (JSC::Options::initialize):
1484         (JSC::Options::dumpOptionsIfNeeded):
1485         (JSC::Options::setOption):
1486         (JSC::Options::dumpAllOptions):
1487         (JSC::Options::dumpAllOptionsInALine):
1488         (JSC::Options::dumpOption):
1489         * runtime/Options.h:
1490         * runtime/VM.cpp:
1491         (JSC::VM::VM):
1492         * runtime/VM.h:
1493         (JSC::VM::exceptionFuzzingBuffer):
1494         * runtime/WriteBarrierInlines.h:
1495         (JSC::WriteBarrierBase<T>::set):
1496         (JSC::WriteBarrierBase<Unknown>::set):
1497         * tests/executableAllocationFuzz.yaml:
1498         * tests/stress/arrowfunction-typeof.js:
1499         * tests/stress/disable-function-dot-arguments.js:
1500         (foo):
1501         * tests/stress/math-sqrt-basics-disable-architecture-specific-optimizations.js:
1502         (sqrtOnInteger):
1503         * tests/stress/regress-148564.js:
1504
1505 2015-10-14  Mark Lam  <mark.lam@apple.com>
1506
1507         Speculative build fix: the CallSiteIndex constructor is explicit and requires an uint32_t.
1508
1509         Not Reviewed.
1510
1511         * bytecode/CodeBlock.cpp:
1512         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
1513
1514 2015-10-14  Commit Queue  <commit-queue@webkit.org>
1515
1516         Unreviewed, rolling out r191030.
1517         https://bugs.webkit.org/show_bug.cgi?id=150116
1518
1519         caused js/class-syntax-method-names.html to crash on debug
1520         builds (Requested by alexchristensen_ on #webkit).
1521
1522         Reverted changeset:
1523
1524         "[ES6] Class expression should have lexical environment that
1525         has itself as an imutable binding"
1526         https://bugs.webkit.org/show_bug.cgi?id=150089
1527         http://trac.webkit.org/changeset/191030
1528
1529 2015-10-13  Yusuke Suzuki  <utatane.tea@gmail.com>
1530
1531         [ES6] Class expression should have lexical environment that has itself as an imutable binding
1532         https://bugs.webkit.org/show_bug.cgi?id=150089
1533
1534         Reviewed by Geoffrey Garen.
1535
1536         According to ES6 spec, class expression has its own lexical environment that holds itself
1537         as an immutable binding[1] (section 14.5.14 step 2, 3, 4, 23)
1538
1539         As a result, even if the binding declared in the outer scope is overridden, methods inside
1540         class expression can refer its class by the class name.
1541
1542         [1]: http://ecma-international.org/ecma-262/6.0/#sec-runtime-semantics-classdefinitionevaluation
1543
1544         * bytecompiler/NodesCodegen.cpp:
1545         (JSC::ClassExprNode::emitBytecode):
1546         * parser/ASTBuilder.h:
1547         (JSC::ASTBuilder::createClassExpr):
1548         * parser/NodeConstructors.h:
1549         (JSC::ClassExprNode::ClassExprNode):
1550         * parser/Nodes.h:
1551         * parser/Parser.cpp:
1552         (JSC::Parser<LexerType>::parseClass):
1553         * parser/SyntaxChecker.h:
1554         (JSC::SyntaxChecker::createClassExpr):
1555         * tests/es6.yaml:
1556         * tests/stress/class-expression-generates-environment.js: Added.
1557         (shouldBe):
1558         (shouldThrow):
1559         (prototype.method):
1560         (staticMethod):
1561         (A.prototype.method):
1562         (A.staticMethod):
1563         (A):
1564         * tests/stress/class-expression-should-be-tdz-in-heritage.js: Added.
1565         (shouldThrow):
1566         (shouldThrow.A):
1567
1568 2015-10-13  Saam barati  <sbarati@apple.com>
1569
1570         We were creating a GCAwareJITStubRoutineWithExceptionHandler when we didn't actually have an exception handler in the CodeBlock's exception handler table
1571         https://bugs.webkit.org/show_bug.cgi?id=150016
1572
1573         Reviewed by Geoffrey Garen.
1574
1575         There was a bug where we created a GCAwareJITStubRoutineWithExceptionHandler
1576         for inline caches that were custom setters/getters (but not JS getters/setters).
1577         This is wrong; we only create GCAwareJITStubRoutineWithExceptionHandler when we have
1578         an inline cache with a JS getter/setter call which causes the inline cache to add itself
1579         to the CodeBlock's exception handling table. The problem was that we created
1580         a GCAwareJITStubRoutineWithExceptionHandler that tried to remove itself from
1581         the exception handler table only to find out that it didn't have an entry in the table.
1582
1583         * bytecode/PolymorphicAccess.cpp:
1584         (JSC::PolymorphicAccess::regenerate):
1585
1586 2015-10-13  Joseph Pecoraro  <pecoraro@apple.com>
1587
1588         Simplify WeakBlock visit and reap phases
1589         https://bugs.webkit.org/show_bug.cgi?id=150045
1590
1591         Reviewed by Geoffrey Garen.
1592
1593         WeakBlock visiting and reaping both happen after MarkedBlock marking.
1594         All the MarkedBlocks we encounter should be either Marked or Retired.
1595
1596         * heap/MarkedBlock.h:
1597         (JSC::MarkedBlock::isMarkedOrRetired):
1598         * heap/WeakBlock.cpp:
1599         (JSC::WeakBlock::visit):
1600         (JSC::WeakBlock::reap):
1601         * heap/WeakBlock.h:
1602
1603 2015-10-12  Geoffrey Garen  <ggaren@apple.com>
1604
1605         CodeBlock write barriers should be precise
1606         https://bugs.webkit.org/show_bug.cgi?id=150042
1607
1608         Reviewed by Saam Barati.
1609
1610         CodeBlock performs lots of unnecessary write barriers. This wastes
1611         performance and makes the code a bit harder to follow, and it might mask
1612         important bugs. Now is a good time to unmask important bugs.
1613
1614         * bytecode/CodeBlock.h:
1615         (JSC::CodeBlockSet::mark): Don't write barrier all CodeBlocks on the
1616         stack. Only CodeBlocks that do value profiling need write barriers, and
1617         they do those themselves.
1618
1619         In steady state, when most of our CodeBlocks are old and FTL-compiled,
1620         and we're doing eden GC's, we should almost never visit a CodeBlock.
1621
1622         * dfg/DFGOSRExitCompilerCommon.cpp:
1623         (JSC::DFG::osrWriteBarrier):
1624         (JSC::DFG::adjustAndJumpToTarget): Don't write barrier all inlined
1625         CodeBlocks on exit. That's not necessary. Instead, write barrier the 
1626         CodeBlock(s) we will exit to, along with the one we will write a value
1627         profile to.
1628
1629 2015-10-13  Yusuke Suzuki  <utatane.tea@gmail.com>
1630
1631         REGRESSION: ASSERT (impl->isAtomic()) @ facebook.com
1632         https://bugs.webkit.org/show_bug.cgi?id=149965
1633
1634         Reviewed by Geoffrey Garen.
1635
1636         Edge filtering for CheckIdent ensures that a given value is either Symbol or StringIdent.
1637         However, this filtering is not applied to CheckIdent when propagating a constant value in
1638         the constant folding phase. As a result, it is not guaranteeed that a constant value
1639         propagated in constant folding is Symbol or StringIdent.
1640
1641         * dfg/DFGConstantFoldingPhase.cpp:
1642         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1643
1644 2015-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1645
1646         Unreviewed, register symbol structure to fix Debug build
1647         https://bugs.webkit.org/show_bug.cgi?id=149622
1648
1649         Since InferredTypes for String or Symbol claim that they don't have any structure,
1650         `registerInferredType` does not register the structure for Symbol.
1651         We take the similar way to String to fix this issue; Registering Symbol structure
1652         explicitly in DFGStructureRegisterationPhase. Because,
1653
1654         1. InferredType::structure is only allowed for ObjectWithStructure / ObjectWithStructureOrOther.
1655            It looks clear to me that only ObjectWithStructure has structure.
1656         2. Symbol is similar primitive value to String. So handling its structure in similar way to String is nice.
1657
1658         * dfg/DFGStructureRegistrationPhase.cpp:
1659         (JSC::DFG::StructureRegistrationPhase::run):
1660
1661 2015-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1662
1663         Iterator loops over key twice after delete
1664         https://bugs.webkit.org/show_bug.cgi?id=149811
1665
1666         Reviewed by Geoffrey Garen.
1667
1668         When an object is the dictionary mode, JSPropertyNameEnumerator collects property names through generic property name enumeration `getPropertyNames`.
1669         The result vector contains indexed property names. But in this case, `publicLength()` may not be 0.
1670         So without disabling indexed names enumeration phase explicitly, JSPropertyNameEnumerator produces indexed property names twice.
1671         One in indexed name enumeration phase, and another in generic property name enumeration phase.
1672         This patch disables indexed names enumeration by setting `indexedLength` to 0 when collecting names through generic property name enumeration.
1673
1674         * runtime/JSPropertyNameEnumerator.h:
1675         (JSC::propertyNameEnumerator):
1676         * tests/stress/property-name-enumerator-should-not-look-into-indexed-values-when-it-is-a-dictionary.js: Added.
1677         (shouldBe):
1678         (col2.of.Reflect.enumerate):
1679
1680 2015-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
1681
1682         Introduce Symbol type for property type inference
1683         https://bugs.webkit.org/show_bug.cgi?id=149622
1684
1685         Reviewed by Geoffrey Garen.
1686
1687         This patch introduces Symbol type into property type inference.
1688         One of the use cases of ES6 Symbol is enum value. In this case,
1689         we may hold different symbols as the same property of the same structure.
1690         Current property type inference does not support Symbol type, so in the
1691         above case, the property will be inferred as Top type.
1692
1693         * bytecode/PutByIdFlags.h:
1694         * dfg/DFGAbstractValue.cpp:
1695         (JSC::DFG::AbstractValue::set):
1696         * dfg/DFGInferredTypeCheck.cpp:
1697         (JSC::DFG::insertInferredTypeCheck):
1698         * ftl/FTLLowerDFGToLLVM.cpp:
1699         (JSC::FTL::DFG::LowerDFGToLLVM::checkInferredType):
1700         * jit/AssemblyHelpers.cpp:
1701         (JSC::AssemblyHelpers::branchIfNotType):
1702         * llint/LLIntData.cpp:
1703         (JSC::LLInt::Data::performAssertions):
1704         * llint/LowLevelInterpreter.asm:
1705         * llint/LowLevelInterpreter32_64.asm:
1706         * llint/LowLevelInterpreter64.asm:
1707         * runtime/InferredType.cpp:
1708         (JSC::InferredType::kindForFlags):
1709         (JSC::InferredType::Descriptor::forValue):
1710         (JSC::InferredType::Descriptor::putByIdFlags):
1711         (JSC::InferredType::Descriptor::merge):
1712         (WTF::printInternal):
1713         * runtime/InferredType.h:
1714         * tests/stress/prop-type-symbol-then-object.js: Added.
1715         (foo):
1716         (bar):
1717         (toString):
1718         * tests/stress/prop-type-symbol-then-string.js: Added.
1719         (foo):
1720         (bar):
1721
1722 2015-10-12  Joseph Pecoraro  <pecoraro@apple.com>
1723
1724         Web Inspector: Rebaseline Inspector generator tests and make better use of RWIProtocol constant
1725         https://bugs.webkit.org/show_bug.cgi?id=150044
1726
1727         Reviewed by Brian Burg.
1728
1729         * inspector/scripts/codegen/generate_objc_configuration_header.py:
1730         (ObjCConfigurationHeaderGenerator.generate_output):
1731         (ObjCConfigurationHeaderGenerator._generate_configuration_interface_for_domains):
1732         * inspector/scripts/codegen/generate_objc_configuration_implementation.py:
1733         (ObjCBackendDispatcherImplementationGenerator._generate_configuration_implementation_for_domains):
1734         * inspector/scripts/codegen/generate_objc_header.py:
1735         (ObjCHeaderGenerator.generate_output):
1736         * inspector/scripts/codegen/generate_objc_internal_header.py:
1737         (ObjCInternalHeaderGenerator.generate_output):
1738         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
1739         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
1740         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
1741         * inspector/scripts/tests/expected/enum-values.json-result:
1742         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
1743         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
1744         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
1745         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
1746         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
1747         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
1748         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
1749         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
1750         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
1751
1752 2015-10-12  Myles C. Maxfield  <mmaxfield@apple.com>
1753
1754         Unreviewed build fix
1755
1756         * runtime/JSObject.cpp:
1757         (JSC::JSObject::reallocateAndShrinkButterfly):
1758
1759 2015-10-08  Filip Pizlo  <fpizlo@apple.com>
1760
1761         GC should have a Baker barrier for concurrent copying
1762         https://bugs.webkit.org/show_bug.cgi?id=149852
1763
1764         Reviewed by Geoffrey Garen.
1765
1766         This adds a Baker-style read barrier [1] to copied space accesses. This barrier incurs some
1767         overhead (0%-2% depending on benchmark suite), but what it buys is the ability to make the GC copy
1768         phase concurrent.
1769
1770         The barrier relies on copied space pointers having two "space bits" in the low pointer bits. The
1771         space bits indicate whether the backing store is being copied right now or not, and if it is being
1772         copied, what stage of copying it's in. Two barrier variants are supported:
1773
1774         Read only barrier: if you load a backing store and immediately load from it without doing anything
1775         else, you can just mask off the bits. In the worst case, you'll get the old backing store while
1776         some copying thread is already allocating and populating the new version of the backing store. But
1777         in that case, forwarding to the new backing store will not enable you to load a more up-to-date
1778         value from the backing store. So, just masking the bits is enough. The read-only barrier is only
1779         used in ICs where we know that we are only reading, and opportunistically within the DFG and FTL
1780         thanks to the CopyBarrierOptimizationPhase. We never explicitly emit a read-only barrier in those
1781         compilers; instead the phase will turn a GetButterfly into GetButterflyReadOnly if it proves that a
1782         bunch of requirements are met.
1783
1784         Normal barrier: if the space bits are non-zero, call a slow path. The slow path will either do
1785         nothing (if the copy phase hasn't started yet), or it will copy the backing store and update the
1786         pointer (if the copy phase hasn't gotten around to copying this particular backing store), or it
1787         will wait for the copying thread to finish (if some thread is copying this backing store right
1788         now), or it will do nothing (if by the time we called into the slow path the backing store was
1789         already copied). This is just like Baker's CAR/CDR barrier, but with a lock thrown in to handle
1790         concurrent execution.
1791
1792         This is a 1% slow-down on SunSpider, a 1.5% slow-down on Octane, a 1.5% slow-down on Kraken, and a
1793         0% slow-down on AsmBench. Note that the Octane slow-down is excluding the SplayLatency benchmark.
1794         That benchmark will eventually speed up a lot once we finish doing all of this stuff. Probably, the
1795         JetStream splay-latency will see an even larger speed-up, since our version of the latency tests do
1796         a better job of punishing bad worst-case behavior.
1797
1798         [1] http://dspace.mit.edu/bitstream/handle/1721.1/41976/AI_WP_139.pdf, look for the CAR and CDR
1799         procedures on page 9.
1800
1801         * CMakeLists.txt:
1802         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1803         * JavaScriptCore.xcodeproj/project.pbxproj:
1804         * bytecode/PolymorphicAccess.cpp:
1805         (JSC::AccessCase::generate):
1806         * dfg/DFGAbstractInterpreterInlines.h:
1807         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1808         * dfg/DFGArgumentsEliminationPhase.cpp:
1809         * dfg/DFGClobberize.h:
1810         (JSC::DFG::clobberize):
1811         * dfg/DFGCopyBarrierOptimizationPhase.cpp: Added.
1812         (JSC::DFG::performCopyBarrierOptimization):
1813         * dfg/DFGCopyBarrierOptimizationPhase.h: Added.
1814         * dfg/DFGDoesGC.cpp:
1815         (JSC::DFG::doesGC):
1816         * dfg/DFGFixupPhase.cpp:
1817         (JSC::DFG::FixupPhase::fixupNode):
1818         * dfg/DFGHeapLocation.cpp:
1819         (WTF::printInternal):
1820         * dfg/DFGHeapLocation.h:
1821         * dfg/DFGLICMPhase.cpp:
1822         (JSC::DFG::LICMPhase::run):
1823         * dfg/DFGNodeType.h:
1824         * dfg/DFGOperations.cpp:
1825         * dfg/DFGOperations.h:
1826         * dfg/DFGPlan.cpp:
1827         (JSC::DFG::Plan::compileInThreadImpl):
1828         * dfg/DFGPredictionPropagationPhase.cpp:
1829         (JSC::DFG::PredictionPropagationPhase::propagate):
1830         * dfg/DFGSafeToExecute.h:
1831         (JSC::DFG::safeToExecute):
1832         * dfg/DFGSpeculativeJIT.cpp:
1833         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
1834         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
1835         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
1836         (JSC::DFG::SpeculativeJIT::compileGetButterfly):
1837         (JSC::DFG::SpeculativeJIT::temporaryRegisterForPutByVal):
1838         * dfg/DFGSpeculativeJIT.h:
1839         * dfg/DFGSpeculativeJIT32_64.cpp:
1840         (JSC::DFG::SpeculativeJIT::compile):
1841         * dfg/DFGSpeculativeJIT64.cpp:
1842         (JSC::DFG::SpeculativeJIT::compile):
1843         * dfg/DFGTypeCheckHoistingPhase.cpp:
1844         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
1845         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
1846         * ftl/FTLCapabilities.cpp:
1847         (JSC::FTL::canCompile):
1848         * ftl/FTLLowerDFGToLLVM.cpp:
1849         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
1850         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetButterfly):
1851         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetButterflyReadOnly):
1852         (JSC::FTL::DFG::LowerDFGToLLVM::compileConstantStoragePointer):
1853         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetIndexedPropertyStorage):
1854         (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckArray):
1855         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetTypedArrayByteOffset):
1856         (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiGetByOffset):
1857         (JSC::FTL::DFG::LowerDFGToLLVM::compileMultiPutByOffset):
1858         (JSC::FTL::DFG::LowerDFGToLLVM::compileGetDirectPname):
1859         (JSC::FTL::DFG::LowerDFGToLLVM::storageForTransition):
1860         (JSC::FTL::DFG::LowerDFGToLLVM::getById):
1861         (JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyWithBarrier):
1862         (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorWithBarrier):
1863         (JSC::FTL::DFG::LowerDFGToLLVM::copyBarrier):
1864         (JSC::FTL::DFG::LowerDFGToLLVM::loadButterflyReadOnly):
1865         (JSC::FTL::DFG::LowerDFGToLLVM::loadVectorReadOnly):
1866         (JSC::FTL::DFG::LowerDFGToLLVM::removeSpaceBits):
1867         (JSC::FTL::DFG::LowerDFGToLLVM::baseIndex):
1868         * ftl/FTLOperations.cpp:
1869         (JSC::FTL::operationNewObjectWithButterfly):
1870         (JSC::FTL::operationPopulateObjectInOSR):
1871         * ftl/FTLOutput.h:
1872         (JSC::FTL::Output::testNonZero32):
1873         (JSC::FTL::Output::testIsZero64):
1874         (JSC::FTL::Output::testNonZero64):
1875         (JSC::FTL::Output::testIsZeroPtr):
1876         (JSC::FTL::Output::testNonZeroPtr):
1877         (JSC::FTL::Output::select):
1878         (JSC::FTL::Output::extractValue):
1879         * heap/CopyBarrier.h: Copied from Source/JavaScriptCore/heap/CopyWriteBarrier.h.
1880         (JSC::CopyBarrierBase::CopyBarrierBase):
1881         (JSC::CopyBarrierBase::operator!):
1882         (JSC::CopyBarrierBase::operator bool):
1883         (JSC::CopyBarrierBase::getWithoutBarrier):
1884         (JSC::CopyBarrierBase::get):
1885         (JSC::CopyBarrierBase::copyState):
1886         (JSC::CopyBarrierBase::setCopyState):
1887         (JSC::CopyBarrierBase::clear):
1888         (JSC::CopyBarrierBase::set):
1889         (JSC::CopyBarrierBase::setWithoutBarrier):
1890         (JSC::CopyBarrierBase::weakCASWithoutBarrier):
1891         (JSC::CopyBarrier::CopyBarrier):
1892         (JSC::CopyBarrier::getWithoutBarrier):
1893         (JSC::CopyBarrier::get):
1894         (JSC::CopyBarrier::set):
1895         (JSC::CopyBarrier::setWithoutBarrier):
1896         (JSC::CopyBarrier::weakCASWithoutBarrier):
1897         (JSC::CopyWriteBarrier::CopyWriteBarrier): Deleted.
1898         (JSC::CopyWriteBarrier::operator!): Deleted.
1899         (JSC::CopyWriteBarrier::operator bool): Deleted.
1900         (JSC::CopyWriteBarrier::get): Deleted.
1901         (JSC::CopyWriteBarrier::operator*): Deleted.
1902         (JSC::CopyWriteBarrier::operator->): Deleted.
1903         (JSC::CopyWriteBarrier::set): Deleted.
1904         (JSC::CopyWriteBarrier::setWithoutWriteBarrier): Deleted.
1905         (JSC::CopyWriteBarrier::clear): Deleted.
1906         * heap/CopyVisitorInlines.h:
1907         (JSC::CopyVisitor::checkIfShouldCopy):
1908         * heap/CopyWriteBarrier.h: Removed.
1909         * heap/Heap.cpp:
1910         (JSC::Heap::addToRememberedSet):
1911         (JSC::Heap::copyBarrier):
1912         (JSC::Heap::collectAndSweep):
1913         * heap/Heap.h:
1914         (JSC::Heap::writeBarrierBuffer):
1915         * heap/HeapInlines.h:
1916         * jit/AssemblyHelpers.h:
1917         (JSC::AssemblyHelpers::branchStructure):
1918         (JSC::AssemblyHelpers::branchIfNotToSpace):
1919         (JSC::AssemblyHelpers::removeSpaceBits):
1920         (JSC::AssemblyHelpers::addressForByteOffset):
1921         * jit/JIT.cpp:
1922         (JSC::JIT::privateCompileMainPass):
1923         (JSC::JIT::privateCompileSlowCases):
1924         * jit/JITOpcodes.cpp:
1925         (JSC::JIT::emitSlow_op_has_indexed_property):
1926         (JSC::JIT::emit_op_get_direct_pname):
1927         (JSC::JIT::emitSlow_op_get_direct_pname):
1928         * jit/JITOpcodes32_64.cpp:
1929         (JSC::JIT::emit_op_get_direct_pname):
1930         (JSC::JIT::emitSlow_op_get_direct_pname):
1931         * jit/JITPropertyAccess.cpp:
1932         (JSC::JIT::emitDoubleLoad):
1933         (JSC::JIT::emitContiguousLoad):
1934         (JSC::JIT::emitArrayStorageLoad):
1935         (JSC::JIT::emitSlow_op_get_by_val):
1936         (JSC::JIT::emitGenericContiguousPutByVal):
1937         (JSC::JIT::emitArrayStoragePutByVal):
1938         (JSC::JIT::emitSlow_op_put_by_val):
1939         (JSC::JIT::emit_op_get_from_scope):
1940         (JSC::JIT::emitSlow_op_get_from_scope):
1941         (JSC::JIT::emit_op_put_to_scope):
1942         (JSC::JIT::emitSlow_op_put_to_scope):
1943         (JSC::JIT::emitIntTypedArrayGetByVal):
1944         (JSC::JIT::emitFloatTypedArrayGetByVal):
1945         (JSC::JIT::emitIntTypedArrayPutByVal):
1946         (JSC::JIT::emitFloatTypedArrayPutByVal):
1947         * llint/LowLevelInterpreter.asm:
1948         * llint/LowLevelInterpreter64.asm:
1949         * runtime/DirectArguments.cpp:
1950         (JSC::DirectArguments::visitChildren):
1951         (JSC::DirectArguments::copyBackingStore):
1952         (JSC::DirectArguments::overrideThings):
1953         (JSC::DirectArguments::overrideThingsIfNecessary):
1954         (JSC::DirectArguments::overrideArgument):
1955         (JSC::DirectArguments::copyToArguments):
1956         * runtime/DirectArguments.h:
1957         (JSC::DirectArguments::canAccessIndexQuickly):
1958         (JSC::DirectArguments::canAccessArgumentIndexQuicklyInDFG):
1959         * runtime/JSArray.cpp:
1960         (JSC::JSArray::setLength):
1961         (JSC::JSArray::pop):
1962         (JSC::JSArray::push):
1963         (JSC::JSArray::fastSlice):
1964         (JSC::JSArray::fastConcatWith):
1965         (JSC::JSArray::shiftCountWithArrayStorage):
1966         (JSC::JSArray::shiftCountWithAnyIndexingType):
1967         (JSC::JSArray::unshiftCountWithAnyIndexingType):
1968         (JSC::JSArray::fillArgList):
1969         (JSC::JSArray::copyToArguments):
1970         * runtime/JSArrayBufferView.cpp:
1971         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
1972         (JSC::JSArrayBufferView::JSArrayBufferView):
1973         (JSC::JSArrayBufferView::finishCreation):
1974         (JSC::JSArrayBufferView::finalize):
1975         * runtime/JSArrayBufferView.h:
1976         (JSC::JSArrayBufferView::vector):
1977         (JSC::JSArrayBufferView::length):
1978         * runtime/JSArrayBufferViewInlines.h:
1979         (JSC::JSArrayBufferView::neuter):
1980         (JSC::JSArrayBufferView::byteOffset):
1981         * runtime/JSGenericTypedArrayView.h:
1982         (JSC::JSGenericTypedArrayView::typedVector):
1983         * runtime/JSGenericTypedArrayViewInlines.h:
1984         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
1985         (JSC::JSGenericTypedArrayView<Adaptor>::copyBackingStore):
1986         (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
1987         * runtime/JSMap.h:
1988         (JSC::JSMap::JSMap):
1989         * runtime/JSObject.cpp:
1990         (JSC::JSObject::copyButterfly):
1991         (JSC::JSObject::visitChildren):
1992         (JSC::JSObject::copyBackingStore):
1993         (JSC::JSObject::getOwnPropertySlotByIndex):
1994         (JSC::JSObject::putByIndex):
1995         (JSC::JSObject::enterDictionaryIndexingMode):
1996         (JSC::JSObject::createInitialIndexedStorage):
1997         (JSC::JSObject::createArrayStorage):
1998         (JSC::JSObject::convertUndecidedToInt32):
1999         (JSC::JSObject::convertUndecidedToDouble):
2000         (JSC::JSObject::convertUndecidedToContiguous):
2001         (JSC::JSObject::constructConvertedArrayStorageWithoutCopyingElements):
2002         (JSC::JSObject::convertUndecidedToArrayStorage):
2003         (JSC::JSObject::convertInt32ToDouble):
2004         (JSC::JSObject::convertInt32ToContiguous):
2005         (JSC::JSObject::convertInt32ToArrayStorage):
2006         (JSC::JSObject::convertDoubleToContiguous):
2007         (JSC::JSObject::convertDoubleToArrayStorage):
2008         (JSC::JSObject::convertContiguousToArrayStorage):
2009         (JSC::JSObject::setIndexQuicklyToUndecided):
2010         (JSC::JSObject::ensureArrayStorageExistsAndEnterDictionaryIndexingMode):
2011         (JSC::JSObject::deletePropertyByIndex):
2012         (JSC::JSObject::getOwnPropertyNames):
2013         (JSC::JSObject::putIndexedDescriptor):
2014         (JSC::JSObject::defineOwnIndexedProperty):
2015         (JSC::JSObject::putByIndexBeyondVectorLengthWithoutAttributes):
2016         (JSC::JSObject::putDirectIndexBeyondVectorLength):
2017         (JSC::JSObject::getNewVectorLength):
2018         (JSC::JSObject::ensureLengthSlow):
2019         (JSC::JSObject::reallocateAndShrinkButterfly):
2020         (JSC::JSObject::growOutOfLineStorage):
2021         (JSC::JSObject::getOwnPropertyDescriptor):
2022         (JSC::JSObject::getEnumerableLength):
2023         * runtime/JSObject.h:
2024         (JSC::JSObject::getArrayLength):
2025         (JSC::JSObject::getVectorLength):
2026         (JSC::JSObject::canGetIndexQuickly):
2027         (JSC::JSObject::getIndexQuickly):
2028         (JSC::JSObject::tryGetIndexQuickly):
2029         (JSC::JSObject::canSetIndexQuickly):
2030         (JSC::JSObject::canSetIndexQuicklyForPutDirect):
2031         (JSC::JSObject::setIndexQuickly):
2032         (JSC::JSObject::initializeIndex):
2033         (JSC::JSObject::hasSparseMap):
2034         (JSC::JSObject::inSparseIndexingMode):
2035         (JSC::JSObject::inlineStorage):
2036         (JSC::JSObject::butterfly):
2037         (JSC::JSObject::outOfLineStorage):
2038         (JSC::JSObject::locationForOffset):
2039         (JSC::JSObject::ensureInt32):
2040         (JSC::JSObject::ensureDouble):
2041         (JSC::JSObject::ensureContiguous):
2042         (JSC::JSObject::ensureArrayStorage):
2043         (JSC::JSObject::arrayStorage):
2044         (JSC::JSObject::arrayStorageOrNull):
2045         (JSC::JSObject::ensureLength):
2046         (JSC::JSObject::putDirectWithoutTransition):
2047         * runtime/JSSet.h:
2048         (JSC::JSSet::JSSet):
2049         * runtime/MapData.h:
2050         (JSC::JSIterator>::MapDataImpl):
2051         (JSC::JSIterator>::IteratorData::next):
2052         (JSC::JSIterator>::IteratorData::refreshCursor):
2053         * runtime/MapDataInlines.h:
2054         (JSC::JSIterator>::clear):
2055         (JSC::JSIterator>::find):
2056         (JSC::JSIterator>::add):
2057         (JSC::JSIterator>::remove):
2058         (JSC::JSIterator>::replaceAndPackBackingStore):
2059         (JSC::JSIterator>::replaceBackingStore):
2060         (JSC::JSIterator>::ensureSpaceForAppend):
2061         (JSC::JSIterator>::visitChildren):
2062         (JSC::JSIterator>::copyBackingStore):
2063         * runtime/Options.h:
2064
2065 2015-10-12  Saam barati  <sbarati@apple.com>
2066
2067         Update JSC features.json
2068         https://bugs.webkit.org/show_bug.cgi?id=150043
2069
2070         Reviewed by Mark Lam.
2071
2072         There were a lot of things implemented that weren't in
2073         the list. We should be better about updating the list
2074         as we land patches for new ES6 features.
2075
2076         * features.json:
2077
2078 2015-10-12  Joseph Pecoraro  <pecoraro@apple.com>
2079
2080         Cleanup Heap.h and some related headers
2081         https://bugs.webkit.org/show_bug.cgi?id=149981
2082
2083         Reviewed by Geoffrey Garen.
2084
2085         * heap/Heap.h:
2086         - Some functions did not need export.
2087         - threadDupStrings never had an implementation.
2088
2089         * heap/ConservativeRoots.cpp:
2090         * heap/ConservativeRoots.h:
2091         * heap/Heap.cpp:
2092         * heap/ListableHandler.h:
2093         * heap/WeakReferenceHarvester.h:
2094         * jit/Repatch.cpp:
2095         * runtime/JSONObject.h:
2096         * runtime/VM.h:
2097         - Stale forward declarations / includes.
2098
2099 2015-10-12  Saam barati  <sbarati@apple.com>
2100
2101         Each *ById inline cache in the FTL must have its own CallSiteIndex
2102         https://bugs.webkit.org/show_bug.cgi?id=150039
2103
2104         Reviewed by Geoffrey Garen and Filip Pizlo.
2105
2106         When lowering to LLVM, we create a patchpoint intrinsic for each
2107         *ById in DFG IR. LLVM may choose to duplicate these patchpoints.
2108         Therefore, we want each resulting inline cache to have a unique
2109         CallSiteIndex because each inline cache will have its own set of 
2110         used registers. This change is necessary when we implement try/catch 
2111         in the FTL because an inline cache will ask for the set of used 
2112         registers it will need to restore in the event of an exception 
2113         being thrown. It asks for this set of registers by giving JITCode
2114         a CallSiteIndex. Because each corresponding inline cache that results
2115         from a duplicated patchpoint may all ask this for this set of registers, 
2116         we must assign each inline cache a unique CallSiteIndex.
2117
2118         * bytecode/CodeBlock.cpp:
2119         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
2120         * dfg/DFGCommonData.cpp:
2121         (JSC::DFG::CommonData::addCodeOrigin):
2122         (JSC::DFG::CommonData::addUniqueCallSiteIndex):
2123         (JSC::DFG::CommonData::addCodeOriginUnconditionally): Deleted.
2124         * dfg/DFGCommonData.h:
2125         * ftl/FTLCompile.cpp:
2126         (JSC::FTL::mmAllocateDataSection):
2127         * ftl/FTLInlineCacheDescriptor.h:
2128         (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
2129         (JSC::FTL::InlineCacheDescriptor::stackmapID):
2130         (JSC::FTL::InlineCacheDescriptor::codeOrigin):
2131         (JSC::FTL::InlineCacheDescriptor::uid):
2132         (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
2133         (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
2134         (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
2135         (JSC::FTL::LazySlowPathDescriptor::LazySlowPathDescriptor):
2136         (JSC::FTL::InlineCacheDescriptor::callSiteIndex): Deleted.
2137         * ftl/FTLLowerDFGToLLVM.cpp:
2138         (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
2139         (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
2140         (JSC::FTL::DFG::LowerDFGToLLVM::getById):
2141         (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
2142
2143 2015-10-12  Andreas Kling  <akling@apple.com>
2144
2145         "A + B" with strings shouldn't copy if A or B is empty.
2146         <https://webkit.org/b/150034>
2147
2148         Reviewed by Anders Carlsson.
2149
2150         * runtime/JSStringBuilder.h:
2151         (JSC::jsMakeNontrivialString):
2152         * runtime/Lookup.cpp:
2153         (JSC::reifyStaticAccessor):
2154         * runtime/ObjectPrototype.cpp:
2155         (JSC::objectProtoFuncToString):
2156
2157 2015-10-12  Joseph Pecoraro  <pecoraro@apple.com>
2158
2159         VisitedValueCount GC Counter misses parallel SlotVisitors
2160         https://bugs.webkit.org/show_bug.cgi?id=149980
2161
2162         Reviewed by Geoffrey Garen.
2163
2164         * heap/Heap.cpp:
2165         (JSC::Heap::updateObjectCounts):
2166         Include threaded slot visitor's object counts in the debugging value.
2167
2168 2015-10-12  Filip Pizlo  <fpizlo@apple.com>
2169
2170         Unreviewed, fix non-FTL build for real.
2171
2172         * ftl/FTLLazySlowPath.h:
2173
2174 2015-10-12  Filip Pizlo  <fpizlo@apple.com>
2175
2176         Unreviewed, clarify a comment. The example code had a bug.
2177
2178         * ftl/FTLLowerDFGToLLVM.cpp:
2179
2180 2015-10-12  Filip Pizlo  <fpizlo@apple.com>
2181
2182         Unreviewed, fix no-FTL build.
2183
2184         * ftl/FTLLazySlowPath.cpp:
2185
2186 2015-10-12  Philip Chimento  <philip.chimento@gmail.com>
2187
2188         webkit-gtk 2.3.3 fails to build on OS X - Conflicting type "Fixed"
2189         https://bugs.webkit.org/show_bug.cgi?id=126433
2190
2191         Reviewed by Philippe Normand
2192
2193         Don't include CoreFoundation.h when building the GTK port.
2194
2195         * Source/JavaScriptCore/API/WebKitAvailability.h: Add !defined(BUILDING_GTK__) to defined(__APPLE__).
2196
2197 2015-10-10  Filip Pizlo  <fpizlo@apple.com>
2198
2199         FTL should generate code to call slow paths lazily
2200         https://bugs.webkit.org/show_bug.cgi?id=149936
2201
2202         Reviewed by Saam Barati.
2203
2204         We often have complex slow paths in FTL-generated code. Those slow paths may never run. Even
2205         if they do run, they don't need stellar performance. So, it doesn't make sense to have LLVM
2206         worry about compiling such slow path code.
2207
2208         This patch enables us to use our own MacroAssembler for compiling the slow path inside FTL
2209         code. It does this by using a crazy lambda thingy (see FTLLowerDFGToLLVM.cpp's lazySlowPath()
2210         and its documentation). The result is quite natural to use.
2211
2212         Even for straight slow path calls via something like vmCall(), the lazySlowPath offers the
2213         benefit that the call marshalling and the exception checking are not expressed using LLVM IR
2214         and do not require LLVM to think about it. It also has the benefit that we never generate the
2215         code if it never runs. That's great, since function calls usually involve ~10 instructions
2216         total (move arguments to argument registers, make the call, check exception, etc.).
2217
2218         This patch adds the lazy slow path abstraction and uses it for some slow paths in the FTL.
2219         The code we generate with lazy slow paths is worse than the code that LLVM would have
2220         generated. Therefore, a lazy slow path only makes sense when we have strong evidence that
2221         the slow path will execute infrequently relative to the fast path. This completely precludes
2222         the use of lazy slow paths for out-of-line Nodes that unconditionally call a C++ function.
2223         It also precludes their use for the GetByVal out-of-bounds handler, since when we generate
2224         a GetByVal with an out-of-bounds handler it means that we only know that the out-of-bounds
2225         case executed at least once. So, for all we know, it may actually be the common case. So,
2226         this patch just deployed the lazy slow path for GC slow paths and masquerades-as-undefined
2227         slow paths. It makes sense for GC slow paths because those have a statistical guarantee of
2228         slow path frequency - probably bounded at less than 1/10. It makes sense for masquerades-as-
2229         undefined because we can say quite confidently that this is an uncommon scenario on the
2230         modern Web.
2231
2232         Something that's always been challenging about abstractions involving the MacroAssembler is
2233         that linking is a separate phase, and there is no way for someone who is just given access to
2234         the MacroAssembler& to emit code that requires linking, since linking happens once we have
2235         emitted all code and we are creating the LinkBuffer. Moreover, the FTL requires that the
2236         final parts of linking happen on the main thread. This patch ran into this issue, and solved
2237         it comprehensively, by introducing MacroAssembler::addLinkTask(). This takes a lambda and
2238         runs it at the bitter end of linking - when performFinalization() is called. This ensure that
2239         the task added by addLinkTask() runs on the main thread. This patch doesn't replace all of
2240         the previously existing idioms for dealing with this issue; we can do that later.
2241
2242         This shows small speed-ups on a bunch of things. No big win on any benchmark aggregate. But
2243         mainly this is done for https://bugs.webkit.org/show_bug.cgi?id=149852, where we found that
2244         outlining the slow path in this way was a significant speed boost.
2245
2246         * CMakeLists.txt:
2247         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2248         * JavaScriptCore.xcodeproj/project.pbxproj:
2249         * assembler/AbstractMacroAssembler.h:
2250         (JSC::AbstractMacroAssembler::replaceWithAddressComputation):
2251         (JSC::AbstractMacroAssembler::addLinkTask):
2252         (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
2253         * assembler/LinkBuffer.cpp:
2254         (JSC::LinkBuffer::linkCode):
2255         (JSC::LinkBuffer::allocate):
2256         (JSC::LinkBuffer::performFinalization):
2257         * assembler/LinkBuffer.h:
2258         (JSC::LinkBuffer::wasAlreadyDisassembled):
2259         (JSC::LinkBuffer::didAlreadyDisassemble):
2260         (JSC::LinkBuffer::vm):
2261         (JSC::LinkBuffer::executableOffsetFor):
2262         * bytecode/CodeOrigin.h:
2263         (JSC::CodeOrigin::CodeOrigin):
2264         (JSC::CodeOrigin::isSet):
2265         (JSC::CodeOrigin::operator bool):
2266         (JSC::CodeOrigin::isHashTableDeletedValue):
2267         (JSC::CodeOrigin::operator!): Deleted.
2268         * ftl/FTLCompile.cpp:
2269         (JSC::FTL::mmAllocateDataSection):
2270         * ftl/FTLInlineCacheDescriptor.h:
2271         (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
2272         (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
2273         (JSC::FTL::LazySlowPathDescriptor::LazySlowPathDescriptor):
2274         * ftl/FTLJITCode.h:
2275         * ftl/FTLJITFinalizer.cpp:
2276         (JSC::FTL::JITFinalizer::finalizeFunction):
2277         * ftl/FTLJITFinalizer.h:
2278         * ftl/FTLLazySlowPath.cpp: Added.
2279         (JSC::FTL::LazySlowPath::LazySlowPath):
2280         (JSC::FTL::LazySlowPath::~LazySlowPath):
2281         (JSC::FTL::LazySlowPath::generate):
2282         * ftl/FTLLazySlowPath.h: Added.
2283         (JSC::FTL::LazySlowPath::createGenerator):
2284         (JSC::FTL::LazySlowPath::patchpoint):
2285         (JSC::FTL::LazySlowPath::usedRegisters):
2286         (JSC::FTL::LazySlowPath::callSiteIndex):
2287         (JSC::FTL::LazySlowPath::stub):
2288         * ftl/FTLLazySlowPathCall.h: Added.
2289         (JSC::FTL::createLazyCallGenerator):
2290         * ftl/FTLLowerDFGToLLVM.cpp:
2291         (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateActivation):
2292         (JSC::FTL::DFG::LowerDFGToLLVM::compileNewFunction):
2293         (JSC::FTL::DFG::LowerDFGToLLVM::compileCreateDirectArguments):
2294         (JSC::FTL::DFG::LowerDFGToLLVM::compileNewArrayWithSize):
2295         (JSC::FTL::DFG::LowerDFGToLLVM::compileMakeRope):
2296         (JSC::FTL::DFG::LowerDFGToLLVM::compileNotifyWrite):
2297         (JSC::FTL::DFG::LowerDFGToLLVM::compileIsObjectOrNull):
2298         (JSC::FTL::DFG::LowerDFGToLLVM::compileIsFunction):
2299         (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
2300         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeNewObject):
2301         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation):
2302         (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckWatchdogTimer):
2303         (JSC::FTL::DFG::LowerDFGToLLVM::allocatePropertyStorageWithSizeImpl):
2304         (JSC::FTL::DFG::LowerDFGToLLVM::allocateObject):
2305         (JSC::FTL::DFG::LowerDFGToLLVM::allocateJSArray):
2306         (JSC::FTL::DFG::LowerDFGToLLVM::buildTypeOf):
2307         (JSC::FTL::DFG::LowerDFGToLLVM::sensibleDoubleToInt32):
2308         (JSC::FTL::DFG::LowerDFGToLLVM::lazySlowPath):
2309         (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
2310         (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
2311         * ftl/FTLOperations.cpp:
2312         (JSC::FTL::operationMaterializeObjectInOSR):
2313         (JSC::FTL::compileFTLLazySlowPath):
2314         * ftl/FTLOperations.h:
2315         * ftl/FTLSlowPathCall.cpp:
2316         (JSC::FTL::SlowPathCallContext::SlowPathCallContext):
2317         (JSC::FTL::SlowPathCallContext::~SlowPathCallContext):
2318         (JSC::FTL::SlowPathCallContext::keyWithTarget):
2319         (JSC::FTL::SlowPathCallContext::makeCall):
2320         (JSC::FTL::callSiteIndexForCodeOrigin):
2321         (JSC::FTL::storeCodeOrigin): Deleted.
2322         (JSC::FTL::callOperation): Deleted.
2323         * ftl/FTLSlowPathCall.h:
2324         (JSC::FTL::callOperation):
2325         * ftl/FTLState.h:
2326         * ftl/FTLThunks.cpp:
2327         (JSC::FTL::genericGenerationThunkGenerator):
2328         (JSC::FTL::osrExitGenerationThunkGenerator):
2329         (JSC::FTL::lazySlowPathGenerationThunkGenerator):
2330         (JSC::FTL::registerClobberCheck):
2331         * ftl/FTLThunks.h:
2332         * interpreter/CallFrame.h:
2333         (JSC::CallSiteIndex::CallSiteIndex):
2334         (JSC::CallSiteIndex::operator bool):
2335         (JSC::CallSiteIndex::bits):
2336         * jit/CCallHelpers.h:
2337         (JSC::CCallHelpers::setupArgument):
2338         (JSC::CCallHelpers::setupArgumentsWithExecState):
2339         * jit/JITOperations.cpp:
2340
2341 2015-10-12  Philip Chimento  <philip.chimento@gmail.com>
2342
2343         webkit-gtk-2.3.4 fails to link JavaScriptCore, missing symbols add_history and readline
2344         https://bugs.webkit.org/show_bug.cgi?id=127059
2345
2346         Reviewed by Philippe Normand.
2347
2348         * shell/CMakeLists.txt: Link JSC with -ledit on Mac OSX.
2349
2350 2015-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2351
2352         ES6 classes: When a class extends B, super() invokes B.prototype.constructor() instead of B()
2353         https://bugs.webkit.org/show_bug.cgi?id=149001
2354
2355         Reviewed by Saam Barati.
2356
2357         This patch matches the `super()` call in the constructor to the latest spec.
2358         Before this patch, when calling `super()`, it loads `callee.[[HomeObject]].__proto__.constructor`
2359         as a super constructor. But after this patch, it loads `callee.__proto__` as a super constructor.
2360         This behavior corresponds to the section 12.3.5.2[1].
2361
2362         [1]: http://www.ecma-international.org/ecma-262/6.0/#sec-getsuperconstructor
2363
2364         * bytecompiler/NodesCodegen.cpp:
2365         (JSC::SuperNode::emitBytecode):
2366         * tests/stress/super-call-does-not-look-up-constructor.js: Added.
2367         (shouldBe):
2368         (B):
2369         (C):
2370         (B.prototype):
2371
2372 2015-10-10  Andreas Kling  <akling@apple.com>
2373
2374         Reduce pointless malloc traffic in CodeBlock construction.
2375         <https://webkit.org/b/149999>
2376
2377         Reviewed by Antti Koivisto.
2378
2379         Create the RefCountedArray<Instruction> for CodeBlock's m_instructions directly
2380         instead of first creating a Vector<Instruction> and then creating a RefCountedArray
2381         from that. None of the Vector functionality is needed here anyway.
2382
2383         * bytecode/CodeBlock.cpp:
2384         (JSC::CodeBlock::finishCreation):
2385         (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
2386         * bytecode/CodeBlock.h:
2387
2388 2015-10-10  Dan Bernstein  <mitz@apple.com>
2389
2390         [iOS] Remove unnecessary iOS version checks
2391         https://bugs.webkit.org/show_bug.cgi?id=150002
2392
2393         Reviewed by Alexey Proskuryakov.
2394
2395         * llvm/library/LLVMExports.cpp:
2396         (initializeAndGetJSCLLVMAPI):
2397
2398 2015-10-10  Dan Bernstein  <mitz@apple.com>
2399
2400         [iOS] Remove project support for iOS 8
2401         https://bugs.webkit.org/show_bug.cgi?id=149993
2402
2403         Reviewed by Alexey Proskuryakov.
2404
2405         * Configurations/Base.xcconfig:
2406         * Configurations/JSC.xcconfig:
2407         * Configurations/JavaScriptCore.xcconfig:
2408         * Configurations/LLVMForJSC.xcconfig:
2409         * Configurations/ToolExecutable.xcconfig:
2410
2411 2015-10-09  Joseph Pecoraro  <pecoraro@apple.com>
2412
2413         Modernize and cleanup an NSNumber constant
2414         https://bugs.webkit.org/show_bug.cgi?id=149962
2415
2416         Reviewed by Andreas Kling.
2417
2418         * API/JSVirtualMachine.mm:
2419         (-[JSVirtualMachine addExternalRememberedObject:]):
2420
2421 2015-10-09  Joseph Pecoraro  <pecoraro@apple.com>
2422
2423         No need to keep setting needsVisit flag in SmallStrings
2424         https://bugs.webkit.org/show_bug.cgi?id=149961
2425
2426         Reviewed by Andreas Kling.
2427
2428         SmallStrings are all initialized at once privately before the VM
2429         enables Garbage Collection. There is no need to keep updating
2430         this flag, as it couldn't have changed.
2431
2432         * runtime/SmallStrings.cpp:
2433         (JSC::SmallStrings::createEmptyString):
2434         (JSC::SmallStrings::createSingleCharacterString):
2435         (JSC::SmallStrings::initialize):
2436         * runtime/SmallStrings.h:
2437
2438 2015-10-09  Geoffrey Garen  <ggaren@apple.com>
2439
2440         Unreviewed, rolling back in r190694
2441         https://bugs.webkit.org/show_bug.cgi?id=149727
2442
2443         This time for double sure?
2444
2445         The cause of the crash was an incorrect write barrier.
2446
2447         OSR exit was barriering the baseline codeblock for the top of the stack
2448         twice, missing the baseline codeblock for the bottom of the stack.
2449
2450         Restored changesets:
2451
2452         "CodeBlock should be a GC object"
2453         https://bugs.webkit.org/show_bug.cgi?id=149727
2454         http://trac.webkit.org/changeset/r190694
2455
2456 2015-10-09  Joseph Pecoraro  <pecoraro@apple.com>
2457
2458         Remove unused RecursiveAllocationScope
2459         https://bugs.webkit.org/show_bug.cgi?id=149967
2460
2461         Reviewed by Csaba Osztrogonác.
2462
2463         RecursiveAllocationScope has been unused since r163691.
2464
2465         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2466         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2467         * JavaScriptCore.xcodeproj/project.pbxproj:
2468         * heap/Heap.cpp:
2469         * heap/Heap.h:
2470         * heap/RecursiveAllocationScope.h: Removed.
2471         * runtime/VM.h:
2472
2473 2015-10-09  Geoffrey Garen  <ggaren@apple.com>
2474
2475         Unreviewed, rolling out r190694
2476         https://bugs.webkit.org/show_bug.cgi?id=148560
2477
2478         Crashes seen on PLT bots and facebook.com.
2479
2480         Reverted changesets:
2481
2482         "CodeBlock should be a GC object"
2483         https://bugs.webkit.org/show_bug.cgi?id=149727
2484         http://trac.webkit.org/changeset/190694
2485
2486 2015-10-09  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>
2487
2488         Automate WebCore JS builtins generation and build system
2489         https://bugs.webkit.org/show_bug.cgi?id=149751
2490
2491         Reviewed by Darin Adler.
2492
2493         * generate-js-builtins: updating the part related to WebCore JS binding.
2494
2495 2015-10-08  Filip Pizlo  <fpizlo@apple.com>
2496
2497         DFG SSA should remove unreachable code
2498         https://bugs.webkit.org/show_bug.cgi?id=149931
2499
2500         Reviewed by Geoffrey Garen.
2501
2502         Rolled back in with a call to m_state.reset(), which fixes the debug asserts.
2503
2504         * dfg/DFGConstantFoldingPhase.cpp:
2505         (JSC::DFG::ConstantFoldingPhase::run): Remove unreachable code.
2506         * dfg/DFGObjectAllocationSinkingPhase.cpp: Deal with the CFG changing.
2507         * dfg/DFGPutStackSinkingPhase.cpp: Deal with the CFG changing.
2508
2509 2015-10-08  Daniel Bates  <dabates@apple.com>
2510
2511         Add LLVM binaries for iOS 9 device
2512         https://bugs.webkit.org/show_bug.cgi?id=149913
2513
2514         Reviewed by Filip Pizlo.
2515
2516         Look for locally built/binary dropped LLVM headers and libraries when building for iOS device
2517         in WebKitBuild/usr/local.
2518
2519         Currently Mac and iOS look for the locally built/binary dropped LLVM in different directories:
2520         WebKitBuild/usr/local and /usr/local/LLVMForJavaScriptCore, respectively. This difference is
2521         due to dependencies with the Apple internal build system. We should look to resolve the
2522         Apple internal dependencies and standardize on one location for both platforms.
2523
2524         * Configurations/Base.xcconfig:
2525
2526 2015-10-08  Commit Queue  <commit-queue@webkit.org>
2527
2528         Unreviewed, rolling out r190749.
2529         https://bugs.webkit.org/show_bug.cgi?id=149938
2530
2531         Caused 50+ layout test failures
2532         https://build.webkit.org/results/Apple%20El%20Capitan%20Debug%20WK1%20(Tests)/r190749%20(213)/results.html
2533         (Requested by litherum1 on #webkit).
2534
2535         Reverted changeset:
2536
2537         "DFG SSA should remove unreachable code"
2538         https://bugs.webkit.org/show_bug.cgi?id=149931
2539         http://trac.webkit.org/changeset/190749
2540
2541 2015-10-08  Filip Pizlo  <fpizlo@apple.com>
2542
2543         DFG SSA should remove unreachable code
2544         https://bugs.webkit.org/show_bug.cgi?id=149931
2545
2546         Reviewed by Geoffrey Garen.
2547
2548         * dfg/DFGConstantFoldingPhase.cpp:
2549         (JSC::DFG::ConstantFoldingPhase::run): Remove unreachable code.
2550         * dfg/DFGObjectAllocationSinkingPhase.cpp: Deal with the CFG changing.
2551         * dfg/DFGPutStackSinkingPhase.cpp: Deal with the CFG changing.
2552
2553 2015-10-08  Joseph Pecoraro  <pecoraro@apple.com>
2554
2555         Unreviewed build fix. Missing forward declaration.
2556
2557         * heap/Heap.h:
2558
2559 2015-10-08  Saam barati  <sbarati@apple.com>
2560
2561         Unreviewed Cloop build fix after bug: https://bugs.webkit.org/show_bug.cgi?id=149601
2562
2563         * bytecode/CodeBlock.cpp:
2564         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
2565         * jit/JITCode.cpp:
2566         (JSC::NativeJITCode::addressForCall):
2567         (JSC::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
2568         * jit/JITCode.h:
2569
2570 2015-10-08  Joseph Pecoraro  <pecoraro@apple.com>
2571
2572         Clean up Marked classes
2573         https://bugs.webkit.org/show_bug.cgi?id=149853
2574
2575         Reviewed by Darin Adler.
2576
2577         * heap/Heap.h:
2578         Move include here where it is really needed.
2579
2580         * heap/HeapStatistics.cpp:
2581         * heap/HeapStatistics.h:
2582         Simplify includes.
2583
2584         * heap/MarkedAllocator.h:
2585         Add missing copyright header.
2586
2587         * heap/MarkedBlock.cpp:
2588         * heap/MarkedBlock.h:
2589         (JSC::MarkedBlock::needsSweeping):
2590         Remove unused constants. Add some static asserts. Add some `const` ness.
2591
2592         * heap/MarkedSpace.h:
2593         (JSC::MarkedSpace::isIterating):
2594         Update comments to better reflect actual values.
2595         Remove unimplemented method (moved to Heap).
2596
2597         * heap/MarkedSpace.cpp:
2598         (JSC::Free::Free):
2599         (JSC::Free::operator()):
2600         (JSC::Free::returnValue): Deleted.
2601         (JSC::FreeOrShrink::FreeOrShrink):
2602         (JSC::FreeOrShrink::operator()):
2603         (JSC::MarkedSpace::~MarkedSpace):
2604         (JSC::MarkedSpace::shrink):
2605         Replace conditional Functor that was not using return value
2606         with simplified targeted VoidFunctors.
2607
2608         (JSC::Shrink::operator()): Deleted.
2609         Remove unused functor.
2610
2611         * heap/WeakBlock.cpp:
2612         * heap/WeakBlock.h:
2613         * runtime/Options.cpp:
2614         Remove dead code.
2615
2616 2015-10-08  Saam barati  <sbarati@apple.com>
2617
2618         We should be able to inline getter/setter calls inside an inline cache even when the SpillRegistersMode is NeedsToSpill
2619         https://bugs.webkit.org/show_bug.cgi?id=149601
2620
2621         Reviewed by Filip Pizlo.
2622
2623         Before, if we had a PolymorphicAccess with and a StructureStubInfo
2624         with a NeedToSpill spillMode, we wouldn't generate getter/setter
2625         calls. This patch changes it such that we will generate the
2626         getter/setter call and do the necessary register spilling/filling
2627         around the getter/setter call to preserve any "usedRegisters".
2628
2629         This has an interesting story with how it relates to exception handling 
2630         inside the DFG. Because the GetById variants are considered a throwing call 
2631         site, we must make sure that we properly restore the registers spilled to the stack 
2632         in case of an exception being thrown inside the getter/setter call. We do 
2633         this by having the inline cache register itself as a new exception handling 
2634         call site. When the inline cache "catches" the exception (i.e, genericUnwind 
2635         will jump to this code), it will restore the registers it spilled that are 
2636         live inside the original catch handler, and then jump to the original catch 
2637         handler. We make sure to only generate this makeshift catch handler when we 
2638         actually need to do any cleanup. If we determine that we don't need to restore 
2639         any registers, we don't bother generating this makeshift catch handler.
2640
2641         * bytecode/CodeBlock.cpp:
2642         (JSC::CodeBlock::~CodeBlock):
2643         (JSC::CodeBlock::handlerForIndex):
2644         (JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
2645         (JSC::CodeBlock::removeExceptionHandlerForCallSite):
2646         (JSC::CodeBlock::lineNumberForBytecodeOffset):
2647         * bytecode/CodeBlock.h:
2648         (JSC::CodeBlock::appendExceptionHandler):
2649         * bytecode/PolymorphicAccess.cpp:
2650         (JSC::AccessGenerationState::AccessGenerationState):
2651         (JSC::AccessGenerationState::restoreScratch):
2652         (JSC::AccessGenerationState::succeed):
2653         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
2654         (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
2655         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCall):
2656         (JSC::AccessGenerationState::restoreLiveRegistersFromStackForCallWithThrownException):
2657         (JSC::AccessGenerationState::liveRegistersForCall):
2658         (JSC::AccessGenerationState::callSiteIndexForExceptionHandlingOrOriginal):
2659         (JSC::AccessGenerationState::callSiteIndexForExceptionHandling):
2660         (JSC::AccessGenerationState::originalExceptionHandler):
2661         (JSC::AccessGenerationState::numberOfStackBytesUsedForRegisterPreservation):
2662         (JSC::AccessGenerationState::needsToRestoreRegistersIfException):
2663         (JSC::AccessGenerationState::originalCallSiteIndex):
2664         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
2665         (JSC::AccessCase::AccessCase):
2666         (JSC::AccessCase::generate):
2667         (JSC::PolymorphicAccess::regenerateWithCases):
2668         (JSC::PolymorphicAccess::regenerate):
2669         (JSC::PolymorphicAccess::aboutToDie):
2670         * bytecode/PolymorphicAccess.h:
2671         (JSC::AccessCase::doesCalls):
2672         (JSC::AccessCase::isGetter):
2673         (JSC::AccessCase::callLinkInfo):
2674         * bytecode/StructureStubInfo.cpp:
2675         (JSC::StructureStubInfo::deref):
2676         (JSC::StructureStubInfo::aboutToDie):
2677         (JSC::StructureStubInfo::addAccessCase):
2678         * bytecode/StructureStubInfo.h:
2679         * bytecode/ValueRecovery.h:
2680         (JSC::ValueRecovery::isInJSValueRegs):
2681         (JSC::ValueRecovery::fpr):
2682         * dfg/DFGCommonData.cpp:
2683         (JSC::DFG::CommonData::addCodeOrigin):
2684         (JSC::DFG::CommonData::addCodeOriginUnconditionally):
2685         (JSC::DFG::CommonData::lastCallSite):
2686         (JSC::DFG::CommonData::removeCallSiteIndex):
2687         (JSC::DFG::CommonData::shrinkToFit):
2688         * dfg/DFGCommonData.h:
2689         * dfg/DFGJITCode.cpp:
2690         (JSC::DFG::JITCode::reconstruct):
2691         (JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
2692         (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
2693         * dfg/DFGJITCode.h:
2694         (JSC::DFG::JITCode::osrEntryBlock):
2695         (JSC::DFG::JITCode::setOSREntryBlock):
2696         * dfg/DFGJITCompiler.cpp:
2697         (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
2698         * dfg/DFGOSRExit.cpp:
2699         (JSC::DFG::OSRExit::OSRExit):
2700         * dfg/DFGOSRExit.h:
2701         * dfg/DFGSpeculativeJIT.cpp:
2702         (JSC::DFG::SpeculativeJIT::compileIn):
2703         * dfg/DFGSpeculativeJIT32_64.cpp:
2704         (JSC::DFG::SpeculativeJIT::cachedGetById):
2705         (JSC::DFG::SpeculativeJIT::cachedPutById):
2706         * dfg/DFGSpeculativeJIT64.cpp:
2707         (JSC::DFG::SpeculativeJIT::cachedGetById):
2708         (JSC::DFG::SpeculativeJIT::cachedPutById):
2709         * ftl/FTLCompile.cpp:
2710         (JSC::FTL::mmAllocateDataSection):
2711         * ftl/FTLJITCode.cpp:
2712         (JSC::FTL::JITCode::validateReferences):
2713         (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
2714         * ftl/FTLJITCode.h:
2715         (JSC::FTL::JITCode::handles):
2716         (JSC::FTL::JITCode::dataSections):
2717         * jit/GCAwareJITStubRoutine.cpp:
2718         (JSC::GCAwareJITStubRoutine::GCAwareJITStubRoutine):
2719         (JSC::GCAwareJITStubRoutine::~GCAwareJITStubRoutine):
2720         (JSC::GCAwareJITStubRoutine::observeZeroRefCount):
2721         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal):
2722         (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
2723         (JSC::GCAwareJITStubRoutineWithExceptionHandler::aboutToDie):
2724         (JSC::GCAwareJITStubRoutineWithExceptionHandler::~GCAwareJITStubRoutineWithExceptionHandler):
2725         (JSC::createJITStubRoutine):
2726         * jit/GCAwareJITStubRoutine.h:
2727         * jit/JITCode.cpp:
2728         (JSC::NativeJITCode::addressForCall):
2729         (JSC::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
2730         * jit/JITCode.h:
2731         * jit/JITInlineCacheGenerator.cpp:
2732         (JSC::JITByIdGenerator::JITByIdGenerator):
2733         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2734         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
2735         * jit/JITInlineCacheGenerator.h:
2736         (JSC::JITByIdGenerator::reportSlowPathCall):
2737         * jit/JITPropertyAccess.cpp:
2738         (JSC::JIT::emitGetByValWithCachedId):
2739         (JSC::JIT::emitPutByValWithCachedId):
2740         (JSC::JIT::emit_op_get_by_id):
2741         (JSC::JIT::emit_op_put_by_id):
2742         * jit/JITPropertyAccess32_64.cpp:
2743         (JSC::JIT::emitGetByValWithCachedId):
2744         (JSC::JIT::emitPutByValWithCachedId):
2745         (JSC::JIT::emit_op_get_by_id):
2746         (JSC::JIT::emit_op_put_by_id):
2747         * jit/JITStubRoutine.h:
2748         (JSC::JITStubRoutine::createSelfManagedRoutine):
2749         (JSC::JITStubRoutine::aboutToDie):
2750         * jit/RegisterSet.cpp:
2751         (JSC::RegisterSet::webAssemblyCalleeSaveRegisters):
2752         (JSC::RegisterSet::registersToNotSaveForCall):
2753         (JSC::RegisterSet::allGPRs):
2754         * jit/RegisterSet.h:
2755         (JSC::RegisterSet::set):
2756         (JSC::RegisterSet::clear):
2757         * jit/ScratchRegisterAllocator.cpp:
2758         (JSC::ScratchRegisterAllocator::allocateScratchGPR):
2759         (JSC::ScratchRegisterAllocator::allocateScratchFPR):
2760         (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
2761         (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
2762         (JSC::ScratchRegisterAllocator::usedRegistersForCall):
2763         (JSC::ScratchRegisterAllocator::preserveUsedRegistersToScratchBufferForCall):
2764         (JSC::ScratchRegisterAllocator::restoreUsedRegistersFromScratchBufferForCall):
2765         (JSC::ScratchRegisterAllocator::preserveRegistersToStackForCall):
2766         (JSC::ScratchRegisterAllocator::restoreRegistersFromStackForCall):
2767         * jit/ScratchRegisterAllocator.h:
2768         (JSC::ScratchRegisterAllocator::numberOfReusedRegisters):
2769         (JSC::ScratchRegisterAllocator::usedRegisters):
2770         * jsc.cpp:
2771         (WTF::CustomGetter::CustomGetter):
2772         (WTF::CustomGetter::createStructure):
2773         (WTF::CustomGetter::create):
2774         (WTF::CustomGetter::getOwnPropertySlot):
2775         (WTF::CustomGetter::customGetter):
2776         (WTF::Element::handleOwner):
2777         (GlobalObject::finishCreation):
2778         (functionCreateImpureGetter):
2779         (functionCreateCustomGetterObject):
2780         (functionSetImpureGetterDelegate):
2781         * tests/stress/try-catch-custom-getter-as-get-by-id.js: Added.
2782         (assert):
2783         (bar):
2784         (foo):
2785         * tests/stress/try-catch-getter-as-get-by-id-register-restoration.js: Added.
2786         (assert):
2787         (o1.get f):
2788         (bar):
2789         (foo):
2790         * tests/stress/try-catch-getter-as-get-by-id.js: Added.
2791         (assert):
2792         (o1.get f):
2793         (bar):
2794         (foo):
2795         * tests/stress/try-catch-setter-as-put-by-id.js: Added.
2796         (assert):
2797         (o1.set f):
2798         (bar):
2799         (foo):
2800         * tests/stress/try-catch-stub-routine-replaced.js: Added.
2801         (assert):
2802         (arr):
2803         (hello):
2804         (foo):
2805         (objChain.get f):
2806         (fakeOut.get f):
2807         (o.get f):
2808
2809 2015-10-08  Commit Queue  <commit-queue@webkit.org>
2810
2811         Unreviewed, rolling out r190716.
2812         https://bugs.webkit.org/show_bug.cgi?id=149924
2813
2814         broke mac build from time to time (Requested by youenn on
2815         #webkit).
2816
2817         Reverted changeset:
2818
2819         "Automate WebCore JS builtins generation and build system"
2820         https://bugs.webkit.org/show_bug.cgi?id=149751
2821         http://trac.webkit.org/changeset/190716
2822
2823 2015-10-08  Csaba Osztrogonác  <ossy@webkit.org>
2824
2825         Fix the WASM build on Linux
2826         https://bugs.webkit.org/show_bug.cgi?id=149919
2827
2828         Reviewed by Mark Lam.
2829
2830         * inspector/ScriptCallStackFactory.cpp:
2831         * wasm/JSWASMModule.cpp:
2832         * wasm/WASMFunctionCompiler.h:
2833         (JSC::sizeOfMemoryType):
2834         * wasm/WASMFunctionLLVMIRGenerator.h:
2835
2836 2015-10-08  Csaba Osztrogonác  <ossy@webkit.org>
2837
2838         Unreviewed CLOOP buildfix after r190718.
2839
2840         * jit/Repatch.h:
2841         (JSC::resetGetByID): Deleted.
2842         (JSC::resetPutByID): Deleted.
2843         (JSC::resetIn): Deleted.
2844
2845 2015-10-08  Joseph Pecoraro  <pecoraro@apple.com>
2846
2847         Remove references to removed class RepatchBuffer
2848         https://bugs.webkit.org/show_bug.cgi?id=149909
2849
2850         Reviewed by Csaba Osztrogonác.
2851
2852         * assembler/AbstractMacroAssembler.h:
2853         * assembler/MacroAssemblerARM.h:
2854         * assembler/MacroAssemblerARM64.h:
2855         * assembler/MacroAssemblerARMv7.h:
2856         * assembler/MacroAssemblerMIPS.h:
2857         * assembler/MacroAssemblerSH4.h:
2858         * assembler/MacroAssemblerX86.h:
2859         * assembler/MacroAssemblerX86_64.h:
2860         * jit/JITStubRoutine.h:
2861         * jit/Repatch.h:
2862
2863 2015-10-08  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>
2864
2865         Automate WebCore JS builtins generation and build system
2866         https://bugs.webkit.org/show_bug.cgi?id=149751
2867
2868         Reviewed by Darin Adler.
2869
2870         * generate-js-builtins: updating the part related to WebCore JS binding.
2871
2872 2015-10-07  Joseph Pecoraro  <pecoraro@apple.com>
2873
2874         Clean up Copied classes
2875         https://bugs.webkit.org/show_bug.cgi?id=149863
2876
2877         Reviewed by Saam Barati.
2878
2879         * heap/CopiedAllocator.h:
2880         (JSC::CopiedAllocator::isValid):
2881         * heap/CopiedBlock.h:
2882         * heap/CopiedBlockInlines.h:
2883         * heap/CopiedSpace.cpp:
2884         * heap/CopiedSpace.h:
2885         (JSC::CopiedSpace::isInCopyPhase):
2886         (JSC::CopiedSpace::shouldDoCopyPhase):
2887         * heap/CopiedSpaceInlines.h:
2888         * heap/CopyToken.h:
2889         * heap/CopyVisitor.cpp:
2890         * heap/CopyVisitor.h:
2891         * heap/CopyVisitorInlines.h:
2892         * heap/CopyWorkList.h:
2893         * heap/HandleBlock.h:
2894         * heap/HandleSet.h:
2895         * heap/HeapHelperPool.cpp:
2896         * heap/HeapHelperPool.h:
2897
2898 2015-10-07  Mark Lam  <mark.lam@apple.com>
2899
2900         [Follow up 2] Disable tail calls because it is breaking some sites.
2901         https://bugs.webkit.org/show_bug.cgi?id=149900
2902
2903         Rubber stamped by Saam Barati.
2904
2905         Also need to surpress JSC tail call tests.
2906
2907         * tests/es6.yaml:
2908         * tests/stress/dfg-tail-calls.js:
2909         (nonInlinedTailCall.callee):
2910         * tests/stress/mutual-tail-call-no-stack-overflow.js:
2911         (shouldThrow):
2912         * tests/stress/tail-call-in-inline-cache.js:
2913         (tail):
2914         * tests/stress/tail-call-no-stack-overflow.js:
2915         (shouldThrow):
2916         * tests/stress/tail-call-recognize.js:
2917         (callerMustBeRun):
2918         * tests/stress/tail-call-varargs-no-stack-overflow.js:
2919         (shouldThrow):
2920
2921 2015-10-07  Geoffrey Garen  <ggaren@apple.com>
2922
2923         Unreviewed, rolling back in r190450
2924         https://bugs.webkit.org/show_bug.cgi?id=149727
2925
2926         This time for sure?
2927
2928         The cause of the leak was an invalidated compilation.
2929
2930         There was vestigial manual memory management code that eagerly removed
2931         a CodeBlock from the set of CodeBlocks if compilation was invalidated.
2932         That's not cool since we rely on the set of CodeBlocks when we run
2933         destructors.
2934
2935         The fix is to remove the vestigial code.
2936
2937         I ran the leaks, correctness, and performance tests locally and did not
2938         see any problems.
2939
2940         Restored changesets:
2941
2942         "CodeBlock should be a GC object"
2943         https://bugs.webkit.org/show_bug.cgi?id=149727
2944         http://trac.webkit.org/changeset/190450
2945
2946 2015-10-07  Mark Lam  <mark.lam@apple.com>
2947
2948         Disable tail calls because it is breaking some sites.
2949         https://bugs.webkit.org/show_bug.cgi?id=149900
2950
2951         Reviewed by Saam Barati.
2952
2953         This is until we fix whatever the breakage is.
2954
2955         * runtime/Options.h:
2956
2957 2015-10-07  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2958
2959         Add an LLVM IR generator for WebAssembly
2960         https://bugs.webkit.org/show_bug.cgi?id=149486
2961
2962         Reviewed by Mark Lam.
2963
2964         This patch adds initial support for an LLVM IR generator in WebAssembly
2965         (polyfill-prototype-1 format). All the methods will be implemented in
2966         subsequent patches.
2967
2968         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2969         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2970         * JavaScriptCore.xcodeproj/project.pbxproj:
2971         * wasm/WASMFunctionLLVMIRGenerator.h: Added.
2972         (JSC::WASMFunctionLLVMIRGenerator::MemoryAddress::MemoryAddress):
2973         (JSC::WASMFunctionLLVMIRGenerator::startFunction):
2974         (JSC::WASMFunctionLLVMIRGenerator::endFunction):
2975         (JSC::WASMFunctionLLVMIRGenerator::buildSetLocal):
2976         (JSC::WASMFunctionLLVMIRGenerator::buildSetGlobal):
2977         (JSC::WASMFunctionLLVMIRGenerator::buildReturn):
2978         (JSC::WASMFunctionLLVMIRGenerator::buildImmediateI32):
2979         (JSC::WASMFunctionLLVMIRGenerator::buildImmediateF32):
2980         (JSC::WASMFunctionLLVMIRGenerator::buildImmediateF64):
2981         (JSC::WASMFunctionLLVMIRGenerator::buildGetLocal):
2982         (JSC::WASMFunctionLLVMIRGenerator::buildGetGlobal):
2983         (JSC::WASMFunctionLLVMIRGenerator::buildConvertType):
2984         (JSC::WASMFunctionLLVMIRGenerator::buildLoad):
2985         (JSC::WASMFunctionLLVMIRGenerator::buildStore):
2986         (JSC::WASMFunctionLLVMIRGenerator::buildUnaryI32):
2987         (JSC::WASMFunctionLLVMIRGenerator::buildUnaryF32):
2988         (JSC::WASMFunctionLLVMIRGenerator::buildUnaryF64):
2989         (JSC::WASMFunctionLLVMIRGenerator::buildBinaryI32):
2990         (JSC::WASMFunctionLLVMIRGenerator::buildBinaryF32):
2991         (JSC::WASMFunctionLLVMIRGenerator::buildBinaryF64):
2992         (JSC::WASMFunctionLLVMIRGenerator::buildRelationalI32):
2993         (JSC::WASMFunctionLLVMIRGenerator::buildRelationalF32):
2994         (JSC::WASMFunctionLLVMIRGenerator::buildRelationalF64):
2995         (JSC::WASMFunctionLLVMIRGenerator::buildMinOrMaxI32):
2996         (JSC::WASMFunctionLLVMIRGenerator::buildMinOrMaxF64):
2997         (JSC::WASMFunctionLLVMIRGenerator::buildCallInternal):
2998         (JSC::WASMFunctionLLVMIRGenerator::buildCallIndirect):
2999         (JSC::WASMFunctionLLVMIRGenerator::buildCallImport):
3000         (JSC::WASMFunctionLLVMIRGenerator::appendExpressionList):
3001         (JSC::WASMFunctionLLVMIRGenerator::discard):
3002         (JSC::WASMFunctionLLVMIRGenerator::linkTarget):
3003         (JSC::WASMFunctionLLVMIRGenerator::jumpToTarget):
3004         (JSC::WASMFunctionLLVMIRGenerator::jumpToTargetIf):
3005         (JSC::WASMFunctionLLVMIRGenerator::startLoop):
3006         (JSC::WASMFunctionLLVMIRGenerator::endLoop):
3007         (JSC::WASMFunctionLLVMIRGenerator::startSwitch):
3008         (JSC::WASMFunctionLLVMIRGenerator::endSwitch):
3009         (JSC::WASMFunctionLLVMIRGenerator::startLabel):
3010         (JSC::WASMFunctionLLVMIRGenerator::endLabel):
3011         (JSC::WASMFunctionLLVMIRGenerator::breakTarget):
3012         (JSC::WASMFunctionLLVMIRGenerator::continueTarget):
3013         (JSC::WASMFunctionLLVMIRGenerator::breakLabelTarget):
3014         (JSC::WASMFunctionLLVMIRGenerator::continueLabelTarget):
3015         (JSC::WASMFunctionLLVMIRGenerator::buildSwitch):
3016         * wasm/WASMFunctionParser.cpp:
3017
3018 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
3019
3020         Get rid of LLInt inline/out-of-line storage helpers, they are unused
3021         https://bugs.webkit.org/show_bug.cgi?id=149892
3022
3023         Reviewed by Mark Lam.
3024
3025         Just killing dead code.
3026
3027         * llint/LowLevelInterpreter.asm:
3028
3029 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
3030
3031         Don't setOutOfBounds in JIT code for PutByVal, since the C++ slow path already does it
3032         https://bugs.webkit.org/show_bug.cgi?id=149885
3033
3034         Reviewed by Geoffrey Garen.
3035
3036         This simplifies the slow path code, which will make it easier to put read barriers on all of
3037         the butterflies.
3038
3039         * jit/JITOperations.cpp:
3040         (JSC::getByVal):
3041         * jit/JITPropertyAccess.cpp:
3042         (JSC::JIT::emitSlow_op_put_by_val):
3043
3044 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
3045
3046         Get rid of JIT::compilePutDirectOffset
3047         https://bugs.webkit.org/show_bug.cgi?id=149884
3048
3049         Reviewed by Andreas Kling.
3050
3051         I'm finding more dead code.
3052
3053         * jit/JIT.h:
3054         * jit/JITPropertyAccess.cpp:
3055         (JSC::JIT::emitSlow_op_put_by_id):
3056         (JSC::JIT::emitVarInjectionCheck):
3057         (JSC::JIT::compilePutDirectOffset): Deleted.
3058
3059 2015-10-07  Joseph Pecoraro  <pecoraro@apple.com>
3060
3061         Heap::isWriteBarrierEnabled is unused
3062         https://bugs.webkit.org/show_bug.cgi?id=149881
3063
3064         Reviewed by Geoffrey Garen.
3065
3066         * heap/Heap.h:
3067         * heap/HeapInlines.h:
3068         (JSC::Heap::isWriteBarrierEnabled): Deleted.
3069
3070 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
3071
3072         JIT::emitGetGlobalProperty/emitPutGlobalProperty are only called from one place
3073         https://bugs.webkit.org/show_bug.cgi?id=149879
3074
3075         Reviewed by Saam Barati.
3076
3077         To simplify my work to insert barriers on loads of the butterfly, I want to reduce the amount
3078         of abstraction we have around code that loads the butterfly.
3079
3080         * jit/JIT.h:
3081         * jit/JITPropertyAccess.cpp:
3082         (JSC::JIT::emitLoadWithStructureCheck):
3083         (JSC::JIT::emitGetVarFromPointer):
3084         (JSC::JIT::emit_op_get_from_scope):
3085         (JSC::JIT::emitSlow_op_get_from_scope):
3086         (JSC::JIT::emitPutGlobalVariable):
3087         (JSC::JIT::emit_op_put_to_scope):
3088         (JSC::JIT::emitGetGlobalProperty): Deleted.
3089         (JSC::JIT::emitPutGlobalProperty): Deleted.
3090         * jit/JITPropertyAccess32_64.cpp:
3091         (JSC::JIT::emitLoadWithStructureCheck):
3092         (JSC::JIT::emitGetVarFromPointer):
3093         (JSC::JIT::emit_op_get_from_scope):
3094         (JSC::JIT::emitSlow_op_get_from_scope):
3095         (JSC::JIT::emitPutGlobalVariable):
3096         (JSC::JIT::emit_op_put_to_scope):
3097         (JSC::JIT::emitGetGlobalProperty): Deleted.
3098         (JSC::JIT::emitPutGlobalProperty): Deleted.
3099
3100 2015-10-07  Filip Pizlo  <fpizlo@apple.com>
3101
3102         JIT::compileGetDirectOffset is useless
3103         https://bugs.webkit.org/show_bug.cgi?id=149878
3104
3105         Reviewed by Mark Lam.
3106
3107         Two of the overloads of this method were never called. The other was called only from one
3108         place, in a manner that rendered most of its code dead. This change removes the dead code and
3109         folds the method into its one caller.
3110
3111         * jit/JIT.h:
3112         * jit/JITPropertyAccess.cpp:
3113         (JSC::JIT::emitSlow_op_get_by_val):
3114         (JSC::JIT::emit_op_put_by_val):
3115         (JSC::JIT::compilePutDirectOffset):
3116         (JSC::JIT::emitVarInjectionCheck):
3117         (JSC::JIT::emitGetGlobalProperty):
3118         (JSC::JIT::emitGetVarFromPointer):
3119         (JSC::JIT::compileGetDirectOffset): Deleted.
3120         * jit/JITPropertyAccess32_64.cpp:
3121         (JSC::JIT::compilePutDirectOffset):
3122         (JSC::JIT::emitVarInjectionCheck):
3123         (JSC::JIT::emitGetGlobalProperty):
3124         (JSC::JIT::emitGetVarFromPointer):
3125         (JSC::JIT::compileGetDirectOffset): Deleted.
3126
3127 2015-10-06  Filip Pizlo  <fpizlo@apple.com>
3128
3129         Inline caches should handle out-of-line offsets out-of-line
3130         https://bugs.webkit.org/show_bug.cgi?id=149869
3131
3132         Reviewed by Saam Barati.
3133
3134         If we want to have a concurrent copying GC, then we need a read barrier on copied space
3135         pointers. That makes the convertible load portion of the get_by_id/put_by_id inline caches
3136         rather challenging. Currently we have a load instruction that we can turn into an add
3137         instruction - the add case is when we have an inline offset, and the load case is when we
3138         have an out-of-line offset and we need to load a copied space pointer. But if the load from
3139         copied space requires a barrier, then there is no easy way to convert that back to the inline
3140         case.
3141
3142         This patch removes the convertible load. The inline path of get_by_id/put_by_id only handles
3143         the inline offsets. Out-of-line offsets are now handled using out-of-line stubs.
3144
3145         * bytecode/StructureStubInfo.h:
3146         * ftl/FTLInlineCacheSize.cpp:
3147         (JSC::FTL::sizeOfGetById):
3148         (JSC::FTL::sizeOfPutById):
3149         * jit/JITInlineCacheGenerator.cpp:
3150         (JSC::JITByIdGenerator::finalize):
3151         (JSC::JITByIdGenerator::generateFastPathChecks):
3152         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
3153         (JSC::JITGetByIdGenerator::generateFastPath):
3154         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
3155         (JSC::JITPutByIdGenerator::generateFastPath):
3156         * jit/JITInlineCacheGenerator.h:
3157         * jit/Repatch.cpp:
3158         (JSC::repatchByIdSelfAccess):
3159         (JSC::tryCacheGetByID):
3160         (JSC::tryCachePutByID):
3161         * runtime/JSObject.h:
3162         (JSC::JSObject::butterflyTotalSize):
3163         (JSC::indexRelativeToBase):
3164         (JSC::offsetRelativeToBase):
3165         (JSC::maxOffsetRelativeToBase):
3166         (JSC::makeIdentifier):
3167         (JSC::offsetRelativeToPatchedStorage): Deleted.
3168         (JSC::maxOffsetRelativeToPatchedStorage): Deleted.
3169
3170 2015-10-07  Commit Queue  <commit-queue@webkit.org>
3171
3172         Unreviewed, rolling out r190664.
3173         https://bugs.webkit.org/show_bug.cgi?id=149877
3174
3175         mac build is sometimes borken due to missing generated header
3176         file (Requested by youenn on #webkit).
3177
3178         Reverted changeset:
3179
3180         "Automate WebCore JS builtins generation and build system"
3181         https://bugs.webkit.org/show_bug.cgi?id=149751
3182         http://trac.webkit.org/changeset/190664
3183
3184 2015-10-07  Xabier Rodriguez Calvar  <calvaris@igalia.com> and Youenn Fablet  <youenn.fablet@crf.canon.fr>
3185
3186         Automate WebCore JS builtins generation and build system
3187         https://bugs.webkit.org/show_bug.cgi?id=149751
3188
3189         Reviewed by Darin Adler.
3190
3191         * generate-js-builtins: updating the part related to WebCore JS binding.
3192
3193 2015-10-06  Mark Lam  <mark.lam@apple.com>
3194
3195         Factoring out op_sub baseline code generation into JITSubGenerator.
3196         https://bugs.webkit.org/show_bug.cgi?id=149600
3197
3198         Reviewed by Geoffrey Garen.
3199
3200         We're going to factor out baseline code generation into snippet generators so
3201         that we can later use them in the DFG and FTL to emit code for to perform the
3202         JS operations where the operand types are predicted to be polymorphic.
3203         We are starting in this patch with the implementation of op_sub.
3204
3205         What was done in this patch:
3206         1. Created JITSubGenerator based on the baseline implementation of op_sub as
3207            expressed in compileBinaryArithOp() and compileBinaryArithOpSlowCase().
3208            I did not attempt to do write a more optimal version of op_sub.  I'll
3209            leave that to a later patch.
3210
3211         2. Convert the 32-bit op_sub baseline implementation to use the same
3212            JITSubGenerator which was based on the 64-bit implementation.  The
3213            pre-existing 32-bit baseline op_sub had handling for more optimization cases.
3214            However, a benchmark run shows that simply going with the 64-bit version
3215            (foregoing those extra optimizations) did not change the performance.
3216
3217            Also, previously, the 32-bit version was able to move double results directly
3218            into the result location on the stack directly.  By using JITSubGenerator,
3219            we now always move that result into a pair of GPRs before storing it into
3220            the stack location.
3221
3222         3. Add some needed emitters to AssemblyHelpers that play nice with JSValueRegs.
3223
3224         * JavaScriptCore.xcodeproj/project.pbxproj:
3225         * jit/AssemblyHelpers.h:
3226         (JSC::AssemblyHelpers::boxDouble):
3227         (JSC::AssemblyHelpers::unboxDouble):
3228         (JSC::AssemblyHelpers::boxBooleanPayload):
3229         * jit/JIT.h:
3230         (JSC::JIT::linkDummySlowCase):
3231         * jit/JITArithmetic.cpp:
3232         (JSC::JIT::compileBinaryArithOp):
3233         (JSC::JIT::compileBinaryArithOpSlowCase):
3234         (JSC::JIT::emitSlow_op_div):
3235         (JSC::JIT::emit_op_sub):
3236         (JSC::JIT::emitSlow_op_sub):
3237         * jit/JITArithmetic32_64.cpp:
3238         (JSC::JIT::emitBinaryDoubleOp):
3239         (JSC::JIT::emit_op_sub): Deleted.
3240         (JSC::JIT::emitSub32Constant): Deleted.
3241         (JSC::JIT::emitSlow_op_sub): Deleted.
3242         * jit/JITInlines.h:
3243         (JSC::JIT::linkSlowCaseIfNotJSCell):
3244         (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
3245         (JSC::JIT::addSlowCase):
3246         (JSC::JIT::emitLoad):
3247         (JSC::JIT::emitGetVirtualRegister):
3248         (JSC::JIT::emitPutVirtualRegister):
3249         * jit/JITSubGenerator.h: Added.
3250         (JSC::JITSubGenerator::JITSubGenerator):
3251         (JSC::JITSubGenerator::generateFastPath):
3252         (JSC::JITSubGenerator::slowPathJumpList):
3253
3254 2015-10-06  Daniel Bates  <dbates@webkit.org>
3255
3256         Enable XSLT when building WebKit for iOS using the public iOS SDK
3257         https://bugs.webkit.org/show_bug.cgi?id=149827
3258
3259         Reviewed by Alexey Proskuryakov.
3260
3261         * Configurations/FeatureDefines.xcconfig:
3262
3263 2015-10-05  Commit Queue  <commit-queue@webkit.org>
3264
3265         Unreviewed, rolling out r190599.
3266         https://bugs.webkit.org/show_bug.cgi?id=149836
3267
3268         Made perf tests randomly crash (Requested by ap on #webkit).
3269
3270         Reverted changeset:
3271
3272         "GC shouldn't cancel every FTL compilation"
3273         https://bugs.webkit.org/show_bug.cgi?id=149821
3274         http://trac.webkit.org/changeset/190599
3275
3276 2015-10-05  Commit Queue  <commit-queue@webkit.org>
3277
3278         Unreviewed, rolling out r190589.
3279         https://bugs.webkit.org/show_bug.cgi?id=149833
3280
3281         Caused lots of leaks, and possibly crashes (Requested by ap on
3282         #webkit).
3283
3284         Reverted changeset:
3285
3286         "Unreviewed, rolling back in r190450"
3287         https://bugs.webkit.org/show_bug.cgi?id=149727
3288         http://trac.webkit.org/changeset/190589
3289
3290 2015-10-05  Geoffrey Garen  <ggaren@apple.com>
3291
3292         Remove a few includes from JSGlobalObject.h
3293         https://bugs.webkit.org/show_bug.cgi?id=148004
3294
3295         Reviewed by Saam Barati.
3296
3297         * parser/VariableEnvironment.cpp:
3298         * parser/VariableEnvironment.h:
3299         * runtime/JSGlobalObject.h:
3300         * runtime/JSString.cpp:
3301         (JSC::JSString::createStructure):
3302         (JSC::JSRopeString::RopeBuilder::expand):
3303         * runtime/JSString.h:
3304         (JSC::JSString::canGetIndex):
3305         (JSC::JSString::offsetOfLength):
3306         (JSC::JSString::offsetOfFlags):
3307         (JSC::JSString::createStructure): Deleted.
3308         * runtime/Structure.h:
3309         * runtime/StructureInlines.h:
3310         * runtime/StructureRareDataInlines.h:
3311
3312 2015-10-05  Filip Pizlo  <fpizlo@apple.com>
3313
3314         GC shouldn't cancel every FTL compilation
3315         https://bugs.webkit.org/show_bug.cgi?id=149821
3316
3317         Reviewed by Saam Barati.
3318
3319         During one of the CodeBlock GC refactorings, we messed up the GC's compilation cancellation
3320         code. The GC should be able to cancel compilation plans if it determines that the plan will
3321         be DOA. But, prior to this fix, that code was killing every FTL compilation. This happened
3322         because the meaning of CodeBlock::isKnownToBeLiveDuringGC() changed.
3323
3324         It's funny that this didn't show up as a bigger slow-down. Basically, those benchmarks that
3325         GC a lot usually don't rely on good compilation, while those benchmarks that do rely on good
3326         compilation usually don't GC a lot. That's probably why this wasn't super obvious when we
3327         broke it.
3328
3329         This change just changes the cancellation logic so that it only cancels plans if the owning
3330         executable is dead. This is safe; in fact the relevant method would be correct even if it
3331         always returned true. It would also be correct if it always returned false. So, compared to
3332         what we had before we changed isKnownToBeLiveDuringGC(), this new code will cancel fewer
3333         compilations. But, that's better than cancelling every compilation. I've filed a bug and
3334         written a FIXME for investigating ways to resurrect the old behavior:
3335         https://bugs.webkit.org/show_bug.cgi?id=149823
3336
3337         Nonetheless, this change looks like it might be a 1% speed-up on Octane. It improves earley
3338         and gbemu.
3339
3340         * dfg/DFGPlan.cpp:
3341         (JSC::DFG::Plan::isKnownToBeLiveDuringGC):
3342
3343 2015-10-05  Sukolsak Sakshuwong  <sukolsak@gmail.com>
3344
3345         [Intl] Change the return type of canonicalizeLocaleList() from JSArray* to Vector<String>
3346         https://bugs.webkit.org/show_bug.cgi?id=149807
3347
3348         Reviewed by Benjamin Poulain.
3349
3350         From ECMA-402, 9.2.1, the abstract operation CanonicalizeLocaleList
3351         returns a List of Strings. From the spec, we never modify the result
3352         from CanonicalizeLocaleList(). We never expose it to the user either.
3353         This patch changes the return type of canonicalizeLocaleList() from
3354         JSArray* to Vector<String>. This should ease the workload of the GC and
3355         make the code a bit easier to read.
3356
3357         * runtime/IntlCollatorConstructor.cpp:
3358         (JSC::IntlCollatorConstructorFuncSupportedLocalesOf):
3359         * runtime/IntlDateTimeFormatConstructor.cpp:
3360         (JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf):
3361         * runtime/IntlNumberFormatConstructor.cpp:
3362         (JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf):
3363         * runtime/IntlObject.cpp:
3364         (JSC::canonicalizeLocaleList):
3365         (JSC::lookupSupportedLocales):
3366         (JSC::bestFitSupportedLocales):
3367         (JSC::supportedLocales):
3368         * runtime/IntlObject.h:
3369
3370 2015-10-01  Geoffrey Garen  <ggaren@apple.com>
3371
3372         Unreviewed, rolling back in r190450
3373         https://bugs.webkit.org/show_bug.cgi?id=149727
3374
3375         The cause of the leak was VM shutdown, which happens in workers.
3376
3377         The fix is for CodeBlockSet to participate in lastChanceToFinalize,
3378         since it's responsible for running CodeBlock destructors.
3379
3380         I ran the leaks tests locally and did not see any CodeBlock-related leaks.
3381
3382         Restored changesets:
3383
3384         "CodeBlock should be a GC object"
3385         https://bugs.webkit.org/show_bug.cgi?id=149727
3386         http://trac.webkit.org/changeset/190450
3387
3388 2015-10-03  Filip Pizlo  <fpizlo@apple.com>
3389
3390         Allow an object's marking state to track The Three Colors
3391         https://bugs.webkit.org/show_bug.cgi?id=149654
3392
3393         Reviewed by Geoffrey Garen.
3394
3395         I want to make GC marking concurrent (see https://bugs.webkit.org/show_bug.cgi?id=149432).
3396         Concurrent GC require barriers to be executed during certain heap operations. We already have a
3397         generational GC. Generational GCs also need barriers, and we already have those. The generational
3398         GC barrier that we use is the "sticky mark bit" barrier. Ordinarily, mark bits get reset after a
3399         collection. In our collector, there is a secondary mark bit that "sticks" - i.e. it does not get
3400         reset. If the sticky mark bit is set in between two collections, then we know that the object is in
3401         old space. This is sufficient to determine when to put things into remembered sets. Additionally,
3402         the sticky mark bit is actually a tri-state that can also tell us if the object has been placed on
3403         a remembered set.
3404
3405         This is awfully similar to what you want in a concurrent GC. Concurrent GCs typically want writes
3406         to the heap that change the object graph to do different things depending on an object's marking
3407         state, which is usually referred to as its color. White means that the object has never been seen
3408         by the collector. All white objects are presumed dead at the flip. Grey objects are those that are
3409         known to the collector but have not been scanned. Black objects are those that have been scanned,
3410         and will not be scanned again. White is exactly just "not being marked", and both grey and black
3411         mean "marked" - with "black" meaning "marked but not on any worklist". That's quite a bit like the
3412         current "Marked" and "MarkedAndRemembered" states that we have for generational GC.
3413         "MarkedAndRemembered" is a lot like "grey", and "Marked" is a lot like "black".
3414
3415         I want to make a concurrent GC that unifies the generational and concurrent barriers into a single
3416         fast path check. Even better if the two barriers are entirely identical. You can do this using
3417         Pirinen's technique #2 [1], originally due to Guy Steele [2]: when doing o.f=v where o is black and
3418         v is white, turn o grey again. This is like remembering an object, in the sense that our gen GC
3419         "rememberes" o when o is old and v is new. It remembers objects by putting them on the mark stack,
3420         setting the generational state to MarkedAndRemembered, and doing nothing to the primary mark bit.
3421
3422         This makes our concurrent GC approach pretty obvious. We want to use one barrier for concurrent and
3423         generational, and we want to basically keep our current barriers unchanged. The only things missing
3424         are just some small changes to allow the concurrent GC to know precisely when an object is black,
3425         and to know during object visiting if we are visiting the object for the first time during a
3426         collection or a subsequent time due to barrier re-greying (concurrent GC) or barrier remembering
3427         (generational GC). So, this patch does the following:
3428
3429         - Changes the terminology used for the gcData header byte in JSCell. This changes the name of this
3430           to cellState, and introduces a new enumeration called CellState. This new enumeration behaves a
3431           lot like the old GCData did. It has the following members, with the following correspondence to
3432           the old GCData:
3433
3434           OldBlack: this is like Marked, with the exception that we ensure that an object becomes OldBlack
3435               as soon as the object starts to be scanned. Previously, an object might be
3436               MarkedAndRemembered during scanning and we'd turn all MarkedAndRemembered objects into Marked
3437               objects during a post-processing step at the end of GC. This patch gets rid of that
3438               post-processing. The act of visiting an object unconditionally makes it OldBlack. Note that
3439               our definition of "black" is not that the object is done being scanned, but that it is either
3440               being scanned right now or it has already been scanned. This is like a combination of
3441               Siebert's anthracite and black states [3].
3442
3443           NewWhite: this is exactly NotMarked. It's the state that objects get when they are allocated.
3444               It's impossible for an object to return to this state.
3445
3446           OldGrey: the object is on the mark stack and will be scanned at some point in the future. This
3447               also means that this isn't the first time in this cycle that the object has been grey. In an
3448               eden collection, an old object that has been remembered is thought of as being OldGrey, even
3449               if this is the first time during this eden collection that it is grey. That's because an eden
3450               collection must behave "as if" the grey->black transition for old objects magically happened
3451               at the start of GC. Remembered objects are like old objects that underwent a concurrent
3452               barrier re-greying just after the magical old object grey->black transition at the start of
3453               GC. This state is almost exactly like MarkedAndRemembered, except that an object now
3454               transitions from OldGrey to OldBlack at the beginning of visiting, rather than how previously
3455               we transitioned from MarkedAndRemembered to Marked at the bitter end of GC.
3456
3457           NewGray: the object is on the mark stack and will be scanned at some point in the future. This
3458               state has no clear relative in the old state system. It means that the object became grey due
3459               to ordinary marking. Previously, ordinary marking would make the object Marked.
3460
3461         - Removal of the post-processing phase that "clears" the remembered set by moving all remembered
3462           objects to the Marked state. This now happens magically during visiting, as described above.
3463
3464         - SlotVisitor now remembers the state that the object did have just before visiting. While visiting
3465           that object, it's possible to query what the state was. This is used for copy space decisions and
3466           for extra memory usage accounting. We don't want to put the backing store on the copy worklist,
3467           and we don't want to count extra memory usage, if the object was OldGrey at the start of
3468           visiting. Previously, we would be able to just ask if the object was MarkedAndRemembered since
3469           that state wouldn't get cleared until after all marking finished. This change also simplifies
3470           some APIs, because there is no need to pass the JSCell* pointer, since these SlotVisitor methods
3471           no longer ask the cell for its state - instead they use the saved pre-visiting state.
3472
3473         - Removal of a bunch of helpers and abstractions. Previously we had various methods for asking if
3474           an object was "marked" and if an object was "remembered". We had helpers for adjusting these
3475           states, and those helpers would assert that they were being used the right way. This is not very
3476           useful for concurrent GC, since now the set of possible state transitions is much larger. Also,
3477           the previous use of the word "marked" was pretty bad - for example in Heap, "marked" refers to
3478           the primary mark bit (that gets cleared at the flip), while in JSCell, "marked" refers to the
3479           sticky mark bit (that does not get cleared, ever). This change gets rid of a lot of those helpers
3480           and inlines their logic. This actually makes the code easier and more fun to read, since you can
3481           now look at the marking and barrier code and see how that code uses the four CellStates. For
3482           example, it's fun to see that the barrier gets fired for o.f=v exactly when o is OldBlack and v
3483           is NewWhite.
3484
3485         This change shouldn't have any effect on performance or GC behavior. It does put our code in a
3486         weird state where we now have states and comments referencing a concurrent GC that doesn't exist
3487         yet.
3488
3489         Finally, some thoughts about the concurrent GC barrier and its implications for performance. This
3490         barrier exhibits very poor guarantees about collector progress, but maximizes throughput by just
3491         reusing the existing barrier code we already emit and optimize. I believe that even our epoch-based
3492         barrier insertion DFG phase is correct for the concurrent interpretation of our existing barrier.
3493         But, the barrier can regress the progress that the collector has made for two reasons:
3494
3495         Incremental update: you don't want to use this barrier with a black stack, since that would mean
3496         that heap loads of white objects will have to explicitly re-grey the stack. The way you implement
3497         this kind of collector is that collector termination will rescan the stack. Termination is reached
3498         only if the at-termination re-scan greys no objects. This means that the collector is a fixpoint.
3499         Luckily, our collector is already a fixpoint because of opaque roots and structure transitions.
3500
3501         Marking ain't monotonic: normally, once an object is black, it stays that way. In this collector,
3502         black objects may become grey again. I don't have personal experience with such concurrent GCs, but
3503         I suspect that this will basically be fine. Concurrent collections finish pretty quickly, and the
3504         mutator usually touches only a subset of the heap. Only that subset of the heap that the mutator is
3505         touching could be re-greyed. Probably, the GC will have to be hybrid incremental and concurrent,
3506         and towards the end of GC when we do the termination stack re-scan, we can ensure that the
3507         collector does some minimal amount of marking. If the minimal amount of marking done by the
3508         collector is large enough, we can ensure that we reach termination before the mutator can regress
3509         progress. The barrier cannot un-terminate the collector; if the collector reaches termination and
3510         the barrier re-greys an object then it's actually doing a generational remembering rather than a
3511         concurrent re-greying.
3512
3513         That's sort of the cute thing about the barrier - it is exactly a re-greying barrier during GC and
3514         it is exactly a remembering barrier in between GCs.
3515
3516         [1] http://www.cs.utexas.edu/ftp/garbage/submit/readable/ppirinen11.ps
3517         [2] http://dl.acm.org/citation.cfm?id=361005
3518         [3] http://www.aicas.com/papers/ISMM132-siebert.pdf
3519
3520         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3521         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3522         * JavaScriptCore.xcodeproj/project.pbxproj:
3523         * bytecode/CodeBlock.cpp:
3524         (JSC::CodeBlock::visitChildren):
3525         * ftl/FTLAbstractHeapRepository.cpp:
3526         (JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
3527         * ftl/FTLAbstractHeapRepository.h:
3528         * ftl/FTLLowerDFGToLLVM.cpp:
3529         (JSC::FTL::DFG::LowerDFGToLLVM::masqueradesAsUndefinedWatchpointIsStillValid):
3530         (JSC::FTL::DFG::LowerDFGToLLVM::loadCellState):
3531         (JSC::FTL::DFG::LowerDFGToLLVM::emitStoreBarrier):
3532         (JSC::FTL::DFG::LowerDFGToLLVM::loadMarkByte): Deleted.
3533         * heap/CellState.h: Added.
3534         * heap/CodeBlockSet.cpp:
3535         (JSC::CodeBlockSet::rememberCurrentlyExecutingCodeBlocks):
3536         * heap/CopiedBlock.h:
3537         * heap/CopiedBlockInlines.h:
3538         (JSC::CopiedBlock::reportLiveBytes):
3539         (JSC::CopiedBlock::shouldReportLiveBytes): Deleted.
3540         * heap/GCLogging.cpp:
3541         (JSC::LoggingFunctor::reviveCells):
3542         * heap/Heap.cpp:
3543         (JSC::Heap::markRoots):
3544         (JSC::Heap::visitWeakHandles):
3545         (JSC::Heap::updateObjectCounts):
3546         (JSC::Heap::addToRememberedSet):
3547         (JSC::Heap::clearRememberedSet): Deleted.
3548         * heap/Heap.h:
3549         * heap/HeapInlines.h:
3550         (JSC::Heap::isLive):
3551         (JSC::Heap::isMarked):
3552         (JSC::Heap::writeBarrier):
3553         (JSC::Heap::reportExtraMemoryAllocated):
3554         (JSC::Heap::reportExtraMemoryVisited):
3555         (JSC::Heap::isRemembered): Deleted.
3556         * heap/SlotVisitor.cpp:
3557         (JSC::SlotVisitor::append):
3558         (JSC::SlotVisitor::visitChildren):
3559         (JSC::SlotVisitor::donateKnownParallel):
3560         (JSC::SlotVisitor::drain):
3561         (JSC::visitChildren): Deleted.
3562         * heap/SlotVisitor.h:
3563         (JSC::SlotVisitor::childCount):
3564         (JSC::SlotVisitor::incrementChildCount):
3565         (JSC::SlotVisitor::dataBeforeVisitingCurrentObject):
3566         * heap/SlotVisitorInlines.h:
3567         (JSC::SlotVisitor::internalAppend):
3568         (JSC::SlotVisitor::copyLater):
3569         (JSC::SlotVisitor::reportExtraMemoryVisited):
3570         (JSC::SlotVisitor::heap):
3571         * jit/AssemblyHelpers.h:
3572         (JSC::AssemblyHelpers::jumpIfIsRememberedOrInEden):
3573         * llint/LowLevelInterpreter.asm:
3574         * llint/LowLevelInterpreter32_64.asm:
3575         * llint/LowLevelInterpreter64.asm:
3576         * runtime/JSCell.h:
3577         (JSC::JSCell::cellState):
3578         (JSC::JSCell::setCellState):
3579         (JSC::JSCell::structureIDOffset):
3580         (JSC::JSCell::indexingTypeOffset):
3581         (JSC::JSCell::cellStateOffset):
3582         (JSC::JSCell::setMarked): Deleted.
3583         (JSC::JSCell::setRemembered): Deleted.
3584         (JSC::JSCell::isMarked): Deleted.
3585         (JSC::JSCell::isRemembered): Deleted.
3586         (JSC::JSCell::gcDataOffset): Deleted.
3587         * runtime/JSCellInlines.h:
3588         (JSC::JSCell::JSCell):
3589         * runtime/JSGenericTypedArrayViewInlines.h:
3590         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
3591         * runtime/JSObject.cpp:
3592         (JSC::JSObject::copyBackingStore):
3593         * runtime/JSString.cpp:
3594         (JSC::JSString::visitChildren):
3595         * runtime/StructureIDBlob.h:
3596         (JSC::StructureIDBlob::StructureIDBlob):
3597         (JSC::StructureIDBlob::operator=):
3598         * runtime/WeakMapData.cpp:
3599         (JSC::WeakMapData::visitChildren):
3600         (JSC::WeakMapData::set):
3601         * tests/stress/basic-eden-gc-test.js: Added.
3602             Hilariously, an earlier version of this patch that didn't have the NewGrey/OldGrey distinction
3603             would only crash super-big tests that GCd twice but it didn't crash any small focused test. All
3604             it took to show the need for the NewGrey/OldGrey distinction was this super simple test.
3605
3606 2015-10-05  Geoffrey Garen  <ggaren@apple.com>
3607
3608         JSC::SlotVisitor should not be a hot mess
3609         https://bugs.webkit.org/show_bug.cgi?id=149798
3610
3611         Reviewed by Andreas Kling.
3612
3613         I had to debug JSC::SlotVisitor the other day. It was hard to follow.
3614         Let's make it easy to follow.
3615
3616         * heap/Heap.cpp:
3617         (JSC::Heap::markRoots):
3618         (JSC::Heap::resetVisitors):
3619         (JSC::Heap::objectCount):
3620         (JSC::Heap::addToRememberedSet):
3621         (JSC::Heap::collectAndSweep):
3622         * heap/Heap.h: Deleted the string hash-consing code. It
3623         was dead code.
3624
3625         Since no benchmark noticed the commit that broke this feature, perhaps
3626         it's not worth having.
3627
3628         Either way, the best thing to do with dead code is to delete it.
3629         It's still there in svn if we ever want to pick it up again.
3630
3631         * heap/HeapRootVisitor.h:
3632         (JSC::HeapRootVisitor::visit):
3633         (JSC::HeapRootVisitor::visitor): Removed the private append functions
3634         for unsafe pointers and switched HeapRootVisitor over to the public
3635         specially named functions for unsafe pointers.
3636
3637         In future, we should either remove the public specially named functions
3638         or remove HeapRootVisitor, since they serve the same purpose. At least
3639         for now we don't have pairs of functions on SlotVisitor that do the
3640         exact same thing.
3641
3642         * heap/SlotVisitor.cpp:
3643         (JSC::validate): Moved this static function to the top of the file.
3644
3645         (JSC::SlotVisitor::SlotVisitor):
3646         (JSC::SlotVisitor::didStartMarking):
3647         (JSC::SlotVisitor::reset): More hash cons removal.
3648
3649         (JSC::SlotVisitor::append):
3650
3651         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
3652         (JSC::SlotVisitor::appendToMarkStack): Renamed these functions to 
3653         distinguish them from the up-front helper functions that just do type
3654         conversions. These are the functions that actually do stuff.
3655
3656         Moved these functions out of line to make it easier to set breakpoints,
3657         and to enable code changes for debugging, like printf and synchronous
3658         marking, without recompiling the world.
3659
3660         setMarkedAndAppendToMarkStack is roughly 258 bytes long (not including
3661         function prologue and epilogue), so inlining it was probably not a
3662         great idea in the first place.
3663
3664         (JSC::SlotVisitor::donateKnownParallel):
3665         (JSC::SlotVisitor::drain):
3666         (JSC::SlotVisitor::drainFromShared): Removed some stack probing code.
3667         It was also dead.
3668
3669         (JSC::SlotVisitor::addOpaqueRoot):
3670         (JSC::SlotVisitor::containsOpaqueRoot):
3671         (JSC::SlotVisitor::containsOpaqueRootTriState):
3672         (JSC::SlotVisitor::opaqueRootCount):
3673         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary):
3674         (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable):
3675         (JSC::SlotVisitor::donate):
3676         (JSC::SlotVisitor::donateAndDrain):
3677         (JSC::SlotVisitor::copyLater):
3678         (JSC::SlotVisitor::mergeOpaqueRoots):
3679         (JSC::SlotVisitor::harvestWeakReferences):
3680         (JSC::SlotVisitor::finalizeUnconditionalFinalizers):
3681         (JSC::SlotVisitor::dump): Moved more code out-of-line. These code paths
3682         are not hot and/or not small, so we need more evidence before we inline
3683         them. The SlotVisitor headers are included everywhere, so we should
3684         make them include less.
3685
3686         Removed "internal" from all function names because it wasn't applied in
3687         any consistent way that would mean anything.
3688
3689         (JSC::JSString::tryHashConsLock): Deleted.
3690         (JSC::JSString::releaseHashConsLock): Deleted.
3691         (JSC::JSString::shouldTryHashCons): Deleted.
3692         (JSC::SlotVisitor::internalAppend): Deleted.
3693         (JSC::SlotVisitor::validate): Deleted.
3694
3695         * heap/SlotVisitor.h:
3696         (JSC::SlotVisitor::resetChildCount): Deleted.
3697         (JSC::SlotVisitor::childCount): Deleted.
3698         (JSC::SlotVisitor::incrementChildCount): Deleted. Removed this child
3699         count thing. It was dead code.
3700
3701         * heap/SlotVisitorInlines.h:
3702         (JSC::SlotVisitor::appendUnbarrieredPointer):
3703         (JSC::SlotVisitor::appendUnbarrieredReadOnlyPointer):
3704         (JSC::SlotVisitor::appendUnbarrieredValue):
3705         (JSC::SlotVisitor::appendUnbarrieredReadOnlyValue): Some renaming and un-inlining.
3706
3707         (JSC::SlotVisitor::appendUnbarrieredWeak): Don't null check our input.
3708         The one true place where null checking happens is our out-of-line
3709         code. All inline functions do only type conversions.
3710
3711         (JSC::SlotVisitor::append):
3712         (JSC::SlotVisitor::appendValues):
3713         (JSC::SlotVisitor::addWeakReferenceHarvester):
3714         (JSC::SlotVisitor::addUnconditionalFinalizer):
3715         (JSC::SlotVisitor::reportExtraMemoryVisited): Some renaming and un-inlining.
3716
3717         (JSC::SlotVisitor::internalAppend): Deleted.
3718         (JSC::SlotVisitor::unconditionallyAppend): Deleted.
3719         (JSC::SlotVisitor::addOpaqueRoot): Deleted.
3720         (JSC::SlotVisitor::containsOpaqueRoot): Deleted.
3721         (JSC::SlotVisitor::containsOpaqueRootTriState): Deleted.
3722         (JSC::SlotVisitor::opaqueRootCount): Deleted.
3723         (JSC::SlotVisitor::mergeOpaqueRootsIfNecessary): Deleted.
3724         (JSC::SlotVisitor::mergeOpaqueRootsIfProfitable): Deleted.
3725         (JSC::SlotVisitor::donate): Deleted.
3726         (JSC::SlotVisitor::donateAndDrain): Deleted.
3727         (JSC::SlotVisitor::copyLater): Deleted.
3728
3729         * runtime/JSString.h:
3730         (JSC::JSString::finishCreation):
3731         (JSC::JSString::setIs8Bit):
3732         (JSC::JSString::isHashConsSingleton): Deleted.
3733         (JSC::JSString::clearHashConsSingleton): Deleted.
3734         (JSC::JSString::setHashConsSingleton): Deleted. More hash cons removal.
3735
3736         * runtime/VM.cpp:
3737         (JSC::VM::VM):
3738         * runtime/VM.h:
3739         (JSC::VM::currentThreadIsHoldingAPILock):
3740         (JSC::VM::apiLock):
3741         (JSC::VM::haveEnoughNewStringsToHashCons): Deleted.
3742         (JSC::VM::resetNewStringsSinceLastHashCons): Deleted. More hash cons removal.
3743
3744 2015-10-04  Filip Pizlo  <fpizlo@apple.com>
3745
3746         Inline cache repatching should be throttled if it happens a lot
3747         https://bugs.webkit.org/show_bug.cgi?id=149796
3748         rdar://problem/22674436
3749
3750         Reviewed by Saam Barati.
3751
3752         We noticed a slight PLT regression from http://trac.webkit.org/changeset/189586. It's because
3753         some pages do things that our inline caches mishandle, in the sense that some ICs end up
3754         repatching themselves very frequently. The cost of repatching outweighs the speed-up on those
3755         pages. There are probably super smart things we could do to tune the IC heuristics to make the
3756         ICs do the right thing on those pages. But more fundamentally, we should ensure that our ICs
3757         back off from continuous repatching if they repatch a lot. That's what this change does.
3758
3759         With this change, StructureStubInfo counts the number of repatchings. If that exceeds a
3760         threshold, we put the IC into a cool-down mode, where some number of future repatch events do
3761         nothing but decrement the cool-down counter. The duration of cool-down increases exponentially
3762         every time we have to do it.
3763
3764         This change also outlines a lot of code. The fact that StructureStubInfo had a lot of inline
3765         methods was starting to get on my nerves. Now it only has inline methods for things that need
3766         to be inlined. Also, I changed StructureStubInfo to be a class rather than a struct. Maybe
3767         with enough such incremental changes, eventually StructureStubInfo will actually behave like a
3768         proper class.
3769
3770         This has no effect on JSC benchmarks. It progresses one of the pages that was hit by the
3771         regression by 15%. It's hard to see if this totally fixes the entire PLT regression since the
3772         geomean regression was very close to noise.
3773
3774         * bytecode/CodeBlock.cpp:
3775         (JSC::CodeBlock::printGetByIdCacheStatus):
3776         (JSC::CodeBlock::printPutByIdCacheStatus):
3777         (JSC::CodeBlock::CodeBlock):
3778         (JSC::CodeBlock::checkIfOptimizationThresholdReached):
3779         * bytecode/CodeBlock.h:
3780         * bytecode/GetByIdStatus.cpp:
3781         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
3782         (JSC::GetByIdStatus::computeFor):
3783         * bytecode/PolymorphicAccess.cpp:
3784         (JSC::PolymorphicAccess::regenerate):
3785         * bytecode/PolymorphicAccess.h:
3786         * bytecode/PutByIdStatus.cpp:
3787         (JSC::PutByIdStatus::computeForStubInfo):
3788         * bytecode/StructureStubClearingWatchpoint.h:
3789         * bytecode/StructureStubInfo.cpp:
3790         (JSC::StructureStubInfo::StructureStubInfo):
3791         (JSC::StructureStubInfo::~StructureStubInfo):
3792         (JSC::StructureStubInfo::initGetByIdSelf):
3793         (JSC::StructureStubInfo::initPutByIdReplace):
3794         (JSC::StructureStubInfo::initStub):
3795         (JSC::StructureStubInfo::deref):
3796         (JSC::StructureStubInfo::addAccessCase):
3797         * bytecode/StructureStubInfo.h:
3798         (JSC::StructureStubInfo::considerCaching):
3799         (JSC::StructureStubInfo::willRepatch):
3800         (JSC::StructureStubInfo::willCoolDown):
3801         (JSC::getStructureStubInfoCodeOrigin):
3802         (JSC::StructureStubInfo::StructureStubInfo): Deleted.
3803         (JSC::StructureStubInfo::initGetByIdSelf): Deleted.
3804         (JSC::StructureStubInfo::initPutByIdReplace): Deleted.
3805         (JSC::StructureStubInfo::initStub): Deleted.
3806         (JSC::StructureStubInfo::seenOnce): Deleted.
3807         (JSC::StructureStubInfo::setSeen): Deleted.
3808         * jit/JIT.h:
3809         * jit/JITOperations.cpp:
3810         * jit/Repatch.cpp:
3811         (JSC::tryCacheGetByID):
3812         (JSC::tryCachePutByID):
3813         (JSC::tryRepatchIn):
3814         * runtime/Options.h:
3815
3816 2015-10-04  Filip Pizlo  <fpizlo@apple.com>
3817
3818         CodeBlock.h shouldn't be included from everywhere
3819         https://bugs.webkit.org/show_bug.cgi?id=149785
3820
3821         Reviewed by Andreas Kling.
3822
3823         * JavaScriptCore.xcodeproj/project.pbxproj:
3824         * dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
3825         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
3826         * interpreter/CallFrame.cpp:
3827         (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
3828         (JSC::CallFrame::callSiteBitsAreCodeOriginIndex):
3829         (JSC::CallFrame::callSiteAsRawBits):
3830         (JSC::CallFrame::callSiteIndex):
3831         (JSC::CallFrame::hasActivation):
3832         (JSC::CallFrame::uncheckedActivation):
3833         (JSC::CallFrame::stack):
3834         * interpreter/CallFrameInlines.h: Removed.
3835         * interpreter/Interpreter.cpp:
3836         * interpreter/StackVisitor.cpp:
3837         * runtime/DirectArguments.cpp:
3838         * runtime/ErrorInstance.cpp:
3839         * runtime/JSArray.cpp:
3840         * runtime/JSCInlines.h:
3841         * runtime/LiteralParser.cpp:
3842         * runtime/NullSetterFunction.cpp:
3843         * tools/JSDollarVMPrototype.cpp:
3844
3845 2015-10-03  Commit Queue  <commit-queue@webkit.org>
3846
3847         Unreviewed, rolling out r190522.
3848         https://bugs.webkit.org/show_bug.cgi?id=149787
3849
3850         Caused a lot of leaks (Requested by ap on #webkit).
3851
3852         Reverted changeset:
3853
3854         "Unreviewed, rolling back in r190450"
3855         https://bugs.webkit.org/show_bug.cgi?id=149727
3856         http://trac.webkit.org/changeset/190522
3857
3858 2015-10-02  Matt Baker  <mattbaker@apple.com>
3859
3860         Web Inspector: Add breakpoint option to ignore n times before stopping
3861         https://bugs.webkit.org/show_bug.cgi?id=147664
3862
3863         Reviewed by Timothy Hatcher.
3864
3865         * debugger/Breakpoint.h:
3866         (JSC::Breakpoint::Breakpoint):
3867         Added ignoreCount and hitCount fields. Cleaned up initializers.
3868
3869         * debugger/Debugger.cpp:
3870         (JSC::Debugger::hasBreakpoint):
3871         If a breakpoint matches the current text position, increment breakpoint hit count and
3872         compare with ignore count before testing the breakpoint condition.
3873
3874         * inspector/ScriptBreakpoint.h:
3875         (Inspector::ScriptBreakpoint::ScriptBreakpoint):
3876         Added ignoreCount field. Cleaned up initializers.
3877
3878         * inspector/ScriptDebugServer.cpp:
3879         (Inspector::ScriptDebugServer::setBreakpoint):
3880         Added ignoreCount field.
3881
3882         * inspector/agents/InspectorDebuggerAgent.cpp:
3883         (Inspector::buildObjectForBreakpointCookie):
3884         (Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
3885         (Inspector::InspectorDebuggerAgent::setBreakpoint):
3886         (Inspector::InspectorDebuggerAgent::continueToLocation):
3887         (Inspector::InspectorDebuggerAgent::didParseSource):
3888         Plumbing for ignoreCount property.
3889