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