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