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