37f1c2af11360913cd6b91bce64ed523786dfc5b
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-03-13  Eric Carlson  <eric.carlson@apple.com>
2
3         [Mac] Enable WIRELESS_PLAYBACK_TARGET
4         https://bugs.webkit.org/show_bug.cgi?id=142635
5
6         Reviewed by Darin Adler.
7
8         * Configurations/FeatureDefines.xcconfig:
9
10 2015-03-13  Ryosuke Niwa  <rniwa@webkit.org>
11
12         Class constructor should throw TypeError when "called"
13         https://bugs.webkit.org/show_bug.cgi?id=142566
14
15         Reviewed by Michael Saboff.
16
17         Added ConstructorKind::None to denote code that doesn't belong to an ES6 class.
18         This allows BytecodeGenerator to emit code to throw TypeError when generating code block
19         to call ES6 class constructors.
20
21         Most of changes are about increasing the number of bits to store ConstructorKind from one
22         bit to two bits.
23
24         * bytecode/UnlinkedCodeBlock.cpp:
25         (JSC::generateFunctionCodeBlock):
26         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
27         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
28         * bytecode/UnlinkedCodeBlock.h:
29         (JSC::ExecutableInfo::ExecutableInfo):
30         (JSC::ExecutableInfo::needsActivation):
31         (JSC::ExecutableInfo::usesEval):
32         (JSC::ExecutableInfo::isStrictMode):
33         (JSC::ExecutableInfo::isConstructor):
34         (JSC::ExecutableInfo::isBuiltinFunction):
35         (JSC::ExecutableInfo::constructorKind):
36         (JSC::UnlinkedFunctionExecutable::constructorKind):
37         (JSC::UnlinkedCodeBlock::constructorKind):
38         (JSC::UnlinkedFunctionExecutable::constructorKindIsDerived): Deleted.
39         (JSC::UnlinkedCodeBlock::constructorKindIsDerived): Deleted.
40         * bytecompiler/BytecodeGenerator.cpp:
41         (JSC::BytecodeGenerator::generate): Don't emit bytecode when we had already emitted code
42         to throw TypeError.
43         (JSC::BytecodeGenerator::BytecodeGenerator): Emit code to throw TypeError when generating
44         code to call.
45         (JSC::BytecodeGenerator::emitReturn):
46         * bytecompiler/BytecodeGenerator.h:
47         (JSC::BytecodeGenerator::constructorKind):
48         (JSC::BytecodeGenerator::constructorKindIsDerived): Deleted.
49         * bytecompiler/NodesCodegen.cpp:
50         (JSC::ThisNode::emitBytecode):
51         (JSC::FunctionCallValueNode::emitBytecode):
52         * parser/Nodes.cpp:
53         (JSC::FunctionBodyNode::FunctionBodyNode):
54         * parser/Nodes.h:
55         * parser/Parser.cpp:
56         (JSC::Parser<LexerType>::parseFunctionInfo): Renamed the incoming function argument to
57         ownerClassKind. Set constructorKind to Base or Derived only if we're parsing a constructor.
58         (JSC::Parser<LexerType>::parseFunctionDeclaration):
59         (JSC::Parser<LexerType>::parseClass): Don't parse static methods using MethodMode since that
60         would result in BytecodeGenerator erroneously treating static method named "constructor" as
61         a class constructor.
62         (JSC::Parser<LexerType>::parsePropertyMethod):
63         (JSC::Parser<LexerType>::parsePrimaryExpression):
64         * parser/Parser.h:
65         * parser/ParserModes.h:
66         * runtime/Executable.h:
67         (JSC::EvalExecutable::executableInfo):
68         (JSC::ProgramExecutable::executableInfo):
69
70 2015-03-13  Filip Pizlo  <fpizlo@apple.com>
71
72         DFG::PutStackSinkingPhase should eliminate GetStacks that have an obviously known source
73         https://bugs.webkit.org/show_bug.cgi?id=141624
74
75         Reviewed by Oliver Hunt.
76         
77         This was an obvious omission from the original PutStackSinkingPhase. Previously, we would treat
78         GetStacks conservatively and assume that the stack slot escaped. That's pretty dumb, since a
79         GetStack is a local load of the stack. This change makes GetStack a no-op from the standpoint of
80         this phase's deferral analysis. At the end we either keep the GetStack (if there was no concrete
81         deferral) or we replace it with an identity over the value that would have been stored by the
82         deferred PutStack. Note that this might be a Phi that the phase creates, so this is strictly
83         stronger than what GCSE could do.
84         
85         This is probably not a speed-up now, but it will be very useful for the varargs simplification
86         done in bug 141174.
87
88         * dfg/DFGPutStackSinkingPhase.cpp:
89
90 2015-03-12  Geoffrey Garen  <ggaren@apple.com>
91
92         Prohibit GC while sweeping
93         https://bugs.webkit.org/show_bug.cgi?id=142638
94
95         Reviewed by Andreas Kling.
96
97         I noticed in https://bugs.webkit.org/show_bug.cgi?id=142636 that a GC
98         could trigger a sweep which could trigger another GC. Yo Dawg.
99
100         I tried to figure out whether this could cause problems or not and it
101         made me cross-eyed.
102
103         (Some clients like to report extra memory cost during deallocation as a
104         way to indicate that the GC now owns something exclusively. It's
105         arguably a bug to communicate with the GC in this way, but we shouldn't
106         do crazy when this happens.)
107
108         This patch makes explicit the fact that we don't allow GC while sweeping.
109
110         Usually, sweeping implicitly defers GC by virtue of happening during
111         allocation. But not always.
112
113         * heap/Heap.cpp:
114         (JSC::Heap::collectAllGarbage): Defer GC while sweeping due to an
115         explicit GC request.
116
117         (JSC::Heap::didFinishCollection): Make sure that zombifying sweep
118         defers GC by not returning to the non-GC state until we're all done.
119
120         * heap/IncrementalSweeper.cpp:
121         (JSC::IncrementalSweeper::sweepNextBlock): Defer GC while sweeping due
122         to a timer.
123
124 2015-03-13  Mark Lam  <mark.lam@apple.com>
125
126         Replace TCSpinLock with a new WTF::SpinLock based on WTF::Atomic.
127         <https://webkit.org/b/142674>
128
129         Reviewed by Filip Pizlo.
130
131         * API/JSValue.mm:
132         (handerForStructTag):
133         * API/JSWrapperMap.mm:
134         * dfg/DFGCommon.cpp:
135         (JSC::DFG::startCrashing):
136         (JSC::DFG::isCrashing):
137         - Changed to use a StaticSpinLock since that's what this code was trying to do
138           anyway.
139         * heap/CopiedBlock.h:
140         (JSC::CopiedBlock::CopiedBlock):
141         * heap/CopiedSpace.cpp:
142         (JSC::CopiedSpace::CopiedSpace):
143         * heap/CopiedSpace.h:
144         * heap/GCThreadSharedData.cpp:
145         (JSC::GCThreadSharedData::GCThreadSharedData):
146         * heap/GCThreadSharedData.h:
147         * heap/ListableHandler.h:
148         (JSC::ListableHandler::List::List):
149         * parser/SourceProvider.cpp:
150         * profiler/ProfilerDatabase.cpp:
151         (JSC::Profiler::Database::addDatabaseToAtExit):
152         (JSC::Profiler::Database::removeDatabaseFromAtExit):
153         (JSC::Profiler::Database::removeFirstAtExitDatabase):
154
155 2015-03-13  Ryosuke Niwa  <rniwa@webkit.org>
156
157         BytecodeGenerator needs to be re-entrant to support miranda functions
158         https://bugs.webkit.org/show_bug.cgi?id=142627
159
160         Reviewed by Filip Pizlo.
161
162         Made CodeCache::getGlobalCodeBlock and CodeCache::getFunctionExecutableFromGlobalCode re-entrant
163         by not keeping AddResult while invoking BytecodeGenerator::generate.
164
165         This is needed to support Miranda functions since they need to be lazily initialized.
166
167         * runtime/CodeCache.cpp:
168         (JSC::CodeCache::getGlobalCodeBlock):
169         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
170         * runtime/CodeCache.h:
171         (JSC::CodeCacheMap::findCacheAndUpdateAge): Extracted from add.
172         (JSC::CodeCacheMap::addCache): Extracted from add.
173         (JSC::CodeCacheMap::add): Deleted.
174
175 2015-03-13  Mark Lam  <mark.lam@apple.com>
176
177         Introduce WTF::Atomic to wrap std::atomic for a friendlier CAS.
178         <https://webkit.org/b/142661>
179
180         Reviewed by Filip Pizlo.
181
182         Changed CodeBlock, and the DFG's crashLock to use WTF::Atomic instead of
183         std::atomic.
184
185         * bytecode/CodeBlock.cpp:
186         (JSC::CodeBlock::CodeBlock):
187         (JSC::CodeBlock::visitAggregate):
188         * bytecode/CodeBlock.h:
189         * dfg/DFGCommon.cpp:
190         (JSC::DFG::startCrashing):
191
192 2015-03-12  Mark Lam  <mark.lam@apple.com>
193
194         Change the DFG crashLock to use std::atomic.
195         <https://webkit.org/b/142649>
196
197         Reviewed by Filip Pizlo.
198
199         * dfg/DFGCommon.cpp:
200         (JSC::DFG::startCrashing):
201         (JSC::DFG::isCrashing):
202
203 2015-03-12  Filip Pizlo  <fpizlo@apple.com>
204
205         Bytecode liveness analysis should have more lambdas and fewer sets
206         https://bugs.webkit.org/show_bug.cgi?id=142647
207
208         Reviewed by Mark Lam.
209         
210         In bug 141174 I'll need to identify all of the bytecode kill sites. This requires hooking into
211         the bytecode analysis' stepOverFunction method, except in such a way that we observe uses that
212         are not in outs. This refactors stepOverFunction so that you can pass it use/def functors that
213         can either be used to propagate outs (as we do right now) or to additionally detect kills or
214         whatever else.
215         
216         In order to achieve this, the liveness analysis was moved off of maintaining uses/defs
217         bitvectors. This wasn't helping the abstraction and was probably inefficient. The new code
218         should be a bit faster since we don't have to clear uses/defs bitvectors on each instruction. On
219         the other hand, being able to intercept each use means that our code for exception handlers is
220         no longer a bitwise-merge; it requires finding set bits. Fortunately, this code only kicks in
221         for instructions inside a try, and its performance is O(live at catch), so that's probably not
222         bad.
223
224         * bytecode/BytecodeLivenessAnalysis.cpp:
225         (JSC::indexForOperand):
226         (JSC::stepOverInstruction):
227         (JSC::computeLocalLivenessForBytecodeOffset):
228         (JSC::BytecodeLivenessAnalysis::computeFullLiveness):
229         (JSC::setForOperand): Deleted.
230         * bytecode/BytecodeUseDef.h:
231         (JSC::computeUsesForBytecodeOffset):
232         (JSC::computeDefsForBytecodeOffset):
233         * bytecode/CodeBlock.cpp:
234
235 2015-03-12  Ryosuke Niwa  <rniwa@webkit.org>
236
237         "this" should be in TDZ until super is called in the constructor of a derived class
238         https://bugs.webkit.org/show_bug.cgi?id=142527
239
240         Reviewed by Mark Hahnenberg.
241
242         DFG and FTL implementations co-authored by Filip Pizlo.
243
244         In ES6 class syntax, "this" register must be in the "temporal dead zone" (TDZ) and throw ReferenceError until
245         super() is called inside the constructor of a derived class.
246
247         Added op_check_tdz, a new OP code, which throws a reference error when the first operand is an empty value
248         to all tiers of JIT and LLint. The op code throws in the slow path on the basis that a TDZ error should be
249         a programming error and not a part of the programs' normal control flow. In DFG, this op code is represented
250         by a no-op must-generate node CheckNotEmpty modeled after CheckCell.
251
252         Also made the constructor of a derived class assign the empty value to "this" register rather than undefined
253         so that ThisNode can emit the op_check_tdz to check the initialized-ness of "this" in such a constructor.
254
255         * bytecode/BytecodeList.json: Added op_check_tdz.
256         * bytecode/BytecodeUseDef.h:
257         (JSC::computeUsesForBytecodeOffset): Ditto.
258         (JSC::computeDefsForBytecodeOffset): Ditto.
259         * bytecode/CodeBlock.cpp:
260         (JSC::CodeBlock::dumpBytecode): Ditto.
261         * bytecode/ExitKind.cpp:
262         (JSC::exitKindToString): Added TDZFailure.
263         * bytecode/ExitKind.h: Ditto.
264         * bytecompiler/BytecodeGenerator.cpp:
265         (JSC::BytecodeGenerator::BytecodeGenerator): Assign the empty value to "this" register to indicate it's in TDZ.
266         (JSC::BytecodeGenerator::emitTDZCheck): Added.
267         (JSC::BytecodeGenerator::emitReturn): Emit the TDZ check since "this" can still be in TDZ if super() was never
268         called. e.g. class B extends A { constructor() { } }
269         * bytecompiler/BytecodeGenerator.h:
270         * bytecompiler/NodesCodegen.cpp:
271         (JSC::ThisNode::emitBytecode): Always emit the TDZ check if we're inside the constructor of a derived class.
272         We can't omit this check even if the result was ignored per spec.
273         * dfg/DFGAbstractInterpreterInlines.h:
274         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Previously, empty value could never appear
275         in a local variable. This is no longer true so generalize this code. Also added the support for CheckNotEmpty.
276         Like CheckCell, we phantomize this DFG node in the constant folding phase if the type of the operand is already
277         found to be not empty. Otherwise filter out SpecEmpty.
278         * dfg/DFGByteCodeParser.cpp:
279         (JSC::DFG::ByteCodeParser::parseBlock): Added op_check_tdz.
280         * dfg/DFGCapabilities.cpp:
281         (JSC::DFG::capabilityLevel): op_check_tdz can be compiled and inlined.
282         * dfg/DFGClobberize.h:
283         (JSC::DFG::clobberize): CheckNotEmpty doesn't read or write values.
284         * dfg/DFGConstantFoldingPhase.cpp:
285         (JSC::DFG::ConstantFoldingPhase::foldConstants): Convert CheckNotEmpty to a phantom if non-emptiness had already
286         been proven for the operand prior to this node.
287         * dfg/DFGDoesGC.cpp:
288         (JSC::DFG::doesGC): CheckNotEmpty does not trigger GC.
289         * dfg/DFGFixupPhase.cpp:
290         (JSC::DFG::FixupPhase::fixupNode): CheckNotEmpty is a no-op in the fixup phase.
291         * dfg/DFGNodeType.h: CheckNotEmpty cannot be removed even if the result was ignored. See ThisNode::emitBytecode.
292         * dfg/DFGPredictionPropagationPhase.cpp:
293         (JSC::DFG::PredictionPropagationPhase::propagate): CheckNotEmpty doesn't return any value.
294         * dfg/DFGSafeToExecute.h:
295         (JSC::DFG::safeToExecute): CheckNotEmpty doesn't load from heap so it's safe.
296         * dfg/DFGSpeculativeJIT32_64.cpp:
297         (JSC::DFG::SpeculativeJIT::compile): Speculative the operand to be not empty. OSR exit if the speculation fails.
298         * dfg/DFGSpeculativeJIT64.cpp:
299         (JSC::DFG::SpeculativeJIT::compile): Ditto.
300         * ftl/FTLCapabilities.cpp:
301         (JSC::FTL::canCompile): CheckNotEmpty can be compiled in FTL.
302         * ftl/FTLLowerDFGToLLVM.cpp:
303         (JSC::FTL::LowerDFGToLLVM::compileNode): Calls compileCheckNotEmpty for CheckNotEmpty.
304         (JSC::FTL::LowerDFGToLLVM::compileCheckNotEmpty): OSR exit with "TDZFailure" if the operand is not empty.
305         * jit/JIT.cpp:
306         (JSC::JIT::privateCompileMainPass): Added op_check_tdz.
307         (JSC::JIT::privateCompileSlowCases): Ditto.
308         * jit/JIT.h:
309         * jit/JITOpcodes.cpp:
310         (JSC::JIT::emit_op_check_tdz): Implements op_check_tdz in Baseline JIT.
311         (JSC::JIT::emitSlow_op_check_tdz): Ditto.
312         * jit/JITOpcodes32_64.cpp:
313         (JSC::JIT::emit_op_check_tdz): Ditto.
314         (JSC::JIT::emitSlow_op_check_tdz): Ditto.
315         * llint/LowLevelInterpreter32_64.asm: Implements op_check_tdz in LLint.
316         * llint/LowLevelInterpreter64.asm: Ditto.
317         * runtime/CommonSlowPaths.cpp:
318         (JSC::SLOW_PATH_DECL): Throws a reference error for op_check_tdz. Shared by LLint and Baseline JIT.
319         * runtime/CommonSlowPaths.h:
320         * tests/stress/class-syntax-no-loop-tdz.js: Added.
321         * tests/stress/class-syntax-no-tdz-in-catch.js: Added.
322         * tests/stress/class-syntax-no-tdz-in-conditional.js: Added.
323         * tests/stress/class-syntax-no-tdz-in-loop-no-inline-super.js: Added.
324         * tests/stress/class-syntax-no-tdz-in-loop.js: Added.
325         * tests/stress/class-syntax-no-tdz.js: Added.
326         * tests/stress/class-syntax-tdz-in-catch.js: Added.
327         * tests/stress/class-syntax-tdz-in-conditional.js: Added.
328         * tests/stress/class-syntax-tdz-in-loop.js: Added.
329         * tests/stress/class-syntax-tdz.js: Added.
330
331 2015-03-12  Yusuke Suzuki  <utatane.tea@gmail.com>
332
333         Integrate MapData into JSMap and JSSet
334         https://bugs.webkit.org/show_bug.cgi?id=142556
335
336         Reviewed by Filip Pizlo.
337
338         This patch integrates MapData into JSMap and JSSet.
339         This removes 2 object allocation per one JSMap / JSSet.
340
341         MapDataImpl is specialized into MapData and SetData.
342         In the case of SetData, it does not have the dummy values
343         previously stored in the MapDataImpl. So the storage size of SetData
344         becomes the half of the previous implementation.
345
346         And now MapData and SetData are completely integrated into JSMap and JSSet,
347         these structures are not exposed to the other code even in WebCore world.
348
349         And at the same time, this patch fixes missing destroy functions
350         in JSMapIterator and JSSetIterator.
351         They are needed because MapData::const_iterator is a non-trivial destructor.
352
353         * CMakeLists.txt:
354         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
355         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
356         * JavaScriptCore.xcodeproj/project.pbxproj:
357         * runtime/JSMap.cpp:
358         (JSC::JSMap::destroy):
359         (JSC::JSMap::visitChildren):
360         (JSC::JSMap::copyBackingStore):
361         (JSC::JSMap::has):
362         (JSC::JSMap::size):
363         (JSC::JSMap::get):
364         (JSC::JSMap::set):
365         (JSC::JSMap::clear):
366         (JSC::JSMap::remove):
367         (JSC::JSMap::finishCreation): Deleted.
368         * runtime/JSMap.h:
369         (JSC::JSMap::Entry::key):
370         (JSC::JSMap::Entry::value):
371         (JSC::JSMap::Entry::visitChildren):
372         (JSC::JSMap::Entry::setKey):
373         (JSC::JSMap::Entry::setKeyWithoutWriteBarrier):
374         (JSC::JSMap::Entry::setValue):
375         (JSC::JSMap::Entry::clear):
376         (JSC::JSMap::begin):
377         (JSC::JSMap::end):
378         (JSC::JSMap::JSMap):
379         (JSC::JSMap::mapData): Deleted.
380         * runtime/JSMapIterator.cpp:
381         (JSC::JSMapIterator::finishCreation):
382         (JSC::JSMapIterator::destroy):
383         (JSC::JSMapIterator::visitChildren):
384         * runtime/JSMapIterator.h:
385         (JSC::JSMapIterator::JSMapIterator):
386         * runtime/JSSet.cpp:
387         (JSC::JSSet::destroy):
388         (JSC::JSSet::visitChildren):
389         (JSC::JSSet::copyBackingStore):
390         (JSC::JSSet::has):
391         (JSC::JSSet::size):
392         (JSC::JSSet::add):
393         (JSC::JSSet::clear):
394         (JSC::JSSet::remove):
395         (JSC::JSSet::finishCreation): Deleted.
396         * runtime/JSSet.h:
397         (JSC::JSSet::Entry::key):
398         (JSC::JSSet::Entry::value):
399         (JSC::JSSet::Entry::visitChildren):
400         (JSC::JSSet::Entry::setKey):
401         (JSC::JSSet::Entry::setKeyWithoutWriteBarrier):
402         (JSC::JSSet::Entry::setValue):
403         (JSC::JSSet::Entry::clear):
404         (JSC::JSSet::begin):
405         (JSC::JSSet::end):
406         (JSC::JSSet::JSSet):
407         (JSC::JSSet::mapData): Deleted.
408         * runtime/JSSetIterator.cpp:
409         (JSC::JSSetIterator::finishCreation):
410         (JSC::JSSetIterator::visitChildren):
411         (JSC::JSSetIterator::destroy):
412         * runtime/JSSetIterator.h:
413         (JSC::JSSetIterator::JSSetIterator):
414         * runtime/MapConstructor.cpp:
415         (JSC::constructMap):
416         * runtime/MapData.h:
417         (JSC::MapDataImpl::const_iterator::key):
418         (JSC::MapDataImpl::const_iterator::value):
419         (JSC::MapDataImpl::size):
420         (JSC::MapDataImpl<Entry>::MapDataImpl):
421         (JSC::MapDataImpl<Entry>::clear):
422         (JSC::MapDataImpl<Entry>::KeyType::KeyType):
423         (JSC::MapDataImpl<Entry>::const_iterator::internalIncrement):
424         (JSC::MapDataImpl<Entry>::const_iterator::ensureSlot):
425         (JSC::MapDataImpl<Entry>::const_iterator::const_iterator):
426         (JSC::MapDataImpl<Entry>::const_iterator::~const_iterator):
427         (JSC::MapDataImpl<Entry>::const_iterator::operator):
428         (JSC::=):
429         (JSC::MapData::const_iterator::key): Deleted.
430         (JSC::MapData::const_iterator::value): Deleted.
431         (JSC::MapData::create): Deleted.
432         (JSC::MapData::createStructure): Deleted.
433         (JSC::MapData::size): Deleted.
434         (JSC::MapData::clear): Deleted.
435         (JSC::MapData::KeyType::KeyType): Deleted.
436         (JSC::MapData::const_iterator::internalIncrement): Deleted.
437         (JSC::MapData::const_iterator::ensureSlot): Deleted.
438         (JSC::MapData::const_iterator::const_iterator): Deleted.
439         (JSC::MapData::const_iterator::~const_iterator): Deleted.
440         (JSC::MapData::const_iterator::operator*): Deleted.
441         (JSC::MapData::const_iterator::end): Deleted.
442         (JSC::MapData::const_iterator::operator!=): Deleted.
443         (JSC::MapData::const_iterator::operator==): Deleted.
444         * runtime/MapDataInlines.h: Renamed from Source/JavaScriptCore/runtime/MapData.cpp.
445         (JSC::MapDataImpl<Entry>::find):
446         (JSC::MapDataImpl<Entry>::contains):
447         (JSC::MapDataImpl<Entry>::add):
448         (JSC::MapDataImpl<Entry>::set):
449         (JSC::MapDataImpl<Entry>::get):
450         (JSC::MapDataImpl<Entry>::remove):
451         (JSC::MapDataImpl<Entry>::replaceAndPackBackingStore):
452         (JSC::MapDataImpl<Entry>::replaceBackingStore):
453         (JSC::MapDataImpl<Entry>::ensureSpaceForAppend):
454         (JSC::MapDataImpl<Entry>::visitChildren):
455         (JSC::MapDataImpl<Entry>::copyBackingStore):
456         * runtime/MapPrototype.cpp:
457         (JSC::getMap):
458         (JSC::mapProtoFuncClear):
459         (JSC::mapProtoFuncDelete):
460         (JSC::mapProtoFuncForEach):
461         (JSC::mapProtoFuncGet):
462         (JSC::mapProtoFuncHas):
463         (JSC::mapProtoFuncSet):
464         (JSC::mapProtoFuncSize):
465         (JSC::getMapData): Deleted.
466         * runtime/SetPrototype.cpp:
467         (JSC::getSet):
468         (JSC::setProtoFuncAdd):
469         (JSC::setProtoFuncClear):
470         (JSC::setProtoFuncDelete):
471         (JSC::setProtoFuncForEach):
472         (JSC::setProtoFuncHas):
473         (JSC::setProtoFuncSize):
474         (JSC::getMapData): Deleted.
475         * runtime/VM.cpp:
476         (JSC::VM::VM):
477         * runtime/VM.h:
478
479 2015-03-12  Mark Lam  <mark.lam@apple.com>
480
481         Use std::atomic for CodeBlock::m_visitAggregateHasBeenCalled.
482         <https://webkit.org/b/142640>
483
484         Reviewed by Mark Hahnenberg.
485
486         We used to spin our own compare and swap on a uint8_t.  Now that we can
487         use C++11, let's use std::atomic instead.
488
489         * bytecode/CodeBlock.cpp:
490         (JSC::CodeBlock::visitAggregate):
491         - The CAS here needs std::memory_order_acquire ordering because it
492           requires lock acquisition semantics to visit the CodeBlock.
493
494         * bytecode/CodeBlock.h:
495         (JSC::CodeBlockSet::mark):
496         * heap/CodeBlockSet.cpp:
497         (JSC::CodeBlockSet::clearMarksForFullCollection):
498         (JSC::CodeBlockSet::clearMarksForEdenCollection):
499         - These can go with relaxed ordering because they are all done before
500           the GC starts parallel marking.
501
502 2015-03-12  Csaba Osztrogonác  <ossy@webkit.org>
503
504         [cmake] Fix the incremental build issue revealed by r181419
505         https://bugs.webkit.org/show_bug.cgi?id=142613
506
507         Reviewed by Carlos Garcia Campos.
508
509         * CMakeLists.txt:
510
511 2015-03-11  Ryosuke Niwa  <rniwa@webkit.org>
512
513         "static" should not be a reserved keyword in non-strict mode even when ES6 class is enabled
514         https://bugs.webkit.org/show_bug.cgi?id=142600
515
516         Reviewed by Mark Lam.
517
518         Make "static" RESERVED_IF_STRICT and manually detect it in parseClass.
519
520         No new tests. This is already checked by js/reserved-words.html and js/keywords-and-reserved_words.html
521
522         * parser/Keywords.table:
523         * parser/Parser.cpp:
524         (JSC::Parser<LexerType>::parseClass):
525         * parser/ParserTokens.h:
526
527 2015-03-11  Geoffrey Garen  <ggaren@apple.com>
528
529         Many users of Heap::reportExtraMemory* are wrong, causing lots of memory growth
530         https://bugs.webkit.org/show_bug.cgi?id=142593
531
532         Reviewed by Andreas Kling.
533
534         Adopt deprecatedReportExtraMemory as a short-term fix for runaway
535         memory growth in these cases where we have not adopted
536         reportExtraMemoryVisited.
537
538         Long-term, we should use reportExtraMemoryAllocated+reportExtraMemoryVisited.
539         That's tracked by https://bugs.webkit.org/show_bug.cgi?id=142595.
540
541         * API/JSBase.cpp:
542         (JSReportExtraMemoryCost):
543         * runtime/SparseArrayValueMap.cpp:
544         (JSC::SparseArrayValueMap::add):
545
546 2015-03-11  Geoffrey Garen  <ggaren@apple.com>
547
548         Refactored the JSC::Heap extra cost API for clarity and to make some known bugs more obvious
549         https://bugs.webkit.org/show_bug.cgi?id=142589
550
551         Reviewed by Andreas Kling.
552
553         * API/JSBase.cpp:
554         (JSReportExtraMemoryCost): Added a FIXME to annotate a known bug.
555
556         * bytecode/CodeBlock.cpp:
557         (JSC::CodeBlock::CodeBlock):
558         (JSC::CodeBlock::visitAggregate):
559         * bytecode/CodeBlock.h:
560         (JSC::CodeBlock::setJITCode): Updated for rename.
561
562         * heap/Heap.cpp:
563         (JSC::Heap::Heap):
564         (JSC::Heap::reportExtraMemoryAllocatedSlowCase):
565         (JSC::Heap::deprecatedReportExtraMemorySlowCase): Renamed our reporting
566         APIs to clarify their relationship to each other: One must report extra
567         memory at the time of allocation, and at the time the GC visits it.
568
569         (JSC::Heap::extraMemorySize):
570         (JSC::Heap::size):
571         (JSC::Heap::capacity):
572         (JSC::Heap::sizeAfterCollect):
573         (JSC::Heap::willStartCollection): Updated for renames. Added explicit
574         API for deprecated users who can't use our best API.
575  
576         (JSC::Heap::reportExtraMemoryCostSlowCase): Deleted.
577         (JSC::Heap::extraSize): Deleted.
578
579         * heap/Heap.h:
580         * heap/HeapInlines.h:
581         (JSC::Heap::reportExtraMemoryAllocated):
582         (JSC::Heap::reportExtraMemoryVisited):
583         (JSC::Heap::deprecatedReportExtraMemory):
584         (JSC::Heap::reportExtraMemoryCost): Deleted. Ditto.
585
586         * heap/SlotVisitor.h:
587         * heap/SlotVisitorInlines.h:
588         (JSC::SlotVisitor::reportExtraMemoryVisited):
589         (JSC::SlotVisitor::reportExtraMemoryUsage): Deleted. Moved this
590         functionality into the Heap since it's pretty detailed in its access
591         to the heap.
592
593         * runtime/JSArrayBufferView.cpp:
594         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
595         * runtime/JSGenericTypedArrayViewInlines.h:
596         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Updated for
597         renames.
598
599         * runtime/JSString.cpp:
600         (JSC::JSString::visitChildren):
601         (JSC::JSRopeString::resolveRopeToAtomicString):
602         (JSC::JSRopeString::resolveRope):
603         * runtime/JSString.h:
604         (JSC::JSString::finishCreation): Updated for renames.
605
606         * runtime/SparseArrayValueMap.cpp:
607         (JSC::SparseArrayValueMap::add): Added FIXME.
608
609         * runtime/WeakMapData.cpp:
610         (JSC::WeakMapData::visitChildren): Updated for rename.
611
612 2015-03-11  Ryosuke Niwa  <rniwa@webkit.org>
613
614         Calling super() in a base class results in a crash
615         https://bugs.webkit.org/show_bug.cgi?id=142563
616
617         Reviewed by Filip Pizlo.
618
619         The bug was caused by BytecodeGenerator trying to generate "super" expression inside the constructor of a base class.
620         Disallow that by keeping track of whether "super" has been used in the current scope or not (needsSuperBinding flag)
621         and then throwing a syntax error in parseFunctionInfo if it was used and the current scope wasn't the constructor of
622         a derived class.
623
624         * parser/Parser.cpp:
625         (JSC::Parser<LexerType>::parseFunctionInfo): Don't allow super() or super.foo outside the constructor of a derived class.
626         (JSC::Parser<LexerType>::parseClass): Pass in the constructor kind to parseGetterSetter.
627         (JSC::Parser<LexerType>::parseGetterSetter): Ditto to parseFunctionInfo.
628         (JSC::Parser<LexerType>::parseMemberExpression): Set needsSuperBinding flag true on the containing scope.
629         * parser/Parser.h:
630         (JSC::Scope::Scope):
631         (JSC::Scope::needsSuperBinding): Added.
632         (JSC::Scope::setNeedsSuperBinding): Added.
633
634 2015-03-10  Darin Adler  <darin@apple.com>
635
636         Some event handler fixes
637         https://bugs.webkit.org/show_bug.cgi?id=142474
638
639         Reviewed by Anders Carlsson.
640
641         * inspector/InjectedScriptManager.cpp:
642         (Inspector::InjectedScriptManager::createInjectedScript): Call clearException.
643         I spotted the fact it was missing by auditing all the calls to JSC::call.
644
645 2015-03-10  Matthew Mirman  <mmirman@apple.com>
646
647         Functions should have initialization precedence over arguments. 
648         https://bugs.webkit.org/show_bug.cgi?id=142550
649         rdar://problem/19702564
650
651         Reviewed by Geoffrey Garen.
652
653         * bytecompiler/BytecodeGenerator.cpp:
654         (JSC::BytecodeGenerator::BytecodeGenerator):
655         (JSC::BytecodeGenerator::initializeCapturedVariable):
656         * tests/stress/initialize_functions_after_arguments.js: Added.
657
658 2015-03-10  Andreas Kling  <akling@apple.com>
659
660         Eden collections should trigger sweep of MarkedBlocks containing new objects.
661         <https://webkit.org/b/142538>
662
663         Reviewed by Geoffrey Garen.
664
665         Take a snapshot of all MarkedBlocks with new objects as part of Eden collections,
666         and append that to the IncrementalSweeper's working set.
667
668         This ensures that we run destructors for objects that were discovered to be garbage during
669         Eden collections, instead of delaying their teardown until the next full collection,
670         or the next allocation cycle for their block.
671
672         * heap/Heap.cpp:
673         (JSC::Heap::snapshotMarkedSpace): For Eden collections, snapshot the list of MarkedBlocks
674         that contain new objects, since those are the only ones we're interested in.
675         Also use Vector::resizeToFit() to allocate the snapshot for full collections, since we know
676         the final size we need up front.
677
678         (JSC::Heap::notifyIncrementalSweeper): For Eden collections, tell the IncrementalSweeper
679         to add the block snapshot (taken earlier) to its existing set of blocks instead of replacing
680         it entirely. This allows Eden collections and incremental sweeping to occur interleaved with
681         each other without missing destruction opportunities.
682
683         * heap/IncrementalSweeper.h:
684         * heap/IncrementalSweeper.cpp:
685         (JSC::IncrementalSweeper::doSweep):
686         (JSC::IncrementalSweeper::sweepNextBlock): Change the way we iterate over the sweeper's
687         work list: instead of keeping an index for the next block, just pop from the end of the list.
688         This allows us to add new blocks and deduplicate the list without disturbing iteration.
689
690         (JSC::IncrementalSweeper::startSweeping): Make this take a Vector<MarkedBlock>&& so we can
691         pass ownership of this Vector efficiently from Heap to IncrementalSweeper.
692
693         (JSC::IncrementalSweeper::addBlocksAndContinueSweeping): Added. This is used by Eden
694         collections to add a set of MarkedBlocks with new objects to the sweeper's existing
695         working set and kick the timer.
696
697         * heap/MarkedSpace.h:
698         (JSC::MarkedSpace::blocksWithNewObjects): Expose the list of MarkedBlocks with new objects.
699
700 2015-03-10  Alex Christensen  <achristensen@webkit.org>
701
702         Use unsigned for HashSet size.
703         https://bugs.webkit.org/show_bug.cgi?id=142518
704
705         Reviewed by Benjamin Poulain.
706
707         * dfg/DFGAvailabilityMap.cpp:
708         (JSC::DFG::AvailabilityMap::prune):
709         * ftl/FTLOSRExitCompiler.cpp:
710         (JSC::FTL::compileStub):
711         * heap/MarkedBlockSet.h:
712         (JSC::MarkedBlockSet::remove):
713         * runtime/WeakMapData.h:
714
715 2015-03-10  Mark Lam  <mark.lam@apple.com>
716
717         Use std::numeric_limits<unsigned>::max() instead of (unsigned)-1.
718         <https://webkit.org/b/142539>
719
720         Reviewed by Benjamin Poulain.
721
722         * jit/JIT.cpp:
723         (JSC::JIT::JIT):
724         (JSC::JIT::privateCompileMainPass):
725         (JSC::JIT::privateCompileSlowCases):
726         (JSC::JIT::privateCompile):
727         (JSC::JIT::privateCompileExceptionHandlers):
728         * jit/JITInlines.h:
729         (JSC::JIT::emitNakedCall):
730         (JSC::JIT::addSlowCase):
731         (JSC::JIT::addJump):
732         (JSC::JIT::emitJumpSlowToHot):
733         (JSC::JIT::emitGetVirtualRegister):
734         * jit/SlowPathCall.h:
735         (JSC::JITSlowPathCall::call):
736         * yarr/Yarr.h:
737
738 2015-03-10  Mark Lam  <mark.lam@apple.com>
739
740         [Win] JSC Build Warnings Need to be Resolved.
741         <https://webkit.org/b/142366>
742
743         Reviewed by Brent Fulgham.
744
745         Applied some benign changes to make the MSVC compiler happy.
746
747         * bytecode/CodeBlock.cpp:
748         (JSC::CodeBlock::dumpBytecode):
749         * dfg/DFGSpeculativeJIT32_64.cpp:
750         (JSC::DFG::SpeculativeJIT::fillJSValue):
751         * runtime/BasicBlockLocation.cpp:
752         (JSC::BasicBlockLocation::getExecutedRanges):
753         * runtime/ControlFlowProfiler.cpp:
754         (JSC::ControlFlowProfiler::hasBasicBlockAtTextOffsetBeenExecuted):
755
756 2015-03-10  Yusuke Suzuki  <utatane.tea@gmail.com>
757
758         Upgrade Map, Set and WeakMap constructor interface
759         https://bugs.webkit.org/show_bug.cgi?id=142348
760
761         Reviewed by Filip Pizlo.
762
763         In the latest ES6 spec, Map and Set constructors take initialization data sets
764         as iterable value. And iterate it and add the values into the constructed one.
765
766         This is breaking change because the old constructor interface is
767         already shipped in Safari 8.
768
769         * runtime/MapConstructor.cpp:
770         (JSC::callMap):
771         (JSC::constructMap):
772         (JSC::MapConstructor::getCallData):
773         * runtime/SetConstructor.cpp:
774         (JSC::callSet):
775         (JSC::constructSet):
776         * runtime/WeakMapConstructor.cpp:
777         (JSC::callWeakMap):
778         (JSC::constructWeakMap):
779         (JSC::WeakMapConstructor::getCallData):
780         * tests/stress/map-constructor-adder.js: Added.
781         * tests/stress/map-constructor.js: Added.
782         (testCallTypeError):
783         (testTypeError):
784         (for):
785         * tests/stress/set-constructor-adder.js: Added.
786         (Set.prototype.add):
787         * tests/stress/set-constructor.js: Added.
788         (for):
789         * tests/stress/weak-map-constructor-adder.js: Added.
790         * tests/stress/weak-map-constructor.js: Added.
791         (testCallTypeError):
792         (testTypeError):
793         (for):
794
795 2015-03-10  Michael Catanzaro  <mcatanzaro@igalia.com>
796
797         GCC: CRASH() should be annotated with NORETURN
798         https://bugs.webkit.org/show_bug.cgi?id=142524
799
800         Reviewed by Anders Carlsson.
801
802         Don't return from a NORETURN function. This used to avoid a warning from GCC, but now it
803         causes one.
804
805         * jsc.cpp:
806
807 2015-03-10  Mark Lam  <mark.lam@apple.com>
808
809         Gardening: fix bleeding debug test bots.
810         https://webkit.org/b/142513>
811
812         Not reviewed.
813
814         The test needs to initialize WTF threading explicitly before using it.
815
816         * API/tests/CompareAndSwapTest.cpp:
817         (testCompareAndSwap):
818
819 2015-03-10  Alex Christensen  <achristensen@webkit.org>
820
821         [WinCairo] Unreviewed build fix.
822
823         * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props:
824         Added directory containing config.h, like r181304.
825
826 2015-03-09  Mark Lam  <mark.lam@apple.com>
827
828         Yet another build fix for Windows.
829         https://webkit.org/b/142513>
830
831         Reviewed by Alex Christensen.
832
833         Looks like MSVC requires the function be explicitly declared in a header file
834         in order for it to be linkable from another file in the same project.  This is
835         strange, but it seems to make MSVC happy.
836
837         Also fixed a typo in testapi.vcxproj.filters.
838
839         * API/tests/CompareAndSwapTest.cpp:
840         * API/tests/CompareAndSwapTest.h: Added.
841         * API/tests/testapi.c:
842         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
843         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
844         * JavaScriptCore.xcodeproj/project.pbxproj:
845
846 2015-03-09  Chris Dumez  <cdumez@apple.com>
847
848         [iOS] Sweep all collected objects on critical memory pressure
849         https://bugs.webkit.org/show_bug.cgi?id=142457
850         <rdar://problem/20044440>
851
852         Reviewed by Geoffrey Garen.
853
854         All fullSweep() API to IncrementalSweeper so that we can call it in the
855         memory pressure handler.
856
857         * heap/IncrementalSweeper.cpp:
858         (JSC::IncrementalSweeper::fullSweep):
859         * heap/IncrementalSweeper.h:
860         (JSC::IncrementalSweeper::hasWork):
861
862 2015-03-09  Mark Lam  <mark.lam@apple.com>
863
864         Another build fix for Windows.
865         https://webkit.org/b/142513>
866
867         Not reviewed.
868
869         * API/tests/CompareAndSwapTest.cpp:
870         - Added JS_EXPORT_PRIVATE attribute.
871
872 2015-03-09  Mark Lam  <mark.lam@apple.com>
873
874         Build fix for Windows after r181305.
875         https://webkit.org/b/142513>
876
877         Reviewed by Alex Christensen.
878
879         Windows doesn't like pthreads anymore.  Changed test to use WTF threading.
880
881         * API/tests/CompareAndSwapTest.cpp:
882         (setBitThreadFunc):
883         (testCompareAndSwap):
884
885 2015-03-09  Mark Lam  <mark.lam@apple.com>
886
887         8-bit version of weakCompareAndSwap() can cause an infinite loop.
888         https://webkit.org/b/142513>
889
890         Reviewed by Filip Pizlo.
891
892         Added a test that exercises the 8-bit CAS from multiple threads.  The threads
893         will contend to set bits in a large array of bytes using the CAS function.
894
895         * API/tests/CompareAndSwapTest.cpp: Added.
896         (Bitmap::Bitmap):
897         (Bitmap::numBits):
898         (Bitmap::clearAll):
899         (Bitmap::concurrentTestAndSet):
900         (setBitThreadFunc):
901         (testCompareAndSwap):
902         * API/tests/testapi.c:
903         (main):
904         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
905         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters:
906         * JavaScriptCore.xcodeproj/project.pbxproj:
907
908 2015-03-09  Brent Fulgham  <bfulgham@apple.com>
909
910         [Win] testapi project is unable to find the 'config.h' file.
911
912         Rubberstamped by Mark Lam.
913
914         * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Add JavaScriptCore source directory
915         to the include path.
916
917 2015-03-09  Andreas Kling  <akling@apple.com>
918
919         Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
920         <https://webkit.org/b/142115>
921         <rdar://problem/19992268>
922
923         Reviewed by Geoffrey Garen.
924
925         Prune stale entries from WeakGCMaps as part of every full garbage collection.
926         This frees up tons of previously-stuck WeakBlocks that were only sitting around
927         with finalized handles waiting to die.
928
929         Note that WeakGCMaps register/unregister themselves with the GC heap in their
930         ctor/dtor, so creating one now requires passing the VM.
931
932         Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
933         to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
934         It seems somewhat excessive to do this on every Eden collection, so it's only
935         doing work in full collections for now.
936
937         Because the GC may now mutate WeakGCMap below object allocation, I've made it
938         so that the classic HashMap::add() optimization can't be used with WeakGCMap.
939         This caused intermittent test failures when originally landed due to having
940         an invalid iterator on the stack after add() inserted a new entry and we
941         proceeded to allocate the new object, triggering GC.
942
943         * API/JSWeakObjectMapRefInternal.h:
944         (OpaqueJSWeakObjectMap::create):
945         (OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
946         * API/JSWeakObjectMapRefPrivate.cpp:
947         * API/JSWrapperMap.mm:
948         (-[JSWrapperMap initWithContext:]):
949         (-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.
950
951         * JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
952         it project-private so WebCore clients can access it.
953
954         * heap/Heap.cpp:
955         (JSC::Heap::collect):
956         (JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
957         stale entries from WeakGCMaps. This is only executed during full collections.
958
959         * heap/Heap.h:
960         * heap/HeapInlines.h:
961         (JSC::Heap::registerWeakGCMap):
962         (JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
963         themselves with the Heap and provide a pruning callback.
964
965         * runtime/PrototypeMap.h:
966         (JSC::PrototypeMap::PrototypeMap):
967         * runtime/Structure.cpp:
968         (JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.
969
970         * runtime/JSCInlines.h: Add "WeakGCMapInlines.h"
971
972         * runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.
973
974         * runtime/JSString.cpp:
975         (JSC::jsStringWithCacheSlowCase):
976         * runtime/PrototypeMap.cpp:
977         (JSC::PrototypeMap::addPrototype):
978         (JSC::PrototypeMap::emptyObjectStructureForPrototype): Remove HashMap add()
979         optimization since it's not safe in the GC-managed WeakGCMap world.
980
981         * runtime/VM.cpp:
982         (JSC::VM::VM): Pass VM to WeakGCMap constructor.
983
984         * runtime/WeakGCMap.h:
985         (JSC::WeakGCMap::set):
986         (JSC::WeakGCMap::add):
987         (JSC::WeakGCMap::WeakGCMap): Deleted.
988         (JSC::WeakGCMap::gcMap): Deleted.
989         (JSC::WeakGCMap::gcMapIfNeeded): Deleted.
990         * runtime/WeakGCMapInlines.h: Added.
991         (JSC::WeakGCMap::WeakGCMap):
992         (JSC::WeakGCMap::~WeakGCMap):
993         (JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
994         to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
995         prunes WeakGCMap at certain growth milestones and instead rely on the GC
996         callback for housekeeping.
997
998 2015-03-09  Ryosuke Niwa  <rniwa@webkit.org>
999
1000         Support extends and super keywords
1001         https://bugs.webkit.org/show_bug.cgi?id=142200
1002
1003         Reviewed by Filip Pizlo.
1004
1005         Added the support for ES6 class syntax inheritance.
1006
1007         Added ConstructorKind as well as boolean flags indicating the constructor kind to
1008         various classes in UnlinkedCodeBlock as well as AST nodes.
1009
1010         Each method stores the associated class as its homeObjectPrivateName. This value is used to
1011         make super calls.
1012
1013         * bytecode/UnlinkedCodeBlock.cpp:
1014         (JSC::generateFunctionCodeBlock):
1015         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1016         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1017
1018         * bytecode/UnlinkedCodeBlock.h:
1019         (JSC::ExecutableInfo::ExecutableInfo):
1020         (JSC::UnlinkedFunctionExecutable::constructorKindIsDerived): Added.
1021         (JSC::UnlinkedCodeBlock::constructorKindIsDerived): Added.
1022
1023         * bytecompiler/BytecodeGenerator.cpp:
1024         (JSC::BytecodeGenerator::BytecodeGenerator): Don't emit op_create_this in a derived class
1025         as the object is allocated by the highest base class's constructor. Also set "this" to null
1026         and store the original value in m_newTargetRegister. "this" is supposed to be in TDZ but
1027         that will be implemented in a separate patch.
1028         (JSC::BytecodeGenerator::emitReturn): Allow "undefined" to be returned from a derived class.
1029         In a derived class's constructor, not returning "undefined" or an object results in a type
1030         error instead of "this" being returned.
1031         (JSC::BytecodeGenerator::emitThrowTypeError): Added.
1032
1033         * bytecompiler/BytecodeGenerator.h:
1034         (JSC::BytecodeGenerator::constructorKindIsDerived): Added.
1035         (JSC::BytecodeGenerator::newTarget): Added.
1036
1037         * bytecompiler/NodesCodegen.cpp:
1038         (JSC::SuperNode::emitBytecode): Added. Emits the code to obtain the callee's parent class.
1039         (JSC::emitSuperBaseForCallee): Added. Emits the code to obtain the parent class's prototype.
1040         (JSC::emitPutHomeObject): Added.
1041         (JSC::PropertyListNode::emitBytecode): Stores the home object when adding methods.
1042         (JSC::PropertyListNode::emitPutConstantProperty): Ditto.
1043         (JSC::BracketAccessorNode::emitBytecode): Added the support for super['foo'].
1044         (JSC::DotAccessorNode::emitBytecode): Added the support for super.foo.
1045         (JSC::FunctionCallValueNode::emitBytecode): Added the support for super().
1046         (JSC::FunctionCallBracketNode::emitBytecode): Added the support for super['foo']().
1047         (JSC::FunctionCallDotNode::emitBytecode): Added the support for super.foo().
1048         (JSC::DeleteBracketNode::emitBytecode): Forbid "delete super.foo".
1049         (JSC::DeleteDotNode::emitBytecode): Forbid "delete super['foo']".
1050         (JSC::ClassExprNode::emitBytecode): Added the support for "classHeritage". This is the main
1051         logic for inheritance. When a class B inherits from a class A, set B.__proto__ to A and set
1052         B.prototype.__proto__ to A.prototype. Throw exceptions when either A or A.__proto__ is not
1053         an object.
1054
1055         * parser/ASTBuilder.h:
1056         (JSC::ASTBuilder::superExpr): Added.
1057
1058         * parser/NodeConstructors.h:
1059         (JSC::SuperNode::SuperNode): Added.
1060
1061         * parser/Nodes.cpp:
1062         (JSC::FunctionBodyNode::FunctionBodyNode):
1063
1064         * parser/Nodes.h:
1065         (JSC::ExpressionNode::isSuperNode):
1066         (JSC::PropertyNode::type):
1067         (JSC::PropertyNode::needsSuperBinding):
1068
1069         * parser/Parser.cpp:
1070         (JSC::Parser<LexerType>::parseFunctionBody):
1071         (JSC::Parser<LexerType>::parseFunctionInfo): Throw a parser error if super() is used outside
1072         of class constructors.
1073         (JSC::Parser<LexerType>::parseFunctionDeclaration):
1074         (JSC::Parser<LexerType>::parseClass): ConstructorKind is "derived" if and only if the parent
1075         class is specified in the declaration / expression.
1076         (JSC::Parser<LexerType>::parseGetterSetter):
1077         (JSC::Parser<LexerType>::parsePrimaryExpression):
1078         (JSC::Parser<LexerType>::parseMemberExpression): Added the support for "super()", "super.foo",
1079         and "super['foo']". Throw a semantic error if "super" appears by itself.
1080
1081         * parser/Parser.h:
1082         (JSC::Scope::Scope): Added m_hasDirectSuper. This variable keeps track of the use of "super()"
1083         so that parseFunctionInfo can spit an error if it's used outside of class constructors.
1084         (JSC::Scope::hasDirectSuper): Added.
1085         (JSC::Scope::setHasDirectSuper): Added.
1086
1087         * parser/ParserModes.h:
1088         (JSC::ConstructorKind): Added.
1089
1090         * parser/SyntaxChecker.h:
1091         (JSC::SyntaxChecker::superExpr): Added.
1092
1093         * runtime/CommonIdentifiers.h: Added homeObjectPrivateName.
1094
1095         * runtime/Executable.h:
1096         (JSC::EvalExecutable::executableInfo): 
1097         (JSC::ProgramExecutable::executableInfo):
1098
1099 2015-03-08  Andreas Kling  <akling@apple.com>
1100
1101         JITThunks keeps finalized Weaks around, pinning WeakBlocks.
1102         <https://webkit.org/b/142454>
1103
1104         Reviewed by Darin Adler.
1105
1106         Make JITThunks a WeakHandleOwner so it can keep its host function map free of stale entries.
1107         This fixes an issue I was seeing where a bunch of WeakBlocks stuck around with nothing but
1108         finalized Weak<NativeExecutable> entries.
1109
1110         * jit/JITThunks.h:
1111         * jit/JITThunks.cpp:
1112         (JSC::JITThunks::finalize): Make JITThunks inherit from WeakHandleOwner so it can receive
1113         a callback when the NativeExecutables get garbage collected.
1114
1115         (JSC::JITThunks::hostFunctionStub): Pass 'this' as the handle owner when creating Weaks.
1116
1117 2015-03-08  Andreas Kling  <akling@apple.com>
1118
1119         BuiltinExecutables keeps finalized Weaks around, pinning WeakBlocks.
1120         <https://webkit.org/b/142460>
1121
1122         Reviewed by Geoffrey Garen.
1123
1124         Make BuiltinExecutables a WeakHandleOwner so it can clear out its respective Weak members
1125         if and when their pointees get garbage collected.
1126
1127         This fixes an issue I've seen locally where a WeakBlock is pinned down by a single one of
1128         these Weak<BuiltinExecutables>.
1129
1130         * builtins/BuiltinExecutables.h: Make BuiltinExecutables inherit from WeakHandleOwner.
1131
1132         * builtins/BuiltinExecutables.cpp:
1133         (JSC::BuiltinExecutables::finalize): Clear out the relevant member pointer when it's been
1134         garbage collected. We use the WeakImpl's "context" field to pass the address of the member.
1135
1136 2015-03-07  Geoffrey Garen  <ggaren@apple.com>
1137
1138         Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
1139         https://bugs.webkit.org/show_bug.cgi?id=140900
1140
1141         Reviewed by Mark Hahnenberg.
1142
1143         Re-landing just the removal of BlockAllocator, which is now unused.
1144
1145         * API/JSBase.cpp:
1146         * CMakeLists.txt:
1147         * JavaScriptCore.order:
1148         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1149         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1150         * JavaScriptCore.xcodeproj/project.pbxproj:
1151         * heap/BlockAllocator.cpp: Removed.
1152         * heap/BlockAllocator.h: Removed.
1153         * heap/GCThreadSharedData.h:
1154         * heap/HandleBlockInlines.h:
1155         * heap/Heap.cpp:
1156         (JSC::Heap::Heap):
1157         * heap/Heap.h:
1158         * heap/HeapInlines.h:
1159         (JSC::Heap::blockAllocator): Deleted.
1160         * heap/HeapTimer.cpp:
1161         * heap/MarkedBlock.h:
1162         * heap/MarkedSpace.h:
1163         * heap/Region.h: Removed.
1164         * heap/SuperRegion.cpp: Removed.
1165         * heap/SuperRegion.h: Removed.
1166
1167 2015-03-07  Commit Queue  <commit-queue@webkit.org>
1168
1169         Unreviewed, rolling out r181010.
1170         https://bugs.webkit.org/show_bug.cgi?id=142442
1171
1172         Broke media/video-src-invalid-poster.html (Requested by kling
1173         on #webkit).
1174
1175         Reverted changeset:
1176
1177         "Stale entries in WeakGCMaps are keeping tons of WeakBlocks
1178         alive unnecessarily."
1179         https://bugs.webkit.org/show_bug.cgi?id=142115
1180         http://trac.webkit.org/changeset/181010
1181
1182 2015-03-07  Ryosuke Niwa  <rniwa@webkit.org>
1183
1184         The code to link FunctionExecutable is duplicated everywhere
1185         https://bugs.webkit.org/show_bug.cgi?id=142436
1186
1187         Reviewed by Darin Adler.
1188
1189         Reduced code duplication by factoring out linkInsideExecutable and linkGlobalCode.
1190
1191         * bytecode/CodeBlock.cpp:
1192         (JSC::CodeBlock::CodeBlock): Calls linkInsideExecutable.
1193
1194         * bytecode/UnlinkedCodeBlock.cpp:
1195         (JSC::UnlinkedFunctionExecutable::linkInsideExecutable): Renamed from link. Now takes care of startOffset.
1196         This change was needed to use this function in CodeBlock::CodeBlock. Also, this function no longer takes
1197         lineOffset since this information is already stored in the source code.
1198         (JSC::UnlinkedFunctionExecutable::linkGlobalCode): Extracted from FunctionExecutable::fromGlobalCode.
1199
1200         * bytecode/UnlinkedCodeBlock.h:
1201
1202         * generate-js-builtins: Calls linkGlobalCode.
1203
1204         * runtime/Executable.cpp:
1205         (JSC::ProgramExecutable::initializeGlobalProperties): Calls linkGlobalCode.
1206         (JSC::FunctionExecutable::fromGlobalCode): Calls linkGlobalCode.
1207
1208 2015-03-06  Geoffrey Garen  <ggaren@apple.com>
1209
1210         Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
1211         https://bugs.webkit.org/show_bug.cgi?id=140900
1212
1213         Reviewed by Mark Hahnenberg.
1214
1215         Re-landing just the MarkedBlock piece of this patch.
1216
1217         * heap/MarkedAllocator.cpp:
1218         (JSC::MarkedAllocator::allocateBlock):
1219         * heap/MarkedBlock.cpp:
1220         (JSC::MarkedBlock::create):
1221         (JSC::MarkedBlock::destroy):
1222         (JSC::MarkedBlock::MarkedBlock):
1223         * heap/MarkedBlock.h:
1224         (JSC::MarkedBlock::capacity):
1225         * heap/MarkedSpace.cpp:
1226         (JSC::MarkedSpace::freeBlock):
1227
1228 2015-03-07  Ryosuke Niwa  <rniwa@webkit.org>
1229
1230         fromGlobalCode has an unused Debugger* argument
1231         https://bugs.webkit.org/show_bug.cgi?id=142430
1232
1233         Reviewed by Darin Adler.
1234
1235         Removed the debugger argument from UnlinkedFunctionExecutable::fromGlobalCode and
1236         FunctionExecutable::fromGlobalCode since it's not used in either function.
1237
1238         Also use reference in other arguments.
1239
1240         * bytecode/UnlinkedCodeBlock.cpp:
1241         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
1242         * bytecode/UnlinkedCodeBlock.h:
1243         * runtime/Executable.cpp:
1244         (JSC::FunctionExecutable::fromGlobalCode):
1245         * runtime/Executable.h:
1246         * runtime/FunctionConstructor.cpp:
1247         (JSC::constructFunctionSkippingEvalEnabledCheck):
1248
1249 2015-03-06  Brent Fulgham  <bfulgham@apple.com>
1250
1251         [Win] Turn off a warning on Windows.
1252
1253         Reduce build logging noise on Windows.
1254
1255         * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props:
1256
1257 2015-03-06  Joseph Pecoraro  <pecoraro@apple.com>
1258
1259         Web Inspector: ES6: Improved Support for Iterator Objects
1260         https://bugs.webkit.org/show_bug.cgi?id=142420
1261
1262         Reviewed by Timothy Hatcher.
1263
1264         * inspector/protocol/Runtime.json:
1265         Add new object subtype "iterator" for built-in iterator objects.
1266
1267         * inspector/InjectedScriptSource.js:
1268         Return iterator values as Entry objects.
1269
1270         * inspector/JSInjectedScriptHost.cpp:
1271         (Inspector::JSInjectedScriptHost::subtype):
1272         Identify "iterator" typed objects.
1273
1274         (Inspector::JSInjectedScriptHost::getInternalProperties):
1275         Provide internal properties for the different Iterator objects.
1276
1277         (Inspector::JSInjectedScriptHost::iteratorEntries):
1278         Fetch the next few iterator entries of a built-in iterator object.
1279
1280         * inspector/JSInjectedScriptHost.h:
1281         * inspector/JSInjectedScriptHostPrototype.cpp:
1282         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
1283         (Inspector::jsInjectedScriptHostPrototypeFunctionIteratorEntries):
1284         Call through to JSInjectedScriptHost.
1285
1286         * runtime/JSArgumentsIterator.cpp:
1287         (JSC::JSArgumentsIterator::clone):
1288         * runtime/JSArgumentsIterator.h:
1289         (JSC::JSArgumentsIterator::iteratedValue):
1290         * runtime/JSArrayIterator.cpp:
1291         (JSC::JSArrayIterator::kind):
1292         (JSC::JSArrayIterator::iteratedValue):
1293         (JSC::JSArrayIterator::clone):
1294         * runtime/JSArrayIterator.h:
1295         * runtime/JSMapIterator.cpp:
1296         (JSC::JSMapIterator::finishCreation):
1297         (JSC::JSMapIterator::clone):
1298         * runtime/JSMapIterator.h:
1299         (JSC::JSMapIterator::kind):
1300         (JSC::JSMapIterator::iteratedValue):
1301         * runtime/JSSetIterator.cpp:
1302         (JSC::JSSetIterator::finishCreation):
1303         (JSC::JSSetIterator::clone):
1304         * runtime/JSSetIterator.h:
1305         (JSC::JSSetIterator::kind):
1306         (JSC::JSSetIterator::iteratedValue):
1307         * runtime/JSStringIterator.cpp:
1308         (JSC::JSStringIterator::iteratedValue):
1309         (JSC::JSStringIterator::clone):
1310         * runtime/JSStringIterator.h:
1311         Add accessors for internal properties and provide a way to clone the
1312         iterator so we can be at the same index and peek at the next few
1313         objects without modifying the original iterator object.
1314
1315 2015-03-06  Ryosuke Niwa  <rniwa@webkit.org>
1316
1317         REGRESSION(r180595): construct varargs fails in FTL
1318         https://bugs.webkit.org/show_bug.cgi?id=142030
1319
1320         Reviewed by Michael Saboff.
1321
1322         Increase sizeOfCallVarargs as done for sizeOfConstructVarargs in r180651.
1323
1324         * ftl/FTLInlineCacheSize.cpp:
1325         (JSC::FTL::sizeOfCallVarargs):
1326
1327 2015-03-06  Joseph Pecoraro  <pecoraro@apple.com>
1328
1329         Web Inspector: Adopt Object Literal Shorthand Property Construction Syntax
1330         https://bugs.webkit.org/show_bug.cgi?id=142374
1331
1332         Reviewed by Timothy Hatcher.
1333
1334         * inspector/InjectedScriptSource.js:
1335
1336 2015-03-06  Joseph Pecoraro  <pecoraro@apple.com>
1337
1338         ES6: Object Literal Extensions - Methods
1339         https://bugs.webkit.org/show_bug.cgi?id=142390
1340
1341         Reviewed by Geoffrey Garen.
1342
1343         Support method syntax in object literals.
1344
1345         * parser/Parser.h:
1346         * parser/Parser.cpp:
1347         (JSC::stringForFunctionMode):
1348         (JSC::Parser<LexerType>::parseProperty):
1349         Methods are allowed for identifier, string, and numeric names,
1350         and computed property names.
1351
1352         (JSC::Parser<LexerType>::parsePropertyMethod):
1353         Helper for parsing a property method.
1354
1355 2015-03-05  Joseph Pecoraro  <pecoraro@apple.com>
1356
1357         __proto__ shorthand property should not modify prototype in Object Literal construction
1358         https://bugs.webkit.org/show_bug.cgi?id=142382
1359
1360         Reviewed by Geoffrey Garen.
1361
1362         When parsing shorthand property syntax we know we will do a
1363         put direct, even if the property name is __proto__. Pass that
1364         information through to bytecode generation.
1365
1366         * bytecompiler/BytecodeGenerator.cpp:
1367         (JSC::BytecodeGenerator::emitDirectPutById):
1368         * bytecompiler/BytecodeGenerator.h:
1369         * bytecompiler/NodesCodegen.cpp:
1370         (JSC::PropertyListNode::emitPutConstantProperty):
1371         * parser/ASTBuilder.h:
1372         (JSC::ASTBuilder::createGetterOrSetterProperty):
1373         (JSC::ASTBuilder::createProperty):
1374         * parser/NodeConstructors.h:
1375         (JSC::PropertyNode::PropertyNode):
1376         * parser/Nodes.h:
1377         (JSC::PropertyNode::putType):
1378         * parser/Parser.cpp:
1379         (JSC::Parser<LexerType>::parseClass):
1380         (JSC::Parser<LexerType>::parseProperty):
1381         * parser/SyntaxChecker.h:
1382         (JSC::SyntaxChecker::createProperty):
1383
1384 2015-03-06  Geoffrey Garen  <ggaren@apple.com>
1385
1386         Fix crashes seen on the the 32-bit buildbots after my last patch.
1387
1388         Unreviewed.
1389
1390         * heap/CopiedBlock.h:
1391         (JSC::CopiedBlock::payload):
1392         * heap/CopiedSpace.cpp:
1393         (JSC::CopiedSpace::tryAllocateOversize): Round up to the right alignment,
1394         since the size of the CopiedBlock class is not guaranteed to be the
1395         right alignment, and is in fact the wrong alignment on 32-bit.
1396
1397 2015-03-05  Geoffrey Garen  <ggaren@apple.com>
1398
1399         Use FastMalloc (bmalloc) instead of BlockAllocator for GC pages
1400         https://bugs.webkit.org/show_bug.cgi?id=140900
1401
1402         Reviewed by Mark Hahnenberg.
1403
1404         Re-landing just the CopiedBlock piece of this patch.
1405
1406         * heap/CopiedBlock.h:
1407         (JSC::CopiedBlock::createNoZeroFill):
1408         (JSC::CopiedBlock::destroy):
1409         (JSC::CopiedBlock::create):
1410         (JSC::CopiedBlock::CopiedBlock):
1411         (JSC::CopiedBlock::isOversize):
1412         (JSC::CopiedBlock::payloadEnd):
1413         (JSC::CopiedBlock::capacity):
1414         * heap/CopiedSpace.cpp:
1415         (JSC::CopiedSpace::~CopiedSpace):
1416         (JSC::CopiedSpace::tryAllocateOversize):
1417         (JSC::CopiedSpace::tryReallocateOversize):
1418         * heap/CopiedSpaceInlines.h:
1419         (JSC::CopiedSpace::recycleEvacuatedBlock):
1420         (JSC::CopiedSpace::recycleBorrowedBlock):
1421         (JSC::CopiedSpace::allocateBlockForCopyingPhase):
1422         (JSC::CopiedSpace::allocateBlock):
1423         (JSC::CopiedSpace::startedCopying):
1424         * heap/CopyWorkList.h:
1425
1426 2015-03-06  Myles C. Maxfield  <mmaxfield@apple.com>
1427
1428         [iOS] SVG fonts are garbled
1429         https://bugs.webkit.org/show_bug.cgi?id=142377
1430
1431         Reviewed by Simon Fraser.
1432
1433         * Configurations/FeatureDefines.xcconfig:
1434
1435 2015-03-05  Joseph Pecoraro  <pecoraro@apple.com>
1436
1437         ES6: Object Literal Extensions - Shorthand Properties (Identifiers)
1438         https://bugs.webkit.org/show_bug.cgi?id=142353
1439
1440         Reviewed by Geoffrey Garen.
1441
1442         * parser/Parser.cpp:
1443         (JSC::Parser<LexerType>::parseProperty):
1444         Parsing an identifier property followed by a comma or end brace treat
1445         as a shorthand property and create a property that has the same
1446         property name as the identifier name and value of a variable with that
1447         identifier. Otherwise, fall through to getter/setter parsing.
1448
1449 2015-03-05  Brent Fulgham  <bfulgham@apple.com>
1450
1451         [Win] Unreviewed gardening.
1452
1453         Confirmed with JSC that warning 4611 (interaction between '_setjmp' and C++ object
1454         destruction is non-portable) should be ignored in the JavaScriptCore project.
1455
1456         * JavaScriptCore.vcxproj/JavaScriptCoreCommon.props: Silence warning 4611.
1457
1458 2015-03-05  Chris Dumez  <cdumez@apple.com>
1459
1460         Regression(r173761): ASSERTION FAILED: !is8Bit() in StringImpl::characters16()
1461         https://bugs.webkit.org/show_bug.cgi?id=142350
1462
1463         Reviewed by Michael Saboff and Benjamin Poulain.
1464
1465         Call WTFString::hasInfixStartingAt() / hasInfixEndingAt() now that these
1466         methods have been renamed for clarity.
1467
1468         * runtime/StringPrototype.cpp:
1469         (JSC::stringProtoFuncStartsWith):
1470         (JSC::stringProtoFuncEndsWith):
1471
1472 2015-03-05  Yusuke Suzuki  <utatane.tea@gmail.com>
1473
1474         Implement ES6 StringIterator
1475         https://bugs.webkit.org/show_bug.cgi?id=142080
1476
1477         Reviewed by Filip Pizlo.
1478
1479         This patch introduces ES6 String Iterator.
1480         It enumerates code points instead of elements in String.
1481         So surrogate pairs should be handled correctly.
1482
1483         * CMakeLists.txt:
1484         * DerivedSources.make:
1485         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1486         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1487         * JavaScriptCore.xcodeproj/project.pbxproj:
1488         * builtins/StringIterator.prototype.js: Added.
1489         (next):
1490         * runtime/CommonIdentifiers.h:
1491         * runtime/JSGlobalObject.cpp:
1492         * runtime/JSGlobalObject.h:
1493         * runtime/JSStringIterator.cpp: Added.
1494         (JSC::JSStringIterator::finishCreation):
1495         * runtime/JSStringIterator.h: Added.
1496         (JSC::JSStringIterator::createStructure):
1497         (JSC::JSStringIterator::create):
1498         (JSC::JSStringIterator::JSStringIterator):
1499         * runtime/StringIteratorConstructor.cpp: Added.
1500         (JSC::StringIteratorConstructor::finishCreation):
1501         * runtime/StringIteratorConstructor.h: Added.
1502         (JSC::StringIteratorConstructor::create):
1503         (JSC::StringIteratorConstructor::createStructure):
1504         (JSC::StringIteratorConstructor::StringIteratorConstructor):
1505         * runtime/StringIteratorPrototype.cpp: Added.
1506         (JSC::StringIteratorPrototype::finishCreation):
1507         (JSC::StringIteratorPrototype::getOwnPropertySlot):
1508         (JSC::stringIteratorPrototypeIterator):
1509         * runtime/StringIteratorPrototype.h: Added.
1510         (JSC::StringIteratorPrototype::create):
1511         (JSC::StringIteratorPrototype::createStructure):
1512         (JSC::StringIteratorPrototype::StringIteratorPrototype):
1513         * runtime/StringPrototype.cpp:
1514         (JSC::StringPrototype::finishCreation):
1515         (JSC::stringProtoFuncIterator):
1516         * tests/stress/string-iterators.js: Added.
1517         (testSurrogatePair):
1518         (increment):
1519         (for):
1520
1521 2015-03-05  Csaba Osztrogonác  <ossy@webkit.org>
1522
1523         [ARM] Fix the FTL build on Aarch64 Linux after r177421
1524         https://bugs.webkit.org/show_bug.cgi?id=142040
1525
1526         Reviewed by Mark Lam.
1527
1528         * llvm/library/LLVMExports.cpp:
1529         (initializeAndGetJSCLLVMAPI):
1530
1531 2015-03-05  Yusuke Suzuki  <utatane.tea@gmail.com>
1532
1533         Upgrade ES6 Iterator interfaces
1534         https://bugs.webkit.org/show_bug.cgi?id=141351
1535
1536         Reviewed by Filip Pizlo.
1537
1538         This patch upgrades the exising ES6 iterator to align the latest spec.
1539         In the latest spec,
1540         1. `Iterator.next` returns object that implements IteratorResult interface { value: value, done, boolean }.
1541         2. `Iterator.return` is introduced. When the iteration is terminated by the abrupt completion,
1542         it is called to close iterator state.
1543         3. Iterator.next of Array is moved from an iterator object to `%ArrayIteratorPrototype%`.
1544
1545         To upgrade it, we changes the bytecode that represents for-of loops.
1546         And to embody the efficient iteration with an iterator object,
1547         we implemented %ArrayIteratorPrototype%.next in JavaScript and
1548         it is located in builtins/ArrayIterator.prototype.js.
1549         Implementing it in JavaScript encourages inlining and
1550         utilizes escape analysis for an iterator result object in DFG JIT.
1551         And we dropped the intrinsic version of %ArrayIteratorPrototype%.next.
1552
1553         And we introduced IteratorOperations that is defined in the spec.
1554         It aligns the iteration in the runtime to the latest spec.
1555         Currently, Promise.all and Promise.race uses an iterable object.
1556         However, Promise.all and Promise.race implementation is also based on the old spec.
1557         Subsequent patches will upgrade it.
1558
1559         * CMakeLists.txt:
1560         * DerivedSources.make:
1561         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1562         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1563         * JavaScriptCore.xcodeproj/project.pbxproj:
1564         * builtins/ArrayIterator.prototype.js: Copied from Source/JavaScriptCore/runtime/ArrayIteratorPrototype.h.
1565         (next):
1566         * bytecompiler/BytecodeGenerator.cpp:
1567         (JSC::BytecodeGenerator::emitReturn):
1568         (JSC::BytecodeGenerator::emitThrowTypeError):
1569         (JSC::BytecodeGenerator::emitEnumeration):
1570         (JSC::BytecodeGenerator::emitIsObject):
1571         (JSC::BytecodeGenerator::emitIsUndefined):
1572         * bytecompiler/BytecodeGenerator.h:
1573         * jit/ThunkGenerators.cpp:
1574         (JSC::arrayIteratorNextThunkGenerator): Deleted.
1575         (JSC::arrayIteratorNextKeyThunkGenerator): Deleted.
1576         (JSC::arrayIteratorNextValueThunkGenerator): Deleted.
1577         * jit/ThunkGenerators.h:
1578         * runtime/ArgumentsIteratorPrototype.cpp:
1579         (JSC::ArgumentsIteratorPrototype::finishCreation):
1580         (JSC::argumentsIteratorPrototypeFuncNext):
1581         * runtime/ArrayIteratorPrototype.cpp:
1582         (JSC::ArrayIteratorPrototype::finishCreation):
1583         (JSC::ArrayIteratorPrototype::getOwnPropertySlot):
1584         (JSC::arrayIteratorProtoFuncIterator):
1585         (JSC::arrayIteratorPrototypeIterate): Deleted.
1586         * runtime/ArrayIteratorPrototype.h:
1587         * runtime/CommonIdentifiers.h:
1588         * runtime/Intrinsic.h:
1589         * runtime/IteratorOperations.cpp: Added.
1590         (JSC::iteratorNext):
1591         (JSC::iteratorValue):
1592         (JSC::iteratorComplete):
1593         (JSC::iteratorStep):
1594         (JSC::iteratorClose):
1595         (JSC::createIterResultObject):
1596         * runtime/IteratorOperations.h: Copied from Source/JavaScriptCore/runtime/ArrayIteratorPrototype.cpp.
1597         * runtime/JSArrayIterator.cpp:
1598         (JSC::JSArrayIterator::finishCreation):
1599         (JSC::JSArrayIterator::visitChildren): Deleted.
1600         (JSC::createIteratorResult): Deleted.
1601         (JSC::arrayIteratorNext): Deleted.
1602         (JSC::arrayIteratorNextKey): Deleted.
1603         (JSC::arrayIteratorNextValue): Deleted.
1604         (JSC::arrayIteratorNextGeneric): Deleted.
1605         * runtime/JSArrayIterator.h:
1606         (JSC::JSArrayIterator::JSArrayIterator):
1607         (JSC::JSArrayIterator::iterationKind): Deleted.
1608         (JSC::JSArrayIterator::iteratedObject): Deleted.
1609         (JSC::JSArrayIterator::nextIndex): Deleted.
1610         (JSC::JSArrayIterator::setNextIndex): Deleted.
1611         (JSC::JSArrayIterator::finish): Deleted.
1612         (JSC::JSArrayIterator::offsetOfIterationKind): Deleted.
1613         (JSC::JSArrayIterator::offsetOfIteratedObject): Deleted.
1614         (JSC::JSArrayIterator::offsetOfNextIndex): Deleted.
1615         * runtime/JSGlobalObject.cpp:
1616         (JSC::JSGlobalObject::init):
1617         * runtime/JSPromiseConstructor.cpp:
1618         (JSC::performPromiseRaceLoop):
1619         (JSC::JSPromiseConstructorFuncRace):
1620         (JSC::performPromiseAll):
1621         (JSC::JSPromiseConstructorFuncAll):
1622         * runtime/MapIteratorPrototype.cpp:
1623         (JSC::MapIteratorPrototype::finishCreation):
1624         (JSC::MapIteratorPrototypeFuncNext):
1625         * runtime/SetIteratorPrototype.cpp:
1626         (JSC::SetIteratorPrototype::finishCreation):
1627         (JSC::SetIteratorPrototypeFuncNext):
1628         * runtime/VM.cpp:
1629         (JSC::thunkGeneratorForIntrinsic):
1630         * tests/stress/array-iterators-next-with-call.js: Added.
1631         (increment):
1632         (for):
1633         * tests/stress/array-iterators-next.js: Added.
1634
1635         Revive the older Array iterator tests that manually call 'next' method.
1636
1637         * tests/stress/custom-iterators.js: Added.
1638         (iter.next):
1639         (iter.Symbol.iterator):
1640         (iter.return):
1641         (iter.get next):
1642         (iter.get return):
1643         (iteratorInterfaceErrorTest.iter.next):
1644         (iteratorInterfaceErrorTest.iter.Symbol.iterator):
1645         (iteratorInterfaceErrorTest.iter.return):
1646         (iteratorInterfaceErrorTest):
1647         (iteratorInterfaceErrorTestReturn.iter.next):
1648         (iteratorInterfaceErrorTestReturn.iter.Symbol.iterator):
1649         (iteratorInterfaceErrorTestReturn.iter.return):
1650         (iteratorInterfaceErrorTestReturn):
1651         (iteratorInterfaceBreakTestReturn.iter.next):
1652         (iteratorInterfaceBreakTestReturn.iter.Symbol.iterator):
1653         (iteratorInterfaceBreakTestReturn.iter.return):
1654         (iteratorInterfaceBreakTestReturn):
1655
1656         This tests the behavior of custom iterators.
1657         'next' and 'return' of iterator work with for-of.
1658
1659         * tests/stress/iterators-shape.js: Added.
1660         (iteratorShape):
1661         (sameNextMethods):
1662         (set var):
1663
1664         This tests the shape of iterators; iterators of Array have 'next' method in %ArrayIteratorPrototype%.
1665
1666         * tests/stress/map-iterators-next.js: Added.
1667         (set var):
1668         (.get if):
1669         (otherKey):
1670         * tests/stress/set-iterators-next.js: Added.
1671         (otherKey):
1672
1673 2015-03-04  Yusuke Suzuki  <utatane.tea@gmail.com>
1674
1675         Hide Promise with runtime flags under Cocoa JSContext API
1676         https://bugs.webkit.org/show_bug.cgi?id=141965
1677
1678         Reviewed by Filip Pizlo.
1679
1680         Since there's no run loop in JavaScriptCore APIs, Promises don't work currently.
1681         So until they work, we hide Promise from a global object.
1682         Introduce new JSC runtime flag, PromiseDisabled. When `isPromiseDisabled` is true,
1683         Promise constructor is not attached to JSGlobalObject.
1684
1685         To make 0 as default runtime flags, we choose PromiseDisabled flag
1686         instead of PromiseEnabled flag. So by default, Promise is enabled.
1687
1688         * API/JSCallbackObjectFunctions.h:
1689         (JSC::JSCallbackObject<Parent>::JSCallbackObject):
1690         * API/JSContextRef.cpp:
1691         (javaScriptRuntimeFlags):
1692         (JSGlobalContextCreateInGroup):
1693         * API/tests/testapi.c:
1694         (main):
1695         * API/tests/testapi.mm:
1696         (testObjectiveCAPI):
1697         * runtime/JSGlobalObject.cpp:
1698         (JSC::JSGlobalObject::init):
1699         * runtime/JSGlobalObject.h:
1700         (JSC::JSGlobalObject::create):
1701         * runtime/RuntimeFlags.h:
1702         (JSC::RuntimeFlags::createAllEnabled):
1703
1704 2015-03-04  Joseph Pecoraro  <pecoraro@apple.com>
1705
1706         Web Inspector: Array/Collection Sizes should be visible and distinct
1707         https://bugs.webkit.org/show_bug.cgi?id=142254
1708
1709         Reviewed by Timothy Hatcher.
1710
1711         * runtime/WeakMapData.h:
1712         (JSC::WeakMapData::size):
1713         * inspector/JSInjectedScriptHost.cpp:
1714         (Inspector::JSInjectedScriptHost::weakMapSize):
1715         * inspector/JSInjectedScriptHost.h:
1716         * inspector/JSInjectedScriptHostPrototype.cpp:
1717         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
1718         (Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapSize):
1719         Add a way to get a WeakMap's size.
1720
1721         * inspector/protocol/Runtime.json:
1722         Include size in RemoteObject and ObjectPreview.
1723
1724         * inspector/InjectedScriptSource.js:
1725         Set the size of RemoteObjects and previews if they
1726         are array/collection types.
1727
1728 2015-03-04  Andreas Kling  <akling@apple.com>
1729
1730         GC should compute stack bounds and dump registers at the earliest opportunity.
1731         <https://webkit.org/b/142310>
1732         <rdar://problem/20045624>
1733
1734         Reviewed by Geoffrey Garen.
1735
1736         Make Heap::collect() a wrapper function around a collectImpl() where the work is actually done.
1737         The wrapper function that grabs a snapshot of the current stack boundaries and register values
1738         on entry, and sanitizes the stack on exit.
1739
1740         This is a speculative fix for what appears to be overly conservative behavior in the garbage
1741         collector following r178364 which caused a measurable regression in memory usage on Membuster.
1742         The theory being that we were putting pointers to dead things on the stack before scanning it,
1743         and by doing that ended up marking things that we'd otherwise discover to be garbage.
1744
1745         * heap/Heap.cpp:
1746         (JSC::Heap::markRoots):
1747         (JSC::Heap::gatherStackRoots):
1748         (JSC::Heap::collect):
1749         (JSC::Heap::collectImpl):
1750         * heap/Heap.h:
1751         * heap/MachineStackMarker.cpp:
1752         (JSC::MachineThreads::gatherFromCurrentThread):
1753         (JSC::MachineThreads::gatherConservativeRoots):
1754         * heap/MachineStackMarker.h:
1755
1756 2015-03-04  Debarshi Ray  <debarshir@gnome.org>
1757
1758         Silence GCC's -Wstrict-prototypes
1759         https://bugs.webkit.org/show_bug.cgi?id=142278
1760
1761         Reviewed by Alexey Proskuryakov.
1762
1763         * API/JSContextRef.h:
1764
1765 2015-03-04  Benjamin Poulain  <bpoulain@apple.com>
1766
1767         [JSC] Add a node for Math.log()
1768         https://bugs.webkit.org/show_bug.cgi?id=142126
1769
1770         Reviewed by Geoffrey Garen.
1771
1772         This patch adds the DFG node ArithLog for LogIntrinsic.
1773
1774         Having a direct call to log has very little value by itself, the implementation
1775         in DFG and FTL is a simple function call.
1776
1777         What is useful in ArithLog is that we know the operation is pure.
1778         This allow us to hoist it out of loops when the argument is independent
1779         is an invariant of the loop.
1780
1781         Perf wise, this patch gives:
1782         -Kraken's imaging-darkroom: definitely 1.2372x faster.
1783         -AsmBench's Towers.c: definitely 1.0261x faster.
1784
1785         * dfg/DFGAbstractInterpreterInlines.h:
1786         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1787         * dfg/DFGByteCodeParser.cpp:
1788         (JSC::DFG::ByteCodeParser::handleIntrinsic):
1789         * dfg/DFGClobberize.h:
1790         (JSC::DFG::clobberize):
1791         * dfg/DFGDoesGC.cpp:
1792         (JSC::DFG::doesGC):
1793         * dfg/DFGFixupPhase.cpp:
1794         (JSC::DFG::FixupPhase::fixupNode):
1795         * dfg/DFGNodeType.h:
1796         * dfg/DFGPredictionPropagationPhase.cpp:
1797         (JSC::DFG::PredictionPropagationPhase::propagate):
1798         (JSC::DFG::PredictionPropagationPhase::doDoubleVoting):
1799         * dfg/DFGSafeToExecute.h:
1800         (JSC::DFG::safeToExecute):
1801         * dfg/DFGSpeculativeJIT.cpp:
1802         (JSC::DFG::SpeculativeJIT::compileArithLog):
1803         * dfg/DFGSpeculativeJIT.h:
1804         * dfg/DFGSpeculativeJIT32_64.cpp:
1805         (JSC::DFG::SpeculativeJIT::compile):
1806         * dfg/DFGSpeculativeJIT64.cpp:
1807         (JSC::DFG::SpeculativeJIT::compile):
1808         * ftl/FTLCapabilities.cpp:
1809         (JSC::FTL::canCompile):
1810         * ftl/FTLIntrinsicRepository.h:
1811         * ftl/FTLLowerDFGToLLVM.cpp:
1812         (JSC::FTL::LowerDFGToLLVM::compileNode):
1813         (JSC::FTL::LowerDFGToLLVM::compileArithLog):
1814         * ftl/FTLOutput.h:
1815         (JSC::FTL::Output::doubleLog):
1816         * tests/stress/math-log-basics.js: Added.
1817         * tests/stress/math-log-with-constants.js: Added.
1818
1819 2015-03-04  Filip Pizlo  <fpizlo@apple.com>
1820
1821         Only Heap should be in charge of deciding how to select a subspace for a type
1822         https://bugs.webkit.org/show_bug.cgi?id=142304
1823
1824         Reviewed by Mark Lam.
1825         
1826         This slightly reduces the code duplication for selecting subspace based on type, and what
1827         duplication is left is at least localized in HeapInlines.h. The immediate effect is that
1828         the DFG and FTL don't have to duplicate this pattern.
1829
1830         * dfg/DFGSpeculativeJIT.h:
1831         (JSC::DFG::SpeculativeJIT::emitAllocateJSObject):
1832         (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject):
1833         * ftl/FTLLowerDFGToLLVM.cpp:
1834         (JSC::FTL::LowerDFGToLLVM::allocateObject):
1835         * heap/Heap.h:
1836         * heap/HeapInlines.h:
1837         (JSC::Heap::allocateObjectOfType):
1838         (JSC::Heap::subspaceForObjectOfType):
1839         (JSC::Heap::allocatorForObjectOfType):
1840         * runtime/JSCellInlines.h:
1841         (JSC::allocateCell):
1842
1843 2015-03-04  Andreas Kling  <akling@apple.com>
1844
1845         Stale entries in WeakGCMaps are keeping tons of WeakBlocks alive unnecessarily.
1846         <https://webkit.org/b/142115>
1847         <rdar://problem/19992268>
1848
1849         Reviewed by Geoffrey Garen.
1850
1851         Prune stale entries from WeakGCMaps as part of every full garbage collection.
1852         This frees up tons of previously-stuck WeakBlocks that were only sitting around
1853         with finalized handles waiting to die.
1854
1855         Note that WeakGCMaps register/unregister themselves with the GC heap in their
1856         ctor/dtor, so creating one now requires passing the VM.
1857
1858         Average time spent in the PruningStaleEntriesFromWeakGCMaps GC phase appears
1859         to be between 0.01ms and 0.3ms, though I've seen a few longer ones at ~1.2ms.
1860         It seems somewhat excessive to do this on every Eden collection, so it's only
1861         doing work in full collections for now.
1862
1863         * API/JSWeakObjectMapRefInternal.h:
1864         (OpaqueJSWeakObjectMap::create):
1865         (OpaqueJSWeakObjectMap::OpaqueJSWeakObjectMap):
1866         * API/JSWeakObjectMapRefPrivate.cpp:
1867         * API/JSWrapperMap.mm:
1868         (-[JSWrapperMap initWithContext:]):
1869         (-[JSWrapperMap jsWrapperForObject:]): Pass VM to WeakGCMap constructor.
1870
1871         * JavaScriptCore.xcodeproj/project.pbxproj: Add WeakGCMapInlines.h and make
1872         it project-private so WebCore clients can access it.
1873
1874         * heap/Heap.cpp:
1875         (JSC::Heap::collect):
1876         (JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Added a new GC phase for pruning
1877         stale entries from WeakGCMaps. This is only executed during full collections.
1878
1879         * heap/Heap.h:
1880         * heap/HeapInlines.h:
1881         (JSC::Heap::registerWeakGCMap):
1882         (JSC::Heap::unregisterWeakGCMap): Added a mechanism for WeakGCMaps to register
1883         themselves with the Heap and provide a pruning callback.
1884
1885         * runtime/PrototypeMap.h:
1886         (JSC::PrototypeMap::PrototypeMap):
1887         * runtime/Structure.cpp:
1888         (JSC::StructureTransitionTable::add): Pass VM to WeakGCMap constructor.
1889
1890         * runtime/JSCInlines.h: Add "WeakGCMapInlines.h"
1891
1892         * runtime/JSGlobalObject.cpp: Include "WeakGCMapInlines.h" so this builds.
1893
1894         * runtime/VM.cpp:
1895         (JSC::VM::VM): Pass VM to WeakGCMap constructor.
1896
1897         * runtime/WeakGCMap.h:
1898         (JSC::WeakGCMap::set):
1899         (JSC::WeakGCMap::add):
1900         (JSC::WeakGCMap::WeakGCMap): Deleted.
1901         (JSC::WeakGCMap::gcMap): Deleted.
1902         (JSC::WeakGCMap::gcMapIfNeeded): Deleted.
1903         * runtime/WeakGCMapInlines.h: Added.
1904         (JSC::WeakGCMap::WeakGCMap):
1905         (JSC::WeakGCMap::~WeakGCMap):
1906         (JSC::WeakGCMap::pruneStaleEntries): Moved ctor, dtor and pruning callback
1907         to WeakGCMapInlines.h to fix interdependent header issues. Removed code that
1908         prunes WeakGCMap at certain growth milestones and instead rely on the GC
1909         callback for housekeeping.
1910
1911 2015-03-03  Filip Pizlo  <fpizlo@apple.com>
1912
1913         DFG IR should refer to FunctionExecutables directly and not via the CodeBlock
1914         https://bugs.webkit.org/show_bug.cgi?id=142229
1915
1916         Reviewed by Mark Lam and Benjamin Poulain.
1917         
1918         Anytime a DFG IR node refers to something in CodeBlock, it has three effects:
1919
1920         - Cumbersome API for accessing the thing that the node refers to.
1921         
1922         - Not obvious how to create a new such node after bytecode parsing, especially if the
1923           thing it refers to isn't already in the CodeBlock. We have done this in the past, but
1924           it usually involves subtle changes to CodeBlock.
1925         
1926         - Not obvious how to inline code that ends up using such nodes. Again, when we have done
1927           this, it involved subtle changes to CodeBlock.
1928         
1929         Prior to this change, the NewFunction* node types used an index into tables in CodeBlock.
1930         For this reason, those operations were not inlineable. But the functin tables in CodeBlock
1931         just point to FunctionExecutables, which are cells; this means that we can just abstract
1932         these operands in DFG IR as cellOperands. cellOperands use DFG::FrozenValue, which means
1933         that GC registration happens automagically. Even better, our dumping for cellOperand
1934         already did FunctionExecutable dumping - so that functionality gets to be deduplicated.
1935         
1936         Because this change increases the number of users of cellOperand, it also adds some
1937         convenience methods for using it. For example, whereas before you'd say things like:
1938         
1939             jsCast<Foo*>(node->cellOperand()->value())
1940         
1941         you can now just say:
1942         
1943             node->castOperand<Foo*>()
1944         
1945         This change also changes existing cellOperand users to use the new conveniance API when
1946         applicable.
1947
1948         * bytecode/CodeBlock.cpp:
1949         (JSC::CodeBlock::jettisonFunctionDeclsAndExprs):
1950         * bytecode/CodeBlock.h:
1951         * dfg/DFGByteCodeParser.cpp:
1952         (JSC::DFG::ByteCodeParser::parseBlock):
1953         * dfg/DFGCapabilities.cpp:
1954         (JSC::DFG::capabilityLevel):
1955         * dfg/DFGFrozenValue.h:
1956         (JSC::DFG::FrozenValue::cell):
1957         (JSC::DFG::FrozenValue::dynamicCast):
1958         (JSC::DFG::FrozenValue::cast):
1959         * dfg/DFGGraph.cpp:
1960         (JSC::DFG::Graph::dump):
1961         (JSC::DFG::Graph::registerFrozenValues):
1962         * dfg/DFGNode.h:
1963         (JSC::DFG::Node::hasCellOperand):
1964         (JSC::DFG::Node::castOperand):
1965         (JSC::DFG::Node::hasFunctionDeclIndex): Deleted.
1966         (JSC::DFG::Node::functionDeclIndex): Deleted.
1967         (JSC::DFG::Node::hasFunctionExprIndex): Deleted.
1968         (JSC::DFG::Node::functionExprIndex): Deleted.
1969         * dfg/DFGSpeculativeJIT.cpp:
1970         (JSC::DFG::SpeculativeJIT::compileNewFunctionNoCheck):
1971         (JSC::DFG::SpeculativeJIT::compileNewFunctionExpression):
1972         * dfg/DFGSpeculativeJIT32_64.cpp:
1973         (JSC::DFG::SpeculativeJIT::compile):
1974         * dfg/DFGSpeculativeJIT64.cpp:
1975         (JSC::DFG::SpeculativeJIT::compile):
1976         * dfg/DFGWatchpointCollectionPhase.cpp:
1977         (JSC::DFG::WatchpointCollectionPhase::handle):
1978         * ftl/FTLLowerDFGToLLVM.cpp:
1979         (JSC::FTL::LowerDFGToLLVM::compileCheckCell):
1980         (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
1981
1982 2015-03-03  Michael Saboff  <msaboff@apple.com>
1983
1984         DelayedReleaseScope drops locks during GC which can cause a thread switch and code reentry
1985         https://bugs.webkit.org/show_bug.cgi?id=141275
1986
1987         Reviewed by Geoffrey Garen.
1988
1989         The original issue is that the CodeCache uses an unsafe method to add new UnlinkedCodeBlocks.
1990         It basically adds a null UnlinkedCodeBlock if there isn't a cached entry and then later
1991         updates the null entry to the result of the compilation.  If during that compilation and
1992         related processing we need to garbage collect, the DelayedReleaseScope would drop locks
1993         possibly allowing another thread to try to get the same source out of the CodeCache.
1994         This second thread would find the null entry and crash.  The fix is to move the processing of
1995         DelayedReleaseScope to when we drop locks and not drop locks during GC.  That was done in
1996         the original patch with the new function releaseDelayedReleasedObjects().
1997
1998         Updated releaseDelayedReleasedObjects() so that objects are released with all locks
1999         dropped.  Now its processing follows these steps
2000             Increment recursion counter and do recursion check and exit if recursing
2001             While there are objects to release
2002                 ASSERT that lock is held by current thread
2003                 Take all items from delayed release Vector and put into temporary Vector
2004                 Release API lock
2005                 Release and clear items from temporary vector
2006                 Reaquire API lock
2007         This meets the requirement that we release while the API lock is released and it is
2008         safer processing of the delayed release Vector.
2009
2010         Added new regression test to testapi.
2011
2012         Also added comment describing how recursion into releaseDelayedReleasedObjects() is
2013         prevented.
2014
2015         * API/tests/Regress141275.h: Added.
2016         * API/tests/Regress141275.mm: Added.
2017         (+[JSTEvaluatorTask evaluatorTaskWithEvaluateBlock:completionHandler:]):
2018         (-[JSTEvaluator init]):
2019         (-[JSTEvaluator initWithScript:]):
2020         (-[JSTEvaluator _accessPendingTasksWithBlock:]):
2021         (-[JSTEvaluator insertSignPostWithCompletion:]):
2022         (-[JSTEvaluator evaluateScript:completion:]):
2023         (-[JSTEvaluator evaluateBlock:completion:]):
2024         (-[JSTEvaluator waitForTasksDoneAndReportResults]):
2025         (__JSTRunLoopSourceScheduleCallBack):
2026         (__JSTRunLoopSourcePerformCallBack):
2027         (__JSTRunLoopSourceCancelCallBack):
2028         (-[JSTEvaluator _jsThreadMain]):
2029         (-[JSTEvaluator _sourceScheduledOnRunLoop:]):
2030         (-[JSTEvaluator _setupEvaluatorThreadContextIfNeeded]):
2031         (-[JSTEvaluator _callCompletionHandler:ifNeededWithError:]):
2032         (-[JSTEvaluator _sourcePerform]):
2033         (-[JSTEvaluator _sourceCanceledOnRunLoop:]):
2034         (runRegress141275):
2035         * API/tests/testapi.mm:
2036         (testObjectiveCAPI):
2037         * JavaScriptCore.xcodeproj/project.pbxproj:
2038         * heap/Heap.cpp:
2039         (JSC::Heap::releaseDelayedReleasedObjects):
2040         * runtime/JSLock.cpp:
2041         (JSC::JSLock::unlock):
2042
2043 2015-03-03  Filip Pizlo  <fpizlo@apple.com>
2044
2045         DFG should constant fold GetScope, and accesses to the scope register in the ByteCodeParser should not pretend that it's a constant as that breaks OSR exit liveness tracking
2046         https://bugs.webkit.org/show_bug.cgi?id=106202
2047
2048         Rubber stamped by Benjamin Poulain.
2049         
2050         This fixes a bug discovered by working on https://bugs.webkit.org/show_bug.cgi?id=142229,
2051         which was in turn discovered by working on https://bugs.webkit.org/show_bug.cgi?id=141174.
2052         Our way of dealing with scopes known to be constant is very sketchy, and only really works
2053         when a function is inlined. When it is, we pretend that every load of the scopeRegister sees
2054         a constant. But this breaks the DFG's tracking of the liveness of the scopeRegister. The way
2055         this worked made us miss oppportunities for optimizing based on a constant scope, and it also
2056         meant that in some cases - particularly like when we inline code that uses NewFuction and
2057         friends, as I do in bug 142229 - it makes OSR exit think that the scope is dead even though
2058         it's most definitely alive and it's a constant.
2059         
2060         The problem here is that we were doing too many optimizations in the ByteCodeParser, and not
2061         later. Later optimization phases know how to preserve OSR exit liveness. They're actually
2062         really good at it. Also, later phases know how to infer that any variable is a constant no
2063         matter how that constant arose - rather than the inlining-specific thing in ByteCodeParser.
2064         
2065         This changes the ByteCodeParser to largely avoid doing constant folding on the scope, except
2066         making the GetScope operation itself a constant. This is a compilation-time hack for small
2067         functions, and it doesn't break the loads of local variables - so OSR exit liveness still
2068         sees that the scopeRegister is in use. This then adds a vastly more powerful GetScope and
2069         GetClosureVar constant folder in the AbstractInterpreter. This handles most general cases
2070         including those that arise in complex control flow. This will catch cases where the scope
2071         is constant for any number of reasons. Basically anytime that the callee is inferred constant
2072         this will give us a constant scope. Also, we still have the parse-time constant folding of
2073         ResolveScope based on the reentry watchpoint, which luckily did the right thing with respect
2074         to OSR exit liveness (it splats a Phantom on its inputs, and it produces a constant result
2075         which is then set() normally).
2076         
2077         This appears to be a broad speed-up, albeit a small one. But mainly it unblocks bug 142229,
2078         which then should unblock bug 141174.
2079
2080         * dfg/DFGAbstractInterpreterInlines.h:
2081         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2082         * dfg/DFGByteCodeParser.cpp:
2083         (JSC::DFG::ByteCodeParser::get):
2084         (JSC::DFG::ByteCodeParser::getLocal):
2085         (JSC::DFG::ByteCodeParser::parseBlock):
2086         (JSC::DFG::ByteCodeParser::parse):
2087         * dfg/DFGClobberize.h:
2088         (JSC::DFG::clobberize):
2089         * dfg/DFGDoesGC.cpp:
2090         (JSC::DFG::doesGC):
2091         * dfg/DFGFixupPhase.cpp:
2092         (JSC::DFG::FixupPhase::fixupNode):
2093         * dfg/DFGGraph.cpp:
2094         (JSC::DFG::Graph::tryGetConstantClosureVar):
2095         (JSC::DFG::Graph::tryGetRegisters):
2096         (JSC::DFG::Graph::tryGetActivation): Deleted.
2097         * dfg/DFGGraph.h:
2098         * dfg/DFGNode.h:
2099         (JSC::DFG::Node::hasVariableWatchpointSet):
2100         (JSC::DFG::Node::hasSymbolTable): Deleted.
2101         (JSC::DFG::Node::symbolTable): Deleted.
2102         * dfg/DFGNodeType.h:
2103         * dfg/DFGPredictionPropagationPhase.cpp:
2104         (JSC::DFG::PredictionPropagationPhase::propagate):
2105         * dfg/DFGSafeToExecute.h:
2106         (JSC::DFG::safeToExecute):
2107         * dfg/DFGSpeculativeJIT32_64.cpp:
2108         (JSC::DFG::SpeculativeJIT::compile):
2109         * dfg/DFGSpeculativeJIT64.cpp:
2110         (JSC::DFG::SpeculativeJIT::compile):
2111         * dfg/DFGWatchpointCollectionPhase.cpp:
2112         (JSC::DFG::WatchpointCollectionPhase::handle):
2113         * ftl/FTLCapabilities.cpp:
2114         (JSC::FTL::canCompile):
2115         * ftl/FTLLowerDFGToLLVM.cpp:
2116         (JSC::FTL::LowerDFGToLLVM::compileNode):
2117         (JSC::FTL::LowerDFGToLLVM::compileGetClosureVar):
2118         * runtime/SymbolTable.cpp:
2119         (JSC::SymbolTable::visitChildren):
2120         (JSC::SymbolTable::localToEntry):
2121         (JSC::SymbolTable::entryFor):
2122         * runtime/SymbolTable.h:
2123         (JSC::SymbolTable::add):
2124         (JSC::SymbolTable::set):
2125         * tests/stress/function-expression-exit.js: Added.
2126         * tests/stress/function-reentry-infer-on-self.js: Added.
2127         (thingy):
2128         * tests/stress/goofy-function-reentry-incorrect-inference.js: Added.
2129
2130 2015-03-03  Anders Carlsson  <andersca@apple.com>
2131
2132         Remove unused compression code
2133         https://bugs.webkit.org/show_bug.cgi?id=142237
2134
2135         Reviewed by Geoffrey Garen.
2136
2137         * bytecode/UnlinkedCodeBlock.h:
2138
2139 2015-03-03  Filip Pizlo  <fpizlo@apple.com>
2140
2141         JIT debugging features that selectively disable the JITs for code blocks need to stay out of the way of the critical path of JIT management
2142         https://bugs.webkit.org/show_bug.cgi?id=142234
2143
2144         Reviewed by Mark Lam and Benjamin Poulain.
2145         
2146         Long ago, we used to selectively disable compilation of CodeBlocks for debugging purposes by
2147         adding hacks to DFGDriver.cpp.  This was all well and good.  It used the existing
2148         CompilationFailed mode of the DFG driver to signal failure of CodeBlocks that we didn't want
2149         to compile.  That's great because CompilationFailed is a well-supported return value on the
2150         critical path, usually used for when we run out of JIT memory.
2151
2152         Later, this was moved into DFGCapabilities. This was basically incorrect. It introduced a bug
2153         where disabling compiling of a CodeBlock meant that we stopped inlining it as well.  So if
2154         you had a compiler bug that arose if foo was inlined into bar, and you bisected down to bar,
2155         then foo would no longer get inlined and you wouldn't see the bug.  That's busted.
2156
2157         So then we changed the code in DFGCapabilities to mark bar as CanCompile and foo as
2158         CanInline. Now, foo wouldn't get compiled alone but it would get inlined.
2159
2160         But then we removed CanCompile because that capability mode only existed for the purpose of
2161         our old varargs hacks.  After that removal, "CanInline" became CannotCompile.  This means
2162         that if you bisect down on bar in the "foo inlined into bar" case, you'll crash in the DFG
2163         because the baseline JIT wouldn't have known to insert profiling on foo.
2164
2165         We could fix this by bringing back CanInline.
2166
2167         But this is all a pile of nonsense.  The debug support to selectively disable compilation of
2168         some CodeBlocks shouldn't cross-cut our entire engine and should most certainly never involve
2169         adding new capability modes.  This support is a hack at best and is for use by JSC hackers
2170         only.  It should be as unintrusive as possible.
2171
2172         So, as in the ancient times, the only proper place to put this hack is in DFGDriver.cpp, and
2173         return CompilationFailed.  This is correct not just because it takes capability modes out of
2174         the picture (and obviates the need to introduce new ones), but also because it means that
2175         disabling compilation doesn't change the profiling mode of other CodeBlocks in the Baseline
2176         JIT.  Capability mode influences profiling mode which in turn influences code generation in
2177         the Baseline JIT, sometimes in very significant ways - like, we sometimes do additional
2178         double-to-int conversions in Baseline if we know that we might tier-up into the DFG, since
2179         this buys us more precise profiling.
2180         
2181         This change reduces the intrusiveness of debugging hacks by making them use the very simple
2182         CompilationFailed mechanism rather than trying to influence capability modes. Capability
2183         modes have very subtle effects on the whole engine, while CompilationFailed just makes the
2184         engine pretend like the DFG compilation will happen at timelike infinity. That makes these
2185         hacks much more likely to continue working as we make other changes to the system.
2186         
2187         This brings back the ability to bisect down onto a function bar when bar inlines foo. Prior
2188         to this change, we would crash in that case.
2189
2190         * dfg/DFGCapabilities.cpp:
2191         (JSC::DFG::isSupported):
2192         (JSC::DFG::mightCompileEval):
2193         (JSC::DFG::mightCompileProgram):
2194         (JSC::DFG::mightCompileFunctionForCall):
2195         (JSC::DFG::mightCompileFunctionForConstruct):
2196         * dfg/DFGCapabilities.h:
2197         * dfg/DFGDriver.cpp:
2198         (JSC::DFG::compileImpl):
2199
2200 2015-03-03  peavo@outlook.com  <peavo@outlook.com>
2201
2202         [Win64] JSC compile error.
2203         https://bugs.webkit.org/show_bug.cgi?id=142216
2204
2205         Reviewed by Mark Lam.
2206
2207         There is missing a version of setupArgumentsWithExecState when NUMBER_OF_ARGUMENT_REGISTERS == 4.
2208
2209         * jit/CCallHelpers.h:
2210         (JSC::CCallHelpers::setupArgumentsWithExecState):
2211
2212 2015-03-02  Filip Pizlo  <fpizlo@apple.com>
2213
2214         DFG compile time measurements should really report milliseconds
2215         https://bugs.webkit.org/show_bug.cgi?id=142209
2216
2217         Reviewed by Benjamin Poulain.
2218         
2219         Fix this to record milliseconds instead of seconds.
2220
2221         * dfg/DFGPlan.cpp:
2222         (JSC::DFG::Plan::compileInThread):
2223         (JSC::DFG::Plan::compileInThreadImpl):
2224
2225 2015-03-02  Filip Pizlo  <fpizlo@apple.com>
2226
2227         Remove op_get_callee, it's unused
2228         https://bugs.webkit.org/show_bug.cgi?id=142206
2229
2230         Reviewed by Andreas Kling.
2231         
2232         It's a bit of a shame that we stopped using this opcode since it gives us same-callee
2233         profiling. But, if we were to add this functionality back in, we would almost certainly do
2234         it by adding a JSFunction allocation watchpoint on FunctionExecutable.
2235
2236         * bytecode/BytecodeList.json:
2237         * bytecode/BytecodeUseDef.h:
2238         (JSC::computeUsesForBytecodeOffset):
2239         (JSC::computeDefsForBytecodeOffset):
2240         * bytecode/CodeBlock.cpp:
2241         (JSC::CodeBlock::dumpBytecode):
2242         (JSC::CodeBlock::finalizeUnconditionally):
2243         * dfg/DFGByteCodeParser.cpp:
2244         (JSC::DFG::ByteCodeParser::parseBlock):
2245         * dfg/DFGCapabilities.cpp:
2246         (JSC::DFG::capabilityLevel):
2247         * jit/JIT.cpp:
2248         (JSC::JIT::privateCompileMainPass):
2249         (JSC::JIT::privateCompileSlowCases):
2250         * jit/JIT.h:
2251         * jit/JITOpcodes.cpp:
2252         (JSC::JIT::emit_op_get_callee): Deleted.
2253         (JSC::JIT::emitSlow_op_get_callee): Deleted.
2254         * jit/JITOpcodes32_64.cpp:
2255         (JSC::JIT::emit_op_get_callee): Deleted.
2256         (JSC::JIT::emitSlow_op_get_callee): Deleted.
2257         * llint/LowLevelInterpreter32_64.asm:
2258         * llint/LowLevelInterpreter64.asm:
2259         * runtime/CommonSlowPaths.cpp:
2260         (JSC::SLOW_PATH_DECL): Deleted.
2261
2262 2015-03-02  Joseph Pecoraro  <pecoraro@apple.com>
2263
2264         Web Inspector: Context Menu to Log a Particular Object
2265         https://bugs.webkit.org/show_bug.cgi?id=142198
2266
2267         Reviewed by Timothy Hatcher.
2268
2269         Add a protocol method to assign a $n index to a value. For an object
2270         use the injected script context for that object. For a value, use
2271         the execution context to know where to save the value.
2272
2273         * inspector/InjectedScript.cpp:
2274         (Inspector::InjectedScript::saveResult):
2275         * inspector/InjectedScript.h:
2276         * inspector/InjectedScriptSource.js:
2277         * inspector/agents/InspectorRuntimeAgent.cpp:
2278         (Inspector::InspectorRuntimeAgent::saveResult):
2279         * inspector/agents/InspectorRuntimeAgent.h:
2280         * inspector/protocol/Debugger.json:
2281         * inspector/protocol/Runtime.json:
2282
2283 2015-03-02  Filip Pizlo  <fpizlo@apple.com>
2284
2285         SpeculativeJIT::emitAllocateArguments() should be a bit faster, and shouldn't do destructor initialization
2286         https://bugs.webkit.org/show_bug.cgi?id=142197
2287
2288         Reviewed by Geoffrey Garen.
2289
2290         * dfg/DFGSpeculativeJIT.cpp:
2291         (JSC::DFG::SpeculativeJIT::emitAllocateArguments): Use shift instead of mul, since mul doesn't automatically strength-reduce to shift. Also pass the structure as a TrustedImmPtr.
2292         * dfg/DFGSpeculativeJIT.h:
2293         (JSC::DFG::SpeculativeJIT::emitAllocateVariableSizedJSObject): Rationalize this a bit. The other emitAllocate... methods take a templated structure so that it can be either a TrustedImmPtr or a register. Also don't do destructor initialization, since its one client doesn't need it, and it's actually probably wrong.
2294
2295 2015-03-02  Mark Lam  <mark.lam@apple.com>
2296
2297         Exception stack unwinding in JSC hangs while the Timeline Profiler is enabled.
2298         <https://webkit.org/b/142191>
2299
2300         Reviewed by Geoffrey Garen.
2301
2302         Imagine a scenario where the Inspector is paused / suspended at a breakpoint or
2303         while the user is stepping through JS code. The user then tries to evaluate an
2304         expression in the console, and that evaluation results in an exception being
2305         thrown. Currently, if the Timeline Profiler is enabled while this exception is
2306         being thrown, the WebProcess will hang while trying to handle that exception.
2307
2308         The issue is that the Timeline Profiler's ProfileGenerator::didExecute() will
2309         return early and decline to process ProfileNodes if the Inspector is paused.
2310         This is proper because it does not want to count work done for injected scripts
2311         (e.g. from the console) towards the timeline profile of the webpage being run.
2312         However, this is in conflict with ProfileGenerator::exceptionUnwind()'s
2313         expectation that didExecute() will process ProfileNodes in order to do the stack
2314         unwinding for the exception handling. As a result,
2315         ProfileGenerator::exceptionUnwind() hangs.
2316
2317         ProfileGenerator::exceptionUnwind() is in error. While the Inspector is paused,
2318         there will not be any ProfileNodes that it needs to "unwind". Hence, the fix is
2319         simply to return early also in ProfileGenerator::exceptionUnwind() if the
2320         Inspector is paused.
2321
2322         * profiler/ProfileGenerator.cpp:
2323         (JSC::ProfileGenerator::exceptionUnwind):
2324
2325 2015-03-02  Filip Pizlo  <fpizlo@apple.com>
2326
2327         FTL should correctly document where it puts the argument count for inlined varargs frames
2328         https://bugs.webkit.org/show_bug.cgi?id=142187
2329
2330         Reviewed by Geoffrey Garn.
2331         
2332         After LLVM tells us where the captured variables alloca landed in the frame, we need to
2333         tell all of our meta-data about it. We were forgetting to do so for the argument count
2334         register, which is used by inlined varargs calls.
2335
2336         * ftl/FTLCompile.cpp:
2337         (JSC::FTL::mmAllocateDataSection):
2338         * tests/stress/inline-varargs-get-arguments.js: Added.
2339         (foo):
2340         (bar):
2341         (baz):
2342
2343 2015-03-02  Filip Pizlo  <fpizlo@apple.com>
2344
2345         Deduplicate slow path calling code in JITOpcodes.cpp/JITOpcodes32_64.cpp
2346         https://bugs.webkit.org/show_bug.cgi?id=142184
2347
2348         Reviewed by Michael Saboff.
2349
2350         * jit/JITOpcodes.cpp:
2351         (JSC::JIT::emit_op_get_enumerable_length):
2352         (JSC::JIT::emitSlow_op_has_structure_property):
2353         (JSC::JIT::emit_op_has_generic_property):
2354         (JSC::JIT::emit_op_get_structure_property_enumerator):
2355         (JSC::JIT::emit_op_get_generic_property_enumerator):
2356         (JSC::JIT::emit_op_to_index_string):
2357         * jit/JITOpcodes32_64.cpp:
2358         (JSC::JIT::emit_op_get_enumerable_length): Deleted.
2359         (JSC::JIT::emitSlow_op_has_structure_property): Deleted.
2360         (JSC::JIT::emit_op_has_generic_property): Deleted.
2361         (JSC::JIT::emit_op_get_structure_property_enumerator): Deleted.
2362         (JSC::JIT::emit_op_get_generic_property_enumerator): Deleted.
2363         (JSC::JIT::emit_op_to_index_string): Deleted.
2364         (JSC::JIT::emit_op_profile_control_flow): Deleted.
2365
2366 2015-03-02  Antti Koivisto  <antti@apple.com>
2367
2368         Add way to dump cache meta data to file
2369         https://bugs.webkit.org/show_bug.cgi?id=142183
2370
2371         Reviewed by Andreas Kling.
2372
2373         Export appendQuotedJSONStringToBuilder.
2374
2375         * bytecompiler/NodesCodegen.cpp:
2376         (JSC::ObjectPatternNode::toString):
2377         * runtime/JSONObject.cpp:
2378         (JSC::appendQuotedJSONStringToBuilder):
2379         (JSC::Stringifier::appendQuotedString):
2380         (JSC::escapeStringToBuilder): Deleted.
2381         * runtime/JSONObject.h:
2382
2383 2015-03-02  Joseph Pecoraro  <pecoraro@apple.com>
2384
2385         Web Inspector: Add Context Menus to Object Tree properties
2386         https://bugs.webkit.org/show_bug.cgi?id=142125
2387
2388         Reviewed by Timothy Hatcher.
2389
2390         * inspector/JSInjectedScriptHost.cpp:
2391         (Inspector::JSInjectedScriptHost::functionDetails):
2392         Update to include columnNumber.
2393
2394 2015-03-01  Filip Pizlo  <fpizlo@apple.com>
2395
2396         BytecodeGenerator shouldn't emit op_resolve_scope as a roundabout way of returning the scopeRegister
2397         https://bugs.webkit.org/show_bug.cgi?id=142153
2398
2399         Reviewed by Michael Saboff.
2400         
2401         We don't need a op_resolve_scope if we know that it will simply return the scope register.
2402         This changes the BytecodeGenerator to use the scope register directly in those cases where
2403         we know statically that we would just have returned that from op_resolve_scope.
2404         
2405         This doesn't appear to have a significant impact on performance.
2406
2407         * bytecode/CodeBlock.cpp:
2408         (JSC::CodeBlock::CodeBlock):
2409         * bytecompiler/BytecodeGenerator.cpp:
2410         (JSC::BytecodeGenerator::emitResolveScope):
2411         (JSC::BytecodeGenerator::emitReturn):
2412         (JSC::BytecodeGenerator::emitGetOwnScope): Deleted.
2413         * bytecompiler/BytecodeGenerator.h:
2414         * bytecompiler/NodesCodegen.cpp:
2415         (JSC::ResolveNode::emitBytecode):
2416         (JSC::EvalFunctionCallNode::emitBytecode):
2417         (JSC::FunctionCallResolveNode::emitBytecode):
2418         (JSC::PostfixNode::emitResolve):
2419         (JSC::DeleteResolveNode::emitBytecode):
2420         (JSC::TypeOfResolveNode::emitBytecode):
2421         (JSC::PrefixNode::emitResolve):
2422         (JSC::ReadModifyResolveNode::emitBytecode):
2423         (JSC::AssignResolveNode::emitBytecode):
2424         (JSC::ConstDeclNode::emitCodeSingle):
2425         (JSC::EmptyVarExpression::emitBytecode):
2426         (JSC::ForInNode::emitLoopHeader):
2427         (JSC::ForOfNode::emitBytecode):
2428         (JSC::BindingNode::bindValue):
2429
2430 2015-02-27  Benjamin Poulain  <bpoulain@apple.com>
2431
2432         [JSC] Use the way number constants are written to help type speculation
2433         https://bugs.webkit.org/show_bug.cgi?id=142072
2434
2435         Reviewed by Filip Pizlo.
2436
2437         This patch changes how we interpret numeric constant based on how they appear
2438         in the source.
2439
2440         Constants that are integers but written with a decimal point now carry that information
2441         to the optimizating tiers. From there, we use that to be more aggressive about typing
2442         math operations toward double operations.
2443
2444         For example, in:
2445             var a = x + 1.0;
2446             var b = y + 1;
2447         The Add for a would be biased toward doubles, the Add for b would speculate
2448         integer as usual.
2449
2450
2451         The gains are tiny but this is a prerequisite to make my next patch useful:
2452         -SunSpider's access-fannkuch: definitely 1.0661x faster
2453         -SunSpider's math-cordic: definitely 1.0266x slower
2454             overal: might be 1.0066x slower.
2455         -Kraken's imaging-darkroom: definitely 1.0333x faster.
2456
2457         * parser/Lexer.cpp:
2458         (JSC::tokenTypeForIntegerLikeToken):
2459         (JSC::Lexer<T>::lex):
2460         The lexer now create two types of tokens for number: INTEGER and DOUBLE.
2461         Those token types only carry information about how the values were
2462         entered, an INTEGER does not have to be an integer, it is only written like one.
2463         Large integer still end up represented as double in memory.
2464
2465         One trap I fell into was typing numbers like 12e3 as double. This kind of literal
2466         is frequently used in integer-typed code, while 12.e3 would appear in double-typed
2467         code.
2468         Because of that, the only signals for double are: decimal point, negative zero,
2469         and ridiculously large values.
2470
2471         * parser/NodeConstructors.h:
2472         (JSC::DoubleNode::DoubleNode):
2473         (JSC::IntegerNode::IntegerNode):
2474         * parser/Nodes.h:
2475         (JSC::NumberNode::value):
2476         (JSC::NumberNode::setValue): Deleted.
2477         Number get specialized in two new kind of nodes in the AST: IntegerNode and DoubleNode.
2478
2479         * bytecompiler/NodesCodegen.cpp:
2480         (JSC::NumberNode::emitBytecode):
2481
2482         * parser/ASTBuilder.h:
2483         (JSC::ASTBuilder::createDoubleExpr):
2484         (JSC::ASTBuilder::createIntegerExpr):
2485         (JSC::ASTBuilder::createIntegerLikeNumber):
2486         (JSC::ASTBuilder::createDoubleLikeNumber):
2487         (JSC::ASTBuilder::createNumberFromBinaryOperation):
2488         (JSC::ASTBuilder::createNumberFromUnaryOperation):
2489         (JSC::ASTBuilder::makeNegateNode):
2490         (JSC::ASTBuilder::makeBitwiseNotNode):
2491         (JSC::ASTBuilder::makeMultNode):
2492         (JSC::ASTBuilder::makeDivNode):
2493         (JSC::ASTBuilder::makeModNode):
2494         (JSC::ASTBuilder::makeAddNode):
2495         (JSC::ASTBuilder::makeSubNode):
2496         (JSC::ASTBuilder::makeLeftShiftNode):
2497         (JSC::ASTBuilder::makeRightShiftNode):
2498         (JSC::ASTBuilder::makeURightShiftNode):
2499         (JSC::ASTBuilder::makeBitOrNode):
2500         (JSC::ASTBuilder::makeBitAndNode):
2501         (JSC::ASTBuilder::makeBitXOrNode):
2502         (JSC::ASTBuilder::createNumberExpr): Deleted.
2503         (JSC::ASTBuilder::createNumber): Deleted.
2504         The AST has some optimization to resolve constants before emitting bytecode.
2505         In the new code, the intger representation is kept if both operands where
2506         also represented as integers.
2507
2508         * parser/Parser.cpp:
2509         (JSC::Parser<LexerType>::parseDeconstructionPattern):
2510         (JSC::Parser<LexerType>::parseProperty):
2511         (JSC::Parser<LexerType>::parseGetterSetter):
2512         (JSC::Parser<LexerType>::parsePrimaryExpression):
2513         (JSC::Parser<LexerType>::printUnexpectedTokenText):
2514         * parser/ParserTokens.h:
2515         * parser/SyntaxChecker.h:
2516         (JSC::SyntaxChecker::createDoubleExpr):
2517         (JSC::SyntaxChecker::createIntegerExpr):
2518         (JSC::SyntaxChecker::createNumberExpr): Deleted.
2519
2520         * bytecode/CodeBlock.cpp:
2521         (JSC::CodeBlock::registerName):
2522         (JSC::CodeBlock::constantName):
2523         Change constantName(r, getConstant(r)) -> constantName(r) to simplify
2524         the dump code.
2525
2526         (JSC::CodeBlock::dumpBytecode):
2527         Dump thre soure representation information we have with each constant.
2528
2529         (JSC::CodeBlock::CodeBlock):
2530         (JSC::CodeBlock::shrinkToFit):
2531         (JSC::constantName): Deleted.
2532         * bytecode/CodeBlock.h:
2533         (JSC::CodeBlock::constantsSourceCodeRepresentation):
2534         (JSC::CodeBlock::addConstant):
2535         (JSC::CodeBlock::addConstantLazily):
2536         (JSC::CodeBlock::constantSourceCodeRepresentation):
2537         (JSC::CodeBlock::setConstantRegisters):
2538
2539         * bytecode/UnlinkedCodeBlock.h:
2540         (JSC::UnlinkedCodeBlock::addConstant):
2541         (JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation):
2542         (JSC::UnlinkedCodeBlock::shrinkToFit):
2543
2544         * bytecompiler/BytecodeGenerator.cpp:
2545         (JSC::BytecodeGenerator::addConstantValue):
2546         (JSC::BytecodeGenerator::emitLoad):
2547         * bytecompiler/BytecodeGenerator.h:
2548         We have to differentiate between constants that have the same values but are
2549         represented differently in the source. Values like 1.0 and 1 now end up
2550         as different constants.
2551
2552         * dfg/DFGByteCodeParser.cpp:
2553         (JSC::DFG::ByteCodeParser::get):
2554         (JSC::DFG::ByteCodeParser::addConstantToGraph):
2555         * dfg/DFGGraph.cpp:
2556         (JSC::DFG::Graph::registerFrozenValues):
2557         * dfg/DFGGraph.h:
2558         (JSC::DFG::Graph::addSpeculationMode):
2559         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
2560         ArithAdd is very aggressive toward using Int52, which is quite useful
2561         in many benchmarks.
2562
2563         Here we need to specialize to make sure we don't force our literals
2564         to Int52 if there were represented as double.
2565
2566         There is one exception to that rule: when the other operand is guaranteed
2567         to come from a NodeResultInt32. This is because there is some weird code
2568         doing stuff like:
2569             var b = a|0;
2570             var c = b*2.0;
2571
2572         * dfg/DFGNode.h:
2573         (JSC::DFG::Node::Node):
2574         (JSC::DFG::Node::setOpAndDefaultFlags):
2575         (JSC::DFG::Node::sourceCodeRepresentation):
2576         * dfg/DFGPredictionPropagationPhase.cpp:
2577         (JSC::DFG::PredictionPropagationPhase::propagate):
2578         * runtime/JSCJSValue.h:
2579         (JSC::EncodedJSValueWithRepresentationHashTraits::emptyValue):
2580         (JSC::EncodedJSValueWithRepresentationHashTraits::constructDeletedValue):
2581         (JSC::EncodedJSValueWithRepresentationHashTraits::isDeletedValue):
2582         (JSC::EncodedJSValueWithRepresentationHash::hash):
2583         (JSC::EncodedJSValueWithRepresentationHash::equal):
2584         * tests/stress/arith-add-with-constants.js: Added.
2585         * tests/stress/arith-mul-with-constants.js: Added.
2586
2587 2015-02-26  Filip Pizlo  <fpizlo@apple.com>
2588
2589         Unreviewed, roll out r180723. It broke a bunch of tests.
2590
2591         * bytecompiler/BytecodeGenerator.cpp:
2592         (JSC::BytecodeGenerator::constLocal):
2593         * bytecompiler/BytecodeGenerator.h:
2594         * bytecompiler/NodesCodegen.cpp:
2595         (JSC::ConstDeclNode::emitCodeSingle):
2596         * tests/stress/const-arguments.js: Removed.
2597
2598 2015-02-26  Mark Lam  <mark.lam@apple.com>
2599
2600         Assertion fix for r180711: The bool returning form of BytecodeGenerator::addVar() can be removed.
2601         <https://webkit.org/b/142064>
2602
2603         Reviewed by Joseph Pecoraro.
2604
2605         * bytecompiler/BytecodeGenerator.cpp:
2606         (JSC::BytecodeGenerator::addVar):
2607
2608 2015-02-26  Mark Lam  <mark.lam@apple.com>
2609
2610         MachineThreads::Thread clean up has a use after free race condition.
2611         <https://webkit.org/b/141990>
2612
2613         Reviewed by Filip Pizlo.
2614
2615         MachineThreads::Thread clean up relies on the clean up mechanism
2616         implemented in _pthread_tsd_cleanup_key(), which looks like this:
2617
2618         void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
2619         {
2620             void (*destructor)(void *);
2621             if (_pthread_key_get_destructor(key, &destructor)) {
2622                 void **ptr = &self->tsd[key];
2623                 void *value = *ptr;
2624
2625             // === Start of window for the bug to manifest =================
2626
2627                 // At this point, this thread has cached "destructor" and "value"
2628                 // (which is a MachineThreads*).  If the VM gets destructed (along
2629                 // with its MachineThreads registry) by another thread, then this
2630                 // thread will have no way of knowing that the MachineThreads* is
2631                 // now pointing to freed memory.  Calling the destructor below will
2632                 // therefore result in a use after free scenario when it tries to
2633                 // access the MachineThreads' data members.
2634
2635                 if (value) {
2636                     *ptr = NULL;
2637                     if (destructor) {
2638
2639             // === End of window for the bug to manifest ==================
2640
2641                         destructor(value);
2642                     }
2643                 }
2644             }
2645         }
2646
2647         The fix is to add each active MachineThreads to an ActiveMachineThreadsManager,
2648         and always check if the manager still contains that MachineThreads object
2649         before we call removeCurrentThread() on it.  When MachineThreads is destructed,
2650         it will remove itself from the manager.  The add, remove, and checking
2651         operations are all synchronized on the manager's lock, thereby ensuring that
2652         the MachineThreads object, if found in the manager, will remain alive for the
2653         duration of time we call removeCurrentThread() on it.
2654
2655         There's also possible for the MachineThreads object to already be destructed
2656         and another one happened to have been instantiated at the same address.
2657         Hence, we should only remove the exiting thread if it is found in the
2658         MachineThreads object.
2659
2660         There is no test for this issue because this bug requires a race condition
2661         between 2 threads where:
2662         1. Thread B, which had previously used the VM, exiting and
2663            getting to the bug window shown in _pthread_tsd_cleanup_key() above.
2664         2. Thread A destructing the VM (and its MachineThreads object)
2665            within that window of time before Thread B calls the destructor.
2666
2667         It is not possible to get a reliable test case without invasively
2668         instrumenting _pthread_tsd_cleanup_key() or MachineThreads::removeCurrentThread()
2669         to significantly increase that window of opportunity.
2670
2671         * heap/MachineStackMarker.cpp:
2672         (JSC::ActiveMachineThreadsManager::Locker::Locker):
2673         (JSC::ActiveMachineThreadsManager::add):
2674         (JSC::ActiveMachineThreadsManager::remove):
2675         (JSC::ActiveMachineThreadsManager::contains):
2676         (JSC::ActiveMachineThreadsManager::ActiveMachineThreadsManager):
2677         (JSC::activeMachineThreadsManager):
2678         (JSC::MachineThreads::MachineThreads):
2679         (JSC::MachineThreads::~MachineThreads):
2680         (JSC::MachineThreads::removeThread):
2681         (JSC::MachineThreads::removeThreadIfFound):
2682         (JSC::MachineThreads::removeCurrentThread): Deleted.
2683         * heap/MachineStackMarker.h:
2684
2685 2015-02-26  Joseph Pecoraro  <pecoraro@apple.com>
2686
2687         Web Inspector: Save Console Evaluations into Command Line variables $1-$99 ($n)
2688         https://bugs.webkit.org/show_bug.cgi?id=142061
2689
2690         Reviewed by Timothy Hatcher.
2691
2692         * inspector/protocol/Debugger.json:
2693         * inspector/protocol/Runtime.json:
2694         Input flag "saveResult" on whether we should try to save a result.
2695         Output int "savedResultIndex" to tell the frontend the saved state.
2696
2697         * inspector/InjectedScriptSource.js:
2698         Handle saving and clearing $1-$99 values.
2699         Include in BasicCommandLineAPI for JSContext inspection.
2700
2701         * inspector/InjectedScriptBase.cpp:
2702         (Inspector::InjectedScriptBase::makeEvalCall):
2703         * inspector/InjectedScriptBase.h:
2704         Allow an optional "savedResultIndex" out value on evals.
2705
2706         * inspector/InjectedScript.cpp:
2707         (Inspector::InjectedScript::evaluate):
2708         (Inspector::InjectedScript::evaluateOnCallFrame):
2709         * inspector/InjectedScript.h:
2710         * inspector/agents/InspectorDebuggerAgent.cpp:
2711         (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
2712         * inspector/agents/InspectorDebuggerAgent.h:
2713         * inspector/agents/InspectorRuntimeAgent.cpp:
2714         (Inspector::InspectorRuntimeAgent::evaluate):
2715         * inspector/agents/InspectorRuntimeAgent.h:
2716         Plumbing for new in and out parameters.
2717
2718 2015-02-26  Filip Pizlo  <fpizlo@apple.com>
2719
2720         The bool returning form of BytecodeGenerator::addVar() can be removed
2721         https://bugs.webkit.org/show_bug.cgi?id=142064
2722
2723         Reviewed by Mark Lam.
2724         
2725         It's easier to implement addVar() when you don't have to return whether it's a new
2726         variable or not.
2727
2728         * bytecompiler/BytecodeGenerator.cpp:
2729         (JSC::BytecodeGenerator::addVar):
2730         * bytecompiler/BytecodeGenerator.h:
2731         (JSC::BytecodeGenerator::addVar): Deleted.
2732
2733 2015-02-26  Filip Pizlo  <fpizlo@apple.com>
2734
2735         Various array access corner cases should take OSR exit feedback
2736         https://bugs.webkit.org/show_bug.cgi?id=142056
2737
2738         Reviewed by Geoffrey Garen.
2739         
2740         Two major changes here:
2741         
2742         - Don't keep converting GetById into GetArrayLength if we exited due to any kind of array
2743           type check.
2744         
2745         - Use a generic form of GetByVal/PutByVal if we exited due to any kind of exotic checks,
2746           like the Arguments safety checks. We use the "ExoticObjectMode" for out-of-bounds on
2747           arguments for now, since it's a convenient way of forcing out-of-bounds to be handled by
2748           the Generic array mode.
2749
2750         * bytecode/ExitKind.cpp:
2751         (JSC::exitKindToString):
2752         * bytecode/ExitKind.h:
2753         * dfg/DFGArrayMode.cpp:
2754         (JSC::DFG::ArrayMode::refine):
2755         * dfg/DFGFixupPhase.cpp:
2756         (JSC::DFG::FixupPhase::fixupNode):
2757         * dfg/DFGSpeculativeJIT.cpp:
2758         (JSC::DFG::SpeculativeJIT::compileGetByValOnArguments):
2759         (JSC::DFG::SpeculativeJIT::compileGetArgumentsLength):
2760         * tests/stress/array-length-array-storage-plain-object.js: Added.
2761         (foo):
2762         * tests/stress/array-length-plain-object.js: Added.
2763         (foo):
2764
2765 2015-02-25  Filip Pizlo  <fpizlo@apple.com>
2766
2767         DFG SSA stack accesses shouldn't speak of VariableAccessDatas
2768         https://bugs.webkit.org/show_bug.cgi?id=142036
2769
2770         Reviewed by Michael Saboff.
2771         
2772         VariableAccessData is a useful thing in LoadStore and ThreadedCPS, but it's purely harmful in
2773         SSA because you can't cook up new VariableAccessDatas. So, if you know that you want to load
2774         or store to the stack, and you know what format to use as well as the location, then prior to
2775         this patch you couldn't do it unless you found some existing VariableAccessData that matched
2776         your requirements. That can be a hard task.
2777         
2778         It's better if SSA doesn't speak of VariableAccessDatas but instead just has stack accesses
2779         that speak of the things that a stack access needs: local, machineLocal, and format. This
2780         patch changes the SSA way of accessing the stack to do just that.
2781         
2782         Also add more IR validation.
2783
2784         * CMakeLists.txt:
2785         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2786         * JavaScriptCore.xcodeproj/project.pbxproj:
2787         * dfg/DFGAbstractInterpreterInlines.h:
2788         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2789         * dfg/DFGClobberize.h:
2790         (JSC::DFG::clobberize):
2791         * dfg/DFGConstantFoldingPhase.cpp:
2792         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2793         * dfg/DFGDoesGC.cpp:
2794         (JSC::DFG::doesGC):
2795         * dfg/DFGFixupPhase.cpp:
2796         (JSC::DFG::FixupPhase::fixupNode):
2797         * dfg/DFGFlushFormat.h:
2798         (JSC::DFG::isConcrete):
2799         * dfg/DFGGraph.cpp:
2800         (JSC::DFG::Graph::dump):
2801         * dfg/DFGGraph.h:
2802         * dfg/DFGMayExit.cpp:
2803         (JSC::DFG::mayExit):
2804         * dfg/DFGNode.cpp:
2805         (JSC::DFG::Node::hasVariableAccessData):
2806         * dfg/DFGNode.h:
2807         (JSC::DFG::StackAccessData::StackAccessData):
2808         (JSC::DFG::StackAccessData::flushedAt):
2809         (JSC::DFG::Node::convertToPutStack):
2810         (JSC::DFG::Node::convertToGetStack):
2811         (JSC::DFG::Node::hasUnlinkedLocal):
2812         (JSC::DFG::Node::hasStackAccessData):
2813         (JSC::DFG::Node::stackAccessData):
2814         (JSC::DFG::Node::willHaveCodeGenOrOSR):
2815         * dfg/DFGNodeType.h:
2816         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
2817         (JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
2818         * dfg/DFGPlan.cpp:
2819         (JSC::DFG::Plan::compileInThreadImpl):
2820         * dfg/DFGPredictionPropagationPhase.cpp:
2821         (JSC::DFG::PredictionPropagationPhase::propagate):
2822         * dfg/DFGPutLocalSinkingPhase.cpp: Removed.
2823         * dfg/DFGPutLocalSinkingPhase.h: Removed.
2824         * dfg/DFGPutStackSinkingPhase.cpp: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.cpp.
2825         (JSC::DFG::performPutStackSinking):
2826         (JSC::DFG::performPutLocalSinking): Deleted.
2827         * dfg/DFGPutStackSinkingPhase.h: Copied from Source/JavaScriptCore/dfg/DFGPutLocalSinkingPhase.h.
2828         * dfg/DFGSSAConversionPhase.cpp:
2829         (JSC::DFG::SSAConversionPhase::run):
2830         * dfg/DFGSafeToExecute.h:
2831         (JSC::DFG::safeToExecute):
2832         * dfg/DFGSpeculativeJIT32_64.cpp:
2833         (JSC::DFG::SpeculativeJIT::compile):
2834         * dfg/DFGSpeculativeJIT64.cpp:
2835         (JSC::DFG::SpeculativeJIT::compile):
2836         * dfg/DFGStackLayoutPhase.cpp:
2837         (JSC::DFG::StackLayoutPhase::run):
2838         * dfg/DFGValidate.cpp:
2839         (JSC::DFG::Validate::validate):
2840         (JSC::DFG::Validate::validateCPS):
2841         (JSC::DFG::Validate::validateSSA):
2842         * dfg/DFGVirtualRegisterAllocationPhase.cpp:
2843         (JSC::DFG::VirtualRegisterAllocationPhase::run):
2844         * ftl/FTLCapabilities.cpp:
2845         (JSC::FTL::canCompile):
2846         * ftl/FTLLowerDFGToLLVM.cpp:
2847         (JSC::FTL::LowerDFGToLLVM::lower):
2848         (JSC::FTL::LowerDFGToLLVM::compileNode):
2849         (JSC::FTL::LowerDFGToLLVM::compileGetStack):
2850         (JSC::FTL::LowerDFGToLLVM::compilePutStack):
2851         (JSC::FTL::LowerDFGToLLVM::compileGetLocal): Deleted.
2852         (JSC::FTL::LowerDFGToLLVM::compilePutLocal): Deleted.
2853         * ftl/FTLOSRExit.h:
2854         * tests/stress/many-sunken-locals.js: Added. This failure mode was caught by some miscellaneous test, so I figured I should write an explicit test for it.
2855         (foo):
2856         (bar):
2857         (baz):
2858         (fuzz):
2859         (buzz):
2860
2861 2015-02-26  Mark Lam  <mark.lam@apple.com>
2862
2863         Rolling out r180602, r180608, r180613, r180617, r180671.
2864         <https://webkit.org/b/141990>
2865
2866         Not reviewed.
2867
2868         The r180602 solution does result in more work for GC when worker
2869         threads are in use.  Filip is uncomfortable with that.
2870         The EFL and GTK ports also seem to be unhappy with this change.
2871         Rolling out while we investigate.
2872
2873         * heap/Heap.cpp:
2874         (JSC::Heap::Heap):
2875         (JSC::Heap::gatherStackRoots):
2876         (JSC::Heap::machineThreads): Deleted.
2877         * heap/Heap.h:
2878         (JSC::Heap::machineThreads):
2879         * heap/MachineStackMarker.cpp:
2880         (JSC::MachineThreads::MachineThreads):
2881         (JSC::MachineThreads::~MachineThreads):
2882         (JSC::MachineThreads::addCurrentThread):
2883         * heap/MachineStackMarker.h:
2884         * runtime/JSLock.cpp:
2885         (JSC::JSLock::didAcquireLock):
2886
2887 2015-02-26  Myles C. Maxfield  <mmaxfield@apple.com>
2888
2889         [Mac] [iOS] Parsing support for -apple-trailing-word
2890         https://bugs.webkit.org/show_bug.cgi?id=141939
2891
2892         Reviewed by Andreas Kling.
2893
2894         * Configurations/FeatureDefines.xcconfig:
2895
2896 2015-02-26  Michael Saboff  <msaboff@apple.com>
2897
2898         [Win] Debug-only JavaScriptCore failures
2899         https://bugs.webkit.org/show_bug.cgi?id=142045
2900
2901         Rubber stamped by Filip Pizlo.
2902
2903         Reduced loop count to a more reasonable value of 10,000.  This still gets us to tier up
2904         to the FTL, but doesn't take too long to run.
2905
2906         * tests/stress/repeated-arity-check-fail.js:
2907
2908 2015-02-26  Brent Fulgham  <bfulgham@apple.com>
2909
2910         [Win] Make build logs more legible by reducing noise
2911         https://bugs.webkit.org/show_bug.cgi?id=142034
2912
2913         Reviewed by Alexey Proskuryakov.
2914
2915         Modify batch files, makefiles, and DOS commands to remove
2916         uninteresting/unhelpful output.
2917
2918         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.make:
2919         * JavaScriptCore.vcxproj/JavaScriptCorePreBuild.cmd:
2920         * JavaScriptCore.vcxproj/copy-files.cmd:
2921         * JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd:
2922         * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd:
2923         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd:
2924         * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd:
2925         * JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd:
2926         * JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd:
2927         * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd:
2928         * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd:
2929
2930 2015-02-26  Csaba Osztrogonác  <ossy@webkit.org>
2931
2932         Add calleeSaveRegisters() implementation for ARM Traditional
2933         https://bugs.webkit.org/show_bug.cgi?id=141903
2934
2935         Reviewed by Darin Adler.
2936
2937         * jit/RegisterSet.cpp:
2938         (JSC::RegisterSet::calleeSaveRegisters):
2939
2940 2015-02-25  Michael Saboff  <msaboff@apple.com>
2941
2942         Web Inspector: CRASH when debugger pauses inside a Promise handler
2943         https://bugs.webkit.org/show_bug.cgi?id=141396
2944
2945         Reviewed by Mark Lam.
2946
2947         For frames that don't have a scope, typically native frames, use the lexicalGlobalObject to
2948         create the DebuggerScope for that frame.
2949
2950         * debugger/DebuggerCallFrame.cpp:
2951         (JSC::DebuggerCallFrame::scope):
2952
2953 2015-02-25  Filip Pizlo  <fpizlo@apple.com>
2954
2955         DFG abstract heaps should respect the difference between heap and stack
2956         https://bugs.webkit.org/show_bug.cgi?id=142022
2957
2958         Reviewed by Geoffrey Garen.
2959         
2960         We will soon (https://bugs.webkit.org/show_bug.cgi?id=141174) be in a world where a "world
2961         clobbering" operation cannot write to our stack, but may be able to read from it. This
2962         means that we need to change the DFG abstract heap hierarchy to have a notion of Heap that
2963         subsumes all that World previously subsumed, and a new notion of Stack that is a subtype
2964         of World and a sibling of Heap.
2965
2966         So, henceforth "clobbering the world" means reading World and writing Heap.
2967         
2968         This makes a bunch of changes to make this work, including changing the implementation of
2969         disjointness in AbstractHeap to make it support a more general hierarchy. I was expecting
2970         a slow-down, but I measured the heck out of this and found no perf difference.
2971
2972         * dfg/DFGAbstractHeap.cpp:
2973         (JSC::DFG::AbstractHeap::dump):
2974         * dfg/DFGAbstractHeap.h:
2975         (JSC::DFG::AbstractHeap::supertype):
2976         (JSC::DFG::AbstractHeap::isStrictSubtypeOf):
2977         (JSC::DFG::AbstractHeap::isSubtypeOf):
2978         (JSC::DFG::AbstractHeap::overlaps):
2979         (JSC::DFG::AbstractHeap::isDisjoint):
2980         * dfg/DFGClobberize.cpp:
2981         (JSC::DFG::clobbersHeap):
2982         (JSC::DFG::clobbersWorld): Deleted.
2983         * dfg/DFGClobberize.h:
2984         (JSC::DFG::clobberize):
2985         * dfg/DFGDoesGC.cpp:
2986         (JSC::DFG::doesGC):
2987
2988 2015-02-25  Ryosuke Niwa  <rniwa@webkit.org>
2989
2990         REGRESSION(r180595): construct varargs fails in FTL
2991         https://bugs.webkit.org/show_bug.cgi?id=142030
2992
2993         Reviewed by Geoffrey Garen.
2994
2995         The bug was caused by IC size being too small for construct_varargs even though we've added a new argument.
2996         Fixed the bug by increasing the IC size to match call_varargs.
2997
2998         * ftl/FTLInlineCacheSize.cpp:
2999         (JSC::FTL::sizeOfConstructVarargs):
3000
3001 2015-02-25  Mark Lam  <mark.lam@apple.com>
3002
3003         ASan does not like JSC::MachineThreads::tryCopyOtherThreadStack.
3004         <https://webkit.org/b/141672>
3005
3006         Reviewed by Alexey Proskuryakov.
3007
3008         ASan does not like the fact that we memcpy the stack for GC scans.  So,
3009         we're working around this by using our own memcpy (asanUnsafeMemcpy)
3010         implementation that we can tell ASan to ignore.
3011
3012         * heap/MachineStackMarker.cpp:
3013         (JSC::asanUnsafeMemcpy):
3014
3015 2015-02-25  Benjamin Poulain  <bpoulain@apple.com>
3016
3017         CodeBlock crashes when dumping op_push_name_scope
3018         https://bugs.webkit.org/show_bug.cgi?id=141953
3019
3020         Reviewed by Filip Pizlo and Csaba Osztrogonác.
3021
3022         * bytecode/CodeBlock.cpp:
3023         (JSC::CodeBlock::dumpBytecode):
3024         * tests/stress/op-push-name-scope-crashes-profiler.js: Added.
3025
3026 2015-02-25  Benjamin Poulain  <benjamin@webkit.org>
3027
3028         Make ParserError immutable by design
3029         https://bugs.webkit.org/show_bug.cgi?id=141955
3030
3031         Reviewed by Geoffrey Garen.
3032
3033         This patch enforce that no field of ParserError can
3034         be modified after the constructor.
3035
3036         * parser/ParserError.h:
3037         Move the attributes to pack the integer + 2 bytes together.
3038         This is irrelevant for memory impact, it is to remve a load-store
3039         when copying by value.
3040
3041         Also move the attributes to be private.
3042
3043         (JSC::ParserError::isValid):
3044         To client of the interface cared about the type of the error,
3045         the only information needed was: is there an error.
3046
3047         (JSC::ParserError::ParserError):
3048         (JSC::ParserError::syntaxErrorType):
3049         (JSC::ParserError::token):
3050         (JSC::ParserError::message):
3051         (JSC::ParserError::line):
3052         (JSC::ParserError::toErrorObject):
3053         * API/JSScriptRef.cpp:
3054         * builtins/BuiltinExecutables.cpp:
3055         (JSC::BuiltinExecutables::createBuiltinExecutable):
3056         * bytecode/UnlinkedCodeBlock.cpp:
3057         (JSC::generateFunctionCodeBlock):
3058         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
3059         (JSC::UnlinkedFunctionExecutable::codeBlockFor):
3060         * bytecode/UnlinkedCodeBlock.h:
3061         * inspector/agents/InspectorRuntimeAgent.cpp:
3062         (Inspector::InspectorRuntimeAgent::parse):
3063         * jsc.cpp:
3064         (runInteractive):
3065         * parser/Parser.h:
3066         (JSC::parse):
3067         * runtime/CodeCache.cpp:
3068         (JSC::CodeCache::getGlobalCodeBlock):
3069         (JSC::CodeCache::getFunctionExecutableFromGlobalCode):
3070         * runtime/CodeCache.h:
3071         * runtime/Completion.h:
3072         * runtime/Executable.cpp:
3073         (JSC::ProgramExecutable::checkSyntax):
3074         * runtime/JSGlobalObject.cpp:
3075         (JSC::JSGlobalObject::createProgramCodeBlock):
3076         (JSC::JSGlobalObject::createEvalCodeBlock):
3077
3078 2015-02-25  Filip Pizlo  <fpizlo@apple.com>
3079
3080         Need to pass RTLD_DEEPBIND to dlopen() to ensure that our LLVMOverrides take effect on Linux
3081         https://bugs.webkit.org/show_bug.cgi?id=142006
3082
3083         Reviewed by Csaba Osztrogonác.
3084
3085         This fixes hard-to-reproduce concurrency-related crashes when running stress tests with FTL and
3086         concurrent JIT enabled.
3087
3088         * llvm/InitializeLLVMPOSIX.cpp:
3089         (JSC::initializeLLVMPOSIX):
3090
3091 2015-02-24  Filip Pizlo  <fpizlo@apple.com>
3092
3093         CMake build of libllvmForJSC.so should limit its export list like the Xcode build does
3094         https://bugs.webkit.org/show_bug.cgi?id=141989
3095
3096         Reviewed by Gyuyoung Kim.
3097
3098         * CMakeLists.txt:
3099         * llvm/library/libllvmForJSC.version: Added.
3100
3101 2015-02-24  Alexey Proskuryakov  <ap@apple.com>
3102
3103         More iOS build fix after r180602.
3104
3105         * heap/Heap.h: Export Heap::machineThreads().
3106
3107 2015-02-24  Brent Fulgham  <bfulgham@apple.com>
3108
3109         Unreviewed build fix after r180602.
3110
3111         * heap/MachineStackMarker.h: Add missing 'no return'
3112         declaration for Windows.
3113
3114 2015-02-24  Commit Queue  <commit-queue@webkit.org>
3115
3116         Unreviewed, rolling out r180599.
3117         https://bugs.webkit.org/show_bug.cgi?id=141998
3118
3119         Lots of new test failures (Requested by smfr on #webkit).
3120
3121         Reverted changeset:
3122
3123         "Parsing support for -webkit-trailing-word"
3124         https://bugs.webkit.org/show_bug.cgi?id=141939
3125         http://trac.webkit.org/changeset/180599
3126
3127 2015-02-24  Mark Lam  <mark.lam@apple.com>
3128
3129         MachineThreads::Thread clean up has a use after free race condition.
3130         <https://webkit.org/b/141990>
3131
3132         Reviewed by Michael Saboff.
3133
3134         MachineThreads::Thread clean up relies on the clean up mechanism
3135         implemented in _pthread_tsd_cleanup_key(), which looks like this:
3136
3137         void _pthread_tsd_cleanup_key(pthread_t self, pthread_key_t key)
3138         {
3139             void (*destructor)(void *);
3140             if (_pthread_key_get_destructor(key, &destructor)) {
3141                 void **ptr = &self->tsd[key];
3142                 void *value = *ptr;
3143
3144                 // At this point, this thread has cached "destructor" and "value"
3145                 // (which is a MachineThreads*).  If the VM gets destructed (along
3146                 // with its MachineThreads registry) by another thread, then this
3147                 // thread will have no way of knowing that the MachineThreads* is
3148                 // now pointing to freed memory.  Calling the destructor below will
3149                 // therefore result in a use after free scenario when it tries to
3150                 // access the MachineThreads' data members.
3151
3152                 if (value) {
3153                     *ptr = NULL;
3154                     if (destructor) {
3155                         destructor(value);
3156                     }
3157                 }
3158             }
3159         }
3160
3161         The solution is simply to change MachineThreads from a per VM thread
3162         registry to a process global singleton thread registry i.e. the
3163         MachineThreads registry is now immortal and we cannot have a use after
3164         free scenario since we never free it.
3165
3166         The cost of this change is that all VM instances will have to scan
3167         stacks of all threads ever touched by a VM, and not just those that
3168         touched a specific VM.  However, stacks tend to be shallow.  Hence,
3169         those additional scans will tend to be cheap.
3170
3171         Secondly, it is not common for there to be multiple JSC VMs in use
3172         concurrently on multiple threads.  Hence, this cost should rarely
3173         manifest in real world applications.
3174
3175         * heap/Heap.cpp:
3176         (JSC::Heap::Heap):
3177         (JSC::Heap::machineThreads):
3178         (JSC::Heap::gatherStackRoots):
3179         * heap/Heap.h:
3180         (JSC::Heap::machineThreads): Deleted.
3181         * heap/MachineStackMarker.cpp:
3182         (JSC::MachineThreads::MachineThreads):
3183         (JSC::MachineThreads::~MachineThreads):
3184         (JSC::MachineThreads::addCurrentThread):
3185         * heap/MachineStackMarker.h:
3186         * runtime/JSLock.cpp:
3187         (JSC::JSLock::didAcquireLock):
3188
3189 2015-02-24  Myles C. Maxfield  <mmaxfield@apple.com>
3190
3191         [Mac] [iOS] Parsing support for -apple-trailing-word
3192         https://bugs.webkit.org/show_bug.cgi?id=141939
3193
3194         Reviewed by Andreas Kling.
3195
3196         * Configurations/FeatureDefines.xcconfig:
3197
3198 2015-02-24  Ryosuke Niwa  <rniwa@webkit.org>
3199
3200         Use "this" instead of "callee" to get the constructor
3201         https://bugs.webkit.org/show_bug.cgi?id=141019
3202
3203         Reviewed by Filip Pizlo.
3204
3205         This patch uses "this" register to pass the constructor (newTarget) to op_create_this from
3206         op_construct or op_construct_varargs. This will allow future patches that implement ES6 class
3207         to pass in the most derived class' constructor through "this" argument.
3208
3209         BytecodeGenerator's emitConstruct and emitConstructVarargs now passes thisRegister like
3210         regular calls and emitCreateThis passes in this register to op_create_this as constructor.
3211
3212         The rest of the code change removes the code for special casing "this" register not being used
3213         in call to construct.
3214
3215         * bytecode/BytecodeUseDef.h:
3216         (JSC::computeUsesForBytecodeOffset):
3217         * bytecompiler/BytecodeGenerator.cpp:
3218         (JSC::BytecodeGenerator::emitCreateThis):
3219         (JSC::BytecodeGenerator::emitConstructVarargs):
3220         (JSC::BytecodeGenerator::emitConstruct):
3221         * bytecompiler/BytecodeGenerator.h:
3222         * bytecompiler/NodesCodegen.cpp:
3223         (JSC::NewExprNode::emitBytecode):
3224         * dfg/DFGByteCodeParser.cpp:
3225         (JSC::DFG::ByteCodeParser::addCallWithoutSettingResult):
3226         (JSC::DFG::ByteCodeParser::handleVarargsCall):
3227         (JSC::DFG::ByteCodeParser::emitArgumentPhantoms):
3228         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
3229         (JSC::DFG::ByteCodeParser::handleInlining):
3230         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
3231         (JSC::DFG::ByteCodeParser::parseBlock):
3232         * dfg/DFGJITCode.cpp:
3233         (JSC::DFG::JITCode::reconstruct):
3234         * dfg/DFGSpeculativeJIT32_64.cpp:
3235         (JSC::DFG::SpeculativeJIT::emitCall):
3236         * dfg/DFGSpeculativeJIT64.cpp:
3237         (JSC::DFG::SpeculativeJIT::emitCall):
3238         * ftl/FTLJSCallVarargs.cpp:
3239         (JSC::FTL::JSCallVarargs::emit):
3240         * ftl/FTLLowerDFGToLLVM.cpp:
3241         (JSC::FTL::LowerDFGToLLVM::compileNativeCallOrConstruct):
3242         (JSC::FTL::LowerDFGToLLVM::compileCallOrConstruct):
3243         (JSC::FTL::LowerDFGToLLVM::compileCallOrConstructVarargs):
3244         * interpreter/Interpreter.cpp:
3245         (JSC::Interpreter::executeConstruct):
3246         * jit/JITOperations.cpp:
3247
3248 2015-02-24  Joseph Pecoraro  <pecoraro@apple.com>
3249
3250         Web Inspector: Make Getter/Setter RemoteObject property and ObjectPreview handling consistent
3251         https://bugs.webkit.org/show_bug.cgi?id=141587
3252
3253         Reviewed by Timothy Hatcher.
3254
3255         Convert getProperties(ownAndGetterProperties) to getDisplayableProperties().
3256         Mark PropertyDescriptors that are presumed to be native getters / bindings
3257         separately so that the frontend may display them differently.
3258
3259         * inspector/InjectedScript.cpp:
3260         (Inspector::InjectedScript::getProperties):
3261         (Inspector::InjectedScript::getDisplayableProperties):
3262         * inspector/InjectedScript.h:
3263         * inspector/InjectedScriptSource.js:
3264         * inspector/agents/InspectorRuntimeAgent.cpp:
3265         (Inspector::InspectorRuntimeAgent::getProperties):
3266         (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
3267         * inspector/agents/InspectorRuntimeAgent.h:
3268         * inspector/protocol/Runtime.json:
3269
3270 2015-02-24  Mark Lam  <mark.lam@apple.com>
3271
3272         Rolling out r179753.  The fix was invalid.
3273         <https://webkit.org/b/141990>
3274
3275         Not reviewed.
3276
3277         * API/tests/testapi.mm:
3278         (threadMain):
3279         (useVMFromOtherThread): Deleted.
3280         (useVMFromOtherThreadAndOutliveVM): Deleted.
3281         * heap/Heap.cpp:
3282         (JSC::Heap::Heap):
3283         (JSC::Heap::~Heap):
3284         (JSC::Heap::gatherStackRoots):
3285         * heap/Heap.h:
3286         (JSC::Heap::machineThreads):
3287         * heap/MachineStackMarker.cpp:
3288         (JSC::MachineThreads::Thread::Thread):
3289         (JSC::MachineThreads::MachineThreads):
3290         (JSC::MachineThreads::~MachineThreads):
3291         (JSC::MachineThreads::addCurrentThread):
3292         (JSC::MachineThreads::removeThread):
3293         (JSC::MachineThreads::removeCurrentThread):
3294         * heap/MachineStackMarker.h:
3295
3296 2015-02-24  Yusuke Suzuki  <utatane.tea@gmail.com>
3297
3298         Constructor returning null should construct an object instead of null
3299         https://bugs.webkit.org/show_bug.cgi?id=141640
3300
3301         Reviewed by Filip Pizlo.
3302
3303         When constructor code doesn't return object, constructor should return `this` object instead.
3304         Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
3305         it allows `null` as an object.
3306         This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
3307         Instead, constructor uses simplified `is_object`.
3308
3309         As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.
3310
3311         1. LLInt and baseline JIT support `op_is_object` as a fast path.
3312         2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
3313         3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
3314         4. FTL lowers DFG's IsObject into LLVM IR.
3315
3316         And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
3317         in LLInt, JIT, DFG and FTL.
3318         Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
3319         So in many places, when the cell is not object, we recognize it as a string, and vice versa.
3320         However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
3321         So this patch stop using !isString as isObject.
3322         To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
3323         we examine typeInfo in JSCell.
3324
3325         * JavaScriptCore.order:
3326         * bytecode/BytecodeList.json:
3327         * bytecode/BytecodeUseDef.h:
3328         (JSC::computeUsesForBytecodeOffset):
3329         (JSC::computeDefsForBytecodeOffset):
3330         * bytecode/CodeBlock.cpp:
3331         (JSC::CodeBlock::dumpBytecode):
3332         * bytecode/PutByIdStatus.cpp:
3333         (JSC::PutByIdStatus::computeFor):
3334         * bytecompiler/BytecodeGenerator.cpp:
3335         (JSC::BytecodeGenerator::emitEqualityOp):
3336         (JSC::BytecodeGenerator::emitReturn):
3337         * dfg/DFGAbstractInterpreterInlines.h:
3338         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3339         * dfg/DFGByteCodeParser.cpp:
3340         (JSC::DFG::ByteCodeParser::parseBlock):
3341         * dfg/DFGCapabilities.cpp:
3342         (JSC::DFG::capabilityLevel):
3343         * dfg/DFGClobberize.h:
3344         (JSC::DFG::clobberize):
3345
3346         IsObject operation only touches JSCell typeInfoType.
3347         And this value would be changed through structure transition.
3348         As a result, IsObject can report that it doesn't read any information.
3349
3350         * dfg/DFGConstantFoldingPhase.cpp:
3351         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3352         * dfg/DFGDoesGC.cpp:
3353         (JSC::DFG::doesGC):
3354         * dfg/DFGFixupPhase.cpp:
3355         (JSC::DFG::FixupPhase::fixupNode):
3356
3357         Just like IsString, IsObject is also fixed up.
3358
3359         * dfg/DFGHeapLocation.cpp:
3360         (WTF::printInternal):
3361         * dfg/DFGHeapLocation.h:
3362         * dfg/DFGNodeType.h:
3363         * dfg/DFGOperations.cpp:
3364         * dfg/DFGOperations.h:
3365         * dfg/DFGPredictionPropagationPhase.cpp:
3366         (JSC::DFG::PredictionPropagationPhase::propagate):
3367         * dfg/DFGSafeToExecute.h:
3368         (JSC::DFG::safeToExecute):
3369         * dfg/DFGSpeculativeJIT.cpp:
3370         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
3371         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
3372         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
3373         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
3374         (JSC::DFG::SpeculativeJIT::speculateObject):
3375         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
3376         (JSC::DFG::SpeculativeJIT::speculateString):
3377         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
3378         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
3379         (JSC::DFG::SpeculativeJIT::emitSwitchString):
3380         (JSC::DFG::SpeculativeJIT::branchIsObject):
3381         (JSC::DFG::SpeculativeJIT::branchNotObject):
3382         (JSC::DFG::SpeculativeJIT::branchIsString):
3383         (JSC::DFG::SpeculativeJIT::branchNotString):
3384         * dfg/DFGSpeculativeJIT.h:
3385         * dfg/DFGSpeculativeJIT32_64.cpp:
3386         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3387         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
3388         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
3389         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
3390         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
3391         (JSC::DFG::SpeculativeJIT::compile):
3392         * dfg/DFGSpeculativeJIT64.cpp:
3393         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3394         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
3395         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
3396         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
3397         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
3398         (JSC::DFG::SpeculativeJIT::compile):
3399         * ftl/FTLCapabilities.cpp:
3400         (JSC::FTL::canCompile):
3401         * ftl/FTLLowerDFGToLLVM.cpp:
3402         (JSC::FTL::LowerDFGToLLVM::compileNode):
3403         (JSC::FTL::LowerDFGToLLVM::compileToString):
3404         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
3405         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
3406         (JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
3407         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
3408         (JSC::FTL::LowerDFGToLLVM::isObject):
3409         (JSC::FTL::LowerDFGToLLVM::isNotObject):
3410         (JSC::FTL::LowerDFGToLLVM::isNotString):
3411         (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
3412         * jit/JIT.cpp:
3413         (JSC::JIT::privateCompileMainPass):
3414         * jit/JIT.h:
3415         * jit/JITInlines.h:
3416         (JSC::JIT::emitJumpIfCellObject):
3417         * jit/JITOpcodes.cpp:
3418         (JSC::JIT::emit_op_is_object):
3419         (JSC::JIT::emit_op_to_primitive):
3420         * jit/JITOpcodes32_64.cpp:
3421         (JSC::JIT::emit_op_is_object):
3422         (JSC::JIT::emit_op_to_primitive):
3423         (JSC::JIT::compileOpStrictEq):
3424         * llint/LowLevelInterpreter.asm:
3425         * llint/LowLevelInterpreter32_64.asm:
3426         * llint/LowLevelInterpreter64.asm:
3427         * runtime/CommonSlowPaths.cpp:
3428         (JSC::SLOW_PATH_DECL):
3429         * runtime/CommonSlowPaths.h:
3430         * runtime/Operations.cpp:
3431         (JSC::jsIsObjectTypeOrNull):
3432         (JSC::jsIsObjectType): Deleted.
3433         * runtime/Operations.h:
3434         * tests/stress/constructor-with-return.js: Added.
3435         (Test):
3436
3437         When constructor doesn't return an object, `this` should be returned instead.
3438         In this test, we check all primitives. And test object, array and wrappers.
3439
3440         * tests/stress/dfg-to-primitive-pass-symbol.js: Added.
3441         (toPrimitiveTarget):
3442         (doToPrimitive):
3443
3444         op_to_primitive operation passes Symbol in fast path.
3445
3446 2015-02-24  Yusuke Suzuki  <utatane.tea@gmail.com>
3447
3448         REGRESSION(r179429): Can't type comments in Facebook
3449         https://bugs.webkit.org/show_bug.cgi?id=141859
3450
3451         Reviewed by Brent Fulgham.
3452
3453         When window.Symbol is exposed to user-space pages,
3454         Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
3455         However, to work with Symbols completely, it also requires
3456         1) Object.getOwnPropertySymbols (for mixin including Symbols)
3457         2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
3458         Since they are not landed yet, comments in Facebook don't work.
3459
3460         This patch introduces RuntimeFlags for JavaScriptCore.
3461         Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
3462         And drop JavaScriptExperimentsEnabled flag
3463         because it is no longer used and use case of this is duplicated to runtime flags.
3464
3465         * JavaScriptCore.order:
3466         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3467         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3468         * JavaScriptCore.xcodeproj/project.pbxproj:
3469         * jsc.cpp:
3470         (GlobalObject::javaScriptRuntimeFlags):
3471         (GlobalObject::javaScriptExperimentsEnabled): Deleted.
3472         * runtime/JSGlobalObject.cpp:
3473         (JSC::JSGlobalObject::JSGlobalObject):
3474         (JSC::JSGlobalObject::init):
3475         * runtime/JSGlobalObject.h:
3476         (JSC::JSGlobalObject::finishCreation):
3477         (JSC::JSGlobalObject::javaScriptRuntimeFlags):
3478         (JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
3479         * runtime/RuntimeFlags.h: Added.
3480         (JSC::RuntimeFlags::RuntimeFlags):
3481         (JSC::RuntimeFlags::createAllEnabled):
3482
3483 2015-02-23  Filip Pizlo  <fpizlo@apple.com>
3484
3485         Our bizarre behavior on Arguments::defineOwnProperty should be deliberate rather than a spaghetti incident
3486         https://bugs.webkit.org/show_bug.cgi?id=141951
3487
3488         Reviewed by Benjamin Poulain.
3489         
3490         This patch has no behavioral change, but it simplifies a bunch of wrong code. The code is
3491         still wrong in exactly the same way, but at least it's obvious what's going on. The wrongness
3492         is covered by this bug: https://bugs.webkit.org/show_bug.cgi?id=141952.
3493
3494         * runtime/Arguments.cpp:
3495         (JSC::Arguments::copyBackingStore): We should only see the arguments token; assert otherwise. This works because if the GC sees the butterfly token it calls the JSObject::copyBackingStore method directly.
3496         (JSC::Arguments::defineOwnProperty): Make our bizarre behavior deliberate rather than an accident of a decade of patches.
3497         * tests/stress/arguments-bizarre-behavior.js: Added.
3498         (foo):
3499         * tests/stress/arguments-bizarre-behaviour-disable-enumerability.js: Added. My choice of spellings of the word "behavio[u]r" is almost as consistent as our implementation of arguments.
3500         (foo):
3501         * tests/stress/arguments-custom-properties-gc.js: Added. I added this test because at first I was unsure if we GCd arguments correctly.
3502         (makeBaseArguments):
3503         (makeArray):
3504         (cons):
3505
3506 2015-02-23  Commit Queue  <commit-queue@webkit.org>
3507
3508         Unreviewed, rolling out r180547 and r180550.
3509         https://bugs.webkit.org/show_bug.cgi?id=141957
3510
3511         Broke 10 Windows tests. (Requested by bfulgham_ on #webkit).
3512
3513         Reverted changesets:
3514
3515         "REGRESSION(r179429): Can't type comments in Facebook"
3516         https://bugs.webkit.org/show_bug.cgi?id=141859
3517         http://trac.webkit.org/changeset/180547
3518
3519         "Constructor returning null should construct an object instead
3520         of null"
3521         https://bugs.webkit.org/show_bug.cgi?id=141640
3522         http://trac.webkit.org/changeset/180550
3523
3524 2015-02-23  Yusuke Suzuki  <utatane.tea@gmail.com>
3525
3526         Constructor returning null should construct an object instead of null
3527         https://bugs.webkit.org/show_bug.cgi?id=141640
3528
3529         Reviewed by Geoffrey Garen.
3530
3531         When constructor code doesn't return object, constructor should return `this` object instead.
3532         Since we used `op_is_object` for this check and `op_is_object` is intended to be used for `typeof`,
3533         it allows `null` as an object.
3534         This patch fixes it by introducing an new bytecode `op_is_object_or_null` for `typeof` use cases.
3535         Instead, constructor uses simplified `is_object`.
3536
3537         As a result, `op_is_object` becomes fairly simple. So we introduce optimization for `op_is_object`.
3538
3539         1. LLInt and baseline JIT support `op_is_object` as a fast path.
3540         2. DFG abstract interpreter support `op_is_object`. And recognize its speculated type and read-write effects.
3541         3. DFG introduces inlined asm for `op_is_object` rather than calling a C++ function.
3542         4. FTL lowers DFG's IsObject into LLVM IR.
3543
3544         And at the same time, this patch fixes isString / isObject predicate used for `op_is_object` and others
3545         in LLInt, JIT, DFG and FTL.
3546         Before introducing ES6 Symbol, JSCell is only used for object and string in user observable area.
3547         So in many places, when the cell is not object, we recognize it as a string, and vice versa.
3548         However, now ES6 Symbol is implemented as a JSCell, this assumption is broken.
3549         So this patch stop using !isString as isObject.
3550         To check whether a cell is an object, instead of seeing that structure ID of a cell is not stringStructure,
3551         we examine typeInfo in JSCell.
3552
3553         * JavaScriptCore.order:
3554         * bytecode/BytecodeList.json:
3555         * bytecode/BytecodeUseDef.h:
3556         (JSC::computeUsesForBytecodeOffset):
3557         (JSC::computeDefsForBytecodeOffset):
3558         * bytecode/CodeBlock.cpp:
3559         (JSC::CodeBlock::dumpBytecode):
3560         * bytecode/PutByIdStatus.cpp:
3561         (JSC::PutByIdStatus::computeFor):
3562         * bytecompiler/BytecodeGenerator.cpp:
3563         (JSC::BytecodeGenerator::emitEqualityOp):
3564         (JSC::BytecodeGenerator::emitReturn):
3565         * dfg/DFGAbstractInterpreterInlines.h:
3566         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3567         * dfg/DFGByteCodeParser.cpp:
3568         (JSC::DFG::ByteCodeParser::parseBlock):
3569         * dfg/DFGCapabilities.cpp:
3570         (JSC::DFG::capabilityLevel):
3571         * dfg/DFGClobberize.h:
3572         (JSC::DFG::clobberize):
3573
3574         IsObject operation only touches JSCell typeInfoType.
3575         And this value would not be changed through structure transition.
3576         As a result, IsObject can report that it doesn't read any information.
3577
3578         * dfg/DFGDoesGC.cpp:
3579         (JSC::DFG::doesGC):
3580         * dfg/DFGFixupPhase.cpp:
3581         (JSC::DFG::FixupPhase::fixupNode):
3582
3583         Just like IsString, IsObject is also fixed up.
3584
3585         * dfg/DFGHeapLocation.cpp:
3586         (WTF::printInternal):
3587         * dfg/DFGHeapLocation.h:
3588         * dfg/DFGNodeType.h:
3589         * dfg/DFGOperations.cpp:
3590         * dfg/DFGOperations.h:
3591         * dfg/DFGPredictionPropagationPhase.cpp:
3592         (JSC::DFG::PredictionPropagationPhase::propagate):
3593         * dfg/DFGSafeToExecute.h:
3594         (JSC::DFG::safeToExecute):
3595         * dfg/DFGSpeculativeJIT.cpp:
3596         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
3597         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
3598         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
3599         (JSC::DFG::SpeculativeJIT::compileToStringOnCell):
3600         (JSC::DFG::SpeculativeJIT::speculateObject):
3601         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
3602         (JSC::DFG::SpeculativeJIT::speculateString):
3603         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
3604         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
3605         (JSC::DFG::SpeculativeJIT::emitSwitchString):
3606         (JSC::DFG::SpeculativeJIT::branchIsObject):
3607         (JSC::DFG::SpeculativeJIT::branchNotObject):
3608         (JSC::DFG::SpeculativeJIT::branchIsString):
3609         (JSC::DFG::SpeculativeJIT::branchNotString):
3610         * dfg/DFGSpeculativeJIT.h:
3611         * dfg/DFGSpeculativeJIT32_64.cpp:
3612         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3613         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
3614         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
3615         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
3616         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
3617         (JSC::DFG::SpeculativeJIT::compile):
3618         * dfg/DFGSpeculativeJIT64.cpp:
3619         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
3620         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
3621         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
3622         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
3623         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
3624         (JSC::DFG::SpeculativeJIT::compile):
3625         * ftl/FTLCapabilities.cpp:
3626         (JSC::FTL::canCompile):
3627         * ftl/FTLLowerDFGToLLVM.cpp:
3628         (JSC::FTL::LowerDFGToLLVM::compileNode):
3629         (JSC::FTL::LowerDFGToLLVM::compileToString):
3630         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
3631         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
3632         (JSC::FTL::LowerDFGToLLVM::speculateTruthyObject):
3633         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
3634         (JSC::FTL::LowerDFGToLLVM::isObject):
3635         (JSC::FTL::LowerDFGToLLVM::isNotObject):
3636         (JSC::FTL::LowerDFGToLLVM::isNotString):
3637         (JSC::FTL::LowerDFGToLLVM::speculateNonNullObject):
3638         * jit/JIT.cpp:
3639         (JSC::JIT::privateCompileMainPass):
3640         * jit/JIT.h:
3641         * jit/JITInlines.h:
3642         (JSC::JIT::emitJumpIfCellObject):
3643         * jit/JITOpcodes.cpp:
3644         (JSC::JIT::emit_op_is_object):
3645         (JSC::JIT::emit_op_to_primitive):
3646         * jit/JITOpcodes32_64.cpp:
3647         (JSC::JIT::emit_op_is_object):
3648         (JSC::JIT::emit_op_to_primitive):
3649         (JSC::JIT::compileOpStrictEq):
3650         * llint/LowLevelInterpreter.asm:
3651         * llint/LowLevelInterpreter32_64.asm:
3652         * llint/LowLevelInterpreter64.asm:
3653         * runtime/CommonSlowPaths.cpp:
3654         (JSC::SLOW_PATH_DECL):
3655         * runtime/CommonSlowPaths.h:
3656         * runtime/Operations.cpp:
3657         (JSC::jsIsObjectTypeOrNull):
3658         (JSC::jsIsObjectType): Deleted.
3659         * runtime/Operations.h:
3660
3661 2015-02-23  Ryosuke Niwa  <rniwa@webkit.org>
3662
3663         Disable font loading events until our implementation gets updated to match the latest spec
3664         https://bugs.webkit.org/show_bug.cgi?id=141938
3665
3666         Reviewed by Andreas Kling.
3667
3668         * Configurations/FeatureDefines.xcconfig:
3669
3670 2015-02-23  Yusuke Suzuki  <utatane.tea@gmail.com>
3671
3672         REGRESSION(r179429): Can't type comments in Facebook
3673         https://bugs.webkit.org/show_bug.cgi?id=141859
3674
3675         Reviewed by Geoffrey Garen.
3676
3677         When window.Symbol is exposed to user-space pages,
3678         Facebook's JavaScript use it (maybe, for immutable-js and React.js's unique key).
3679         However, to work with Symbols completely, it also requires
3680         1) Object.getOwnPropertySymbols (for mixin including Symbols)
3681         2) the latest ES6 Iterator interface that uses Iterator.next and it returns { done: boolean, value: value }.
3682         Since they are not landed yet, comments in Facebook don't work.
3683
3684         This patch introduces RuntimeFlags for JavaScriptCore.
3685         Specifying SymbolEnabled flag under test runner and inspector to continue to work with Symbol.
3686         And drop JavaScriptExperimentsEnabled flag
3687         because it is no longer used and use case of this is duplicated to runtime flags.
3688
3689         * JavaScriptCore.order:
3690         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3691         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3692         * JavaScriptCore.xcodeproj/project.pbxproj:
3693         * jsc.cpp:
3694         (GlobalObject::javaScriptRuntimeFlags):
3695         (GlobalObject::javaScriptExperimentsEnabled): Deleted.
3696         * runtime/JSGlobalObject.cpp:
3697         (JSC::JSGlobalObject::JSGlobalObject):
3698         (JSC::JSGlobalObject::init):
3699         * runtime/JSGlobalObject.h:
3700         (JSC::JSGlobalObject::finishCreation):
3701         (JSC::JSGlobalObject::javaScriptRuntimeFlags):
3702         (JSC::JSGlobalObject::javaScriptExperimentsEnabled): Deleted.
3703         * runtime/RuntimeFlags.h: Added.
3704         (JSC::RuntimeFlags::RuntimeFlags):
3705         (JSC::RuntimeFlags::createAllEnabled):
3706
3707 2015-02-23  Benjamin Poulain  <bpoulain@apple.com>
3708
3709         Set the semantic origin of delayed SetLocal to the Bytecode that originated it
3710         https://bugs.webkit.org/show_bug.cgi?id=141727
3711
3712         Reviewed by Filip Pizlo.
3713
3714         Previously, delayed SetLocals would have the NodeOrigin of the next
3715         bytecode. This was because delayed SetLocal are...delayed... and
3716         currentCodeOrigin() is the one where the node is emitted.
3717
3718         This made debugging a little awkward since the OSR exits on SetLocal
3719         were reported for the next bytecode. This patch changes the semantic
3720         origin to keep the original bytecode.
3721
3722         From benchmarks, this looks like it could be a tiny bit faster
3723         but it likely just noise.
3724
3725         * dfg/DFGByteCodeParser.cpp:
3726         (JSC::DFG::ByteCodeParser::setDirect):
3727         (JSC::DFG::ByteCodeParser::setLocal):
3728         (JSC::DFG::ByteCodeParser::setArgument):
3729         (JSC::DFG::ByteCodeParser::currentNodeOrigin):
3730         (JSC::DFG::ByteCodeParser::addToGraph):
3731         (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal):
3732         (JSC::DFG::ByteCodeParser::DelayedSetLocal::execute):
3733
3734 2015-02-23  Benjamin Poulain  <bpoulain@apple.com>
3735
3736         Remove DFGNode::predictHeap()
3737         https://bugs.webkit.org/show_bug.cgi?id=141864
3738
3739         Reviewed by Geoffrey Garen.
3740
3741         * dfg/DFGNode.h:
3742         (JSC::DFG::Node::predictHeap): Deleted.
3743         Unused code.
3744
3745 2015-02-23  Filip Pizlo  <fpizlo@apple.com>
3746
3747         Get rid of JSLexicalEnvironment::argumentsGetter
3748         https://bugs.webkit.org/show_bug.cgi?id=141930
3749
3750         Reviewed by Mark Lam.
3751         
3752         This function is unused, and the way it's written is bizarre - it's a return statement that
3753         dominates a bunch of dead code.
3754
3755         * runtime/JSLexicalEnvironment.cpp:
3756         (JSC::JSLexicalEnvironment::argumentsGetter): Deleted.
3757         * runtime/JSLexicalEnvironment.h:
3758
3759 2015-02-23  Filip Pizlo  <fpizlo@apple.com>
3760
3761         Remove unused activationCount and allTheThingsCount variable declarations.
3762
3763         Rubber stamped by Mark Lam and Michael Saboff.
3764
3765         * runtime/JSLexicalEnvironment.h:
3766
3767 2015-02-23  Saam Barati  <saambarati1@gmail.com>
3768
3769         Adjust the ranges of basic block statements in JSC's control flow profiler to be mutually exclusive
3770         https://bugs.webkit.org/show_bug.cgi?id=141095
3771
3772         Reviewed by Mark Lam.
3773
3774         Suppose the control flow of a program forms basic block A with successor block
3775         B. A's end offset will be the *same* as B's start offset in the current architecture 
3776         of the control flow profiler. This makes reasoning about the text offsets of
3777         the control flow profiler unsound. To make reasoning about offsets sound, all 
3778         basic block ranges should be mutually exclusive.  All calls to emitProfileControlFlow 
3779         now pass in the *start* of a basic block as the text offset argument. This simplifies 
3780         all calls to emitProfileControlFlow because the previous implementation had a
3781         lot of edge cases for getting the desired basic block text boundaries.
3782
3783         This patch also ensures that the basic block boundary of a block statement 
3784         is the exactly the block's open and close brace offsets (inclusive). For example,
3785         in if/for/while statements. This also has the consequence that for statements 
3786         like "if (cond) foo();", the whitespace preceding "foo()" is not part of 
3787         the "foo()" basic block, but instead is part of the "if (cond) " basic block. 
3788         This is okay because these text offsets aren't meant to be human readable.
3789         Instead, they reflect the text offsets of JSC's AST nodes. The Web Inspector 
3790         is the only client of this API and user of these text offsets and it is 
3791         not negatively effected by this new behavior.
3792
3793         * bytecode/CodeBlock.cpp:
3794         (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
3795         When computing basic block boundaries in CodeBlock, we ensure that every
3796         block's end offset is one less than its successor's start offset to
3797         maintain that boundaries' ranges should be mutually exclusive.
3798
3799         * bytecompiler/BytecodeGenerator.cpp:
3800         (JSC::BytecodeGenerator::BytecodeGenerator):
3801         Because the control flow profiler needs to know which functions
3802         have executed, we can't lazily create functions. This was a bug 
3803         from before that was hidden because the Type Profiler was always 
3804         enabled when the control flow profiler was enabled when profiling 
3805         was turned on from the Web Inspector. But, JSC allows for Control 
3806         Flow profiling to be turned on without Type Profiling, so we need 
3807         to ensure the Control Flow profiler has all the data it needs.
3808
3809         * bytecompiler/NodesCodegen.cpp:
3810         (JSC::ConditionalNode::emitBytecode):
3811         (JSC::IfElseNode::emitBytecode):
3812         (JSC::WhileNode::emitBytecode):
3813         (JSC::ForNode::emitBytecode):
3814         (JSC::ForInNode::emitMultiLoopBytecode):
3815         (JSC::ForOfNode::emitBytecode):
3816         (JSC::TryNode::emitBytecode):
3817         * jsc.cpp:
3818         (functionHasBasicBlockExecuted):
3819         We now assert that the substring argument is indeed a substring
3820         of the function argument's text because subtle bugs could be
3821         introduced otherwise.
3822
3823         * parser/ASTBuilder.h:
3824         (JSC::ASTBuilder::setStartOffset):
3825         * parser/Nodes.h:
3826         (JSC::Node::setStartOffset):
3827         * parser/Parser.cpp:
3828         (JSC::Parser<LexerType>::parseBlockStatement):
3829         (JSC::Parser<LexerType>::parseStatement):
3830         (JSC::Parser<LexerType>::parseMemberExpression):
3831         For the various function call AST nodes, their m_position member 
3832         variable is now the start of the entire function call expression 
3833         and not at the start of the open paren of the arguments list.
3834
3835         * runtime/BasicBlockLocation.cpp:
3836         (JSC::BasicBlockLocation::getExecutedRanges):
3837         * runtime/ControlFlowProfiler.cpp:
3838         (JSC::ControlFlowProfiler::getBasicBlocksForSourceID):
3839         Function ranges inserted as gaps should follow the same criteria
3840         that the bytecode generator uses to ensure that basic blocks
3841         start and end offsets are mutually exclusive.
3842
3843         * tests/controlFlowProfiler/brace-location.js: Added.
3844         (foo):
3845         (bar):
3846         (baz):
3847         (testIf):
3848         (testForRegular):
3849         (testForIn):
3850         (testForOf):
3851         (testWhile):
3852         (testIfNoBraces):
3853         (testForRegularNoBraces):
3854         (testForInNoBraces):
3855         (testForOfNoBraces):
3856         (testWhileNoBraces):
3857         * tests/controlFlowProfiler/conditional-expression.js: Added.
3858         (foo):
3859         (bar):
3860         (baz):
3861         (testConditionalBasic):
3862         (testConditionalFunctionCall):
3863         * tests/controlFlowProfiler/driver/driver.js:
3864         (checkBasicBlock):
3865
3866 2015-02-23  Matthew Mirman  <mmirman@apple.com>
3867
3868         r9 is volatile on ARMv7 for iOS 3 and up. 
3869         https://bugs.webkit.org/show_bug.cgi?id=141489
3870         rdar://problem/19432916
3871
3872         Reviewed by Michael Saboff.
3873
3874         * jit/RegisterSet.cpp: 
3875         (JSC::RegisterSet::calleeSaveRegisters): removed r9 from the list of ARMv7 callee save registers.
3876         * tests/stress/regress-141489.js: Added.
3877         (foo):
3878
3879 2015-02-23  Csaba Osztrogonác  <ossy@webkit.org>
3880
3881         [ARM] Add the necessary setupArgumentsWithExecState after bug141915
3882         https://bugs.webkit.org/show_bug.cgi?id=141921
3883
3884         Reviewed by Michael Saboff.
3885
3886         * jit/CCallHelpers.h:
3887         (JSC::CCallHelpers::setupArgumentsWithExecState):
3888
3889 2015-02-23  Filip Pizlo  <fpizlo@apple.com>
3890
3891         Scopes should always be created with a previously-created symbol table rather than creating one on the fly
3892         https://bugs.webkit.org/show_bug.cgi?id=141915
3893
3894         Reviewed by Mark Lam.
3895         
3896         The main effect of this change is that pushing name scopes no longer requires creating symbol
3897         tables on the fly.
3898         
3899         This also makes it so that JSEnvironmentRecords must always have an a priori symbol table.
3900         
3901         JSSegmentedVariableObject still does a hack where it creates a blank symbol table on-demand.
3902         This is needed because that's what JSGlobalObject and all of its many subclasses want. That's
3903         harmless; I mainly needed a prior symbol tables for JSEnvironmentRecords anyway.
3904
3905         * bytecode/BytecodeList.json:
3906         * bytecompiler/BytecodeGenerator.cpp:
3907         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
3908         (JSC::BytecodeGenerator::emitPushCatchScope):
3909         * jit/CCallHelpers.h:
3910 &nbs