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