Fix typo in function name parseFunctionParamters -> parseFunctionParameters
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-05-15  Alexandr Skachkov  <gskachkov@gmail.com>
2
3         Fix typo in function name parseFunctionParamters -> parseFunctionParameters
4         https://bugs.webkit.org/show_bug.cgi?id=145040
5
6         Reviewed by Mark Lam.
7
8         * parser/Parser.h:
9         * parser/Parser.cpp:
10
11 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
12
13         Remove StoreBarrierWithNullCheck, nobody ever generates this.
14         
15         Rubber stamped by Benjamin Poulain and Michael Saboff.
16
17         If we did bring something like this back in the future, we would just use UntypedUse instead
18         of CellUse to indicate that this is what we want.
19
20         * dfg/DFGAbstractInterpreterInlines.h:
21         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
22         * dfg/DFGClobberize.h:
23         (JSC::DFG::clobberize):
24         * dfg/DFGDoesGC.cpp:
25         (JSC::DFG::doesGC):
26         * dfg/DFGFixupPhase.cpp:
27         (JSC::DFG::FixupPhase::fixupNode):
28         * dfg/DFGNode.h:
29         (JSC::DFG::Node::isStoreBarrier):
30         * dfg/DFGNodeType.h:
31         * dfg/DFGObjectAllocationSinkingPhase.cpp:
32         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
33         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
34         * dfg/DFGPredictionPropagationPhase.cpp:
35         (JSC::DFG::PredictionPropagationPhase::propagate):
36         * dfg/DFGSafeToExecute.h:
37         (JSC::DFG::safeToExecute):
38         * dfg/DFGSpeculativeJIT.cpp:
39         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
40         * dfg/DFGSpeculativeJIT32_64.cpp:
41         (JSC::DFG::SpeculativeJIT::compile):
42         * dfg/DFGSpeculativeJIT64.cpp:
43         (JSC::DFG::SpeculativeJIT::compile):
44         * ftl/FTLCapabilities.cpp:
45         (JSC::FTL::canCompile):
46         * ftl/FTLLowerDFGToLLVM.cpp:
47         (JSC::FTL::LowerDFGToLLVM::compileNode):
48         (JSC::FTL::LowerDFGToLLVM::compileStoreBarrierWithNullCheck): Deleted.
49
50 2015-05-14  Filip Pizlo  <fpizlo@apple.com>
51
52         PutGlobalVar should reference the global object it's storing into
53         https://bugs.webkit.org/show_bug.cgi?id=145036
54
55         Reviewed by Michael Saboff.
56         
57         This makes it easier to reason about store barrier insertion and elimination. This changes
58         the format of PutGlobalVar so that child1 is the global object and child2 is the value.
59         Previously it just had child1, and that was the value.
60
61         * dfg/DFGByteCodeParser.cpp:
62         (JSC::DFG::ByteCodeParser::parseBlock):
63         * dfg/DFGClobberize.h:
64         (JSC::DFG::clobberize):
65         * dfg/DFGFixupPhase.cpp:
66         (JSC::DFG::FixupPhase::fixupNode):
67         * dfg/DFGSpeculativeJIT32_64.cpp:
68         (JSC::DFG::SpeculativeJIT::compile):
69         * dfg/DFGSpeculativeJIT64.cpp:
70         (JSC::DFG::SpeculativeJIT::compile):
71         * ftl/FTLLowerDFGToLLVM.cpp:
72         (JSC::FTL::LowerDFGToLLVM::compilePutGlobalVar):
73
74 2015-05-14  Michael Catanzaro  <mcatanzaro@igalia.com>
75
76         [CMake] Error out when ruby is too old
77         https://bugs.webkit.org/show_bug.cgi?id=145014
78
79         Reviewed by Martin Robinson.
80
81         Don't enforce the check for the Ruby executable here; it's now enforced in the top-level
82         CMakeLists.txt instead.
83
84         * CMakeLists.txt:
85
86 2015-05-12  Basile Clement  <basile_clement@apple.com>
87
88         Enforce options coherency
89         https://bugs.webkit.org/show_bug.cgi?id=144921
90
91         Reviewed by Mark Lam.
92
93         JavaScriptCore should be failing early when the options are set in such
94         a way that we don't have a meaningful way to execute JavaScript, rather
95         than failing for obscure reasons at some point during execution.
96
97         This patch adds a new function that checks whether the options are set
98         in a coherent way, and makes JSC::Options::initialize() crash when the
99         environment enforces incoherent options.
100         Client applications able to add or change additional options are
101         responsible to check for coherency again before starting to actually
102         execute JavaScript, if any additional options have been set. This is
103         implemented for the jsc executable in this patch.
104
105         * jsc.cpp:
106         (CommandLine::parseArguments):
107         * runtime/Options.cpp:
108         (JSC::Options::initialize):
109         (JSC::Options::ensureOptionsAreCoherent): Added.
110         * runtime/Options.h:
111         (JSC::Options::ensureOptionsAreCoherent): Added.
112
113 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
114
115         REGRESSION (r184337): [EFL] unresolved reference errors in ARM builds
116         https://bugs.webkit.org/show_bug.cgi?id=145019
117
118         Reviewed by Ryosuke Niwa.
119
120         Attempt to fix compile errors in EFL ARM buildbots.
121         By executing `nm`, found JSTemplateRegistryKey.cpp.o and TemplateRegistry.cpp.o have
122         unresolved reference to Structure::get. That is inlined function in StructureInlines.h.
123
124         * runtime/JSTemplateRegistryKey.cpp:
125         * runtime/TemplateRegistry.cpp:
126
127 2015-05-14  Alexandr Skachkov  <gskachkov@gmail.com>
128
129         Small refactoring before implementation of the ES6 arrow function.
130         https://bugs.webkit.org/show_bug.cgi?id=144954
131
132         Reviewed by Ryosuke Niwa.
133
134         * parser/Parser.h:
135         * parser/Parser.cpp:
136
137 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
138
139         REGRESSION (r184337): ASSERT failed in debug builds for tagged templates
140         https://bugs.webkit.org/show_bug.cgi?id=145013
141
142         Reviewed by Filip Pizlo.
143
144         Fix the regression introduced by r184337.
145
146         1. JSTemporaryRegistryKey::s_info should inherit the Base::s_info,
147            JSDestructibleObject::s_info.
148
149         2. The first register argument of BytecodeGenerator::emitNode
150            should be a referenced register if it is a temporary register.
151
152         * bytecompiler/NodesCodegen.cpp:
153         (JSC::TaggedTemplateNode::emitBytecode):
154         * runtime/JSTemplateRegistryKey.cpp:
155
156 2015-05-14  Andreas Kling  <akling@apple.com>
157
158         String.prototype.split() should create efficient substrings.
159         <https://webkit.org/b/144985>
160         <rdar://problem/20949344>
161
162         Reviewed by Geoffrey Garen.
163
164         Teach split() how to make substring JSStrings instead of relying on StringImpl's
165         substring sharing mechanism. The optimization works by deferring the construction
166         of a StringImpl until the substring's value is actually needed.
167
168         This knocks ~2MB off of theverge.com by avoiding the extra StringImpl allocations.
169         Out of ~70000 substrings created by split(), only ~2000 of them get reified.
170
171         * runtime/StringPrototype.cpp:
172         (JSC::jsSubstring):
173         (JSC::splitStringByOneCharacterImpl):
174         (JSC::stringProtoFuncSplit):
175
176 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
177
178         Change the status of ES6 tagged templates to Done in features.json
179         https://bugs.webkit.org/show_bug.cgi?id=145003
180
181         Reviewed by Benjamin Poulain.
182
183         Now it's implemented in r184337.
184
185         * features.json:
186
187 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
188
189         Introduce SymbolType into SpeculativeTypes
190         https://bugs.webkit.org/show_bug.cgi?id=142651
191
192         Reviewed by Filip Pizlo.
193
194         Introduce SpecSymbol type into speculative types.
195         Previously symbol type is categorized into SpecCellOther.
196         But SpecCellOther is not intended to be used for such cells.
197
198         This patch just introduces SpecSymbol.
199         It represents the type of target value is definitely the symbol type.
200         It is the part of SpecCell.
201
202         In this patch, we do not introduce SymbolUse tracking.
203         It will be added in the separate patch.
204
205         * bytecode/SpeculatedType.cpp:
206         (JSC::dumpSpeculation):
207         (JSC::speculationFromStructure):
208         * bytecode/SpeculatedType.h:
209         (JSC::isSymbolSpeculation):
210         * dfg/DFGAbstractInterpreterInlines.h:
211         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
212         * dfg/DFGAbstractValue.cpp:
213         (JSC::DFG::AbstractValue::setType):
214         * dfg/DFGConstantFoldingPhase.cpp:
215         (JSC::DFG::ConstantFoldingPhase::foldConstants):
216         * tests/stress/typeof-symbol.js: Added.
217
218 2015-05-14  Yusuke Suzuki  <utatane.tea@gmail.com>
219
220         [ES6] Implement tagged templates
221         https://bugs.webkit.org/show_bug.cgi?id=143183
222
223         Reviewed by Oliver Hunt.
224
225         This patch implements ES6 tagged templates.
226         In tagged templates, the function takes the template object.
227
228         The template object contains the raw and cooked template strings,
229         so when parsing the tagged templates, we need to tokenize the raw and cooked strings.
230         While tagged templates require the both strings, the template literal only requires
231         the cooked strings. So when tokenizing under the template literal context,
232         we only builds the cooked strings.
233
234         As per ES6 spec, the template objects for the same raw strings are shared in the same realm.
235         The template objects is cached. And every time we evaluate the same tagged templates,
236         the same (cached) template objects are used.
237         Since the spec freezes this template objects completely,
238         we cannot attach some properties to it.
239         So we can say that it behaves as if the template objects are the primitive values (like JSString).
240         Since we cannot attach properties, the only way to test the identity of the template object is comparing. (===)
241         As the result, when there is no reference to the template object, we can garbage collect it
242         because the user has no way to test that the newly created template object does not equal
243         to the already collected template object.
244
245         So, to implement tagged templates, we implement the following components.
246
247         1. JSTemplateRegistryKey
248         It holds the template registry key and it does not exposed to users.
249         TemplateRegistryKey holds the vector of raw and cooked strings with the pre-computed hash value.
250         When obtaining the template object for the (statically, a.k.a. at the parsing time) given raw string vectors,
251         we use this JSTemplateRegistryKey as a key to the map and look up the template object from
252         TemplateRegistry.
253         JSTemplateRegistryKey is created at the bytecode compiling time and
254         stored in the CodeBlock as like as JSString content values.
255
256         2. TemplateRegistry
257         This manages the cached template objects.
258         It holds the weak map (JSTemplateRegistryKey -> the template object).
259         The template object is weakly referenced.
260         So if there is no reference to the template object,
261         the template object is automatically GC-ed.
262         When looking up the template object, it searches the cached template object.
263         If it is found, it is returned to the users.
264         If there is no cached template objects, it creates the new template object and
265         stores it with the given template registry key.
266
267         * CMakeLists.txt:
268         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
269         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
270         * JavaScriptCore.xcodeproj/project.pbxproj:
271         * bytecompiler/BytecodeGenerator.cpp:
272         (JSC::BytecodeGenerator::addTemplateRegistryKeyConstant):
273         (JSC::BytecodeGenerator::emitGetTemplateObject):
274         * bytecompiler/BytecodeGenerator.h:
275         * bytecompiler/NodesCodegen.cpp:
276         (JSC::TaggedTemplateNode::emitBytecode):
277         (JSC::TemplateLiteralNode::emitBytecode): Deleted.
278         * parser/ASTBuilder.h:
279         (JSC::ASTBuilder::createTaggedTemplate):
280         (JSC::ASTBuilder::createTemplateLiteral): Deleted.
281         * parser/Lexer.cpp:
282         (JSC::Lexer<T>::setCode):
283         (JSC::Lexer<T>::parseTemplateLiteral):
284         (JSC::Lexer<T>::lex):
285         (JSC::Lexer<T>::scanTrailingTemplateString):
286         (JSC::Lexer<T>::clear):
287         * parser/Lexer.h:
288         (JSC::Lexer<T>::makeEmptyIdentifier):
289         * parser/NodeConstructors.h:
290         (JSC::TaggedTemplateNode::TaggedTemplateNode):
291         (JSC::TemplateLiteralNode::TemplateLiteralNode): Deleted.
292         * parser/Nodes.h:
293         (JSC::TemplateLiteralNode::templateStrings):
294         (JSC::TemplateLiteralNode::templateExpressions):
295         (JSC::TaggedTemplateNode::templateLiteral):
296         * parser/Parser.cpp:
297         (JSC::Parser<LexerType>::parseTemplateString):
298         (JSC::Parser<LexerType>::parseTemplateLiteral):
299         (JSC::Parser<LexerType>::parsePrimaryExpression):
300         (JSC::Parser<LexerType>::parseMemberExpression):
301         * parser/Parser.h:
302         * parser/ParserArena.h:
303         (JSC::IdentifierArena::makeEmptyIdentifier):
304         * parser/SyntaxChecker.h:
305         (JSC::SyntaxChecker::createTaggedTemplate):
306         (JSC::SyntaxChecker::createTemplateLiteral): Deleted.
307         * runtime/CommonIdentifiers.h:
308         * runtime/JSGlobalObject.cpp:
309         (JSC::getTemplateObject):
310         (JSC::JSGlobalObject::JSGlobalObject):
311         (JSC::JSGlobalObject::init):
312         * runtime/JSGlobalObject.h:
313         (JSC::JSGlobalObject::templateRegistry):
314         * runtime/JSTemplateRegistryKey.cpp: Added.
315         (JSC::JSTemplateRegistryKey::JSTemplateRegistryKey):
316         (JSC::JSTemplateRegistryKey::create):
317         (JSC::JSTemplateRegistryKey::destroy):
318         * runtime/JSTemplateRegistryKey.h: Added.
319         * runtime/ObjectConstructor.cpp:
320         (JSC::objectConstructorFreeze):
321         * runtime/ObjectConstructor.h:
322         * runtime/TemplateRegistry.cpp: Added.
323         (JSC::TemplateRegistry::TemplateRegistry):
324         (JSC::TemplateRegistry::getTemplateObject):
325         * runtime/TemplateRegistry.h: Added.
326         * runtime/TemplateRegistryKey.h: Added.
327         (JSC::TemplateRegistryKey::isDeletedValue):
328         (JSC::TemplateRegistryKey::isEmptyValue):
329         (JSC::TemplateRegistryKey::hash):
330         (JSC::TemplateRegistryKey::rawStrings):
331         (JSC::TemplateRegistryKey::cookedStrings):
332         (JSC::TemplateRegistryKey::operator==):
333         (JSC::TemplateRegistryKey::operator!=):
334         (JSC::TemplateRegistryKey::Hasher::hash):
335         (JSC::TemplateRegistryKey::Hasher::equal):
336         (JSC::TemplateRegistryKey::TemplateRegistryKey):
337         * runtime/VM.cpp:
338         (JSC::VM::VM):
339         * runtime/VM.h:
340         * tests/stress/tagged-templates-identity.js: Added.
341         (shouldBe):
342         * tests/stress/tagged-templates-raw-strings.js: Added.
343         (shouldBe):
344         (tag):
345         (testEval):
346         * tests/stress/tagged-templates-syntax.js: Added.
347         (tag):
348         (testSyntax):
349         (testSyntaxError):
350         * tests/stress/tagged-templates-template-object.js: Added.
351         (shouldBe):
352         (tag):
353         * tests/stress/tagged-templates-this.js: Added.
354         (shouldBe):
355         (tag):
356         * tests/stress/tagged-templates.js: Added.
357         (shouldBe):
358         (raw):
359         (cooked):
360         (Counter):
361
362 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
363
364         REGRESSION(r180595): same-callee profiling no longer works
365         https://bugs.webkit.org/show_bug.cgi?id=144787
366
367         Reviewed by Filip Pizlo.
368
369         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
370         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
371         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
372
373         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
374         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
375         our speculation that the callee is the same. To avoid recompiling the same code for different callee
376         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
377         LLint and baseline JIT when multiple callees are observed.
378
379         Tests: stress/create-this-with-callee-variants.js
380
381         * bytecode/BytecodeList.json: Increased the number of operands to 5.
382         * bytecode/CodeBlock.cpp:
383         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
384         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
385         * bytecompiler/BytecodeGenerator.cpp:
386         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
387         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
388         operand.
389         * dfg/DFGByteCodeParser.cpp:
390         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
391         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
392         * jit/JITOpcodes.cpp:
393         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
394         as seenMultipleCalleeObjects() to indicate the polymorphic behavior and/or we've OSR exited here.
395         (JSC::JIT::emitSlow_op_create_this):
396         * jit/JITOpcodes32_64.cpp:
397         (JSC::JIT::emit_op_create_this): Ditto.
398         (JSC::JIT::emitSlow_op_create_this):
399         * llint/LowLevelInterpreter32_64.asm:
400         (_llint_op_create_this): Ditto.
401         * llint/LowLevelInterpreter64.asm:
402         (_llint_op_create_this): Ditto.
403         * runtime/CommonSlowPaths.cpp:
404         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
405         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
406         * runtime/JSCell.h:
407         (JSC::JSCell::seenMultipleCalleeObjects): Added.
408         * runtime/WriteBarrier.h:
409         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
410         * tests/stress/create-this-with-callee-variants.js: Added.
411
412 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
413
414         Clean up some possible RefPtr to PassRefPtr churn
415         https://bugs.webkit.org/show_bug.cgi?id=144779
416
417         Reviewed by Darin Adler.
418
419         * runtime/GenericTypedArrayViewInlines.h:
420         (JSC::GenericTypedArrayView<Adaptor>::create):
421         (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
422         * runtime/JSArrayBufferConstructor.cpp:
423         (JSC::constructArrayBuffer):
424         * runtime/Structure.cpp:
425         (JSC::Structure::toStructureShape):
426         * runtime/TypedArrayBase.h:
427         (JSC::TypedArrayBase::create):
428         (JSC::TypedArrayBase::createUninitialized):
429         * tools/FunctionOverrides.cpp:
430         (JSC::initializeOverrideInfo):
431         Release the last use of a RefPtr as it is passed on.
432
433 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
434
435         ES6: Allow duplicate property names
436         https://bugs.webkit.org/show_bug.cgi?id=142895
437
438         Reviewed by Geoffrey Garen.
439
440         Introduce new `op_put_getter_by_id` and `op_put_setter_by_id` opcodes
441         that will define a single getter or setter property on an object.
442
443         The existing `op_put_getter_setter` opcode is still preferred for
444         putting both a getter and setter at the same time but cannot be used
445         for putting an individual getter or setter which is needed in
446         some cases.
447
448         Add a new slow path when generating bytecodes for a property list
449         with computed properties, as computed properties are the only time
450         the list of properties cannot be determined statically.
451
452         * bytecompiler/NodesCodegen.cpp:
453         (JSC::PropertyListNode::emitBytecode):
454         - fast path for all constant properties
455         - slow but paired getter/setter path if there are no computed properties
456         - slow path, individual put operation for every property, if there are computed properties
457
458         * parser/Nodes.h:
459         Distinguish a Computed property from a Constant property.
460
461         * parser/Parser.cpp:
462         (JSC::Parser<LexerType>::parseProperty):
463         (JSC::Parser<LexerType>::parsePropertyMethod):
464         Distingish Computed and Constant properties.
465
466         (JSC::Parser<LexerType>::parseObjectLiteral):
467         When we drop into strict mode it is because we saw a getter
468         or setter, so be more explicit.
469
470         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
471         Eliminate duplicate property syntax error exception.
472
473         * parser/SyntaxChecker.h:
474         (JSC::SyntaxChecker::getName):
475         * parser/ASTBuilder.h:
476         (JSC::ASTBuilder::getName): Deleted.
477         No longer used.
478
479         * runtime/JSObject.h:
480         (JSC::JSObject::putDirectInternal):
481         When updating a property. If the Accessor attribute changed
482         update the Structure.
483
484         * runtime/JSObject.cpp:
485         (JSC::JSObject::putGetter):
486         (JSC::JSObject::putSetter):
487         Called by the opcodes, just perform the same operation that
488         __defineGetter__ or __defineSetter__ would do.
489
490         (JSC::JSObject::putDirectNonIndexAccessor):
491         This transition is now handled in putDirectInternal.
492
493         * runtime/Structure.h:
494         Add needed export.
495
496         * bytecode/BytecodeList.json:
497         * bytecode/BytecodeUseDef.h:
498         (JSC::computeUsesForBytecodeOffset):
499         (JSC::computeDefsForBytecodeOffset):
500         * bytecode/CodeBlock.cpp:
501         (JSC::CodeBlock::dumpBytecode):
502         * bytecompiler/BytecodeGenerator.cpp:
503         (JSC::BytecodeGenerator::emitPutGetterById):
504         (JSC::BytecodeGenerator::emitPutSetterById):
505         * bytecompiler/BytecodeGenerator.h:
506         * jit/JIT.cpp:
507         (JSC::JIT::privateCompileMainPass):
508         * jit/JIT.h:
509         * jit/JITInlines.h:
510         (JSC::JIT::callOperation):
511         * jit/JITOperations.cpp:
512         * jit/JITOperations.h:
513         * jit/JITPropertyAccess.cpp:
514         (JSC::JIT::emit_op_put_getter_by_id):
515         (JSC::JIT::emit_op_put_setter_by_id):
516         * jit/JITPropertyAccess32_64.cpp:
517         (JSC::JIT::emit_op_put_getter_by_id):
518         (JSC::JIT::emit_op_put_setter_by_id):
519         * llint/LLIntSlowPaths.cpp:
520         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
521         * llint/LLIntSlowPaths.h:
522         * llint/LowLevelInterpreter.asm:
523         New bytecodes. Modelled after existing op_put_getter_setter.
524
525 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
526
527         Creating a new blank document in icloud pages causes an AI error: Abstract value (CellBytecodedoubleBoolOther, TOP, TOP) for double node has type outside SpecFullDouble.
528         https://bugs.webkit.org/show_bug.cgi?id=144856
529
530         Reviewed by Benjamin Poulain.
531         
532         First I made fixTypeForRepresentation() print out better diagnostics when it dies.
533         
534         Then I fixed the bug: Node::convertToIdentityOn(Node*) needs to make sure that when it
535         converts to a representation-changing node, it needs to use one of the UseKinds that such
536         a node expects. For example, DoubleRep(UntypedUse:) doesn't make sense; it needs to be
537         something like DoubleRep(NumberUse:) since it will speculate that the input is a number.
538
539         * dfg/DFGAbstractInterpreter.h:
540         (JSC::DFG::AbstractInterpreter::setBuiltInConstant):
541         * dfg/DFGAbstractInterpreterInlines.h:
542         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
543         * dfg/DFGAbstractValue.cpp:
544         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
545         * dfg/DFGAbstractValue.h:
546         * dfg/DFGInPlaceAbstractState.cpp:
547         (JSC::DFG::InPlaceAbstractState::initialize):
548         * dfg/DFGNode.cpp:
549         (JSC::DFG::Node::convertToIdentityOn):
550         * tests/stress/cloned-arguments-get-by-val-double-array.js: Added.
551         (foo):
552
553 2015-05-13  Commit Queue  <commit-queue@webkit.org>
554
555         Unreviewed, rolling out r184313.
556         https://bugs.webkit.org/show_bug.cgi?id=144974
557
558         Introduced an assertion failure in class-syntax-
559         declaration.js, class-syntax-expression.js, and object-
560         literal-syntax.js (Requested by rniwa on #webkit).
561
562         Reverted changeset:
563
564         "Small refactoring before ES6 Arrow function implementation."
565         https://bugs.webkit.org/show_bug.cgi?id=144954
566         http://trac.webkit.org/changeset/184313
567
568 2015-05-13  Oliver Hunt  <oliver@apple.com>
569         Ensure that all the smart pointer types in WTF clear their pointer before deref
570         https://bugs.webkit.org/show_bug.cgi?id=143789
571
572         Reviewed by Ryosuke Niwa.
573
574         One of the simpler cases of this in JavaScriptCore. There
575         are other cases where we need to guard the derefs but they
576         are more complex cases.
577
578         * inspector/JSInjectedScriptHost.cpp:
579         (Inspector::JSInjectedScriptHost::releaseImpl):
580         * inspector/JSJavaScriptCallFrame.cpp:
581         (Inspector::JSJavaScriptCallFrame::releaseImpl):
582
583 2015-05-13  Alexandr Skachkov  <gskachkov@gmail.com>
584
585         Small refactoring before ES6 Arrow function implementation.
586         https://bugs.webkit.org/show_bug.cgi?id=144954
587
588         Reviewed by Filip Pizlo.
589
590         * parser/Parser.h:
591         * parser/Parser.cpp:
592
593 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
594
595         The liveness pruning done by ObjectAllocationSinkingPhase ignores the possibility of an object's bytecode liveness being longer than its DFG liveness
596         https://bugs.webkit.org/show_bug.cgi?id=144945
597
598         Reviewed by Michael Saboff.
599         
600         We were making the mistake of using DFG liveness for object allocation sinking decisions.
601         This is wrong. In fact we almost never want to use DFG liveness directly. The only place
602         where that makes sense is pruning in DFG AI.
603         
604         So, I created a CombinedLiveness class that combines the DFG liveness with bytecode
605         liveness.
606         
607         In the process of doing this, I realized that the DFGForAllKills definition of combined
608         liveness at block tail was not strictly right; it was using the bytecode liveness at the
609         block terminal instead of the union of the bytecode live-at-heads of successor blocks. So,
610         I changed DFGForAllKills to work in terms of CombinedLiveness.
611         
612         This allows me to unskip the test I added in r184260. I also added a new test that tries to
613         trigger this bug more directly.
614
615         * CMakeLists.txt:
616         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
617         * JavaScriptCore.xcodeproj/project.pbxproj:
618         * dfg/DFGArgumentsEliminationPhase.cpp:
619         * dfg/DFGCombinedLiveness.cpp: Added.
620         (JSC::DFG::liveNodesAtHead):
621         (JSC::DFG::CombinedLiveness::CombinedLiveness):
622         * dfg/DFGCombinedLiveness.h: Added.
623         (JSC::DFG::CombinedLiveness::CombinedLiveness):
624         * dfg/DFGForAllKills.h:
625         (JSC::DFG::forAllKillsInBlock):
626         (JSC::DFG::forAllLiveNodesAtTail): Deleted.
627         * dfg/DFGObjectAllocationSinkingPhase.cpp:
628         (JSC::DFG::ObjectAllocationSinkingPhase::performSinking):
629         (JSC::DFG::ObjectAllocationSinkingPhase::determineMaterializationPoints):
630         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
631         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
632         * tests/stress/escape-object-in-diamond-then-exit.js: Added.
633         * tests/stress/sink-object-past-invalid-check-sneaky.js:
634
635 2015-05-13  Ryosuke Niwa  <rniwa@webkit.org>
636
637         I skipped a wrong test in r184270. Fix that.
638         The failure is tracked by webkit.org/b/144947.
639
640         * tests/stress/arith-modulo-node-behaviors.js:
641         * tests/stress/arith-mul-with-constants.js:
642
643 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
644
645         Avoid always running some debug code in type profiling
646         https://bugs.webkit.org/show_bug.cgi?id=144775
647
648         Reviewed by Daniel Bates.
649
650         * runtime/TypeProfilerLog.cpp:
651         (JSC::TypeProfilerLog::processLogEntries):
652
653 2015-05-13  Joseph Pecoraro  <pecoraro@apple.com>
654
655         Pass String as reference in more places
656         https://bugs.webkit.org/show_bug.cgi?id=144769
657
658         Reviewed by Daniel Bates.
659
660         * debugger/Breakpoint.h:
661         (JSC::Breakpoint::Breakpoint):
662         * parser/Parser.h:
663         (JSC::Parser::setErrorMessage):
664         (JSC::Parser::updateErrorWithNameAndMessage):
665         * parser/ParserError.h:
666         (JSC::ParserError::ParserError):
667         * runtime/RegExp.cpp:
668         (JSC::RegExpFunctionalTestCollector::outputOneTest):
669         * runtime/RegExpObject.cpp:
670         (JSC::regExpObjectSourceInternal):
671         * runtime/TypeProfiler.cpp:
672         (JSC::TypeProfiler::typeInformationForExpressionAtOffset):
673         * runtime/TypeProfilerLog.cpp:
674         (JSC::TypeProfilerLog::processLogEntries):
675         * runtime/TypeProfilerLog.h:
676         * tools/FunctionOverrides.cpp:
677         (JSC::initializeOverrideInfo):
678         * inspector/scripts/codegen/generate_objc_conversion_helpers.py:
679         (ObjCConversionHelpersGenerator._generate_enum_from_protocol_string):
680
681         * inspector/scripts/codegen/objc_generator_templates.py:
682         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
683         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
684         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
685         * inspector/scripts/tests/expected/enum-values.json-result:
686         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
687         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
688         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
689         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
690         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
691         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
692         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
693         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
694         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
695         Rebaseline tests after updating the generator.
696
697 2015-05-13  Michael Saboff  <msaboff@apple.com>
698
699         com.apple.WebKit.WebContent crashed at JavaScriptCore: JSC::CodeBlock::finalizeUnconditionally
700         https://bugs.webkit.org/show_bug.cgi?id=144933
701
702         Changed the RELEASE_ASSERT_NOT_REACHED into an ASSERT.  Added some diagnostic messages to
703         help determine the cause for any crash.
704
705         Reviewed by Geoffrey Garen.
706
707         * bytecode/CodeBlock.cpp:
708         (JSC::CodeBlock::finalizeUnconditionally):
709
710 2015-05-13  Filip Pizlo  <fpizlo@apple.com>
711
712         REGRESSION(r184260): arguments elimination has stopped working because of Check(UntypedUse:) from SSAConversionPhase
713         https://bugs.webkit.org/show_bug.cgi?id=144951
714
715         Reviewed by Michael Saboff.
716         
717         There were two issues here:
718         
719         - In r184260 we expected a small number of possible use kinds in Check nodes, and
720           UntypedUse was not one of them. That seemed like a sensible assumption because we don't
721           create Check nodes unless it's to have a check. But, SSAConversionPhase was creating a
722           Check that could have UntypedUse. I fixed this. It's cleaner for SSAConversionPhase to
723           follow the same idiom as everyone else and not create tautological checks.
724         
725         - It's clearly not very robust to assume that Checks will not be used tautologically. So,
726           this changes how we validate Checks in the escape analyses. We now use willHaveCheck,
727           which catches cases that AI would have already marked as unnecessary. It then also uses
728           a new helper called alreadyChecked(), which allows us to just ask if the check is
729           unnecessary for objects. That's a good fall-back in case AI hadn't run yet.
730
731         * dfg/DFGArgumentsEliminationPhase.cpp:
732         * dfg/DFGMayExit.cpp:
733         * dfg/DFGObjectAllocationSinkingPhase.cpp:
734         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
735         * dfg/DFGSSAConversionPhase.cpp:
736         (JSC::DFG::SSAConversionPhase::run):
737         * dfg/DFGUseKind.h:
738         (JSC::DFG::alreadyChecked):
739         * dfg/DFGVarargsForwardingPhase.cpp:
740
741 k
742 2015-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>
743
744         [ES6] Implement String.raw
745         https://bugs.webkit.org/show_bug.cgi?id=144330
746
747         Reviewed by Filip Pizlo.
748
749         Implement String.raw. It is intended to be used with tagged-templates syntax.
750         To implement ToString abstract operation efficiently,
751         we introduce @toString bytecode intrinsic. It emits op_to_string directly.
752
753         * CMakeLists.txt:
754         * builtins/StringConstructor.js: Added.
755         (raw):
756         * bytecompiler/NodesCodegen.cpp:
757         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
758         * runtime/CommonIdentifiers.h:
759         * runtime/StringConstructor.cpp:
760         * tests/stress/string-raw.js: Added.
761         (shouldBe):
762         (.get shouldBe):
763         (Counter):
764
765 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
766
767         Temporarily disable the test on Windows. The failure is tracked in webkit.org/b/144897.
768
769         * tests/stress/arith-mul-with-constants.js:
770
771 2015-05-12  Filip Pizlo  <fpizlo@apple.com>
772
773         js/dom/stack-trace.html fails with eager compilation
774         https://bugs.webkit.org/show_bug.cgi?id=144853
775
776         Reviewed by Benjamin Poulain.
777         
778         All of our escape analyses were mishandling Check(). They were assuming that this is a
779         non-escaping operation. But, if we do for example a Check(Int32:@x) and @x is an escape
780         candidate, then we need to do something: if we eliminate or sink @x, then the check no
781         longer makes any sense since a phantom allocation has no type. This will make us forget
782         that this operation would have exited. This was causing us to not call a valueOf method in
783         js/dom/stack-trace.html with eager compilation enabled, because it was doing something like
784         +o where o had a valueOf method, and o was otherwise sinkable.
785         
786         This changes our escape analyses to basically pretend that any Check() that isn't obviously
787         unnecessary is an escape. We don't have to be super careful here. Most checks will be
788         completely eliminated by constant-folding. If that doesn't run in time, then the most
789         common check we will see is CellUse. So, we just recognize some very obvious check kinds
790         that we know would have passed, and for all of the rest we just assume that it's an escape.
791         
792         This was super tricky to test. The obvious way to test it is to use +o like
793         stack-trace.html, except that doing so relies on the fact that we still haven't implemented
794         the optimal behavior for op_to_number. So, I take four approaches in testing this patch:
795         
796         1) Use +o. These will test what we want it to test for now, but at some point in the future
797            these tests will just be a good sanity-check that our op_to_number implementation is
798            right.
799         
800         2) Do fancy control flow tricks to fool the profiling into thinking that some arithmetic
801            operation always sees integers even though we eventually feed it an object and that
802            object is a sink candidate.
803         
804         3) Introduce a new jsc.cpp intrinsic called isInt32() which returns true if the incoming
805            value is an int32. This intrinsic is required to be implemented by DFG by
806            unconditionally speculating that the input is int32. This allows us to write much more
807            targetted tests of the underlying issue.
808         
809         4) I made a version of stack-trace.html that runs in run-jsc-stress-tests, so that we can
810            get regression test coverage of this test in eager mode.
811
812         * dfg/DFGArgumentsEliminationPhase.cpp:
813         * dfg/DFGByteCodeParser.cpp:
814         (JSC::DFG::ByteCodeParser::handleIntrinsic):
815         * dfg/DFGObjectAllocationSinkingPhase.cpp:
816         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
817         * dfg/DFGVarargsForwardingPhase.cpp:
818         * ftl/FTLExitValue.cpp:
819         (JSC::FTL::ExitValue::dumpInContext):
820         * ftl/FTLLowerDFGToLLVM.cpp:
821         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
822         * ftl/FTLOSRExitCompiler.cpp:
823         (JSC::FTL::compileFTLOSRExit):
824         * jsc.cpp:
825         (GlobalObject::finishCreation):
826         (functionIsInt32):
827         * runtime/Intrinsic.h:
828         * tests/stress/sink-arguments-past-invalid-check-dfg.js: Added.
829         * tests/stress/sink-arguments-past-invalid-check-int32-dfg.js: Added.
830         * tests/stress/sink-arguments-past-invalid-check-int32.js: Added.
831         * tests/stress/sink-arguments-past-invalid-check-sneakier.js: Added.
832         * tests/stress/sink-arguments-past-invalid-check.js: Added.
833         * tests/stress/sink-function-past-invalid-check-sneakier.js: Added.
834         * tests/stress/sink-function-past-invalid-check-sneaky.js: Added.
835         * tests/stress/sink-object-past-invalid-check-int32.js: Added.
836         * tests/stress/sink-object-past-invalid-check-sneakier.js: Added.
837         * tests/stress/sink-object-past-invalid-check-sneaky.js: Added.
838         * tests/stress/sink-object-past-invalid-check.js: Added.
839
840 2015-05-12  Benjamin Poulain  <benjamin@webkit.org>
841
842         Fix the iteration count of arith-modulo-node-behaviors.js
843
844         * tests/stress/arith-modulo-node-behaviors.js:
845         No need for big numbers for the real testing.
846
847 2015-05-12  Mark Lam  <mark.lam@apple.com>
848
849         Windows: Cannot use HANDLE from GetCurrentThread() to get the CONTEXT of another thread.
850         https://bugs.webkit.org/show_bug.cgi?id=144924
851
852         Reviewed by Alex Christensen.
853
854         The present stack scanning code in the Windows port is expecting that the
855         GetCurrentThread() API will provide a unique HANDLE for each thread.  The code
856         then saves and later uses that HANDLE with GetThreadContext() to get the
857         runtime state of the target thread from the GC thread.  According to
858         https://msdn.microsoft.com/en-us/library/windows/desktop/ms683182(v=vs.85).aspx,
859         GetCurrentThread() does not provide this unique HANDLE that we expect:
860
861             "The function cannot be used by one thread to create a handle that can
862             be used by other threads to refer to the first thread. The handle is
863             always interpreted as referring to the thread that is using it. A
864             thread can create a "real" handle to itself that can be used by other
865             threads, or inherited by other processes, by specifying the pseudo
866             handle as the source handle in a call to the DuplicateHandle function."
867
868         As a result of this, GetCurrentThread() always returns the same HANDLE value, and
869         we end up never scanning the stacks of other threads because we wrongly think that
870         they are all equal (in identity) to the scanning thread.  This, in turn, results
871         in crashes due to objects that are incorrectly collected.
872
873         The fix is to call DuplicateHandle() to create a HANDLE that we can use.  The
874         MachineThreads::Thread class already accurately tracks the period of time when
875         we need that HANDLE for the VM.  Hence, the life-cycle of the HANDLE can be tied
876         to the life-cycle of the MachineThreads::Thread object for the corresponding thread.
877
878         * heap/MachineStackMarker.cpp:
879         (JSC::getCurrentPlatformThread):
880         (JSC::MachineThreads::Thread::Thread):
881         (JSC::MachineThreads::Thread::~Thread):
882         (JSC::MachineThreads::Thread::suspend):
883         (JSC::MachineThreads::Thread::resume):
884         (JSC::MachineThreads::Thread::getRegisters):
885
886 2015-05-12  Benjamin Poulain  <bpoulain@apple.com>
887
888         [JSC] Make the NegZero backward propagated flags of ArithMod stricter
889         https://bugs.webkit.org/show_bug.cgi?id=144897
890
891         Reviewed by Geoffrey Garen.
892
893         The NegZero flags of ArithMod were the same as ArithDiv: both children were
894         marked as needing to handle NegativeZero.
895
896         Lucky for us, ArithMod is quite a bit different than ArithDiv.
897
898         First, the sign of the result is completely independent from
899         the sign of the divisor. A zero on the divisor always produces a NaN.
900         That's great, we can remove the NodeBytecodeNeedsNegZero
901         from the flags propagated to child2.
902
903         Second, the sign of the result is always the same as the sign of
904         the dividend. A dividend of zero produces a zero of same sign
905         unless the divisor is zero (in which case the result is NaN).
906         This is great too: we can just pass the flags we got into
907         ArithMod.
908
909         With those two out of the way, we can make a faster version of ArithRound
910         for Kraken's oscillator. Since we no longer care about negative zero,
911         rounding becomes cast<int32>(value + 0.5). This gives ~3% faster runtime
912         on the benchmark.
913
914         Unfortunatelly, most of the time is spent in FTL and the same optimization
915         does not apply well just yet: rdar://problem/20904149.
916
917         * dfg/DFGBackwardsPropagationPhase.cpp:
918         (JSC::DFG::BackwardsPropagationPhase::propagate):
919         Never add NodeBytecodeNeedsNegZero unless needed by the users of this node.
920
921         * dfg/DFGSpeculativeJIT.cpp:
922         (JSC::DFG::SpeculativeJIT::compileArithRound):
923         Faster Math.round() when negative zero is not important.
924
925         * tests/stress/arith-modulo-node-behaviors.js: Added.
926         (moduloWithNegativeZeroDividend):
927         (moduloWithUnusedNegativeZeroDividend):
928         (moduloWithNegativeZeroDivisor):
929
930 2015-05-12  Mark Lam  <mark.lam@apple.com>
931
932         Refactor MachineStackMarker.cpp so that it's easier to reason about MachineThreads::Thread.
933         https://bugs.webkit.org/show_bug.cgi?id=144925
934
935         Reviewed by Michael Saboff.
936
937         Currently, the code in MachineStackMarker.cpp is written as a bunch of functions that
938         operate on the platformThread value in the MachineThreads::Thread struct.  Instead, we
939         can apply better OO encapsulation and convert all these functions into methods of the
940         MachineThreads::Thread struct.
941
942         This will also make it easier to reason about the fix for
943         https://bugs.webkit.org/show_bug.cgi?id=144924 later.
944
945         * heap/MachineStackMarker.cpp:
946         (JSC::getCurrentPlatformThread):
947         (JSC::MachineThreads::Thread::createForCurrentThread):
948         (JSC::MachineThreads::Thread::operator!=):
949         (JSC::MachineThreads::Thread::operator==):
950         (JSC::MachineThreads::addCurrentThread):
951         (JSC::MachineThreads::removeThreadIfFound):
952         (JSC::MachineThreads::Thread::suspend):
953         (JSC::MachineThreads::Thread::resume):
954         (JSC::MachineThreads::Thread::getRegisters):
955         (JSC::MachineThreads::Thread::Registers::stackPointer):
956         (JSC::MachineThreads::Thread::freeRegisters):
957         (JSC::MachineThreads::Thread::captureStack):
958         (JSC::MachineThreads::tryCopyOtherThreadStack):
959         (JSC::MachineThreads::tryCopyOtherThreadStacks):
960         (JSC::equalThread): Deleted.
961         (JSC::suspendThread): Deleted.
962         (JSC::resumeThread): Deleted.
963         (JSC::getPlatformThreadRegisters): Deleted.
964         (JSC::otherThreadStackPointer): Deleted.
965         (JSC::freePlatformThreadRegisters): Deleted.
966         (JSC::otherThreadStack): Deleted.
967
968 2015-05-12  Ryosuke Niwa  <rniwa@webkit.org>
969
970         Array.slice should have a fast path like Array.splice
971         https://bugs.webkit.org/show_bug.cgi?id=144901
972
973         Reviewed by Geoffrey Garen.
974
975         Add a fast memcpy path to Array.prototype.slice as done for Array.prototype.splice.
976         In Kraken, this appears to be 30% win on stanford-crypto-ccm and 10% win on stanford-crypto-pbkdf2.
977
978         * runtime/ArrayPrototype.cpp:
979         (JSC::arrayProtoFuncSlice):
980         * runtime/JSArray.cpp:
981         (JSC::JSArray::fastSlice): Added.
982         * runtime/JSArray.h:
983
984 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
985
986         OSR availability analysis would be more scalable (and correct) if it did more liveness pruning
987         https://bugs.webkit.org/show_bug.cgi?id=143078
988
989         Reviewed by Andreas Kling.
990         
991         In https://bugs.webkit.org/show_bug.cgi?id=144883, we found an example of where liveness
992         pruning is actually necessary. Well, not quite: we just need to prune out keys from the
993         heap availability map where the base node doesn't dominate the point where we are asking
994         for availability. If we don't do this, then eventually the IR gets corrupt because we'll
995         insert PutHints that reference the base node in places where the base node doesn't
996         dominate. But if we're going to do any pruning, then it makes sense to prune by bytecode
997         liveness. This is the strongest possible pruning we can do, and it should be sound. We
998         shouldn't have a node available for a virtual register if that register is live and the
999         node doesn't dominate.
1000         
1001         Making this work meant reusing the prune-to-liveness algorithm from the FTL backend. So, I
1002         abstracted this a bit better. You can now availabilityMap.pruneByLiveness(graph, origin).
1003
1004         * dfg/DFGAvailabilityMap.cpp:
1005         (JSC::DFG::AvailabilityMap::pruneHeap):
1006         (JSC::DFG::AvailabilityMap::pruneByLiveness):
1007         (JSC::DFG::AvailabilityMap::prune): Deleted.
1008         * dfg/DFGAvailabilityMap.h:
1009         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
1010         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
1011         * ftl/FTLLowerDFGToLLVM.cpp:
1012         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1013         * tests/stress/liveness-pruning-needed-for-osr-availability.js: Added. This is a proper regression test.
1014         * tests/stress/liveness-pruning-needed-for-osr-availability-eager.js: Added. This is the original reduced test case, requires eager-no-cjit to fail prior to this changeset.
1015
1016 2015-05-12  Gabor Loki  <loki@webkit.org>
1017
1018         Workaround for Cortex-A53 erratum 843419
1019         https://bugs.webkit.org/show_bug.cgi?id=144680
1020
1021         Reviewed by Michael Saboff.
1022
1023         This patch is about to give simple workaround for Cortex-A53 erratum 843419.
1024         It inserts nops after ADRP instruction to avoid wrong address accesses.
1025
1026         * assembler/ARM64Assembler.h:
1027         (JSC::ARM64Assembler::adrp):
1028         (JSC::ARM64Assembler::nopCortexA53Fix843419):
1029
1030 2015-05-11  Commit Queue  <commit-queue@webkit.org>
1031
1032         Unreviewed, rolling out r184009.
1033         https://bugs.webkit.org/show_bug.cgi?id=144900
1034
1035         Caused crashes on inspector tests (Requested by ap on
1036         #webkit).
1037
1038         Reverted changeset:
1039
1040         "MapDataImpl::add() shouldn't do the same hash lookup twice."
1041         https://bugs.webkit.org/show_bug.cgi?id=144759
1042         http://trac.webkit.org/changeset/184009
1043
1044 2015-05-11  Commit Queue  <commit-queue@webkit.org>
1045
1046         Unreviewed, rolling out r184123.
1047         https://bugs.webkit.org/show_bug.cgi?id=144899
1048
1049         Seems to have introduced flaky crashes in many JS tests
1050         (Requested by rniwa on #webkit).
1051
1052         Reverted changeset:
1053
1054         "REGRESSION(r180595): same-callee profiling no longer works"
1055         https://bugs.webkit.org/show_bug.cgi?id=144787
1056         http://trac.webkit.org/changeset/184123
1057
1058 2015-05-11  Brent Fulgham  <bfulgham@apple.com>
1059
1060         [Win] Move Windows build target to Windows 7 (or newer)
1061         https://bugs.webkit.org/show_bug.cgi?id=144890
1062         <rdar://problem/20707307>
1063
1064         Reviewed by Anders Carlsson.
1065
1066         Update linked SDK and minimal Windows level to be compatible with
1067         Windows 7 or newer.
1068
1069         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1070         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1071         * JavaScriptCore.vcxproj/JavaScriptCoreGenerated.vcxproj:
1072         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj:
1073         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj:
1074         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj:
1075         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj:
1076         * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj:
1077         * JavaScriptCore.vcxproj/libllvmForJSC/libllvmForJSC.vcxproj:
1078         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj:
1079         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj:
1080         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj:
1081         * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj:
1082         * config.h:
1083
1084 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
1085
1086         CPS rethreading phase's flush detector flushes way too many SetLocals
1087         https://bugs.webkit.org/show_bug.cgi?id=144819
1088
1089         Reviewed by Geoffrey Garen.
1090         
1091         After probably unrelated changes, this eventually caused some arguments elimination to stop
1092         working because it would cause more SetLocals to turn into PutStacks. But it was a bug for
1093         a long time. Basically, we don't want the children of a SetLocal to be flushed. Flushing is
1094         meant to only affect the SetLocal itself.
1095         
1096         This is a speed-up on Octane/earley.
1097
1098         * dfg/DFGCPSRethreadingPhase.cpp:
1099         (JSC::DFG::CPSRethreadingPhase::computeIsFlushed):
1100
1101 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
1102
1103         gmail and google maps fail to load with eager compilation: Failed to insert inline cache for varargs call (specifically, CallForwardVarargs) because we thought the size would be 250 but it ended up being 262 prior to compaction.
1104         https://bugs.webkit.org/show_bug.cgi?id=144854
1105
1106         Reviewed by Oliver Hunt.
1107         
1108         This is easy: just lift the threshold. Also remove the need for some duplicate thresholds.
1109         It used to be that Construct required less code, but that's not the case for now.
1110
1111         * ftl/FTLInlineCacheSize.cpp:
1112         (JSC::FTL::sizeOfCallForwardVarargs):
1113         (JSC::FTL::sizeOfConstructVarargs):
1114         (JSC::FTL::sizeOfConstructForwardVarargs):
1115
1116 2015-05-11  Ryosuke Niwa  <rniwa@webkit.org>
1117
1118         REGRESSION(r180595): same-callee profiling no longer works
1119         https://bugs.webkit.org/show_bug.cgi?id=144787
1120
1121         Reviewed by Michael Saboff.
1122
1123         This patch introduces a DFG optimization to use NewObject node when the callee of op_create_this is
1124         always the same JSFunction. This condition doesn't hold when the byte code creates multiple
1125         JSFunction objects at runtime as in: function y() { return function () {} }; new y(); new y();
1126
1127         To enable this optimization, LLint and baseline JIT now store the last callee we saw in the newly
1128         added fourth operand of op_create_this. We use this JSFunction's structure in DFG after verifying
1129         our speculation that the callee is the same. To avoid recompiling the same code for different callee
1130         objects in the polymorphic case, the special value of seenMultipleCalleeObjects() is set in
1131         LLint and baseline JIT when multiple callees are observed.
1132
1133         Tests: stress/create-this-with-callee-variants.js
1134
1135         * bytecode/BytecodeList.json: Increased the number of operands to 5.
1136         * bytecode/BytecodeUseDef.h:
1137         (JSC::computeUsesForBytecodeOffset): op_create_this uses 2nd (constructor) and 4th (callee cache)
1138         operands.
1139         * bytecode/CodeBlock.cpp:
1140         (JSC::CodeBlock::dumpBytecode): Dump the newly added callee cache.
1141         (JSC::CodeBlock::finalizeUnconditionally): Clear the callee cache if the callee is no longer alive.
1142         * bytecompiler/BytecodeGenerator.cpp:
1143         (JSC::BytecodeGenerator::emitCreateThis): Add the instruction to propertyAccessInstructions so that
1144         we can clear the callee cache in CodeBlock::finalizeUnconditionally. Also initialize the newly added
1145         operand.
1146         * dfg/DFGByteCodeParser.cpp:
1147         (JSC::DFG::ByteCodeParser::parseBlock): Implement the optimization. Speculate the actual callee to
1148         match the cache. Use the cached callee's structure if the speculation succeeds. Otherwise, OSR exit.
1149         * jit/JITOpcodes.cpp:
1150         (JSC::JIT::emit_op_create_this): Go to the slow path to update the cache unless it's already marked
1151         as seenMultipleCalleeObjects() to indicate the polymorphic behavior.
1152         (JSC::JIT::emitSlow_op_create_this):
1153         * jit/JITOpcodes32_64.cpp:
1154         (JSC::JIT::emit_op_create_this): Ditto.
1155         (JSC::JIT::emitSlow_op_create_this):
1156         * llint/LowLevelInterpreter32_64.asm:
1157         (_llint_op_create_this): Ditto.
1158         * llint/LowLevelInterpreter64.asm:
1159         (_llint_op_create_this): Ditto.
1160         * runtime/CommonSlowPaths.cpp:
1161         (slow_path_create_this): Set the callee cache to the actual callee if it's not set. If the cache has
1162         been set to a JSFunction* different from the actual callee, set it to seenMultipleCalleeObjects().
1163         * runtime/JSCell.h:
1164         (JSC::JSCell::seenMultipleCalleeObjects): Added.
1165         * runtime/WriteBarrier.h:
1166         (JSC::WriteBarrierBase::unvalidatedGet): Removed the compile guard around it.
1167         * tests/stress/create-this-with-callee-variants.js: Added.
1168
1169 2015-05-11  Andreas Kling  <akling@apple.com>
1170
1171         PropertyNameArray should use a Vector when there are few entries.
1172         <https://webkit.org/b/144874>
1173
1174         Reviewed by Geoffrey Garen.
1175
1176         Bring back an optimization that was lost in the for-in refactoring.
1177         PropertyNameArray now holds a Vector<AtomicStringImpl*> until there are
1178         enough (20) entries to justify converting to a HashSet for contains().
1179
1180         Also inlined the code while we're here, since it has so few clients and
1181         the call overhead adds up.
1182
1183         ~5% progression on Kraken/json-stringify-tinderbox.
1184
1185         * runtime/PropertyNameArray.cpp: Removed.
1186         * runtime/PropertyNameArray.h:
1187         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
1188         (JSC::PropertyNameArray::add):
1189         (JSC::PropertyNameArray::addKnownUnique):
1190
1191 2015-05-11  Matt Baker  <mattbaker@apple.com>
1192
1193         Web Inspector: REGRESSION (r175203): No profile information is shown in Inspector
1194         https://bugs.webkit.org/show_bug.cgi?id=144808
1195
1196         Reviewed by Darin Adler.
1197
1198         Since a profile can be started after a timeline recording has already begun, we can't assume a zero start time.
1199         The start time for the root node's call entry should be based on the stopwatch used by the ProfileGenerator.
1200
1201         * profiler/Profile.cpp:
1202         (JSC::Profile::create):
1203         (JSC::Profile::Profile):
1204         * profiler/Profile.h:
1205         * profiler/ProfileGenerator.cpp:
1206         (JSC::ProfileGenerator::ProfileGenerator):
1207         (JSC::AddParentForConsoleStartFunctor::operator()):
1208
1209 2015-05-11  Basile Clement  <basile_clement@apple.com>
1210
1211         Unreviewed, remove unintended change.
1212
1213         * dfg/DFGAbstractInterpreterInlines.h:
1214         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1215
1216 2015-05-11  Filip Pizlo  <fpizlo@apple.com>
1217
1218         Make it easy to enable eager/non-concurrent JIT compilation
1219         https://bugs.webkit.org/show_bug.cgi?id=144877
1220
1221         Reviewed by Michael Saboff.
1222
1223         * runtime/Options.cpp:
1224         (JSC::recomputeDependentOptions):
1225         * runtime/Options.h:
1226
1227 2015-05-10  Filip Pizlo  <fpizlo@apple.com>
1228
1229         We shouldn't promote LoadVarargs to a sequence of GetStacks and PutStacks if doing so would exceed the LoadVarargs' limit
1230         https://bugs.webkit.org/show_bug.cgi?id=144851
1231
1232         Reviewed by Michael Saboff.
1233         
1234         LoadVarargs loads arguments from some object and puts them on the stack. The region of
1235         stack is controlled by a bunch of meta-data, including InlineCallFrame. InlineCallFrame
1236         shouldn't really be edited after ByteCodeParser, so we cannot convert LoadVarargs to
1237         something that uses more stack than the LoadVarargs wanted to.
1238         
1239         This check was missing in the ArgumentsEliminationPhase's LoadVarargs->GetStack+PutStack
1240         promoter. This is an important promotion rule for performance, and in cases where we are
1241         compiling truly hot code, the LoadVarargs limit will be at least as big as the length of
1242         the phantom arguments array that this phase sees. The LoadVarargs limit is based on
1243         profiling and the phantom arguments array is a proof; in most cases the profiling is more
1244         conservative.
1245         
1246         But, you could write some crazy code where the statically obvious arguments array value is
1247         bigger than what the profiling would have told you. When this happens, this promotion
1248         effectively removes a bounds check. This either results in us clobbering a bunch of stack,
1249         or it means that we never initialize a region of the stack that a later operation will read
1250         (the uninitialization happens because PutStackSinkingPhase removes PutStacks that appear
1251         unnecessary, and a GetMyArgumentByVal will claim not to use the region of the stack outside
1252         the original LoadVarargs limit).
1253         
1254         * dfg/DFGArgumentsEliminationPhase.cpp:
1255         * tests/stress/load-varargs-elimination-bounds-check-barely.js: Added.
1256         (foo):
1257         (bar):
1258         (baz):
1259         * tests/stress/load-varargs-elimination-bounds-check.js: Added.
1260         (foo):
1261         (bar):
1262         (baz):
1263
1264 2015-05-11  Andreas Kling  <akling@apple.com>
1265
1266         JSON.stringify shouldn't use generic get() to access Array.length
1267         <https://webkit.org/b/144847>
1268
1269         Reviewed by Geoffrey Garen.
1270
1271         If the value being serialized is a JSArray object, we can downcast and call its
1272         length() directly instead of doing a generic property lookup.
1273
1274         0.5% progression on Kraken/json-stringify-tinderbox.
1275
1276         * runtime/JSONObject.cpp:
1277         (JSC::Stringifier::Holder::appendNextProperty):
1278
1279 2015-05-10  Andreas Kling  <akling@apple.com>
1280
1281         Remove unnecessary AtomicStringImpl* hash specification in PropertyNameArray.
1282
1283         Follow up to r184050 suggested by Darin.
1284
1285         * runtime/PropertyNameArray.h:
1286
1287 2015-05-10  Andreas Kling  <akling@apple.com>
1288
1289         Remove unused things from PropertyNameArray.
1290         <https://webkit.org/b/144834>
1291
1292         Reviewed by Filip Pizlo.
1293
1294         PropertyNameArray had a bunch of bells and whistles added to it when for-in iteration
1295         was refactored and optimized last year. Then more refactoring happened and this class
1296         doesn't need to ring and toot anymore.
1297
1298         The RefCountedIdentifierSet class disappears since the JSPropertyNameEnumerator wasn't
1299         actually using it for anything and we were just wasting time creating these.
1300
1301         Also made the member functions take AtomicStringImpl* instead of plain StringImpl*.
1302
1303         * runtime/JSObject.cpp:
1304         (JSC::JSObject::getPropertyNames):
1305         * runtime/JSPropertyNameEnumerator.cpp:
1306         (JSC::JSPropertyNameEnumerator::create):
1307         (JSC::JSPropertyNameEnumerator::JSPropertyNameEnumerator):
1308         * runtime/JSPropertyNameEnumerator.h:
1309         * runtime/PropertyNameArray.cpp:
1310         (JSC::PropertyNameArray::add):
1311         (JSC::PropertyNameArray::setPreviouslyEnumeratedProperties): Deleted.
1312         * runtime/PropertyNameArray.h:
1313         (JSC::PropertyNameArray::PropertyNameArray):
1314         (JSC::PropertyNameArray::add):
1315         (JSC::PropertyNameArray::addKnownUnique):
1316         (JSC::PropertyNameArray::canAddKnownUniqueForStructure):
1317         (JSC::RefCountedIdentifierSet::contains): Deleted.
1318         (JSC::RefCountedIdentifierSet::size): Deleted.
1319         (JSC::RefCountedIdentifierSet::add): Deleted.
1320         (JSC::PropertyNameArray::identifierSet): Deleted.
1321         (JSC::PropertyNameArray::numCacheableSlots): Deleted.
1322         (JSC::PropertyNameArray::setNumCacheableSlotsForObject): Deleted.
1323         (JSC::PropertyNameArray::setBaseObject): Deleted.
1324         (JSC::PropertyNameArray::setPreviouslyEnumeratedLength): Deleted.
1325
1326 2015-05-09  Yoav Weiss  <yoav@yoav.ws>
1327
1328         Remove the PICTURE_SIZES build flag
1329         https://bugs.webkit.org/show_bug.cgi?id=144679
1330
1331         Reviewed by Benjamin Poulain.
1332
1333         Removed the PICTURE_SIZES build time flag.
1334
1335         * Configurations/FeatureDefines.xcconfig:
1336
1337 2015-05-08  Filip Pizlo  <fpizlo@apple.com>
1338
1339         Extend the SaneChain optimization to Contiguous arrays
1340         https://bugs.webkit.org/show_bug.cgi?id=144664
1341
1342         Reviewed by Mark Lam.
1343         
1344         Previously if you loaded from a hole, you'd either have to take slow path for the array
1345         load (which means C++ calls and prototype chain walks) or you'd exit (if you hadn't
1346         gathered the necessary profiling yet). But that's unnecessary if we know that the
1347         prototype chain is sane - i.e. has no indexed properties. Then we can just return
1348         Undefined for the hole.
1349         
1350         Making this change requires setting more watchpoints on the array prototype chain. But
1351         that hit a horrible bug: ArrayPrototype still uses the static lookup tables and builds
1352         itself up lazily. This means that this increased the number of recompilations we'd get
1353         due to the array prototype chain being built up.
1354         
1355         So, this change also removes the laziness and static tables from ArrayPrototype.
1356         
1357         But to make that change, I also had to add a helper for eagerly building up a prototype
1358         that has builtin functions.
1359
1360         * CMakeLists.txt:
1361         * DerivedSources.make:
1362         * dfg/DFGArrayMode.h:
1363         * dfg/DFGFixupPhase.cpp:
1364         (JSC::DFG::FixupPhase::fixupNode):
1365         * dfg/DFGSpeculativeJIT32_64.cpp:
1366         (JSC::DFG::SpeculativeJIT::compile):
1367         * dfg/DFGSpeculativeJIT64.cpp:
1368         (JSC::DFG::SpeculativeJIT::compile):
1369         * ftl/FTLLowerDFGToLLVM.cpp:
1370         (JSC::FTL::LowerDFGToLLVM::compileGetByVal):
1371         * runtime/ArrayPrototype.cpp:
1372         (JSC::ArrayPrototype::finishCreation):
1373         (JSC::ArrayPrototype::getOwnPropertySlot): Deleted.
1374         * runtime/ArrayPrototype.h:
1375         * runtime/JSObject.h:
1376
1377 2015-05-08  Michael Saboff  <msaboff@apple.com>
1378
1379         Creating a large MarkedBlock sometimes results in more than one cell in the block
1380         https://bugs.webkit.org/show_bug.cgi?id=144815
1381
1382         Reviewed by Mark Lam.
1383
1384         Large MarkedBlocks should have one and only one cell.  Changed the calculation of
1385         m_endAtom for large blocks to use the location of the first cell + 1.  This
1386         assures that large blocks only have one cell.
1387
1388         * heap/MarkedBlock.cpp:
1389         (JSC::MarkedBlock::MarkedBlock):
1390
1391 2015-05-08  Oliver Hunt  <oliver@apple.com>
1392
1393         MapDataImpl::add() shouldn't do the same hash lookup twice.
1394         https://bugs.webkit.org/show_bug.cgi?id=144759
1395
1396         Reviewed by Gavin Barraclough.
1397
1398         We don't actually need to do a double lookup here, all we need to
1399         do is update the index to point to the correct m_size.
1400
1401         * runtime/MapDataInlines.h:
1402         (JSC::JSIterator>::add):
1403
1404 2015-05-08  Andreas Kling  <akling@apple.com>
1405
1406         Micro-optimize JSON serialization of string primitives.
1407         <https://webkit.org/b/144800>
1408
1409         Reviewed by Sam Weinig.
1410
1411         Don't use the out-of-line JSValue::getString() to grab at string primitives
1412         in serialization. Just check if it's a JSString and then downcast to grab at
1413         the WTF::String inside.
1414
1415         2% progression on Kraken/json-stringify-tinderbox.
1416
1417         * runtime/JSONObject.cpp:
1418         (JSC::Stringifier::appendStringifiedValue):
1419
1420 2015-05-08  Andreas Kling  <akling@apple.com>
1421
1422         Optimize serialization of quoted JSON strings.
1423         <https://webkit.org/b/144754>
1424
1425         Reviewed by Darin Adler.
1426
1427         Optimized the serialization of quoted strings into JSON by moving the logic into
1428         StringBuilder so it can make smarter decisions about buffering.
1429
1430         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
1431
1432         * bytecompiler/NodesCodegen.cpp:
1433         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
1434
1435         * runtime/JSONObject.h:
1436         * runtime/JSONObject.cpp:
1437         (JSC::Stringifier::Holder::appendNextProperty):
1438         (JSC::appendStringToStringBuilder): Deleted.
1439         (JSC::appendQuotedJSONStringToBuilder): Deleted.
1440         (JSC::Stringifier::appendQuotedString): Deleted.
1441         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
1442         to StringBuilder and call that from here.
1443
1444 2015-05-07  Commit Queue  <commit-queue@webkit.org>
1445
1446         Unreviewed, rolling out r183961.
1447         https://bugs.webkit.org/show_bug.cgi?id=144784
1448
1449         Broke js/dom/JSON-stringify.html (Requested by kling on
1450         #webkit).
1451
1452         Reverted changeset:
1453
1454         "Optimize serialization of quoted JSON strings."
1455         https://bugs.webkit.org/show_bug.cgi?id=144754
1456         http://trac.webkit.org/changeset/183961
1457
1458 2015-05-07  Filip Pizlo  <fpizlo@apple.com>
1459
1460         GC has trouble with pathologically large array allocations
1461         https://bugs.webkit.org/show_bug.cgi?id=144609
1462
1463         Reviewed by Geoffrey Garen.
1464
1465         The bug was that SlotVisitor::copyLater() would return early for oversize blocks (right
1466         after pinning them), and would skip the accounting. The GC calculates the size of the heap
1467         in tandem with the scan to save time, and that accounting was part of how the GC would
1468         know how big the heap was. The GC would then think that oversize copied blocks use no
1469         memory, and would then mess up its scheduling of the next GC.
1470         
1471         Fixing this bug is harder than it seems. When running an eden GC, we figure out the heap
1472         size by summing the size from the last collection and the size by walking the eden heap.
1473         But this breaks when we eagerly delete objects that the last collection touched. We can do
1474         that in one corner case: copied block reallocation. The old block will be deleted from old
1475         space during the realloc and a new block will be allocated in new space. In order for the
1476         GC to know that the size of old space actually shrank, we need a field to tell us how much
1477         such shrinkage could occur. Since this is a very dirty corner case and it only works for
1478         very particular reasons arising from the special properties of copied space (single owner,
1479         and the realloc is used in places where the compiler already knows that it cannot register
1480         allocate a pointer to the old block), I opted for an equally dirty shrinkage counter
1481         devoted just to this case. It's called bytesRemovedFromOldSpaceDueToReallocation.
1482         
1483         To test this, I needed to add an Option to force a particular RAM size in the GC. This
1484         allows us to write tests that assert that the GC heap size is some value X, without
1485         worrying about machine-to-machine variations due to GC heuristics changing based on RAM
1486         size.
1487
1488         * heap/CopiedSpace.cpp:
1489         (JSC::CopiedSpace::CopiedSpace): Initialize the dirty shrinkage counter.
1490         (JSC::CopiedSpace::tryReallocateOversize): Bump the dirty shrinkage counter.
1491         * heap/CopiedSpace.h:
1492         (JSC::CopiedSpace::takeBytesRemovedFromOldSpaceDueToReallocation): Swap out the counter. Used by the GC when it does its accounting.
1493         * heap/Heap.cpp:
1494         (JSC::Heap::Heap): Allow the user to force the RAM size.
1495         (JSC::Heap::updateObjectCounts): Use the dirty shrinkage counter to good effect. Also, make this code less confusing.
1496         * heap/SlotVisitorInlines.h:
1497         (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
1498         * jsc.cpp: Add size measuring hooks to write the largeish test.
1499         (GlobalObject::finishCreation):
1500         (functionGCAndSweep):
1501         (functionFullGC):
1502         (functionEdenGC):
1503         (functionHeapSize):
1504         * runtime/Options.h:
1505         * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
1506         * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
1507         (foo):
1508         (test):
1509
1510 2015-05-07  Saam Barati  <saambarati1@gmail.com>
1511
1512         Global functions should be initialized as JSFunctions in byte code
1513         https://bugs.webkit.org/show_bug.cgi?id=144178
1514
1515         Reviewed by Geoffrey Garen.
1516
1517         This patch makes the initialization of global functions more explicit by
1518         moving initialization into bytecode. It also prepares JSC for having ES6
1519         style lexical scoping because initializing global functions in bytecode
1520         easily allows global functions to be initialized with the proper scope that
1521         will have access to global lexical variables. Global lexical variables
1522         should be visible to global functions but don't live on the global object.
1523
1524         * bytecode/UnlinkedCodeBlock.cpp:
1525         (JSC::UnlinkedProgramCodeBlock::visitChildren):
1526         * bytecode/UnlinkedCodeBlock.h:
1527         * bytecompiler/BytecodeGenerator.cpp:
1528         (JSC::BytecodeGenerator::generate):
1529         (JSC::BytecodeGenerator::BytecodeGenerator):
1530         * bytecompiler/BytecodeGenerator.h:
1531         * runtime/Executable.cpp:
1532         (JSC::ProgramExecutable::initializeGlobalProperties):
1533         * runtime/JSGlobalObject.cpp:
1534         (JSC::JSGlobalObject::addGlobalVar):
1535         (JSC::JSGlobalObject::addFunction):
1536         * runtime/JSGlobalObject.h:
1537
1538 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
1539
1540         Fix the x86 32bits build
1541
1542         * assembler/X86Assembler.h:
1543
1544 2015-05-07  Benjamin Poulain  <bpoulain@apple.com>
1545
1546         [JSC] Add basic DFG/FTL support for Math.round
1547         https://bugs.webkit.org/show_bug.cgi?id=144725
1548
1549         Reviewed by Filip Pizlo.
1550
1551         This patch adds two optimizations targeting Math.round():
1552         -Add a DFGNode ArithRound corresponding to the intrinsic RoundIntrinsic.
1553         -Change the MacroAssembler to be stricter on how we fail to convert a double
1554          to ingeter. Previously, any number valued zero would fail, now we only
1555          fail for -0.
1556
1557         Since ArithRound speculate it produces int32, the MacroAssembler assembler
1558         part became necessary because zero is a pretty common output of Math.round()
1559         and we would OSR exit a lot (and eventually recompile for doubles).
1560
1561         The implementation itself of the inline Math.round() is exactly the same
1562         as the C function that exists for Math.round(). We can very likely do better
1563         but it is a good start known to be valid and inlining alone alread provides
1564         significant speedups.
1565
1566         * assembler/X86Assembler.h:
1567         (JSC::X86Assembler::movmskpd_rr):
1568         * assembler/MacroAssemblerX86Common.h:
1569         (JSC::MacroAssemblerX86Common::branchConvertDoubleToInt32):
1570         When we have a zero, get the sign bit out of the double and check if is one.
1571
1572         I'll look into doing the same improvement for ARM.
1573
1574         * bytecode/SpeculatedType.cpp:
1575         (JSC::typeOfDoubleRounding):
1576         (JSC::typeOfDoubleFRound): Deleted.
1577         * bytecode/SpeculatedType.h:
1578         * dfg/DFGAbstractInterpreterInlines.h:
1579         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1580         * dfg/DFGByteCodeParser.cpp:
1581         (JSC::DFG::ByteCodeParser::handleIntrinsic):
1582         * dfg/DFGClobberize.h:
1583         (JSC::DFG::clobberize):
1584         * dfg/DFGDoesGC.cpp:
1585         (JSC::DFG::doesGC):
1586         * dfg/DFGFixupPhase.cpp:
1587         (JSC::DFG::FixupPhase::fixupNode):
1588         * dfg/DFGGraph.h:
1589         (JSC::DFG::Graph::roundShouldSpeculateInt32):
1590         (JSC::DFG::Graph::negateShouldSpeculateMachineInt): Deleted.
1591         * dfg/DFGNode.h:
1592         (JSC::DFG::Node::arithNodeFlags):
1593         (JSC::DFG::Node::hasHeapPrediction):
1594         (JSC::DFG::Node::hasArithMode):
1595         * dfg/DFGNodeType.h:
1596         * dfg/DFGPredictionPropagationPhase.cpp:
1597         (JSC::DFG::PredictionPropagationPhase::propagate):
1598         * dfg/DFGSafeToExecute.h:
1599         (JSC::DFG::safeToExecute):
1600         * dfg/DFGSpeculativeJIT.cpp:
1601         (JSC::DFG::SpeculativeJIT::compileArithRound):
1602         * dfg/DFGSpeculativeJIT.h:
1603         * dfg/DFGSpeculativeJIT32_64.cpp:
1604         (JSC::DFG::SpeculativeJIT::compile):
1605         * dfg/DFGSpeculativeJIT64.cpp:
1606         (JSC::DFG::SpeculativeJIT::compile):
1607         * ftl/FTLCapabilities.cpp:
1608         (JSC::FTL::canCompile):
1609         * ftl/FTLIntrinsicRepository.h:
1610         * ftl/FTLLowerDFGToLLVM.cpp:
1611         (JSC::FTL::LowerDFGToLLVM::compileNode):
1612         (JSC::FTL::LowerDFGToLLVM::convertDoubleToInt32):
1613         (JSC::FTL::LowerDFGToLLVM::compileDoubleAsInt32):
1614         (JSC::FTL::LowerDFGToLLVM::compileArithRound):
1615         * ftl/FTLOutput.h:
1616         (JSC::FTL::Output::ceil64):
1617         * jit/ThunkGenerators.cpp:
1618         * runtime/MathCommon.cpp:
1619         * runtime/MathCommon.h:
1620         * runtime/MathObject.cpp:
1621         (JSC::mathProtoFuncRound):
1622         * tests/stress/math-round-basics.js: Added.
1623         (mathRoundOnIntegers):
1624         (mathRoundOnDoubles):
1625         (mathRoundOnBooleans):
1626         (uselessMathRound):
1627         (mathRoundWithOverflow):
1628         (mathRoundConsumedAsDouble):
1629         (mathRoundDoesNotCareAboutMinusZero):
1630         (mathRoundNoArguments):
1631         (mathRoundTooManyArguments):
1632         (testMathRoundOnConstants):
1633         (mathRoundStructTransition):
1634         (Math.round):
1635
1636 2015-05-07  Saam Barati  <saambarati1@gmail.com>
1637
1638         exceptionFuzz tests should explicitly initialize the exceptionFuzz boolean in JavaScript code through a function in jsc.cpp
1639         https://bugs.webkit.org/show_bug.cgi?id=144753
1640
1641         Reviewed by Mark Lam.
1642
1643         This allows the BytecodeGenerator to freely emit startup code that "may"
1644         throw exceptions without worrying that this startup code will trigger
1645         the exceptionFuzz exception. The exceptionFuzz counter will only begin
1646         ticking when the 'enableExceptionFuzz' function is explicitly called in 
1647         the exceptionFuzz tests.
1648
1649         * jsc.cpp:
1650         (GlobalObject::finishCreation):
1651         (functionEnableExceptionFuzz):
1652         * tests/exceptionFuzz/3d-cube.js:
1653         * tests/exceptionFuzz/date-format-xparb.js:
1654         * tests/exceptionFuzz/earley-boyer.js:
1655
1656 2015-05-07  Andreas Kling  <akling@apple.com>
1657
1658         Optimize serialization of quoted JSON strings.
1659         <https://webkit.org/b/144754>
1660
1661         Reviewed by Darin Adler.
1662
1663         Optimized the serialization of quoted strings into JSON by moving the logic into
1664         StringBuilder so it can make smarter decisions about buffering.
1665
1666         12% progression on Kraken/json-stringify-tinderbox (on my Mac Pro.)
1667
1668         * bytecompiler/NodesCodegen.cpp:
1669         (JSC::ObjectPatternNode::toString): Use the new StringBuilder API.
1670
1671         * runtime/JSONObject.h:
1672         * runtime/JSONObject.cpp:
1673         (JSC::Stringifier::Holder::appendNextProperty):
1674         (JSC::appendStringToStringBuilder): Deleted.
1675         (JSC::appendQuotedJSONStringToBuilder): Deleted.
1676         (JSC::Stringifier::appendQuotedString): Deleted.
1677         (JSC::Stringifier::appendStringifiedValue): Moved the bulk of this logic
1678         to StringBuilder and call that from here.
1679
1680 2015-05-07  Yusuke Suzuki  <utatane.tea@gmail.com>
1681
1682         FunctionCallBracketNode should store the base value to the temporary when subscript has assignment
1683         https://bugs.webkit.org/show_bug.cgi?id=144678
1684
1685         Reviewed by Geoffrey Garen.
1686
1687         Currently, FunctionCallBracketNode directly use the RegisterID returned by emitNode.
1688         But if the base part is the local register and the subscript part has assignment to it, the base result is accidentally rewritten.
1689
1690         function t() { var ok = {null: function () { } }; ok[ok = null](); }
1691         t();  // Should not throw error.
1692
1693         This patch takes care about `subscriptHasAssignment`.
1694         By using `emitNodeForLeftHandSide`, when there's assignment to local variables in RHS,
1695         it correctly moves the LHS value to a temporary register.
1696
1697         * bytecompiler/NodesCodegen.cpp:
1698         (JSC::FunctionCallBracketNode::emitBytecode):
1699         * parser/ASTBuilder.h:
1700         (JSC::ASTBuilder::makeFunctionCallNode):
1701         * parser/NodeConstructors.h:
1702         (JSC::FunctionCallBracketNode::FunctionCallBracketNode):
1703         * parser/Nodes.h:
1704         * tests/stress/assignment-in-function-call-bracket-node.js: Added.
1705         (shouldBe):
1706         (shouldBe.):
1707
1708 2015-05-07  Basile Clement  <basile_clement@apple.com>
1709
1710         Unreviewed, add missing braces on a single-line if that got expanded in r183939
1711
1712         * ftl/FTLLowerDFGToLLVM.cpp:
1713         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1714
1715 2015-05-05  Myles C. Maxfield  <mmaxfield@apple.com>
1716
1717         Revert "Introducing the Platform Abstraction Layer (PAL)"
1718         https://bugs.webkit.org/show_bug.cgi?id=144751
1719
1720         Unreviewed.
1721
1722         PAL should be a new target inside WebCore, rather than a top-level folder.
1723
1724         * Configurations/FeatureDefines.xcconfig: Updated
1725
1726 2015-05-07  Basile Clement  <basile_clement@apple.com>
1727
1728         Dumping OSR ExitValue should expand materializations only once
1729         https://bugs.webkit.org/show_bug.cgi?id=144694
1730
1731         Reviewed by Filip Pizlo.
1732
1733         Currently, dumping OSR exit values will print the full materialization
1734         information each time it is encountered. We change it to print only a
1735         brief description (only the materialization's address), and print the
1736         whole set of materializations later on.
1737
1738         This makes the dump less confusing (less likely to think that two
1739         instances of the same materialization are different), and will be a
1740         necessary change if/when we support materialization cycles.
1741
1742         * ftl/FTLCompile.cpp:
1743         (JSC::FTL::mmAllocateDataSection):
1744         * ftl/FTLExitValue.cpp:
1745         (JSC::FTL::ExitValue::dumpInContext):
1746         * ftl/FTLLowerDFGToLLVM.cpp:
1747         (JSC::FTL::LowerDFGToLLVM::buildExitArguments):
1748
1749 2015-05-07  Andreas Kling  <akling@apple.com>
1750
1751         Worker threads leak WeakBlocks (as seen on leaks bot)
1752         <https://webkit.org/b/144721>
1753         <rdar://problem/20848288>
1754
1755         Reviewed by Darin Adler.
1756
1757         Nuke any remaining empty WeakBlocks when the Heap is being torn down.
1758         Trying to peek into these blocks after the VM is dead would be a bug anyway.
1759
1760         This fixes a ~750 KB leak seen on the leaks bot.
1761
1762         * heap/Heap.cpp:
1763         (JSC::Heap::~Heap):
1764
1765 2015-05-05  Geoffrey Garen  <ggaren@apple.com>
1766
1767         Don't branch when accessing the callee
1768         https://bugs.webkit.org/show_bug.cgi?id=144645
1769
1770         Reviewed by Michael Saboff.
1771
1772         The branch was added in <http://trac.webkit.org/changeset/81040> without
1773         explanation.
1774
1775         kling found it to be a performance problem. See <https://webkit.org/b/144586>.
1776
1777         Our theory of access to Registers is that it's up to the client to access
1778         them in the right way. So, let's do that.
1779
1780         * interpreter/CallFrame.h:
1781         (JSC::ExecState::callee):
1782         (JSC::ExecState::setCallee): Call the field object instead of function
1783         because nothing guarantees that it's a function.
1784         * interpreter/ProtoCallFrame.h:
1785         (JSC::ProtoCallFrame::callee):
1786         (JSC::ProtoCallFrame::setCallee):
1787         * interpreter/Register.h:
1788         * runtime/JSObject.h:
1789         (JSC::Register::object): Just do a cast like our other accessors do.
1790         (JSC::Register::operator=):
1791         (JSC::Register::function): Deleted.
1792         (JSC::Register::withCallee): Deleted.
1793
1794 2015-05-07  Dan Bernstein  <mitz@apple.com>
1795
1796         <rdar://problem/19317140> [Xcode] Remove usage of AspenFamily.xcconfig in Source/
1797         https://bugs.webkit.org/show_bug.cgi?id=144727
1798
1799         Reviewed by Darin Adler.
1800
1801         * Configurations/Base.xcconfig: Don’t include AspenFamily.xcconfig, and define
1802         INSTALL_PATH_PREFIX and LD_DYLIB_INSTALL_NAME for the iOS 8.x Simulator.
1803
1804 2015-05-07  Andreas Kling  <akling@apple.com>
1805
1806         Special-case Int32 values in JSON.stringify().
1807         <https://webkit.org/b/144731>
1808
1809         Reviewed by Michael Saboff.
1810
1811         Add a fast path for serializing Int32 values to JSON. This is far faster than dragging
1812         simple integers through the full-blown dtoa() machinery.
1813
1814         ~50% speedup on Kraken/json-stringify-tinderbox.
1815
1816         * runtime/JSONObject.cpp:
1817         (JSC::Stringifier::appendStringifiedValue):
1818
1819 2015-05-06  Ryosuke Niwa  <rniwa@webkit.org>
1820
1821         ToT WebKit crashes while loading ES6 compatibility table
1822         https://bugs.webkit.org/show_bug.cgi?id=144726
1823
1824         Reviewed by Filip Pizlo.
1825
1826         The bug was caused by parseClass superfluously avoiding to build up the string after seeing {.
1827
1828         Always build the identifier here as it could be a method name.
1829
1830         * parser/Parser.cpp:
1831         (JSC::Parser<LexerType>::parseClass):
1832
1833 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
1834
1835         Sane chain and string watchpoints should be set in FixupPhase or the backend rather than WatchpointCollectionPhase
1836         https://bugs.webkit.org/show_bug.cgi?id=144665
1837
1838         Reviewed by Michael Saboff.
1839         
1840         This is a step towards getting rid of WatchpointCollectionPhase. It's also a step towards
1841         extending SaneChain to all indexing shapes.
1842
1843         * dfg/DFGFixupPhase.cpp:
1844         (JSC::DFG::FixupPhase::fixupNode): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
1845         (JSC::DFG::FixupPhase::checkArray): Clarify the need for checking the structure. We often forget why we do this instead of always using CheckArray.
1846         * dfg/DFGSpeculativeJIT.cpp:
1847         (JSC::DFG::SpeculativeJIT::compileGetByValOnString): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
1848         * dfg/DFGWatchpointCollectionPhase.cpp:
1849         (JSC::DFG::WatchpointCollectionPhase::handle): Remove some code.
1850         (JSC::DFG::WatchpointCollectionPhase::handleStringGetByVal): Deleted.
1851         * ftl/FTLLowerDFGToLLVM.cpp:
1852         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt): Set the watchpoints here so that we don't need a case in WatchpointCollectionPhase.
1853
1854 2015-04-02  Myles C. Maxfield  <mmaxfield@apple.com>
1855
1856         Introducing the Platform Abstraction Layer (PAL)
1857         https://bugs.webkit.org/show_bug.cgi?id=143358
1858
1859         Reviewed by Simon Fraser.
1860
1861         * Configurations/FeatureDefines.xcconfig: Updated
1862
1863 2015-05-06  Andreas Kling  <akling@apple.com>
1864
1865         Don't allocate a StringImpl for every Number JSValue in JSON.stringify().
1866         <https://webkit.org/b/144676>
1867
1868         Reviewed by Darin Adler.
1869
1870         We were creating a new String for every number JSValue passing through the JSON stringifier.
1871         These StringImpl allocations were dominating one of the Kraken JSON benchmarks.
1872         Optimize this by using StringBuilder::appendECMAScriptNumber() which uses a stack buffer
1873         for the conversion instead.
1874
1875         13% progression on Kraken/json-stringify-tinderbox.
1876
1877         * runtime/JSONObject.cpp:
1878         (JSC::Stringifier::appendStringifiedValue):
1879
1880 2015-05-06  Commit Queue  <commit-queue@webkit.org>
1881
1882         Unreviewed, rolling out r183847.
1883         https://bugs.webkit.org/show_bug.cgi?id=144691
1884
1885         Caused many assertion failures (Requested by ap on #webkit).
1886
1887         Reverted changeset:
1888
1889         "GC has trouble with pathologically large array allocations"
1890         https://bugs.webkit.org/show_bug.cgi?id=144609
1891         http://trac.webkit.org/changeset/183847
1892
1893 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
1894
1895         PutGlobalVar shouldn't have an unconditional store barrier
1896         https://bugs.webkit.org/show_bug.cgi?id=133104
1897
1898         Reviewed by Benjamin Poulain.
1899         
1900         We don't need a store barrier on PutGlobalVar if the value being stored can be
1901         speculated to not be a cell.
1902
1903         * dfg/DFGFixupPhase.cpp:
1904         (JSC::DFG::FixupPhase::fixupNode):
1905
1906 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
1907
1908         CopiedBlock::reportLiveBytes() should be totally cool with oversize blocks
1909         https://bugs.webkit.org/show_bug.cgi?id=144667
1910
1911         Reviewed by Andreas Kling.
1912         
1913         We are now calling this method for oversize blocks. It had an assertion that indirectly
1914         implied that the block is not oversize, because it was claiming that the number of live
1915         bytes should be smaller than the non-oversize-block size.
1916
1917         * heap/CopiedBlockInlines.h:
1918         (JSC::CopiedBlock::reportLiveBytes):
1919
1920 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
1921
1922         GC has trouble with pathologically large array allocations
1923         https://bugs.webkit.org/show_bug.cgi?id=144609
1924
1925         Reviewed by Mark Lam.
1926
1927         * heap/Heap.cpp:
1928         (JSC::Heap::updateObjectCounts): Make this code less confusing.
1929         * heap/SlotVisitorInlines.h:
1930         (JSC::SlotVisitor::copyLater): The early return for isOversize() was the bug. We still need to report these bytes as live. Otherwise the GC doesn't know that it owns this memory.
1931         * jsc.cpp: Add size measuring hooks to write the largeish test.
1932         (GlobalObject::finishCreation):
1933         (functionGCAndSweep):
1934         (functionFullGC):
1935         (functionEdenGC):
1936         (functionHeapSize):
1937         * tests/stress/new-array-storage-array-with-size.js: Fix this so that it actually allocates ArrayStorage arrays and tests the thing it was supposed to test.
1938         * tests/stress/new-largeish-contiguous-array-with-size.js: Added. This tests what the other test accidentally started testing, but does so without running your system out of memory.
1939         (foo):
1940         (test):
1941
1942 2015-05-05  Filip Pizlo  <fpizlo@apple.com>
1943
1944         FTL SwitchString slow case creates duplicate switch cases
1945         https://bugs.webkit.org/show_bug.cgi?id=144634
1946
1947         Reviewed by Geoffrey Garen.
1948         
1949         The problem of duplicate switches is sufficiently annoying that I fixed the issue and also
1950         added mostly-debug-only asserts to catch such issues earlier.
1951
1952         * bytecode/CallVariant.cpp:
1953         (JSC::variantListWithVariant): Assertion to prevent similar bugs.
1954         * ftl/FTLLowerDFGToLLVM.cpp:
1955         (JSC::FTL::LowerDFGToLLVM::switchStringRecurse): Assertion to prevent similar bugs.
1956         (JSC::FTL::LowerDFGToLLVM::switchStringSlow): This is the bug.
1957         * jit/BinarySwitch.cpp:
1958         (JSC::BinarySwitch::BinarySwitch): Assertion to prevent similar bugs.
1959         * jit/Repatch.cpp:
1960         (JSC::linkPolymorphicCall): Assertion to prevent similar bugs.
1961         * tests/stress/ftl-switch-string-slow-duplicate-cases.js: Added. This tests the FTL SwitchString bug. It was previously crashing every time.
1962         (foo):
1963         (cat):
1964
1965 2015-05-05  Basile Clement  <basile_clement@apple.com>
1966
1967         Fix debug builds after r183812
1968         https://bugs.webkit.org/show_bug.cgi?id=144300
1969
1970         Rubber stamped by Andreas Kling and Filip Pizlo.
1971
1972         hasObjectMaterializationData() didn't treat MaterializeCreateActivation
1973         as having materialization data, which was causing an assertion failure when
1974         sinking CreateActivations on debug builds.
1975
1976         * dfg/DFGNode.h:
1977         (JSC::DFG::Node::hasObjectMaterializationData):
1978
1979 2015-05-04  Basile Clement  <basile_clement@apple.com>
1980
1981         Allow CreateActivation sinking
1982         https://bugs.webkit.org/show_bug.cgi?id=144300
1983
1984         Reviewed by Filip Pizlo.
1985
1986         This pursues the work started in
1987         https://bugs.webkit.org/show_bug.cgi?id=144016 to expand the set of
1988         allocations we are able to sink by allowing sinking of CreateActivation
1989         node.
1990
1991         This is achieved by following closely the way NewObject is currently
1992         sunk: we add a new PhantomCreateActivation node to record the initial
1993         position of the CreateActivation node, new ClosureVarPLoc promoted heap
1994         locations to keep track of the variables put in the activation, and a
1995         new MaterializeCreateActivation node to allocate and populate the sunk
1996         activation.
1997
1998         * dfg/DFGAbstractInterpreterInlines.h:
1999         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2000         * dfg/DFGClobberize.h:
2001         (JSC::DFG::clobberize):
2002         * dfg/DFGDoesGC.cpp:
2003         (JSC::DFG::doesGC):
2004         * dfg/DFGFixupPhase.cpp:
2005         (JSC::DFG::FixupPhase::fixupNode):
2006         * dfg/DFGNode.cpp:
2007         (JSC::DFG::Node::convertToPutClosureVarHint):
2008         * dfg/DFGNode.h:
2009         (JSC::DFG::Node::convertToPhantomCreateActivation):
2010         (JSC::DFG::Node::isActivationAllocation):
2011         (JSC::DFG::Node::isPhantomActivationAllocation):
2012         (JSC::DFG::Node::isPhantomAllocation):
2013         * dfg/DFGNodeType.h:
2014         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2015         (JSC::DFG::ObjectAllocationSinkingPhase::lowerNonReadingOperationsOnPhantomAllocations):
2016         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2017         (JSC::DFG::ObjectAllocationSinkingPhase::createMaterialize):
2018         (JSC::DFG::ObjectAllocationSinkingPhase::populateMaterialize):
2019         * dfg/DFGPredictionPropagationPhase.cpp:
2020         (JSC::DFG::PredictionPropagationPhase::propagate):
2021         * dfg/DFGPromotedHeapLocation.cpp:
2022         (WTF::printInternal):
2023         * dfg/DFGPromotedHeapLocation.h:
2024         * dfg/DFGSafeToExecute.h:
2025         (JSC::DFG::safeToExecute):
2026         * dfg/DFGSpeculativeJIT32_64.cpp:
2027         (JSC::DFG::SpeculativeJIT::compile):
2028         * dfg/DFGSpeculativeJIT64.cpp:
2029         (JSC::DFG::SpeculativeJIT::compile):
2030         * dfg/DFGValidate.cpp:
2031         (JSC::DFG::Validate::validateCPS):
2032         * ftl/FTLCapabilities.cpp:
2033         (JSC::FTL::canCompile):
2034         * ftl/FTLLowerDFGToLLVM.cpp:
2035         (JSC::FTL::LowerDFGToLLVM::compileNode):
2036         (JSC::FTL::LowerDFGToLLVM::compileMaterializeCreateActivation):
2037         * ftl/FTLOperations.cpp:
2038         (JSC::FTL::operationMaterializeObjectInOSR):
2039         * tests/stress/activation-sink-osrexit.js: Added.
2040         (bar):
2041         (foo.set result):
2042         * tests/stress/activation-sink.js: Added.
2043         (bar):
2044
2045 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2046
2047         Unreviewed, fix stale comment.
2048
2049         * tests/mozilla/js1_5/Array/regress-101964.js:
2050
2051 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2052
2053         Large array shouldn't be slow
2054         https://bugs.webkit.org/show_bug.cgi?id=144617
2055
2056         Rubber stamped by Mark Lam.
2057
2058         * tests/mozilla/js1_5/Array/regress-101964.js: 500ms isn't enough in debug mode. We don't care how long this takes so long as we run it to completion. I've raised the limit much higher.
2059
2060 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2061
2062         Large array shouldn't be slow
2063         https://bugs.webkit.org/show_bug.cgi?id=144617
2064
2065         Rubber stamped by Mark Lam.
2066
2067         * tests/mozilla/js1_5/Array/regress-101964.js: Mozilla may have cared about this being fast a decade ago (or more), but we don't care. We've consistently found that an array implementation that punishes this case to get speed on common-case array accesses is better. This should fix some test failures on the bots.
2068
2069 2015-05-04  Commit Queue  <commit-queue@webkit.org>
2070
2071         Unreviewed, rolling out r183789.
2072         https://bugs.webkit.org/show_bug.cgi?id=144620
2073
2074         Causing flakiness on exceptionFuzz tests locally on 32-bit
2075         build (Requested by saamyjoon on #webkit).
2076
2077         Reverted changeset:
2078
2079         "Global functions should be initialized as JSFunctions in byte
2080         code"
2081         https://bugs.webkit.org/show_bug.cgi?id=144178
2082         http://trac.webkit.org/changeset/183789
2083
2084 2015-05-04  Saam Barati  <saambarati1@gmail.com>
2085
2086         Global functions should be initialized as JSFunctions in byte code
2087         https://bugs.webkit.org/show_bug.cgi?id=144178
2088
2089         Reviewed by Geoffrey Garen.
2090
2091         This patch makes the initialization of global functions more explicit by
2092         moving initialization into bytecode. It also prepares JSC for having ES6
2093         style lexical scoping because initializing global functions in bytecode
2094         easily allows global functions to be initialized with the proper scope that
2095         will have access to global lexical variables. Global lexical variables
2096         should be visible to global functions but don't live on the global object.
2097
2098         * bytecode/UnlinkedCodeBlock.cpp:
2099         (JSC::UnlinkedProgramCodeBlock::visitChildren):
2100         * bytecode/UnlinkedCodeBlock.h:
2101         * bytecompiler/BytecodeGenerator.cpp:
2102         (JSC::BytecodeGenerator::generate):
2103         (JSC::BytecodeGenerator::BytecodeGenerator):
2104         * bytecompiler/BytecodeGenerator.h:
2105         * runtime/Executable.cpp:
2106         (JSC::ProgramExecutable::initializeGlobalProperties):
2107         * runtime/JSGlobalObject.cpp:
2108         (JSC::JSGlobalObject::addGlobalVar):
2109         (JSC::JSGlobalObject::addFunction):
2110         * runtime/JSGlobalObject.h:
2111
2112 2015-05-04  Filip Pizlo  <fpizlo@apple.com>
2113
2114         Large array shouldn't be slow
2115         https://bugs.webkit.org/show_bug.cgi?id=144617
2116
2117         Reviewed by Geoffrey Garen.
2118         
2119         Decouple MIN_SPARSE_ARRAY_INDEX, which is the threshold for storing to the sparse map when
2120         you're already using ArrayStorage mode, from the minimul array length required to use
2121         ArrayStorage in a new Array(length) allocation.
2122         
2123         Lift the array allocation length threshold to something very high. If this works, we'll
2124         probably remove that threshold entirely.
2125         
2126         This is a 27% speed-up on JetStream/hash-map. Because run-jsc-benchmarks still can't run
2127         JetStream as a discrete suite, this adds hash-map to LongSpider so that we run it somewhere
2128         for now.
2129
2130         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
2131         * dfg/DFGSpeculativeJIT32_64.cpp:
2132         (JSC::DFG::SpeculativeJIT::compile):
2133         * dfg/DFGSpeculativeJIT64.cpp:
2134         (JSC::DFG::SpeculativeJIT::compile):
2135         * ftl/FTLLowerDFGToLLVM.cpp:
2136         (JSC::FTL::LowerDFGToLLVM::compileNewArrayWithSize):
2137         * runtime/ArrayConventions.h:
2138         * runtime/JSArray.h:
2139         (JSC::JSArray::create):
2140         * runtime/JSGlobalObject.h:
2141         (JSC::constructEmptyArray):
2142         * tests/stress/new-array-storage-array-with-size.js: Skip this test until we fix https://bugs.webkit.org/show_bug.cgi?id=144609.
2143
2144 2015-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>
2145
2146         Add backed intrinsics to private functions exposed with private symbols in global object
2147         https://bugs.webkit.org/show_bug.cgi?id=144545
2148
2149         Reviewed by Darin Adler.
2150
2151         Math.abs and Math.floor have ASM intrinsics And it is further accelerated in DFG/FTL layers.
2152         This patch adds intrinsic to private functions exposed with private symbols in global object,
2153         @floor and @abs.
2154
2155         * runtime/JSGlobalObject.cpp:
2156         (JSC::JSGlobalObject::init):
2157         * runtime/JSGlobalObjectFunctions.cpp:
2158         (JSC::globalPrivateFuncAbs): Deleted.
2159         (JSC::globalPrivateFuncFloor): Deleted.
2160         * runtime/MathObject.cpp:
2161         * runtime/MathObject.h:
2162         * tests/stress/array-from-abs-and-floor.js: Added.
2163         (target1):
2164         (target2):
2165         (target3):
2166
2167 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
2168
2169         [cmake] ARM related build system cleanup
2170         https://bugs.webkit.org/show_bug.cgi?id=144566
2171
2172         Reviewed by Darin Adler.
2173
2174         * CMakeLists.txt:
2175
2176 2015-05-04  Andreas Kling  <akling@apple.com>
2177
2178         Optimize WeakBlock's "reap" and "visit" operations.
2179         <https://webkit.org/b/144585>
2180
2181         Reviewed by Geoffrey Garen.
2182
2183         WeakBlock was using Heap::isLive(void*) to determine the liveness of weak pointees.
2184         That function was really written with conservative roots marking in mind, and will do a bunch
2185         of sanity and bounds checks.
2186
2187         For weaks, we know that the pointer will have been a valid cell pointer into a block
2188         of appropriate cell size, so we can skip a lot of the checks.
2189
2190         We now keep a pointer to the MarkedBlock in each WeakBlock. That way we no longer have to do
2191         MarkedBlock::blockFor() for every single cell when iterating.
2192
2193         Note that a WeakBlock's MarkedBlock pointer becomes null when we detach a logically empty
2194         WeakBlock from its WeakSet and transfer ownership to Heap. At that point, the block will never
2195         be pointing to any live cells, and the only operation that will run on the block is sweep().
2196
2197         Finally, MarkedBlock allows liveness queries in three states: Marked, Retired, and Allocated.
2198         In Allocated state, all cells are reported as live. This state will reset to Marked on next GC.
2199         This patch uses that knowledge to avoid branching on the MarkedBlock's state for every cell.
2200
2201         This is a ~3x speedup of visit() and a ~2x speedup of reap() on Dromaeo/dom-modify, netting
2202         what looks like a 1% speedup locally.
2203
2204         * heap/MarkedBlock.cpp:
2205         (JSC::MarkedBlock::MarkedBlock): Pass *this to the WeakSet's ctor.
2206
2207         * heap/MarkedBlock.h:
2208         (JSC::MarkedBlock::isMarkedOrNewlyAllocated): Added, stripped-down version of isLive() when the
2209         block's state is known to be either Marked or Retired.
2210
2211         (JSC::MarkedBlock::isAllocated): Added, tells WeakBlock it's okay to skip reap/visit since isLive()
2212         would report that all cells are live anyway.
2213
2214         * heap/WeakBlock.cpp:
2215         (JSC::WeakBlock::create):
2216         (JSC::WeakBlock::WeakBlock): Stash a MarkedBlock* on each WeakBlock.
2217
2218         (JSC::WeakBlock::visit):
2219         (JSC::WeakBlock::reap): Optimized these two to avoid a bunch of pointer arithmetic and branches.
2220
2221         * heap/WeakBlock.h:
2222         (JSC::WeakBlock::disconnectMarkedBlock): Added.
2223         * heap/WeakSet.cpp:
2224         (JSC::WeakSet::sweep): Call the above when removing a WeakBlock from WeakSet and transferring
2225         ownership to Heap until it can die peacefully.
2226
2227         (JSC::WeakSet::addAllocator):
2228         * heap/WeakSet.h:
2229         (JSC::WeakSet::WeakSet): Give WeakSet a MarkedBlock& for passing on to WeakBlocks.
2230
2231 2015-05-04  Basile Clement  <basile_clement@apple.com>
2232
2233         Allocation sinking is prohibiting the creation of phis between a Phantom object and its materialization
2234         https://bugs.webkit.org/show_bug.cgi?id=144587
2235
2236         Rubber stamped by Filip Pizlo.
2237
2238         When sinking object allocations, we ensure in
2239         determineMaterializationPoints that whenever an allocation is
2240         materialized on a path to a block, it is materialized in all such
2241         paths. Thus when running the SSA calculator to place Phis in
2242         placeMaterializationPoints, we can't encounter a situation where some
2243         Upsilons are referring to a materialization while others are referring
2244         to the phantom object.
2245
2246         This replaces the code that was adding a materialization late in
2247         placeMaterializationPoints to handle that case by an assertion that it
2248         does not happen, which will make
2249         https://bugs.webkit.org/show_bug.cgi?id=143073 easier to implement.
2250
2251         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2252         (JSC::DFG::ObjectAllocationSinkingPhase::placeMaterializationPoints):
2253
2254 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
2255
2256         Extending undefined in class syntax should throw a TypeError
2257         https://bugs.webkit.org/show_bug.cgi?id=144284
2258
2259         Reviewed by Darin Adler.
2260
2261         The bug was caused by op_eq_null evaluating to true when compared to undefined.
2262         Explicitly check op_eq_undefined first to detect the case where we're extending undefined.
2263
2264         We also had bogus test cases checked in class-syntax-extends.html. This patch also fixes them.
2265
2266         * bytecompiler/NodesCodegen.cpp:
2267         (JSC::ClassExprNode::emitBytecode):
2268
2269 2015-05-04  Ryosuke Niwa  <rniwa@webkit.org>
2270
2271         new super should be a syntax error
2272         https://bugs.webkit.org/show_bug.cgi?id=144282
2273
2274         Reviewed by Joseph Pecoraro.
2275
2276         Disallow "new super" as ES6 spec doesn't allow this.
2277
2278         * parser/Parser.cpp:
2279         (JSC::Parser<LexerType>::parseMemberExpression):
2280
2281 2015-05-04  Saam Barati  <saambarati1@gmail.com>
2282
2283         JSCallbackObject does not maintain symmetry between accesses for getOwnPropertySlot and put
2284         https://bugs.webkit.org/show_bug.cgi?id=144265
2285
2286         Reviewed by Geoffrey Garen.
2287
2288         JSCallbackObject will defer to a parent's implementation of getOwnPropertySlot
2289         for a static function if the parent has that property slot. JSCallbackObject::put 
2290         did not maintain this symmetry of also calling ::put on the parent if the parent 
2291         has the property. We should ensure that this symmetry exists.
2292
2293         * API/JSCallbackObjectFunctions.h:
2294         (JSC::JSCallbackObject<Parent>::put):
2295         * API/tests/testapi.c:
2296         * API/tests/testapi.js:
2297         (globalStaticFunction2):
2298         (this.globalStaticFunction2):
2299         (iAmNotAStaticFunction):
2300         (this.iAmNotAStaticFunction):
2301
2302 2015-05-04  Andreas Kling  <akling@apple.com>
2303
2304         Make ExecState::vm() branchless in release builds.
2305         <https://webkit.org/b/144586>
2306
2307         Reviewed by Geoffrey Garen.
2308
2309         Avoid null checking the ExecState's callee() before getting the
2310         VM from it. The code was already dereferencing it anyway, since we
2311         know it's not gonna be null.
2312
2313         * runtime/JSCellInlines.h:
2314         (JSC::ExecState::vm):
2315
2316 2015-05-04  Basile Clement  <basile_clement@apple.com>
2317
2318         Object allocation not sinking properly through CheckStructure
2319         https://bugs.webkit.org/show_bug.cgi?id=144465
2320
2321         Reviewed by Filip Pizlo.
2322
2323         Currently, sinking an allocation through a CheckStructure will
2324         completely ignore all structure checking, which is obviously wrong.
2325
2326         A CheckStructureImmediate node type was present for that purpose, but
2327         the CheckStructures were not properly replaced.  This ensures that
2328         CheckStructure nodes are replaced by CheckStructureImmediate nodes when
2329         sunk through, and that structure checking happens correctly.
2330
2331         * dfg/DFGNode.h:
2332         (JSC::DFG::Node::convertToCheckStructureImmediate): Added.
2333         (JSC::DFG::Node::hasStructureSet):
2334         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2335         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
2336         * ftl/FTLLowerDFGToLLVM.cpp:
2337         (JSC::FTL::LowerDFGToLLVM::compileCheckStructure):
2338         (JSC::FTL::LowerDFGToLLVM::compileCheckStructureImmediate):
2339         (JSC::FTL::LowerDFGToLLVM::checkStructure):
2340         * tests/stress/sink_checkstructure.js: Added.
2341         (foo):
2342
2343 2015-05-01  Geoffrey Garen  <ggaren@apple.com>
2344
2345         REGRESSION(r183570): jslib-traverse-jquery is 22% slower
2346         https://bugs.webkit.org/show_bug.cgi?id=144476
2347
2348         Reviewed by Sam Weinig.
2349
2350         jslib-traverse-jquery is now 31% faster than its unregressed baseline.
2351
2352         The jQuery algorithm for sorting DOM nodes is so pathologically slow that,
2353         to my knowledge, the topic of how to optimize it is not covered in any
2354         literature about sorting.
2355
2356         On the slowest jQuery sorting test -- prevAll -- our new
2357         Array.prototype.sort, compared to its predecessor, performed 12% fewer
2358         comparisons and requireed 10X less overhead per comparison. Yet, it was
2359         slower.
2360
2361         It was slower because it inadvertantly increased the average cost of the
2362         comparison function by 2X. jQuery uses compareDocumentPosition to compare
2363         DOM nodes, and compareDocumentPosition(a, b) is O(N) in the distance
2364         required to traverse backwards from b to a. In prevAll, we encounter the
2365         worst case for merge sort of compareDocumentPosition: A long list of DOM
2366         nodes in mostly reverse order. In this case, merge sort will sequentially
2367         compareDocumentPosition(a, b), where a is not reachable backwards from
2368         b, and therefore compareDocumentPosition will traverse the whole sibling
2369         list.
2370
2371         The solution is simple enough: Call compareDocumentPosition(b, a) instead.
2372
2373         This is a pretty silly thing to do, but it is harmless, and jQuery is
2374         popular, so let's do it.
2375
2376         We do not risk suffering the same problem in reverse when sorting a long
2377         list of DOM nodes in forward order. (We still have a 37% speedup on the
2378         nextAll benchmark.) The reason is that merge sort performs 2X fewer
2379         comparisons when the list is already sorted, so we can worry less about
2380         the cost of each comparison.
2381
2382         A fully principled soultion to this problem would probably do something
2383         like Python's timsort, which special-cases ordered ranges to perform
2384         only O(n) comparisons. But that would contradict our original
2385         goal of just having something simple that works.
2386
2387         Another option is for elements to keep a compareDocumentPosition cache,
2388         like a node list cache, which allows you to determine the absolute
2389         position of a node using a hash lookup. I will leave this as an exercise
2390         for kling.
2391
2392         * builtins/Array.prototype.js:
2393         (sort.merge): Compare in an order that is favorable to a comparator
2394         that calls compareDocumentPosition.
2395
2396 2015-05-04  Csaba Osztrogonác  <ossy@webkit.org>
2397
2398         [cmake] Fix generate-js-builtins related incremental build issue
2399         https://bugs.webkit.org/show_bug.cgi?id=144094
2400
2401         Reviewed by Michael Saboff.
2402
2403         * CMakeLists.txt: Generated JSCBuiltins.<cpp|h> should depend on Source/JavaScriptCore/builtins directory.
2404         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
2405         * DerivedSources.make:
2406         Pass input directory to generate-js-builtins instead of Source/JavaScriptCore/builtins/*.js.
2407         * generate-js-builtins: Accept input files and input directory too.
2408
2409 2015-05-03  Simon Fraser  <simon.fraser@apple.com>
2410
2411         Make some static data const
2412         https://bugs.webkit.org/show_bug.cgi?id=144552
2413
2414         Reviewed by Andreas Kling.
2415         
2416         Turn characterSetInfo into const data.
2417
2418         * yarr/YarrCanonicalizeUCS2.cpp:
2419         * yarr/YarrCanonicalizeUCS2.h:
2420
2421 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
2422
2423         TypeOf should be fast
2424         https://bugs.webkit.org/show_bug.cgi?id=144396
2425
2426         Reviewed by Geoffrey Garen.
2427         
2428         Adds comprehensive support for fast typeof to the optimizing JITs. Calls into the runtime
2429         are only used for very exotic objects - they must have either the MasqueradesAsUndefined or
2430         TypeOfShouldCallGetCallData type flags set. All other cases are handled inline.
2431         
2432         This means optimizing IsObjectOrNull, IsFunction, and TypeOf - all node types that used to
2433         rely heavily on C++ calls to fulfill their function.
2434         
2435         Because TypeOf is now so fast, we no longer need to do any speculations on this node.
2436         
2437         In the FTL, we take this further by querying AI for each branch in the TypeOf decision tree.
2438         This means that if the TypeOf is dominated by any type checks, we will automatically prune
2439         out cases that are redundant.
2440         
2441         This patch anticipates the addition of SwitchTypeOf or something like that. So, the TypeOf
2442         code generation is designed to be reusable.
2443         
2444         This is a speed-up on most typeof benchmarks. But, it is a slow-down on benchmarks that take
2445         the exotic call trap hook. That hook is now in a deeper slow path than before.
2446
2447         * CMakeLists.txt:
2448         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2449         * JavaScriptCore.xcodeproj/project.pbxproj:
2450         * dfg/DFGClobberize.h:
2451         (JSC::DFG::clobberize): TypeOf was pure all along, but we failed to realize this.
2452         * dfg/DFGFixupPhase.cpp:
2453         (JSC::DFG::FixupPhase::fixupNode):
2454         * dfg/DFGHeapLocation.cpp:
2455         (WTF::printInternal):
2456         * dfg/DFGHeapLocation.h:
2457         * dfg/DFGOperations.cpp:
2458         * dfg/DFGOperations.h:
2459         * dfg/DFGSpeculativeJIT.cpp:
2460         (JSC::DFG::SpeculativeJIT::compileIsObjectOrNull):
2461         (JSC::DFG::SpeculativeJIT::compileIsFunction):
2462         (JSC::DFG::SpeculativeJIT::compileTypeOf):
2463         * dfg/DFGSpeculativeJIT.h:
2464         (JSC::DFG::SpeculativeJIT::blessedBooleanResult):
2465         (JSC::DFG::SpeculativeJIT::callOperation):
2466         * dfg/DFGSpeculativeJIT32_64.cpp:
2467         (JSC::DFG::SpeculativeJIT::compile):
2468         * dfg/DFGSpeculativeJIT64.cpp:
2469         (JSC::DFG::SpeculativeJIT::compile):
2470         * ftl/FTLCapabilities.cpp:
2471         (JSC::FTL::canCompile):
2472         * ftl/FTLIntrinsicRepository.h:
2473         * ftl/FTLLowerDFGToLLVM.cpp:
2474         (JSC::FTL::LowerDFGToLLVM::compileNode):
2475         (JSC::FTL::LowerDFGToLLVM::compileIsObjectOrNull):
2476         (JSC::FTL::LowerDFGToLLVM::compileIsFunction):
2477         (JSC::FTL::LowerDFGToLLVM::compileTypeOf):
2478         (JSC::FTL::LowerDFGToLLVM::buildTypeOf): Reusable TypeOf building for the FTL.
2479         (JSC::FTL::LowerDFGToLLVM::isExoticForTypeof):
2480         * ftl/FTLSwitchCase.h:
2481         (JSC::FTL::SwitchCase::SwitchCase):
2482         * jit/AssemblyHelpers.h:
2483         (JSC::AssemblyHelpers::branchIfNotEqual):
2484         (JSC::AssemblyHelpers::branchIfEqual):
2485         (JSC::AssemblyHelpers::branchIfNumber):
2486         (JSC::AssemblyHelpers::branchIfNotNumber):
2487         (JSC::AssemblyHelpers::branchIfBoolean):
2488         (JSC::AssemblyHelpers::branchIfNotBoolean):
2489         (JSC::AssemblyHelpers::boxBooleanPayload):
2490         (JSC::AssemblyHelpers::boxBoolean):
2491         (JSC::AssemblyHelpers::emitTypeOf): Reusable TypeOf building for assembly JITs.
2492         * jit/JITOperations.h:
2493         * runtime/SmallStrings.h:
2494         (JSC::SmallStrings::typeString):
2495         * runtime/TypeofType.cpp: Added.
2496         (WTF::printInternal):
2497         * runtime/TypeofType.h: Added.
2498         * tests/stress/type-of-functions-and-objects.js: Modified this test to give more comprehensive feedback.
2499
2500 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
2501
2502         Unreviewed, add a FIXME referencing https://bugs.webkit.org/show_bug.cgi?id=144527.
2503
2504         * dfg/DFGLICMPhase.cpp:
2505         (JSC::DFG::LICMPhase::attemptHoist):
2506
2507 2015-05-02  Filip Pizlo  <fpizlo@apple.com>
2508
2509         Unreviewed, add FIXMEs referencing https://bugs.webkit.org/show_bug.cgi?id=144524 and
2510         https://bugs.webkit.org/show_bug.cgi?id=144525.
2511
2512         * dfg/DFGLICMPhase.cpp:
2513         (JSC::DFG::LICMPhase::attemptHoist):
2514         * dfg/DFGPhantomInsertionPhase.cpp:
2515
2516 2015-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>
2517
2518         Static property hashtable should only lookup with non-symbol key
2519         https://bugs.webkit.org/show_bug.cgi?id=144438
2520
2521         Reviewed by Darin Adler.
2522
2523         Static property hashtable compares the Identifier's uid
2524         with the normal C string without interning it.
2525         So this comparison is performed in their contents.
2526         As the result, in this comparison, symbol-ness is not considered.
2527
2528         So if accidentally the hash collision occur with the symbol and the string
2529         and they have the same contents, the hash table entry is looked up incorrectly.
2530
2531         * runtime/Lookup.h:
2532         (JSC::HashTable::entry):
2533
2534 2015-05-01  Ryosuke Niwa  <rniwa@webkit.org>
2535
2536         Class syntax should allow string and numeric identifiers for method names
2537         https://bugs.webkit.org/show_bug.cgi?id=144254
2538
2539         Reviewed by Darin Adler.
2540
2541         Added the support for string and numeric identifiers in class syntax.
2542
2543         * parser/Parser.cpp:
2544         (JSC::Parser<LexerType>::parseFunctionInfo): Instead of using ConstructorKind to indicate whether we're
2545         inside a class or not, use the newly added SuperBinding argument instead. ConstructorKind is now None
2546         outside a class constructor as it should be.
2547         (JSC::Parser<LexerType>::parseFunctionDeclaration):
2548         (JSC::Parser<LexerType>::parseClass): No longer expects an identifier at the beginning of every class
2549         element to allow numeric and string method names. For both of those method names, parse it here instead
2550         of parseFunctionInfo since it doesn't support either type. Also pass in SuperBinding::Needed.
2551         (JSC::Parser<LexerType>::parsePropertyMethod): Call parseFunctionInfo with SuperBinding::NotNeeded since
2552         this function is never used to parse a class method.
2553         (JSC::Parser<LexerType>::parseGetterSetter): Pass in superBinding argument to parseFunctionInfo.
2554         (JSC::Parser<LexerType>::parsePrimaryExpression): Call parseFunctionInfo with SuperBinding::NotNeeded.
2555         * parser/Parser.h:
2556         * parser/SyntaxChecker.h:
2557         (JSC::SyntaxChecker::createProperty):
2558
2559 2015-05-01  Filip Pizlo  <fpizlo@apple.com>
2560
2561         FTL should use AI more
2562         https://bugs.webkit.org/show_bug.cgi?id=144500
2563
2564         Reviewed by Oliver Hunt.
2565         
2566         This makes our type check folding even more comprehensive by ensuring that even if the FTL
2567         decides to emit some checks, it will still do another query to the abstract interpreter to
2568         see if the check is necessary. This helps with cases where we decided early on to speculate
2569         one way, but later proved a more specific type of the value in question, and the constant
2570         folder didn't catch it.
2571         
2572         This also makes it more natural to query the abstract interpreter. For example, if you just
2573         want the proven type, you can now say provenType(node) or provenType(edge).
2574
2575         * dfg/DFGArrayMode.cpp:
2576         (JSC::DFG::ArrayMode::alreadyChecked):
2577         * dfg/DFGArrayMode.h:
2578         * ftl/FTLLowerDFGToLLVM.cpp:
2579         (JSC::FTL::LowerDFGToLLVM::compileBooleanToNumber):
2580         (JSC::FTL::LowerDFGToLLVM::compileToThis):
2581         (JSC::FTL::LowerDFGToLLVM::compileValueAdd):
2582         (JSC::FTL::LowerDFGToLLVM::compileArithAddOrSub):
2583         (JSC::FTL::LowerDFGToLLVM::compileArithPow):
2584         (JSC::FTL::LowerDFGToLLVM::compileArithNegate):
2585         (JSC::FTL::LowerDFGToLLVM::compileGetById):
2586         (JSC::FTL::LowerDFGToLLVM::compileCheckArray):
2587         (JSC::FTL::LowerDFGToLLVM::compilePutByVal):
2588         (JSC::FTL::LowerDFGToLLVM::compileToStringOrCallStringConstructor):
2589         (JSC::FTL::LowerDFGToLLVM::compileToPrimitive):
2590         (JSC::FTL::LowerDFGToLLVM::compileStringCharAt):
2591         (JSC::FTL::LowerDFGToLLVM::compileStringCharCodeAt):
2592         (JSC::FTL::LowerDFGToLLVM::compileCompareStrictEq):
2593         (JSC::FTL::LowerDFGToLLVM::compileSwitch):
2594         (JSC::FTL::LowerDFGToLLVM::compileIsBoolean):
2595         (JSC::FTL::LowerDFGToLLVM::compileIsNumber):
2596         (JSC::FTL::LowerDFGToLLVM::compileIsString):
2597         (JSC::FTL::LowerDFGToLLVM::compileIsObject):
2598         (JSC::FTL::LowerDFGToLLVM::compileInstanceOf):
2599         (JSC::FTL::LowerDFGToLLVM::numberOrNotCellToInt32):
2600         (JSC::FTL::LowerDFGToLLVM::baseIndex):
2601         (JSC::FTL::LowerDFGToLLVM::compareEqObjectOrOtherToObject):
2602         (JSC::FTL::LowerDFGToLLVM::typedArrayLength):
2603         (JSC::FTL::LowerDFGToLLVM::boolify):
2604         (JSC::FTL::LowerDFGToLLVM::equalNullOrUndefined):
2605         (JSC::FTL::LowerDFGToLLVM::lowInt32):
2606         (JSC::FTL::LowerDFGToLLVM::lowInt52):
2607         (JSC::FTL::LowerDFGToLLVM::lowCell):
2608         (JSC::FTL::LowerDFGToLLVM::lowBoolean):
2609         (JSC::FTL::LowerDFGToLLVM::lowDouble):
2610         (JSC::FTL::LowerDFGToLLVM::isCellOrMisc):
2611         (JSC::FTL::LowerDFGToLLVM::isNotCellOrMisc):
2612         (JSC::FTL::LowerDFGToLLVM::isNumber):
2613         (JSC::FTL::LowerDFGToLLVM::isNotNumber):
2614         (JSC::FTL::LowerDFGToLLVM::isNotCell):
2615         (JSC::FTL::LowerDFGToLLVM::isCell):
2616         (JSC::FTL::LowerDFGToLLVM::isNotMisc):
2617         (JSC::FTL::LowerDFGToLLVM::isMisc):
2618         (JSC::FTL::LowerDFGToLLVM::isNotBoolean):
2619         (JSC::FTL::LowerDFGToLLVM::isBoolean):
2620         (JSC::FTL::LowerDFGToLLVM::isNotOther):
2621         (JSC::FTL::LowerDFGToLLVM::isOther):
2622         (JSC::FTL::LowerDFGToLLVM::isProvenValue):
2623         (JSC::FTL::LowerDFGToLLVM::isObject):
2624         (JSC::FTL::LowerDFGToLLVM::isNotObject):
2625         (JSC::FTL::LowerDFGToLLVM::isNotString):
2626         (JSC::FTL::LowerDFGToLLVM::isString):
2627         (JSC::FTL::LowerDFGToLLVM::isFunction):
2628         (JSC::FTL::LowerDFGToLLVM::isNotFunction):
2629         (JSC::FTL::LowerDFGToLLVM::speculateObjectOrOther):
2630         (JSC::FTL::LowerDFGToLLVM::speculateStringObjectForStructureID):
2631         (JSC::FTL::LowerDFGToLLVM::speculateNotStringVar):
2632         (JSC::FTL::LowerDFGToLLVM::abstractValue):
2633         (JSC::FTL::LowerDFGToLLVM::provenType):
2634         (JSC::FTL::LowerDFGToLLVM::provenValue):
2635         (JSC::FTL::LowerDFGToLLVM::abstractStructure):
2636
2637 2015-05-01  Martin Robinson  <mrobinson@igalia.com>
2638
2639         USE(...) macro should expect unprefixed variables
2640         https://bugs.webkit.org/show_bug.cgi?id=144454
2641
2642         Reviewed by Daniel Bates.
2643
2644         * CMakeLists.txt: Replace all occurrences WTF_USE with USE.
2645
2646 2015-05-01  Jordan Harband  <ljharb@gmail.com>
2647
2648         String#startsWith/endsWith/includes don't handle Infinity position/endPosition args correctly
2649         https://bugs.webkit.org/show_bug.cgi?id=144314
2650
2651         Reviewed by Darin Adler.
2652
2653         Fixing handling of Infinity position args, per
2654         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.includes
2655         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.startswith
2656         https://people.mozilla.org/~jorendorff/es6-draft.html#sec-string.prototype.endswith
2657
2658         * runtime/StringPrototype.cpp:
2659         (JSC::clampInt32):
2660         (JSC::stringProtoFuncStartsWith):
2661         (JSC::stringProtoFuncEndsWith):
2662         (JSC::stringProtoFuncIncludes):
2663
2664 2015-05-01  Basile Clement  <basile_clement@apple.com>
2665
2666         Math.abs() returns negative
2667         https://bugs.webkit.org/show_bug.cgi?id=137827
2668
2669         Reviewed by Michael Saboff.
2670
2671         Math.abs() on doubles was mistakenly assumed by the DFG AI to be the
2672         identity function.
2673
2674         * dfg/DFGAbstractInterpreterInlines.h:
2675         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2676         * tests/stress/math-abs-positive.js: Added, was previously failing.
2677         (foo):
2678
2679 2015-05-01  Basile Clement  <basile_clement@apple.com>
2680
2681         Function allocation sinking shouldn't be performed on singleton functions
2682         https://bugs.webkit.org/show_bug.cgi?id=144166
2683
2684         Reviewed by Geoffrey Garen.
2685
2686         Function allocations usually are free of any other side effects, but
2687         this is not the case for allocations performed while the underlying
2688         FunctionExecutable is still a singleton (as this allogation will fire
2689         watchpoints invalidating code that depends on it being a singleton).
2690         As the object allocation sinking phase assumes object allocation is
2691         free of side-effects, sinking these allocations is not correct.
2692
2693         This also means that when materializing a function allocation on OSR
2694         exit, that function's executable will never be a singleton, and we don't have
2695         to worry about its watchpoint, allowing us to use
2696         JSFunction::createWithInvalidatedRellocationWatchpoint instead of
2697         JSFunction::create.
2698
2699         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2700         (JSC::DFG::ObjectAllocationSinkingPhase::handleNode):
2701         * ftl/FTLOperations.cpp:
2702         (JSC::FTL::operationMaterializeObjectInOSR):
2703
2704 2015-04-30  Jon Davis  <jond@apple.com>
2705
2706         Web Inspector: console should show an icon for console.info() messages
2707         https://bugs.webkit.org/show_bug.cgi?id=18530
2708
2709         Reviewed by Timothy Hatcher.
2710
2711         * inspector/ConsoleMessage.cpp:
2712         (Inspector::messageLevelValue):
2713         * inspector/protocol/Console.json:
2714         * runtime/ConsoleClient.cpp:
2715         (JSC::appendMessagePrefix):
2716         * runtime/ConsolePrototype.cpp:
2717         (JSC::ConsolePrototype::finishCreation):
2718         (JSC::consoleProtoFuncInfo):
2719         * runtime/ConsoleTypes.h:
2720
2721 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
2722
2723         Move all of the branchIs<type> helpers from SpeculativeJIT into AssemblyHelpers
2724         https://bugs.webkit.org/show_bug.cgi?id=144462
2725
2726         Reviewed by Geoffrey Garen and Mark Lam.
2727         
2728         At some point we started adding representation-agnostic helpers for doing common type tests.
2729         We added some in SpeculativeJIT, and then some in AssemblyHelpers. Prior to this change,
2730         they had overlapping powers, though SpeculativeJIT was a bit better.
2731         
2732         This removes SpeculativeJIT's helpers and strengthens AssemblyHelpers' helpers. This is
2733         better because now all of these helpers can be used in all of the assembly-based JITs, not
2734         just the DFG. It also settles on what I find to be a slightly better naming convention.
2735         For example where we previously would have said branchIsString, now we say
2736         branchIfString. Similarly, branchNotString becomes branchIfNotString.
2737
2738         * dfg/DFGSpeculativeJIT.cpp:
2739         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectEquality):
2740         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
2741         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
2742         (JSC::DFG::SpeculativeJIT::compileInstanceOf):
2743         (JSC::DFG::SpeculativeJIT::compileStringToUntypedEquality):
2744         (JSC::DFG::SpeculativeJIT::compileStringIdentToNotStringVarEquality):
2745         (JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
2746         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
2747         (JSC::DFG::SpeculativeJIT::speculateObject):
2748         (JSC::DFG::SpeculativeJIT::speculateObjectOrOther):
2749         (JSC::DFG::SpeculativeJIT::speculateString):
2750         (JSC::DFG::SpeculativeJIT::speculateNotStringVar):
2751         (JSC::DFG::SpeculativeJIT::speculateNotCell):
2752         (JSC::DFG::SpeculativeJIT::speculateOther):
2753         (JSC::DFG::SpeculativeJIT::emitSwitchChar):
2754         (JSC::DFG::SpeculativeJIT::emitSwitchString):
2755         (JSC::DFG::SpeculativeJIT::branchIsObject): Deleted.
2756         (JSC::DFG::SpeculativeJIT::branchNotObject): Deleted.
2757         (JSC::DFG::SpeculativeJIT::branchIsString): Deleted.
2758         (JSC::DFG::SpeculativeJIT::branchNotString): Deleted.
2759         * dfg/DFGSpeculativeJIT.h:
2760         * dfg/DFGSpeculativeJIT32_64.cpp:
2761         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
2762         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
2763         (JSC::DFG::SpeculativeJIT::emitCall):
2764         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2765         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
2766         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
2767         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
2768         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
2769         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
2770         (JSC::DFG::SpeculativeJIT::compile):
2771         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
2772         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
2773         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
2774         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
2775         * dfg/DFGSpeculativeJIT64.cpp:
2776         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompareNull):
2777         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranchNull):
2778         (JSC::DFG::SpeculativeJIT::fillSpeculateCell):
2779         (JSC::DFG::SpeculativeJIT::compileObjectEquality):
2780         (JSC::DFG::SpeculativeJIT::compileObjectToObjectOrOtherEquality):
2781         (JSC::DFG::SpeculativeJIT::compilePeepHoleObjectToObjectOrOtherEquality):
2782         (JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot):
2783         (JSC::DFG::SpeculativeJIT::emitObjectOrOtherBranch):
2784         (JSC::DFG::SpeculativeJIT::compile):
2785         (JSC::DFG::SpeculativeJIT::writeBarrier):
2786         (JSC::DFG::SpeculativeJIT::branchIsCell): Deleted.
2787         (JSC::DFG::SpeculativeJIT::branchNotCell): Deleted.
2788         (JSC::DFG::SpeculativeJIT::branchIsOther): Deleted.
2789         (JSC::DFG::SpeculativeJIT::branchNotOther): Deleted.
2790         * jit/AssemblyHelpers.h:
2791         (JSC::AssemblyHelpers::branchIfCell):
2792         (JSC::AssemblyHelpers::branchIfOther):
2793         (JSC::AssemblyHelpers::branchIfNotOther):
2794         (JSC::AssemblyHelpers::branchIfObject):
2795         (JSC::AssemblyHelpers::branchIfNotObject):
2796         (JSC::AssemblyHelpers::branchIfType):
2797         (JSC::AssemblyHelpers::branchIfNotType):
2798         (JSC::AssemblyHelpers::branchIfString):
2799         (JSC::AssemblyHelpers::branchIfNotString):
2800         (JSC::AssemblyHelpers::branchIfSymbol):
2801         (JSC::AssemblyHelpers::branchIfNotSymbol):
2802         (JSC::AssemblyHelpers::branchIfFunction):
2803         (JSC::AssemblyHelpers::branchIfNotFunction):
2804         (JSC::AssemblyHelpers::branchIfEmpty):
2805         (JSC::AssemblyHelpers::branchIsEmpty): Deleted.
2806         (JSC::AssemblyHelpers::branchIfCellNotObject): Deleted.
2807         * jit/JITPropertyAccess.cpp:
2808         (JSC::JIT::emitScopedArgumentsGetByVal):
2809
2810 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
2811
2812         js/regress/is-string-fold-tricky.html and js/regress/is-string-fold.html are crashing
2813         https://bugs.webkit.org/show_bug.cgi?id=144463
2814
2815         Reviewed by Benjamin Poulain.
2816         
2817         Fixup phase was super cleverly folding an IsString(@x) when @x is predicted SpecString
2818         into a Check(String:@x) followed by JSConstant(true). Then in these tests the
2819         ValueAdd(IsString(@x), @stuff) would try to turn this into an integer add by cleverly
2820         converting the boolean into an integer. But as part of doing that, it would try to
2821         short-circuit any profiling by leveraging the fact that the IsString is now a constant,
2822         and it would try to figure out if the addition might overflow. Part of that logic
2823         involved checking if the immediate is either a boolean or a sufficiently small integer.
2824         But: it would check if it's a sufficiently small integer before checking if it was a
2825         boolean, so it would try to call asNumber() on the boolean.
2826         
2827         All of this cleverness was very deliberate, but apparently the @stuff + booleanConstant
2828         case was previously never hit until I wrote these tests, and so we never knew that
2829         calling asNumber() on a boolean was wrong.
2830         
2831         The fix is super simple: the expression should just check for boolean first.
2832         
2833         This bug was benign in release builds. JSValue::asNumber() on a boolean would return
2834         garbage, and that's OK, since we'd take the boolean case anyway.
2835
2836         * dfg/DFGGraph.h:
2837         (JSC::DFG::Graph::addImmediateShouldSpeculateInt32):
2838
2839 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
2840
2841         Unreviewed, add a FIXME comment referencing https://bugs.webkit.org/show_bug.cgi?id=144458.
2842
2843         * jit/JITOperations.cpp:
2844
2845 2015-04-30  Filip Pizlo  <fpizlo@apple.com>
2846
2847         Add a comment clarifying the behavior and semantics of getCallData/getConstructData, in
2848         particular that they cannot change their minds and may be called from compiler threads.
2849
2850         Rubber stamped by Geoffrey Garen.
2851
2852         * runtime/JSCell.h:
2853
2854 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
2855
2856         DFG Is<Blah> versions of TypeOf should fold based on proven input type
2857         https://bugs.webkit.org/show_bug.cgi?id=144409
2858
2859         Reviewed by Geoffrey Garen.
2860         
2861         We were missing some obvious folding opportunities here. I don't know how this affects real
2862         code, but in general, we like to ensure that our constant folding is comprehensive. So this
2863         is more about placating my static analysis OCD than anything else.
2864         
2865         I added a bunch of speed/correctness tests for this in LayoutTests/js/regress.
2866
2867         * dfg/DFGAbstractInterpreterInlines.h:
2868         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2869
2870 2015-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
2871
2872         Use the default hash value for Symbolized StringImpl
2873         https://bugs.webkit.org/show_bug.cgi?id=144347
2874
2875         Reviewed by Darin Adler.
2876
2877         Before this patch, symbolized StringImpl* has a special hash value
2878         to avoid the hash collision with the other normal StringImpl*.
2879         I guess that it is introduced when private symbols are introduced.
2880         However, it prevents using symbolized StringImpl* in the other place
2881         For example, using it as WTFString cause a problem because of its special hash value.
2882
2883         When only using private symbols, they are not exposed to the outside of JSC,
2884         so we can handle it carefully. But now, it's extended to symbols.
2885         So I think storing a special hash value in StringImpl* causes an error.
2886
2887         To avoid this, I propose using the usual hash value in symbolized StringImpl*.
2888         And to provide significantly different hash value when using it as symbol,
2889         store the additional hash value in symbolized StringImpl*. It is used when
2890         the hash value is required by IdentifierRepHash.
2891
2892         * runtime/Identifier.h:
2893         (JSC::IdentifierRepHash::hash):
2894         * runtime/Lookup.h:
2895         (JSC::HashTable::entry):
2896         * runtime/PropertyMapHashTable.h:
2897         (JSC::PropertyTable::find):
2898         (JSC::PropertyTable::get):
2899         * runtime/Structure.cpp:
2900         (JSC::PropertyTable::checkConsistency):
2901
2902 2015-04-29  Benjamin Poulain  <bpoulain@apple.com>
2903
2904         [JSC] Remove RageConvert array conversion
2905         https://bugs.webkit.org/show_bug.cgi?id=144433
2906
2907         Reviewed by Filip Pizlo.
2908
2909         RageConvert was causing a subtle bug that was hitting the Kraken crypto tests
2910         pretty hard:
2911         -The indexing types shows that the array access varies between Int32 and DoubleArray.
2912         -ArrayMode::fromObserved() decided to use the most generic type: DoubleArray.
2913          An Arrayify node would convert the Int32 to that type.
2914         -Somewhere, a GetByVal or PutByVal would have the flag NodeBytecodeUsesAsInt. That
2915          node would use RageConvert instead of Convert.
2916         -The Arrayify for that GetByVal with RageConvert would not convert the array to
2917          Contiguous.
2918         -All the following array access that do not have the flag NodeBytecodeUsesAsInt would
2919          now expect a DoubleArray and always get a Contiguous Array. The CheckStructure
2920          fail systematically and we never get to run the later code.
2921
2922         Getting rid of RageConvert fixes the problem and does not seems to have any
2923         negative side effect on other benchmarks.
2924
2925         The improvments on Kraken are:
2926             -stanford-crypto-aes: definitely 1.0915x faster.
2927             -stanford-crypto-pbkdf2: definitely 1.2446x faster.
2928             -stanford-crypto-sha256-iterative: definitely 1.0544x faster.
2929
2930         * dfg/DFGAbstractInterpreterInlines.h:
2931         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2932         * dfg/DFGArrayMode.cpp:
2933         (JSC::DFG::ArrayMode::refine):
2934         (JSC::DFG::arrayConversionToString):
2935         * dfg/DFGArrayMode.h:
2936         * dfg/DFGArrayifySlowPathGenerator.h:
2937         * dfg/DFGFixupPhase.cpp:
2938         (JSC::DFG::FixupPhase::fixupNode):
2939         * dfg/DFGOperations.cpp:
2940         * dfg/DFGOperations.h:
2941         * dfg/DFGPredictionPropagationPhase.cpp:
2942         (JSC::DFG::PredictionPropagationPhase::propagate):
2943         * dfg/DFGTypeCheckHoistingPhase.cpp:
2944         (JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
2945         * ftl/FTLLowerDFGToLLVM.cpp:
2946         (JSC::FTL::LowerDFGToLLVM::compileArrayifyToStructure):
2947         * runtime/JSObject.cpp:
2948         (JSC::JSObject::convertDoubleToContiguous):
2949         (JSC::JSObject::ensureContiguousSlow):
2950         (JSC::JSObject::genericConvertDoubleToContiguous): Deleted.
2951         (JSC::JSObject::rageConvertDoubleToContiguous): Deleted.
2952         (JSC::JSObject::rageEnsureContiguousSlow): Deleted.
2953         * runtime/JSObject.h:
2954         (JSC::JSObject::rageEnsureContiguous): Deleted.
2955
2956 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
2957
2958         Gracefully handle missing auto pause key on remote inspector setup
2959         https://bugs.webkit.org/show_bug.cgi?id=144411
2960
2961         Reviewed by Timothy Hatcher.
2962
2963         * inspector/remote/RemoteInspector.mm:
2964         (Inspector::RemoteInspector::receivedSetupMessage):
2965
2966 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
2967
2968         NodeList has issues with Symbol and empty string
2969         https://bugs.webkit.org/show_bug.cgi?id=144310
2970
2971         Reviewed by Darin Adler.
2972
2973         * runtime/PropertyName.h:
2974         (JSC::PropertyName::isSymbol):
2975         Helper to check if the PropertyName is a string or symbol property.
2976
2977 2015-04-29  Alex Christensen  <achristensen@webkit.org>
2978
2979         Fix non-cygwin incremental builds on Windows.
2980         https://bugs.webkit.org/show_bug.cgi?id=143264
2981
2982         Reviewed by Brent Fulgham.
2983
2984         * generate-js-builtins:
2985         Remove stale headers before calling os.rename to replace them.
2986
2987 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
2988
2989         JSTypeInfo should have an inline type flag to indicate of getCallData() has been overridden
2990         https://bugs.webkit.org/show_bug.cgi?id=144397
2991
2992         Reviewed by Andreas Kling.
2993         
2994         Add the flag to JSTypeInfo. It's an inline flag so that it's fast to query. Slap the flag on
2995         callback objects and internal functions. Modify the TypeOf operation to use this flag to avoid
2996         making a getCallData() call if it isn't necessary.
2997
2998         * API/JSCallbackObject.h:
2999         * runtime/InternalFunction.h:
3000         * runtime/JSTypeInfo.h:
3001         (JSC::TypeInfo::typeOfShouldCallGetCallData):
3002         * runtime/Operations.cpp:
3003         (JSC::jsTypeStringForValue):
3004         * tests/stress/type-of-functions-and-objects.js: Added.
3005         (foo):
3006         (bar):
3007         (baz):
3008         (fuzz):
3009         (expect):
3010         (test):
3011
3012 2015-04-28  Geoffrey Garen  <ggaren@apple.com>
3013
3014         It shouldn't take 1846 lines of code and 5 FIXMEs to sort an array.
3015         https://bugs.webkit.org/show_bug.cgi?id=144013
3016
3017         Reviewed by Mark Lam.
3018
3019         This patch implements Array.prototype.sort in JavaScript, removing the
3020         C++ implementations. It is simpler and less error-prone to express our
3021         operations in JavaScript, which provides memory safety, exception safety,
3022         and recursion safety.
3023
3024         The performance result is mixed, but net positive in my opinion. It's
3025         difficult to enumerate all the results, since we used to have so many
3026         different sorting modes, and there are lots of different data patterns
3027         across which you might want to measure sorting. Suffice it to say:
3028
3029             (*) The benchmarks we track are faster or unchanged.
3030
3031             (*) Sorting random input using a comparator -- which we think is
3032             common -- is 3X faster.
3033
3034             (*) Sorting random input in a non-array object -- which jQuery does
3035             -- is 4X faster.
3036
3037             (*) Sorting random input in a compact array of integers using a
3038             trivial pattern-matchable comparator is 2X *slower*.
3039
3040         * builtins/Array.prototype.js:
3041         (sort.min):
3042         (sort.stringComparator):
3043         (sort.compactSparse): Special case compaction for sparse arrays because
3044         we don't want to hang when sorting new Array(BIG).
3045
3046         (sort.compact):
3047         (sort.merge):
3048         (sort.mergeSort): Use merge sort because it's a reasonably efficient
3049         stable sort. We have evidence that some sites depend on stable sort,
3050         even though the ES6 spec does not mandate it. (See
3051         <http://trac.webkit.org/changeset/33967>.)
3052
3053         This is a textbook implementation of merge sort with three optimizations:
3054
3055             (1) Use iteration instead of recursion;
3056
3057             (2) Use array subscripting instead of array copying in order to
3058             create logical sub-lists without creating physical sub-lists;
3059
3060             (3) Swap src and dst at each iteration instead of copying src into
3061             dst, and only copy src into the subject array at the end if src is
3062             not the subject array.
3063
3064         (sort.inflate):
3065         (sort.comparatorSort):
3066         (sort): Sort in JavaScript for the win.
3067
3068         * builtins/BuiltinExecutables.cpp:
3069         (JSC::BuiltinExecutables::createExecutableInternal): Allow non-private
3070         names so we can use helper functions.
3071
3072         * bytecode/CodeBlock.h:
3073         (JSC::CodeBlock::isNumericCompareFunction): Deleted.
3074         * bytecode/UnlinkedCodeBlock.cpp:
3075         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
3076         * bytecode/UnlinkedCodeBlock.h:
3077         (JSC::UnlinkedCodeBlock::setIsNumericCompareFunction): Deleted.
3078         (JSC::UnlinkedCodeBlock::isNumericCompareFunction): Deleted.
3079         * bytecompiler/BytecodeGenerator.cpp:
3080         (JSC::BytecodeGenerator::setIsNumericCompareFunction): Deleted.
3081         * bytecompiler/BytecodeGenerator.h:
3082         * bytecompiler/NodesCodegen.cpp:
3083         (JSC::FunctionNode::emitBytecode): We don't do this special casing based
3084         on pattern matching anymore. This was mainly an optimization to avoid 
3085         the overhead of calling from C++ to JS, which we now avoid by
3086         sorting in JS.
3087
3088         * heap/Heap.cpp:
3089         (JSC::Heap::markRoots):
3090         (JSC::Heap::pushTempSortVector): Deleted.
3091         (JSC::Heap::popTempSortVector): Deleted.
3092         (JSC::Heap::visitTempSortVectors): Deleted.
3093         * heap/Heap.h: We don't have temp sort vectors anymore because we sort
3094         in JavaScript using a normal JavaScript array for our temporary storage.
3095
3096         * parser/Parser.cpp:
3097         (JSC::Parser<LexerType>::parseInner): Allow capturing so we can use
3098         helper functions.
3099
3100         * runtime/ArrayPrototype.cpp:
3101         (JSC::isNumericCompareFunction): Deleted.
3102         (JSC::attemptFastSort): Deleted.
3103         (JSC::performSlowSort): Deleted.
3104         (JSC::arrayProtoFuncSort): Deleted.
3105
3106         * runtime/CommonIdentifiers.h: New strings used by sort.
3107
3108         * runtime/JSArray.cpp:
3109         (JSC::compareNumbersForQSortWithInt32): Deleted.
3110         (JSC::compareNumbersForQSortWithDouble): Deleted.
3111         (JSC::compareNumbersForQSort): Deleted.
3112         (JSC::compareByStringPairForQSort): Deleted.
3113         (JSC::JSArray::sortNumericVector): Deleted.
3114         (JSC::JSArray::sortNumeric): Deleted.
3115         (JSC::ContiguousTypeAccessor::getAsValue): Deleted.
3116         (JSC::ContiguousTypeAccessor::setWithValue): Deleted.
3117         (JSC::ContiguousTypeAccessor::replaceDataReference): Deleted.
3118         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::getAsValue): Deleted.
3119         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::setWithValue): Deleted.
3120         (JSC::ContiguousTypeAccessor<ArrayWithDouble>::replaceDataReference): Deleted.
3121         (JSC::JSArray::sortCompactedVector): Deleted.
3122         (JSC::JSArray::sort): Deleted.
3123         (JSC::AVLTreeAbstractorForArrayCompare::get_less): Deleted.
3124         (JSC::AVLTreeAbstractorForArrayCompare::set_less): Deleted.
3125         (JSC::AVLTreeAbstractorForArrayCompare::get_greater): Deleted.
3126         (JSC::AVLTreeAbstractorForArrayCompare::set_greater): Deleted.
3127         (JSC::AVLTreeAbstractorForArrayCompare::get_balance_factor): Deleted.
3128         (JSC::AVLTreeAbstractorForArrayCompare::set_balance_factor): Deleted.
3129         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_key): Deleted.
3130         (JSC::AVLTreeAbstractorForArrayCompare::compare_key_node): Deleted.
3131         (JSC::AVLTreeAbstractorForArrayCompare::compare_node_node): Deleted.
3132         (JSC::AVLTreeAbstractorForArrayCompare::null): Deleted.
3133         (JSC::JSArray::sortVector): Deleted.
3134         (JSC::JSArray::compactForSorting): Deleted.
3135         * runtime/JSArray.h:
3136
3137         * runtime/JSGlobalObject.cpp:
3138         (JSC::JSGlobalObject::init):
3139         * runtime/ObjectConstructor.cpp:
3140         (JSC::ObjectConstructor::finishCreation): Provide some builtins used
3141         by sort.
3142
3143 2015-04-29  Mark Lam  <mark.lam@apple.com>
3144
3145         Safari WebKit crash when loading Google Spreadsheet.
3146         https://bugs.webkit.org/show_bug.cgi?id=144020
3147
3148         Reviewed by Filip Pizlo.
3149
3150         The bug is that the object allocation sinking phase did not account for a case
3151         where a property of a sunken object is only initialized on one path and not
3152         another.  As a result, on the path where the property is not initialized, we'll
3153         encounter an Upsilon with a BottomValue (which is not allowed by definition).
3154
3155         The fix is to use a JSConstant(undefined) as the bottom value instead (of
3156         BottomValue).  If the property is uninitialized, it should still be accessible
3157         and have the value undefined.
3158
3159         * dfg/DFGObjectAllocationSinkingPhase.cpp:
3160         (JSC::DFG::ObjectAllocationSinkingPhase::promoteSunkenFields):
3161         * tests/stress/object-allocation-sinking-with-uninitialized-property-on-one-path.js: Added.
3162         (foo):
3163         (foo2):
3164
3165 2015-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
3166
3167         REGRESSION (r183373): ASSERT failed in wtf/SHA1.h
3168         https://bugs.webkit.org/show_bug.cgi?id=144257
3169
3170         Reviewed by Darin Adler.
3171
3172         SHA1 is used to calculate CodeBlockHash.
3173         To calculate hash value, we pass the source code UTF-8 CString to SHA1::addBytes.
3174         However, the source code can contain null character.
3175         So when performing `strlen` on the source code's CString, it returns the incorrect length.
3176         In SHA1::addBytes, there's assertion `input.length() == strlen(string)` and it fails.
3177
3178         In the template-literal-syntax.js, we perform `eval` with the script contains "\0".
3179         As the result, `strlen(string)` accidentally shortened by the contained "\0", and assertion fails.
3180
3181         CString will be changed not to contain a null-character[1]. However, inserting the assertion here
3182         is not correct. Because
3183
3184         1. If CString should not contain a null character, this should be asserted in CString side instead of SHA1::addBytes.
3185         2. If CString can contain a null character, this assertion becomes incorrect.
3186
3187         So this patch just drops the assertion.
3188
3189         In the current implementation, we once convert the entire source code to the newly allocated
3190         UTF-8 string and pass it to the SHA1 processing. However, this is memory consuming.
3191         Ideally, we should stream the decoded bytes into the SHA1 processing iteratively.
3192         We'll implement it in the separate patch[2].
3193
3194         [1]: https://bugs.webkit.org/show_bug.cgi?id=144339
3195         [2]: https://bugs.webkit.org/show_bug.cgi?id=144263
3196
3197         * tests/stress/eval-script-contains-null-character.js: Added.
3198         (shouldBe):
3199         (test):
3200         * tests/stress/template-literal-line-terminators.js:
3201         * tests/stress/template-literal-syntax.js:
3202         * tests/stress/template-literal.js:
3203
3204 2015-04-29  Filip Pizlo  <fpizlo@apple.com>
3205
3206         Evict IsEnvironmentRecord from inline type flags
3207         https://bugs.webkit.org/show_bug.cgi?id=144398
3208
3209         Reviewed by Mark Lam and Michael Saboff.
3210         
3211         In https://bugs.webkit.org/show_bug.cgi?id=144397, we'll need an extra bit in the inline
3212         type flags. This change picks the least important inline type flag - IsEnvironmentRecord -
3213         and evicts it into the out-of-line type flags. This change has no performance implications
3214         because we never even accessed IsEnvironmentRecord via the StructureIDBlob. The only place
3215         where we access it at all is in String.prototype.repeat, and there we already load the
3216         structure anyway.
3217
3218         * runtime/JSTypeInfo.h:
3219         (JSC::TypeInfo::implementsHasInstance):
3220         (JSC::TypeInfo::structureIsImmortal):
3221         (JSC::TypeInfo::isEnvironmentRecord):
3222
3223 2015-04-29  Darin Adler  <darin@apple.com>
3224
3225         [ES6] Implement Unicode code point escapes
3226         https://bugs.webkit.org/show_bug.cgi?id=144377
3227
3228         Reviewed by Antti Koivisto.
3229
3230         * parser/Lexer.cpp: Moved the UnicodeHexValue class in here from
3231         the header. Made it a non-member class so it doesn't need to be part
3232         of a template. Made it use UChar32 instead of int for the value to
3233         make it clearer what goes into this class.
3234         (JSC::ParsedUnicodeEscapeValue::isIncomplete): Added. Replaces the
3235         old type() function.
3236         (JSC::Lexer<CharacterType>::parseUnicodeEscape): Renamed from
3237         parseFourDigitUnicodeHex and added support for code point escapes.
3238         (JSC::isLatin1): Added an overload for UChar32.
3239         (JSC::isIdentStart): Changed this to take UChar32; no caller tries
3240         to call it with a UChar, so no need to overload for that type for now.
3241         (JSC::isNonLatin1IdentPart): Changed argument type to UChar32 for clarity.
3242         Also added FIXME about a subtle ES6 change that we might want to make later.
3243         (JSC::isIdentPart): Changed this to take UChar32; no caller tries
3244         to call it with a UChar, so no need to overload for that type for now.
3245         (JSC::isIdentPartIncludingEscapeTemplate): Made this a template so that we
3246         don't need to repeat the code twice. Added code to handle code point escapes.
3247         (JSC::isIdentPartIncludingEscape): Call the template instead of having the
3248         code in line.
3249         (JSC::Lexer<CharacterType>::recordUnicodeCodePoint): Added.
3250         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase): Made small tweaks and
3251         updated to call parseUnicodeEscape instead of parseFourDigitUnicodeHex.
3252         (JSC::Lexer<CharacterType>::parseComplexEscape): Call parseUnicodeEscape
3253         instead of parseFourDigitUnicodeHex. Move the code to handle "\u" before
3254         the code that handles the escapes, since the code point escape code now
3255         consumes characters while parsing rather than peeking ahead. Test case
3256         covers this: Symptom would be that "\u{" would evaluate to "u" instead of
3257         giving a syntax error.
3258
3259         * parser/Lexer.h: Updated for above changes.
3260
3261         * runtime/StringConstructor.cpp:
3262         (JSC::stringFromCodePoint): Use ICU's UCHAR_MAX_VALUE instead of writing
3263         out 0x10FFFF; clearer this way.
3264
3265 2015-04-29  Martin Robinson  <mrobinson@igalia.com>
3266
3267         [CMake] [GTK] Organize and clean up unused CMake variables
3268         https://bugs.webkit.org/show_bug.cgi?id=144364
3269
3270         Reviewed by Gyuyoung Kim.
3271
3272         * PlatformGTK.cmake: Add variables specific to this project.
3273
3274 2015-04-28  Filip Pizlo  <fpizlo@apple.com>
3275
3276         TypeOf should return SpecStringIdent and the DFG should know this
3277         https://bugs.webkit.org/show_bug.cgi?id=144376
3278
3279         Reviewed by Andreas Kling.
3280         
3281         Make TypeOf return atomic strings. That's a simple change in SmallStrings.
3282         
3283         Make the DFG know this and use it for optimization. This makes Switch(TypeOf) a bit less
3284         bad.
3285
3286         * dfg/DFGAbstractInterpreterInlines.h:
3287         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3288         * dfg/DFGAbstractValue.cpp:
3289         (JSC::DFG::AbstractValue::setType):
3290         * dfg/DFGAbstractValue.h:
3291         (JSC::DFG::AbstractValue::setType):
3292         * dfg/DFGInPlaceAbstractState.cpp:
3293         (JSC::DFG::InPlaceAbstractState::initialize):
3294         * dfg/DFGPredictionPropagationPhase.cpp:
3295         (JSC::DFG::PredictionPropagationPhase::propagate):
3296         * runtime/SmallStrings.cpp:
3297         (JSC::SmallStrings::initialize):
3298         * tests/stress/switch-typeof-indirect.js: Added.
3299         (bar):
3300         (foo):
3301         (test):
3302         * tests/stress/switch-typeof-slightly-indirect.js: Added.
3303         (foo):
3304         (test):
3305         * tests/stress/switch-typeof.js: Added.
3306         (foo):
3307         (test):
3308
3309 2015-04-29  Joseph Pecoraro  <pecoraro@apple.com>
3310
3311         REGRESSION(181868): Windows Live SkyDrive cannot open an excel file
3312         https://bugs.webkit.org/show_bug.cgi?id=144373
3313
3314         Reviewed by Darin Adler.
3315
3316         Revert r181868 as it caused a failure on live.com. We can try
3317         re-enabling this exception after we make idl attributes configurable,
3318         which may have prevented this particular failure.
3319
3320         * runtime/ObjectPrototype.cpp:
3321         (JSC::objectProtoFuncDefineGetter):
3322         (JSC::objectProtoFuncDefineSetter):
3323
3324 2015-04-28  Joseph Pecoraro  <pecoraro@apple.com>