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