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