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