PolymorphicAccess::regenerate() shouldn't have to clone non-generated AccessCases
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-04-12  Filip Pizlo  <fpizlo@apple.com>
2
3         PolymorphicAccess::regenerate() shouldn't have to clone non-generated AccessCases
4         https://bugs.webkit.org/show_bug.cgi?id=156493
5
6         Reviewed by Geoffrey Garen.
7
8         Cloning AccessCases is only necessary if they hold some artifacts that are used by code that
9         they already generated. So, if the state is not Generated, we don't have to bother with
10         cloning them.
11
12         This should speed up PolymorphicAccess regeneration a bit more.
13
14         * bytecode/PolymorphicAccess.cpp:
15         (JSC::AccessCase::commit):
16         (JSC::PolymorphicAccess::regenerate):
17
18 2016-04-13  Mark Lam  <mark.lam@apple.com>
19
20         ES6: Implement String.prototype.split and RegExp.prototype[@@split].
21         https://bugs.webkit.org/show_bug.cgi?id=156013
22
23         Reviewed by Keith Miller.
24
25         Re-landing r199393 now that the shadow chicken crash has been fixed.
26
27         * CMakeLists.txt:
28         * JavaScriptCore.xcodeproj/project.pbxproj:
29         * builtins/GlobalObject.js:
30         (speciesConstructor):
31         * builtins/PromisePrototype.js:
32         - refactored to use the @speciesConstructor internal function.
33
34         * builtins/RegExpPrototype.js:
35         (advanceStringIndex):
36         - refactored from @advanceStringIndexUnicode() to be match the spec.
37           Benchmarks show that there's no advantage in doing the unicode check outside
38           of the advanceStringIndexUnicode part.  So, I simplified the code to match the
39           spec (especially since @@split needs to call advanceStringIndex from more than
40           1 location).
41         (match):
42         - Removed an unnecessary call to @Object because it was already proven above.
43         - Changed to use advanceStringIndex instead of advanceStringIndexUnicode.
44           Again, there's no perf regression for this.
45         (regExpExec):
46         (hasObservableSideEffectsForRegExpSplit):
47         (split):
48         (advanceStringIndexUnicode): Deleted.
49
50         * builtins/StringPrototype.js:
51         (split):
52         - Modified to use RegExp.prototype[@@split].
53
54         * bytecode/BytecodeIntrinsicRegistry.cpp:
55         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
56         (JSC::BytecodeIntrinsicRegistry::lookup):
57         * bytecode/BytecodeIntrinsicRegistry.h:
58         - Added the @@split symbol.
59
60         * runtime/CommonIdentifiers.h:
61         * runtime/ECMAScriptSpecInternalFunctions.cpp: Added.
62         (JSC::esSpecIsConstructor):
63         (JSC::esSpecIsRegExp):
64         * runtime/ECMAScriptSpecInternalFunctions.h: Added.
65
66         * runtime/JSGlobalObject.cpp:
67         (JSC::getGetterById):
68         (JSC::JSGlobalObject::init):
69
70         * runtime/PropertyDescriptor.cpp:
71         (JSC::PropertyDescriptor::setDescriptor):
72         - Removed an assert that is no longer valid.
73
74         * runtime/RegExpObject.h:
75         - Made advanceStringUnicode() public so that it can be re-used by the regexp split
76           fast path.
77
78         * runtime/RegExpPrototype.cpp:
79         (JSC::RegExpPrototype::finishCreation):
80         (JSC::regExpProtoFuncExec):
81         (JSC::regExpProtoFuncSearch):
82         (JSC::advanceStringIndex):
83         (JSC::regExpProtoFuncSplitFast):
84         * runtime/RegExpPrototype.h:
85
86         * runtime/StringObject.h:
87         (JSC::jsStringWithReuse):
88         (JSC::jsSubstring):
89         - Hoisted some utility functions from StringPrototype.cpp so that they can be
90           reused by the regexp split fast path.
91
92         * runtime/StringPrototype.cpp:
93         (JSC::StringPrototype::finishCreation):
94         (JSC::stringProtoFuncSplitFast):
95         (JSC::stringProtoFuncSubstr):
96         (JSC::builtinStringSubstrInternal):
97         (JSC::stringProtoFuncSubstring):
98         (JSC::stringIncludesImpl):
99         (JSC::stringProtoFuncIncludes):
100         (JSC::builtinStringIncludesInternal):
101         (JSC::jsStringWithReuse): Deleted.
102         (JSC::jsSubstring): Deleted.
103         (JSC::stringProtoFuncSplit): Deleted.
104         * runtime/StringPrototype.h:
105
106         * tests/es6.yaml:
107
108 2016-04-13  Mark Lam  <mark.lam@apple.com>
109
110         ShadowChicken::visitChildren() should not visit tailMarkers and throwMarkers.
111         https://bugs.webkit.org/show_bug.cgi?id=156532
112
113         Reviewed by Saam Barati and Filip Pizlo.
114
115         ShadowChicken can store tailMarkers and throwMarkers in its log, specifically in
116         the callee field of a log packet.  However, ShadowChicken::visitChildren()
117         unconditionally visits the callee field of each packet as if they are real
118         objects.  If visitChildren() encounters one of these markers in the log, we get a
119         crash.
120
121         This crash was observed in the v8-v6/v8-regexp.js stress test running with shadow
122         chicken when r199393 landed.  r199393 introduced tail calls to a RegExp split
123         fast path, and the v8-regexp.js test exercised this fast path a lot.  Throw in
124         some timely GCs, and we get a crash party.
125
126         The fix is to have ShadowChicken::visitChildren() filter out the tailMarker and
127         throwMarker.
128
129         Alternatively, if perf is an issue, we can allocate 2 dedicated objects for
130         these markers so that ShadowChicken can continue to visit them.  For now, I'm
131         going with the filter.
132
133         * interpreter/ShadowChicken.cpp:
134         (JSC::ShadowChicken::visitChildren):
135
136 2016-04-13  Yusuke Suzuki  <utatane.tea@gmail.com>
137
138         [ES6] Add @@toStringTag to GeneratorFunction
139         https://bugs.webkit.org/show_bug.cgi?id=156499
140
141         Reviewed by Mark Lam.
142
143         GeneratorFunction.prototype has @@toStringTag property, "GeneratorFunction".
144         https://tc39.github.io/ecma262/#sec-generatorfunction.prototype-@@tostringtag
145
146         * runtime/GeneratorFunctionPrototype.cpp:
147         (JSC::GeneratorFunctionPrototype::finishCreation):
148         * tests/es6.yaml:
149         * tests/es6/well-known_symbols_Symbol.toStringTag_new_built-ins.js: Added.
150         (test):
151
152 2016-04-13  Alberto Garcia  <berto@igalia.com>
153
154         Fix build in glibc-based BSD systems
155         https://bugs.webkit.org/show_bug.cgi?id=156533
156
157         Reviewed by Carlos Garcia Campos.
158
159         Change the order of the #elif conditionals so glibc-based BSD
160         systems (e.g. Debian GNU/kFreeBSD) use the code inside the
161         OS(FREEBSD) blocks.
162
163         * heap/MachineStackMarker.cpp:
164         (JSC::MachineThreads::Thread::Registers::stackPointer):
165         (JSC::MachineThreads::Thread::Registers::framePointer):
166         (JSC::MachineThreads::Thread::Registers::instructionPointer):
167         (JSC::MachineThreads::Thread::Registers::llintPC):
168
169 2016-04-12  Keith Miller  <keith_miller@apple.com>
170
171         Unreviewed undo change from ArrayClass to ArrayWithUndecided, which
172         was not intedend to land with r199397.
173
174         * runtime/ArrayPrototype.h:
175         (JSC::ArrayPrototype::createStructure):
176
177 2016-04-12  Mark Lam  <mark.lam@apple.com>
178
179         Rollout: ES6: Implement String.prototype.split and RegExp.prototype[@@split].
180         https://bugs.webkit.org/show_bug.cgi?id=156013
181
182         Speculative rollout to fix 32-bit shadow-chicken.yaml/tests/v8-v6/v8-regexp.js.shadow-chicken test failure.
183
184         Not reviewed.
185
186         * CMakeLists.txt:
187         * JavaScriptCore.xcodeproj/project.pbxproj:
188         * builtins/GlobalObject.js:
189         (speciesGetter):
190         (speciesConstructor): Deleted.
191         * builtins/PromisePrototype.js:
192         * builtins/RegExpPrototype.js:
193         (advanceStringIndexUnicode):
194         (match):
195         (advanceStringIndex): Deleted.
196         (regExpExec): Deleted.
197         (hasObservableSideEffectsForRegExpSplit): Deleted.
198         (split): Deleted.
199         * builtins/StringPrototype.js:
200         (repeat):
201         (split): Deleted.
202         * bytecode/BytecodeIntrinsicRegistry.cpp:
203         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
204         (JSC::BytecodeIntrinsicRegistry::lookup):
205         * bytecode/BytecodeIntrinsicRegistry.h:
206         * runtime/CommonIdentifiers.h:
207         * runtime/ECMAScriptSpecInternalFunctions.cpp: Removed.
208         * runtime/ECMAScriptSpecInternalFunctions.h: Removed.
209         * runtime/JSGlobalObject.cpp:
210         (JSC::JSGlobalObject::setGlobalThis):
211         (JSC::JSGlobalObject::init):
212         (JSC::getGetterById): Deleted.
213         * runtime/PropertyDescriptor.cpp:
214         (JSC::PropertyDescriptor::setDescriptor):
215         * runtime/RegExpObject.h:
216         (JSC::RegExpObject::offsetOfLastIndexIsWritable):
217         * runtime/RegExpPrototype.cpp:
218         (JSC::RegExpPrototype::finishCreation):
219         (JSC::regExpProtoFuncExec):
220         (JSC::regExpProtoFuncSearch):
221         (JSC::advanceStringIndex): Deleted.
222         (JSC::regExpProtoFuncSplitFast): Deleted.
223         * runtime/RegExpPrototype.h:
224         * runtime/StringObject.h:
225         (JSC::jsStringWithReuse): Deleted.
226         (JSC::jsSubstring): Deleted.
227         * runtime/StringPrototype.cpp:
228         (JSC::StringPrototype::finishCreation):
229         (JSC::jsStringWithReuse):
230         (JSC::jsSubstring):
231         (JSC::substituteBackreferencesSlow):
232         (JSC::splitStringByOneCharacterImpl):
233         (JSC::stringProtoFuncSplit):
234         (JSC::stringProtoFuncSubstr):
235         (JSC::stringProtoFuncSubstring):
236         (JSC::stringProtoFuncEndsWith):
237         (JSC::stringProtoFuncIncludes):
238         (JSC::stringProtoFuncIterator):
239         (JSC::stringProtoFuncSplitFast): Deleted.
240         (JSC::builtinStringSubstrInternal): Deleted.
241         (JSC::stringIncludesImpl): Deleted.
242         (JSC::builtinStringIncludesInternal): Deleted.
243         * runtime/StringPrototype.h:
244         * tests/es6.yaml:
245
246 2016-04-12  Mark Lam  <mark.lam@apple.com>
247
248         Remove 2 unused JSC options.
249         https://bugs.webkit.org/show_bug.cgi?id=156526
250
251         Reviewed by Benjamin Poulain.
252
253         The options JSC_assertICSizing and JSC_dumpFailedICSizing are no longer in use
254         now that we have B3.
255
256         * runtime/Options.h:
257
258 2016-04-12  Keith Miller  <keith_miller@apple.com>
259
260         [ES6] Add support for Symbol.isConcatSpreadable.
261         https://bugs.webkit.org/show_bug.cgi?id=155351
262
263         Reviewed by Saam Barati.
264
265         This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the
266         Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to
267         a builtin performant. First, four new DFG intrinsics were added.
268
269         1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of
270            the Array.isArray function.
271         2) IsJSArray: checks the first child is a JSArray object.
272         3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor.
273         4) CallObjectConstructor: an intrinsic of the Object constructor.
274
275         IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if
276         we are able to prove that the first child is an Array or for ToObject an Object.
277
278         In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy
279         code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and
280         were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and
281         the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this
282         into a contiguous array).
283
284         This patch also adds a new fast path for concat with more than one array argument by using memcpy to append
285         values onto the result array. This works roughly the same as the two array fast path using the same methodology
286         to decide if we can memcpy the other butterfly into the result butterfly.
287
288         Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private
289         name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our
290         dataLog function on it.
291
292         Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a
293         JSValueOperand if the operand's use count is one.
294
295         * JavaScriptCore.xcodeproj/project.pbxproj:
296         * builtins/ArrayPrototype.js:
297         (concatSlowPath):
298         (concat):
299         * bytecode/BytecodeIntrinsicRegistry.cpp:
300         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
301         * bytecode/BytecodeIntrinsicRegistry.h:
302         * dfg/DFGAbstractInterpreterInlines.h:
303         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
304         * dfg/DFGByteCodeParser.cpp:
305         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
306         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
307         * dfg/DFGClobberize.h:
308         (JSC::DFG::clobberize):
309         * dfg/DFGDoesGC.cpp:
310         (JSC::DFG::doesGC):
311         * dfg/DFGFixupPhase.cpp:
312         (JSC::DFG::FixupPhase::fixupNode):
313         * dfg/DFGNodeType.h:
314         * dfg/DFGOperations.cpp:
315         * dfg/DFGOperations.h:
316         * dfg/DFGPredictionPropagationPhase.cpp:
317         (JSC::DFG::PredictionPropagationPhase::propagate):
318         * dfg/DFGSafeToExecute.h:
319         (JSC::DFG::safeToExecute):
320         * dfg/DFGSpeculativeJIT.cpp:
321         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
322         (JSC::DFG::SpeculativeJIT::compileIsJSArray):
323         (JSC::DFG::SpeculativeJIT::compileIsArrayObject):
324         (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor):
325         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
326         * dfg/DFGSpeculativeJIT.h:
327         (JSC::DFG::SpeculativeJIT::callOperation):
328         * dfg/DFGSpeculativeJIT32_64.cpp:
329         (JSC::DFG::SpeculativeJIT::compile):
330         * dfg/DFGSpeculativeJIT64.cpp:
331         (JSC::DFG::SpeculativeJIT::compile):
332         * ftl/FTLCapabilities.cpp:
333         (JSC::FTL::canCompile):
334         * ftl/FTLLowerDFGToB3.cpp:
335         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
336         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
337         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject):
338         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
339         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor):
340         (JSC::FTL::DFG::LowerDFGToB3::isArray):
341         * jit/JITOperations.h:
342         * jsc.cpp:
343         (GlobalObject::finishCreation):
344         (functionDataLogValue):
345         * runtime/ArrayConstructor.cpp:
346         (JSC::ArrayConstructor::finishCreation):
347         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
348         * runtime/ArrayConstructor.h:
349         (JSC::isArrayConstructor):
350         * runtime/ArrayPrototype.cpp:
351         (JSC::ArrayPrototype::finishCreation):
352         (JSC::arrayProtoPrivateFuncIsJSArray):
353         (JSC::moveElements):
354         (JSC::arrayProtoPrivateFuncConcatMemcpy):
355         (JSC::arrayProtoPrivateFuncAppendMemcpy):
356         (JSC::arrayProtoFuncConcat): Deleted.
357         * runtime/ArrayPrototype.h:
358         (JSC::ArrayPrototype::createStructure):
359         * runtime/CommonIdentifiers.h:
360         * runtime/Intrinsic.h:
361         * runtime/JSArray.cpp:
362         (JSC::JSArray::appendMemcpy):
363         (JSC::JSArray::fastConcatWith): Deleted.
364         * runtime/JSArray.h:
365         (JSC::JSArray::createStructure):
366         (JSC::JSArray::fastConcatType): Deleted.
367         * runtime/JSArrayInlines.h: Added.
368         (JSC::JSArray::memCopyWithIndexingType):
369         (JSC::JSArray::canFastCopy):
370         * runtime/JSGlobalObject.cpp:
371         (JSC::JSGlobalObject::init):
372         * runtime/JSType.h:
373         * runtime/ObjectConstructor.h:
374         (JSC::constructObject):
375         * tests/es6.yaml:
376         * tests/stress/array-concat-spread-object.js: Added.
377         (arrayEq):
378         * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
379         (arrayEq):
380         * tests/stress/array-concat-spread-proxy.js: Added.
381         (arrayEq):
382         * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
383         (arrayEq):
384         * tests/stress/array-species-config-array-constructor.js:
385
386 2016-04-12  Saam barati  <sbarati@apple.com>
387
388         Lets not iterate over the constant pool twice every time we link a code block
389         https://bugs.webkit.org/show_bug.cgi?id=156517
390
391         Reviewed by Mark Lam.
392
393         I introduced a second iteration over the constant pool when I implemented
394         block scoping. I did this because we must clone all the symbol tables when
395         we link a CodeBlock. We can just do this cloning when setting the constant
396         registers for the first time. There is no need to iterate over the constant
397         pool a second time.
398
399         * bytecode/CodeBlock.cpp:
400         (JSC::CodeBlock::finishCreation):
401         (JSC::CodeBlock::~CodeBlock):
402         (JSC::CodeBlock::setConstantRegisters):
403         (JSC::CodeBlock::setAlternative):
404         * bytecode/CodeBlock.h:
405         (JSC::CodeBlock::replaceConstant):
406         (JSC::CodeBlock::setConstantRegisters): Deleted.
407
408 2016-04-12  Mark Lam  <mark.lam@apple.com>
409
410         ES6: Implement String.prototype.split and RegExp.prototype[@@split].
411         https://bugs.webkit.org/show_bug.cgi?id=156013
412
413         Reviewed by Keith Miller.
414
415         * CMakeLists.txt:
416         * JavaScriptCore.xcodeproj/project.pbxproj:
417         * builtins/GlobalObject.js:
418         (speciesConstructor):
419         * builtins/PromisePrototype.js:
420         - refactored to use the @speciesConstructor internal function.
421
422         * builtins/RegExpPrototype.js:
423         (advanceStringIndex):
424         - refactored from @advanceStringIndexUnicode() to be match the spec.
425           Benchmarks show that there's no advantage in doing the unicode check outside
426           of the advanceStringIndexUnicode part.  So, I simplified the code to match the
427           spec (especially since @@split needs to call advanceStringIndex from more than
428           1 location).
429         (match):
430         - Removed an unnecessary call to @Object because it was already proven above.
431         - Changed to use advanceStringIndex instead of advanceStringIndexUnicode.
432           Again, there's no perf regression for this.
433         (regExpExec):
434         (hasObservableSideEffectsForRegExpSplit):
435         (split):
436         (advanceStringIndexUnicode): Deleted.
437
438         * builtins/StringPrototype.js:
439         (split):
440         - Modified to use RegExp.prototype[@@split].
441
442         * bytecode/BytecodeIntrinsicRegistry.cpp:
443         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
444         (JSC::BytecodeIntrinsicRegistry::lookup):
445         * bytecode/BytecodeIntrinsicRegistry.h:
446         - Added the @@split symbol.
447
448         * runtime/CommonIdentifiers.h:
449         * runtime/ECMAScriptSpecInternalFunctions.cpp: Added.
450         (JSC::esSpecIsConstructor):
451         (JSC::esSpecIsRegExp):
452         * runtime/ECMAScriptSpecInternalFunctions.h: Added.
453
454         * runtime/JSGlobalObject.cpp:
455         (JSC::getGetterById):
456         (JSC::JSGlobalObject::init):
457
458         * runtime/PropertyDescriptor.cpp:
459         (JSC::PropertyDescriptor::setDescriptor):
460         - Removed an assert that is no longer valid.
461
462         * runtime/RegExpObject.h:
463         - Made advanceStringUnicode() public so that it can be re-used by the regexp split
464           fast path.
465
466         * runtime/RegExpPrototype.cpp:
467         (JSC::RegExpPrototype::finishCreation):
468         (JSC::regExpProtoFuncExec):
469         (JSC::regExpProtoFuncSearch):
470         (JSC::advanceStringIndex):
471         (JSC::regExpProtoFuncSplitFast):
472         * runtime/RegExpPrototype.h:
473
474         * runtime/StringObject.h:
475         (JSC::jsStringWithReuse):
476         (JSC::jsSubstring):
477         - Hoisted some utility functions from StringPrototype.cpp so that they can be
478           reused by the regexp split fast path.
479
480         * runtime/StringPrototype.cpp:
481         (JSC::StringPrototype::finishCreation):
482         (JSC::stringProtoFuncSplitFast):
483         (JSC::stringProtoFuncSubstr):
484         (JSC::builtinStringSubstrInternal):
485         (JSC::stringProtoFuncSubstring):
486         (JSC::stringIncludesImpl):
487         (JSC::stringProtoFuncIncludes):
488         (JSC::builtinStringIncludesInternal):
489         (JSC::jsStringWithReuse): Deleted.
490         (JSC::jsSubstring): Deleted.
491         (JSC::stringProtoFuncSplit): Deleted.
492         * runtime/StringPrototype.h:
493
494         * tests/es6.yaml:
495
496 2016-04-12  Keith Miller  <keith_miller@apple.com>
497
498         AbstractValue should use the result type to filter structures
499         https://bugs.webkit.org/show_bug.cgi?id=156516
500
501         Reviewed by Geoffrey Garen.
502
503         When filtering an AbstractValue with a SpeculatedType we would not use the merged type when
504         filtering out the valid structures (despite what the comment directly above said). This
505         would cause us to crash if our structure-set was Top and the two speculated types were
506         different kinds of cells.
507
508         * dfg/DFGAbstractValue.cpp:
509         (JSC::DFG::AbstractValue::filter):
510         * tests/stress/ai-consistency-filter-cells.js: Added.
511         (get value):
512         (attribute.value.get record):
513         (attribute.attrs.get this):
514         (get foo):
515         (let.thisValue.return.serialize):
516         (let.thisValue.transformFor):
517
518 2016-04-12  Filip Pizlo  <fpizlo@apple.com>
519
520         Unreviewed, remove FIXME for https://bugs.webkit.org/show_bug.cgi?id=156457 and replace it
521         with a comment that describes what we do now.
522
523         * bytecode/PolymorphicAccess.h:
524
525 2016-04-12  Saam barati  <sbarati@apple.com>
526
527         isLocked() assertion broke builds because ConcurrentJITLock isn't always a real lock.
528
529         Rubber-stamped by Filip Pizlo.
530
531         * bytecode/CodeBlock.cpp:
532         (JSC::CodeBlock::resultProfileForBytecodeOffset):
533         (JSC::CodeBlock::ensureResultProfile):
534
535 2016-04-11  Filip Pizlo  <fpizlo@apple.com>
536
537         PolymorphicAccess should buffer AccessCases before regenerating
538         https://bugs.webkit.org/show_bug.cgi?id=156457
539
540         Reviewed by Benjamin Poulain.
541
542         Prior to this change, whenever we added an AccessCase to a PolymorphicAccess, we would
543         regenerate the whole stub. That meant that we'd do O(N^2) work for N access cases.
544
545         One way to fix this is to have each AccessCase generate a stub just for itself, which
546         cascades down to the already-generated cases. But that removes the binary switch
547         optimization, which makes the IC perform great even when there are many cases.
548
549         This change fixes the issue by buffering access cases. When we take slow path and try to add
550         a new case, the StructureStubInfo will usually just buffer the new case without generating
551         new code. We simply guarantee that after we buffer a case, we will take at most
552         Options::repatchBufferingCountdown() slow path calls before generating code for it. That
553         option is currently 7. Taking 7 more slow paths means that we have 7 more opportunities to
554         gather more access cases, or to realize that this IC is too crazy to bother with.
555
556         This change ensures that the DFG still gets the same kind of profiling. This is because the
557         buffered AccessCases are still part of PolymorphicAccess and so are still scanned by
558         GetByIdStatus and PutByIdStatus. The fact that the AccessCases hadn't been generated and so
559         hadn't executed doesn't change much. Mainly, it increases the likelihood that the DFG will
560         see an access case that !couldStillSucceed(). The DFG's existing profile parsing logic can
561         handle this just fine.
562         
563         There are a bunch of algorithmic changes here. StructureStubInfo now caches the set of
564         structures that it has seen as a guard to prevent adding lots of redundant cases, in case
565         we see the same 7 cases after buffering the first one. This cache means we won't wastefully
566         allocate 7 identical AccessCase instances. PolymorphicAccess is now restructured around
567         having separate addCase() and regenerate() calls. That means a bit more moving data around.
568         So far that seems OK for performance, probably since it's O(N) work rather than O(N^2) work.
569         There is room for improvement for future patches, to be sure.
570         
571         This is benchmarking as slightly positive or neutral on JS benchmarks. It's meant to reduce
572         pathologies I saw in page loads.
573
574         * bytecode/GetByIdStatus.cpp:
575         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
576         * bytecode/PolymorphicAccess.cpp:
577         (JSC::PolymorphicAccess::PolymorphicAccess):
578         (JSC::PolymorphicAccess::~PolymorphicAccess):
579         (JSC::PolymorphicAccess::addCases):
580         (JSC::PolymorphicAccess::addCase):
581         (JSC::PolymorphicAccess::visitWeak):
582         (JSC::PolymorphicAccess::dump):
583         (JSC::PolymorphicAccess::commit):
584         (JSC::PolymorphicAccess::regenerate):
585         (JSC::PolymorphicAccess::aboutToDie):
586         (WTF::printInternal):
587         (JSC::PolymorphicAccess::regenerateWithCases): Deleted.
588         (JSC::PolymorphicAccess::regenerateWithCase): Deleted.
589         * bytecode/PolymorphicAccess.h:
590         (JSC::AccessCase::isGetter):
591         (JSC::AccessCase::callLinkInfo):
592         (JSC::AccessGenerationResult::AccessGenerationResult):
593         (JSC::AccessGenerationResult::madeNoChanges):
594         (JSC::AccessGenerationResult::gaveUp):
595         (JSC::AccessGenerationResult::buffered):
596         (JSC::AccessGenerationResult::generatedNewCode):
597         (JSC::AccessGenerationResult::generatedFinalCode):
598         (JSC::AccessGenerationResult::shouldGiveUpNow):
599         (JSC::AccessGenerationResult::generatedSomeCode):
600         (JSC::PolymorphicAccess::isEmpty):
601         (JSC::PolymorphicAccess::size):
602         (JSC::PolymorphicAccess::at):
603         * bytecode/PutByIdStatus.cpp:
604         (JSC::PutByIdStatus::computeForStubInfo):
605         * bytecode/StructureStubInfo.cpp:
606         (JSC::StructureStubInfo::StructureStubInfo):
607         (JSC::StructureStubInfo::addAccessCase):
608         (JSC::StructureStubInfo::reset):
609         (JSC::StructureStubInfo::visitWeakReferences):
610         * bytecode/StructureStubInfo.h:
611         (JSC::StructureStubInfo::considerCaching):
612         (JSC::StructureStubInfo::willRepatch): Deleted.
613         (JSC::StructureStubInfo::willCoolDown): Deleted.
614         * jit/JITOperations.cpp:
615         * jit/Repatch.cpp:
616         (JSC::tryCacheGetByID):
617         (JSC::repatchGetByID):
618         (JSC::tryCachePutByID):
619         (JSC::repatchPutByID):
620         (JSC::tryRepatchIn):
621         (JSC::repatchIn):
622         * runtime/JSCJSValue.h:
623         * runtime/JSCJSValueInlines.h:
624         (JSC::JSValue::putByIndex):
625         (JSC::JSValue::structureOrNull):
626         (JSC::JSValue::structureOrUndefined):
627         * runtime/Options.h:
628
629 2016-04-12  Saam barati  <sbarati@apple.com>
630
631         There is a race with the compiler thread and the main thread with result profiles
632         https://bugs.webkit.org/show_bug.cgi?id=156503
633
634         Reviewed by Filip Pizlo.
635
636         The compiler thread should not be asking for a result
637         profile while the execution thread is creating one.
638         We must guard against such races with a lock.
639
640         * bytecode/CodeBlock.cpp:
641         (JSC::CodeBlock::resultProfileForBytecodeOffset):
642         (JSC::CodeBlock::ensureResultProfile):
643         (JSC::CodeBlock::capabilityLevel):
644         * bytecode/CodeBlock.h:
645         (JSC::CodeBlock::couldTakeSlowCase):
646         (JSC::CodeBlock::numberOfResultProfiles):
647         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
648         (JSC::CodeBlock::ensureResultProfile): Deleted.
649
650 2016-04-12  Commit Queue  <commit-queue@webkit.org>
651
652         Unreviewed, rolling out r199339.
653         https://bugs.webkit.org/show_bug.cgi?id=156505
654
655         memset_s is indeed necessary (Requested by alexchristensen_ on
656         #webkit).
657
658         Reverted changeset:
659
660         "Build fix after r199299."
661         https://bugs.webkit.org/show_bug.cgi?id=155508
662         http://trac.webkit.org/changeset/199339
663
664 2016-04-12  Guillaume Emont  <guijemont@igalia.com>
665
666         MIPS: add MacroAssemblerMIPS::store8(TrustedImm32,ImplicitAddress)
667         https://bugs.webkit.org/show_bug.cgi?id=156481
668
669         This method with this signature is used by r199075, and therefore
670         WebKit doesn't build on MIPS since then.
671
672         Reviewed by Mark Lam.
673
674         * assembler/MacroAssemblerMIPS.h:
675         (JSC::MacroAssemblerMIPS::store8):
676
677 2016-04-12  Saam barati  <sbarati@apple.com>
678
679         We incorrectly parse arrow function expressions
680         https://bugs.webkit.org/show_bug.cgi?id=156373
681
682         Reviewed by Mark Lam.
683
684         This patch removes the notion of "isEndOfArrowFunction".
685         This was a very weird function and it was incorrect.
686         It checked that the arrow functions with concise body
687         grammar production "had a valid ending". "had a valid
688         ending" is in quotes because concise body arrow functions
689         have a valid ending as long as their body has a valid
690         assignment expression. I've removed all notion of this
691         function because it was wrong and was causing us
692         to throw syntax errors on valid programs.
693
694         * parser/Lexer.cpp:
695         (JSC::Lexer<T>::nextTokenIsColon):
696         (JSC::Lexer<T>::lex):
697         (JSC::Lexer<T>::setTokenPosition): Deleted.
698         * parser/Lexer.h:
699         (JSC::Lexer::setIsReparsingFunction):
700         (JSC::Lexer::isReparsingFunction):
701         (JSC::Lexer::lineNumber):
702         * parser/Parser.cpp:
703         (JSC::Parser<LexerType>::parseInner):
704         (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
705         (JSC::Parser<LexerType>::parseFunctionInfo):
706         * parser/Parser.h:
707         (JSC::Parser::matchIdentifierOrKeyword):
708         (JSC::Parser::tokenStart):
709         (JSC::Parser::autoSemiColon):
710         (JSC::Parser::canRecurse):
711         (JSC::Parser::isEndOfArrowFunction): Deleted.
712         (JSC::Parser::setEndOfStatement): Deleted.
713         * tests/stress/arrowfunction-others.js:
714         (testCase):
715         (simpleArrowFunction):
716         (truthy):
717         (falsey):
718
719 2016-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
720
721         [JSC] addStaticGlobals should emit SymbolTableEntry watchpoints to encourage constant folding in DFG
722         https://bugs.webkit.org/show_bug.cgi?id=155110
723
724         Reviewed by Saam Barati.
725
726         `addStaticGlobals` does not emit SymbolTableEntry watchpoints for the added entries.
727         So, all the global variable lookups pointing to these static globals are not converted
728         into constants in DFGBytecodeGenerator: this fact leaves these lookups as GetGlobalVar.
729         Such thing avoids constant folding chance and emits CheckCell for @privateFunction inlining.
730         This operation is pure overhead.
731
732         Static globals are not configurable, and they are typically non-writable.
733         So they are constants in almost all the cases.
734
735         This patch initializes watchpoints for these static globals.
736         These watchpoints allow DFG to convert these nodes into constants in DFG BytecodeParser.
737         These watchpoints includes many builtin operations and `undefined`.
738
739         The microbenchmark, many-foreach-calls shows 5 - 7% improvement since it removes unnecessary CheckCell.
740
741         * bytecode/VariableWriteFireDetail.h:
742         * runtime/JSGlobalObject.cpp:
743         (JSC::JSGlobalObject::addGlobalVar):
744         (JSC::JSGlobalObject::addStaticGlobals):
745         * runtime/JSSymbolTableObject.h:
746         (JSC::symbolTablePutTouchWatchpointSet):
747         (JSC::symbolTablePutInvalidateWatchpointSet):
748         (JSC::symbolTablePut):
749         (JSC::symbolTablePutWithAttributesTouchWatchpointSet): Deleted.
750         * runtime/SymbolTable.h:
751         (JSC::SymbolTableEntry::SymbolTableEntry):
752         (JSC::SymbolTableEntry::operator=):
753         (JSC::SymbolTableEntry::swap):
754
755 2016-04-12  Alex Christensen  <achristensen@webkit.org>
756
757         Build fix after r199299.
758         https://bugs.webkit.org/show_bug.cgi?id=155508
759
760         * jit/ExecutableAllocatorFixedVMPool.cpp:
761         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
762         memset_s is not defined.  __STDC_WANT_LIB_EXT1__ is not defined anywhere.
763         Since the return value is unused and set_constraint_handler_s is never called
764         I'm chaning it to memset.
765
766 2016-04-11  Benjamin Poulain  <bpoulain@apple.com>
767
768         [JSC] B3 can use undefined bits or not defined required bits when spilling
769         https://bugs.webkit.org/show_bug.cgi?id=156486
770
771         Reviewed by Filip Pizlo.
772
773         Spilling had issues when replacing arguments in place.
774
775         The problems are:
776         1) If we have a 32bit stackslot, a x86 instruction could still try to load 64bits from it.
777         2) If we have a 64bit stackslot, Move32 would only set half the bits.
778         3) We were reducing Move to Move32 even if the top bits are read from the stack slot.
779
780         The case 1 appear with something like this:
781             Move32 %tmp0, %tmp1
782             Op64 %tmp1, %tmp2, %tmp3
783         When we spill %tmp1, the stack slot is 32bit, Move32 sets 32bits
784         but Op64 supports addressing for %tmp1. When we substitute %tmp1 in Op64,
785         we are creating a 64bit read for a 32bit stack slot.
786
787         The case 2 is an other common one. If we have:
788             BB#1
789                 Move32 %tmp0, %tmp1
790                 Jump #3
791             BB#2
792                 Op64 %tmp0, %tmp1
793                 Jump #3
794             BB#3
795                 Use64 %tmp1
796
797         We have a stack slot of 64bits. When spilling %tmp1 in #1, we are
798         effectively doing a 32bit store on the stack slot, leaving the top bits undefined.
799
800         Case 3 is pretty much the same as 2 but we create the Move32 ourself
801         because the source is a 32bit with ZDef.
802
803         Case (1) is solved by requiring that the stack slot is at least as large as the largest
804         use/def of that tmp.
805
806         Case (2) and (3) are solved by not replacing a Tmp by an Address if the Def
807         is smaller than the stack slot.
808
809         * b3/air/AirIteratedRegisterCoalescing.cpp:
810         * b3/testb3.cpp:
811         (JSC::B3::testSpillDefSmallerThanUse):
812         (JSC::B3::testSpillUseLargerThanDef):
813         (JSC::B3::run):
814
815 2016-04-11  Brian Burg  <bburg@apple.com>
816
817         Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses
818         https://bugs.webkit.org/show_bug.cgi?id=156407
819         <rdar://problem/25627659>
820
821         Reviewed by Joseph Pecoraro.
822
823         There's no point having these subclasses as they don't save any space.
824         Add a StringImpl to the union and merge some implementations of writeJSON.
825
826         Rename m_data to m_map and explicitly name the union as InspectorValue::m_value.
827         If the value is a string and the string is not empty or null (i.e., it has a
828         StringImpl), then we need to ref() and deref() the string as the InspectorValue
829         is created or destroyed.
830
831         Move uses of the subclass to InspectorValue and delete redundant methods.
832         Now, most InspectorValue methods are non-virtual so they can be templated.
833
834         * bindings/ScriptValue.cpp:
835         (Deprecated::jsToInspectorValue):
836         * inspector/InjectedScriptBase.cpp:
837         (Inspector::InjectedScriptBase::makeCall):
838         Don't used deleted subclasses.
839
840         * inspector/InspectorValues.cpp:
841         (Inspector::InspectorValue::null):
842         (Inspector::InspectorValue::create):
843         (Inspector::InspectorValue::asValue):
844         (Inspector::InspectorValue::asBoolean):
845         (Inspector::InspectorValue::asDouble):
846         (Inspector::InspectorValue::asInteger):
847         (Inspector::InspectorValue::asString):
848         These only need one implementation now.
849
850         (Inspector::InspectorValue::writeJSON):
851         Still a virtual method since Object and Array need their members.
852
853         (Inspector::InspectorObjectBase::InspectorObjectBase):
854         (Inspector::InspectorBasicValue::asBoolean): Deleted.
855         (Inspector::InspectorBasicValue::asDouble): Deleted.
856         (Inspector::InspectorBasicValue::asInteger): Deleted.
857         (Inspector::InspectorBasicValue::writeJSON): Deleted.
858         (Inspector::InspectorString::asString): Deleted.
859         (Inspector::InspectorString::writeJSON): Deleted.
860         (Inspector::InspectorString::create): Deleted.
861         (Inspector::InspectorBasicValue::create): Deleted.
862
863         * inspector/InspectorValues.h:
864         (Inspector::InspectorObjectBase::find):
865         (Inspector::InspectorObjectBase::setBoolean):
866         (Inspector::InspectorObjectBase::setInteger):
867         (Inspector::InspectorObjectBase::setDouble):
868         (Inspector::InspectorObjectBase::setString):
869         (Inspector::InspectorObjectBase::setValue):
870         (Inspector::InspectorObjectBase::setObject):
871         (Inspector::InspectorObjectBase::setArray):
872         (Inspector::InspectorArrayBase::pushBoolean):
873         (Inspector::InspectorArrayBase::pushInteger):
874         (Inspector::InspectorArrayBase::pushDouble):
875         (Inspector::InspectorArrayBase::pushString):
876         (Inspector::InspectorArrayBase::pushValue):
877         (Inspector::InspectorArrayBase::pushObject):
878         (Inspector::InspectorArrayBase::pushArray):
879         Use new factory methods.
880
881         * replay/EncodedValue.cpp:
882         (JSC::ScalarEncodingTraits<bool>::encodeValue):
883         (JSC::ScalarEncodingTraits<double>::encodeValue):
884         (JSC::ScalarEncodingTraits<float>::encodeValue):
885         (JSC::ScalarEncodingTraits<int32_t>::encodeValue):
886         (JSC::ScalarEncodingTraits<int64_t>::encodeValue):
887         (JSC::ScalarEncodingTraits<uint32_t>::encodeValue):
888         (JSC::ScalarEncodingTraits<uint64_t>::encodeValue):
889         * replay/EncodedValue.h:
890         Use new factory methods.
891
892 2016-04-11  Filip Pizlo  <fpizlo@apple.com>
893
894         It should be possible to edit StructureStubInfo without recompiling the world
895         https://bugs.webkit.org/show_bug.cgi?id=156470
896
897         Reviewed by Keith Miller.
898
899         This change makes it less painful to make changes to the IC code. It used to be that any
900         change to StructureStubInfo caused every JIT-related file to get recompiled. Now only a
901         smaller set of files - ones that actually peek into StructureStubInfo - will recompile. This
902         is mainly because CodeBlock.h no longer includes StructureStubInfo.h.
903
904         * bytecode/ByValInfo.h:
905         * bytecode/CodeBlock.cpp:
906         * bytecode/CodeBlock.h:
907         * bytecode/GetByIdStatus.cpp:
908         * bytecode/GetByIdStatus.h:
909         * bytecode/PutByIdStatus.cpp:
910         * bytecode/PutByIdStatus.h:
911         * bytecode/StructureStubInfo.h:
912         (JSC::getStructureStubInfoCodeOrigin):
913         * dfg/DFGByteCodeParser.cpp:
914         * dfg/DFGJITCompiler.cpp:
915         * dfg/DFGOSRExitCompilerCommon.cpp:
916         * dfg/DFGSpeculativeJIT.h:
917         * ftl/FTLLowerDFGToB3.cpp:
918         * ftl/FTLSlowPathCall.h:
919         * jit/IntrinsicEmitter.cpp:
920         * jit/JITInlineCacheGenerator.cpp:
921         * jit/JITInlineCacheGenerator.h:
922         * jit/JITOperations.cpp:
923         * jit/JITPropertyAccess.cpp:
924         * jit/JITPropertyAccess32_64.cpp:
925
926 2016-04-11  Skachkov Oleksandr  <gskachkov@gmail.com>
927
928         Remove NewArrowFunction from DFG IR
929         https://bugs.webkit.org/show_bug.cgi?id=156439
930
931         Reviewed by Saam Barati.
932
933         It seems that NewArrowFunction was left in DFG IR during refactoring by mistake.
934
935         * dfg/DFGAbstractInterpreterInlines.h:
936         * dfg/DFGClobberize.h:
937         (JSC::DFG::clobberize):
938         * dfg/DFGClobbersExitState.cpp:
939         * dfg/DFGDoesGC.cpp:
940         * dfg/DFGFixupPhase.cpp:
941         * dfg/DFGMayExit.cpp:
942         * dfg/DFGNode.h:
943         (JSC::DFG::Node::convertToPhantomNewFunction):
944         * dfg/DFGNodeType.h:
945         * dfg/DFGObjectAllocationSinkingPhase.cpp:
946         * dfg/DFGPredictionPropagationPhase.cpp:
947         * dfg/DFGSafeToExecute.h:
948         * dfg/DFGSpeculativeJIT.cpp:
949         (JSC::DFG::SpeculativeJIT::compileNewFunction):
950         * dfg/DFGSpeculativeJIT32_64.cpp:
951         * dfg/DFGSpeculativeJIT64.cpp:
952         * dfg/DFGStoreBarrierInsertionPhase.cpp:
953         * dfg/DFGStructureRegistrationPhase.cpp:
954         * ftl/FTLCapabilities.cpp:
955         * ftl/FTLLowerDFGToB3.cpp:
956         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
957
958 2016-04-05  Oliver Hunt  <oliver@apple.com>
959
960         Remove compile time define for SEPARATED_HEAP
961         https://bugs.webkit.org/show_bug.cgi?id=155508
962
963         Reviewed by Mark Lam.
964
965         Remove the SEPARATED_HEAP compile time flag. The separated
966         heap is available, but off by default, on x86_64, ARMv7, and
967         ARM64.
968
969         Working through the issues that happened last time essentially
970         required implementing the ARMv7 path for the separated heap
971         just so I could find all the ways it was going wrong.
972
973         We fixed all the logic by making the branch and jump logic in
974         the linker and assemblers take two parameters, the location to
975         write to, and the location we'll actually be writing to. We 
976         need to do this because it's no longer sufficient to compute
977         jumps relative to region the linker is writing to.
978
979         The repatching jump, branch, and call functions only need the
980         executable address as the patching is performed directly using
981         performJITMemcpy function which works in terms of the executable
982         address.
983
984         There is no performance impact on jsc-benchmarks with the separate
985         heap either emabled or disabled.
986
987         * Configurations/FeatureDefines.xcconfig:
988         * assembler/ARM64Assembler.h:
989         (JSC::ARM64Assembler::linkJump):
990         (JSC::ARM64Assembler::linkCall):
991         (JSC::ARM64Assembler::relinkJump):
992         (JSC::ARM64Assembler::relinkCall):
993         (JSC::ARM64Assembler::link):
994         (JSC::ARM64Assembler::linkJumpOrCall):
995         (JSC::ARM64Assembler::linkCompareAndBranch):
996         (JSC::ARM64Assembler::linkConditionalBranch):
997         (JSC::ARM64Assembler::linkTestAndBranch):
998         (JSC::ARM64Assembler::relinkJumpOrCall):
999         * assembler/ARMv7Assembler.h:
1000         (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2):
1001         (JSC::ARMv7Assembler::revertJumpTo_movT3):
1002         (JSC::ARMv7Assembler::link):
1003         (JSC::ARMv7Assembler::linkJump):
1004         (JSC::ARMv7Assembler::relinkJump):
1005         (JSC::ARMv7Assembler::repatchCompact):
1006         (JSC::ARMv7Assembler::replaceWithJump):
1007         (JSC::ARMv7Assembler::replaceWithLoad):
1008         (JSC::ARMv7Assembler::replaceWithAddressComputation):
1009         (JSC::ARMv7Assembler::setInt32):
1010         (JSC::ARMv7Assembler::setUInt7ForLoad):
1011         (JSC::ARMv7Assembler::isB):
1012         (JSC::ARMv7Assembler::isBX):
1013         (JSC::ARMv7Assembler::isMOV_imm_T3):
1014         (JSC::ARMv7Assembler::isMOVT):
1015         (JSC::ARMv7Assembler::isNOP_T1):
1016         (JSC::ARMv7Assembler::isNOP_T2):
1017         (JSC::ARMv7Assembler::linkJumpT1):
1018         (JSC::ARMv7Assembler::linkJumpT2):
1019         (JSC::ARMv7Assembler::linkJumpT3):
1020         (JSC::ARMv7Assembler::linkJumpT4):
1021         (JSC::ARMv7Assembler::linkConditionalJumpT4):
1022         (JSC::ARMv7Assembler::linkBX):
1023         (JSC::ARMv7Assembler::linkConditionalBX):
1024         (JSC::ARMv7Assembler::linkJumpAbsolute):
1025         * assembler/LinkBuffer.cpp:
1026         (JSC::LinkBuffer::copyCompactAndLinkCode):
1027         * assembler/MacroAssemblerARM64.h:
1028         (JSC::MacroAssemblerARM64::link):
1029         * assembler/MacroAssemblerARMv7.h:
1030         (JSC::MacroAssemblerARMv7::link):
1031         * jit/ExecutableAllocator.h:
1032         (JSC::performJITMemcpy):
1033         * jit/ExecutableAllocatorFixedVMPool.cpp:
1034         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
1035         (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
1036         (JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion):
1037         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Deleted.
1038         * runtime/Options.cpp:
1039         (JSC::recomputeDependentOptions):
1040         * runtime/Options.h:
1041
1042 2016-04-10  Filip Pizlo  <fpizlo@apple.com>
1043
1044         Clean up how we reason about the states of AccessCases
1045         https://bugs.webkit.org/show_bug.cgi?id=156454
1046
1047         Reviewed by Mark Lam.
1048         
1049         Currently when we add an AccessCase to a PolymorphicAccess stub, we regenerate the stub.
1050         That means that as we grow a stub to have N cases, we will do O(N^2) generation work. I want
1051         to explore buffering AccessCases so that we can do O(N) generation work instead. But to
1052         before I go there, I want to make sure that the statefulness of AccessCase makes sense. So,
1053         I broke it down into three different states and added assertions about the transitions. I
1054         also broke out a separate operation called AccessCase::commit(), which is the work that
1055         cannot be buffered since there cannot be any JS effects between when the AccessCase was
1056         created and when we do the work in commit().
1057         
1058         This opens up a fairly obvious path to buffering AccessCases: add them to the list without
1059         regenerating. Then when we do eventually trigger regeneration, those cases will get cloned
1060         and generated automagically. This patch doesn't implement this technique yet, but gives us
1061         an opportunity to independently test the scaffolding necessary to do it.
1062
1063         This is perf-neutral on lots of tests.
1064
1065         * bytecode/PolymorphicAccess.cpp:
1066         (JSC::AccessGenerationResult::dump):
1067         (JSC::AccessCase::clone):
1068         (JSC::AccessCase::commit):
1069         (JSC::AccessCase::guardedByStructureCheck):
1070         (JSC::AccessCase::dump):
1071         (JSC::AccessCase::generateWithGuard):
1072         (JSC::AccessCase::generate):
1073         (JSC::AccessCase::generateImpl):
1074         (JSC::PolymorphicAccess::regenerateWithCases):
1075         (JSC::PolymorphicAccess::regenerate):
1076         (WTF::printInternal):
1077         * bytecode/PolymorphicAccess.h:
1078         (JSC::AccessCase::type):
1079         (JSC::AccessCase::state):
1080         (JSC::AccessCase::offset):
1081         (JSC::AccessCase::viaProxy):
1082         (JSC::AccessCase::callLinkInfo):
1083         * bytecode/StructureStubInfo.cpp:
1084         (JSC::StructureStubInfo::addAccessCase):
1085         * bytecode/Watchpoint.h:
1086         * dfg/DFGOperations.cpp:
1087         * jit/Repatch.cpp:
1088         (JSC::repatchGetByID):
1089         (JSC::repatchPutByID):
1090         (JSC::repatchIn):
1091         * runtime/VM.cpp:
1092         (JSC::VM::dumpRegExpTrace):
1093         (JSC::VM::ensureWatchpointSetForImpureProperty):
1094         (JSC::VM::registerWatchpointForImpureProperty):
1095         (JSC::VM::addImpureProperty):
1096         * runtime/VM.h:
1097
1098 2016-04-11  Fujii Hironori  <Hironori.Fujii@jp.sony.com>
1099
1100         [CMake] Make FOLDER property INHERITED
1101         https://bugs.webkit.org/show_bug.cgi?id=156460
1102
1103         Reviewed by Brent Fulgham.
1104
1105         * CMakeLists.txt:
1106         * shell/CMakeLists.txt:
1107         * shell/PlatformWin.cmake:
1108         Set FOLDER property as a directory property not a target property
1109
1110 2016-04-09  Keith Miller  <keith_miller@apple.com>
1111
1112         tryGetById should be supported by the DFG/FTL
1113         https://bugs.webkit.org/show_bug.cgi?id=156378
1114
1115         Reviewed by Filip Pizlo.
1116
1117         This patch adds support for tryGetById in the DFG/FTL. It adds a new DFG node
1118         TryGetById, which acts similarly to the normal GetById DFG node. One key
1119         difference between GetById and TryGetById is that in the LLInt and Baseline
1120         we do not profile the result type. This profiling is unnessary for the current
1121         use case of tryGetById, which is expected to be a strict equality comparision
1122         against a specific object or undefined. In either case other DFG optimizations
1123         will make this equally fast with or without the profiling information.
1124
1125         Additionally, this patch adds new reuse modes for JSValueRegsTemporary that take
1126         an operand and attempt to reuse the registers for that operand if they are free
1127         after the current DFG node.
1128
1129         * bytecode/GetByIdStatus.cpp:
1130         (JSC::GetByIdStatus::computeFromLLInt):
1131         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
1132         * dfg/DFGAbstractInterpreterInlines.h:
1133         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1134         * dfg/DFGByteCodeParser.cpp:
1135         (JSC::DFG::ByteCodeParser::handleGetById):
1136         (JSC::DFG::ByteCodeParser::parseBlock):
1137         * dfg/DFGCapabilities.cpp:
1138         (JSC::DFG::capabilityLevel):
1139         * dfg/DFGClobberize.h:
1140         (JSC::DFG::clobberize):
1141         * dfg/DFGDoesGC.cpp:
1142         (JSC::DFG::doesGC):
1143         * dfg/DFGFixupPhase.cpp:
1144         (JSC::DFG::FixupPhase::fixupNode):
1145         * dfg/DFGNode.h:
1146         (JSC::DFG::Node::hasIdentifier):
1147         * dfg/DFGNodeType.h:
1148         * dfg/DFGPredictionPropagationPhase.cpp:
1149         (JSC::DFG::PredictionPropagationPhase::propagate):
1150         * dfg/DFGSafeToExecute.h:
1151         (JSC::DFG::safeToExecute):
1152         * dfg/DFGSpeculativeJIT.cpp:
1153         (JSC::DFG::SpeculativeJIT::compileTryGetById):
1154         (JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):
1155         * dfg/DFGSpeculativeJIT.h:
1156         (JSC::DFG::GPRTemporary::operator=):
1157         * dfg/DFGSpeculativeJIT32_64.cpp:
1158         (JSC::DFG::SpeculativeJIT::cachedGetById):
1159         (JSC::DFG::SpeculativeJIT::compile):
1160         * dfg/DFGSpeculativeJIT64.cpp:
1161         (JSC::DFG::SpeculativeJIT::cachedGetById):
1162         (JSC::DFG::SpeculativeJIT::compile):
1163         * ftl/FTLCapabilities.cpp:
1164         (JSC::FTL::canCompile):
1165         * ftl/FTLLowerDFGToB3.cpp:
1166         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1167         (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
1168         (JSC::FTL::DFG::LowerDFGToB3::getById):
1169         * jit/JITOperations.cpp:
1170         * jit/JITOperations.h:
1171         * tests/stress/try-get-by-id.js:
1172         (tryGetByIdTextStrict):
1173         (get let):
1174         (let.get createBuiltin):
1175         (get throw):
1176         (getCaller.obj.1.throw.new.Error): Deleted.
1177
1178 2016-04-09  Saam barati  <sbarati@apple.com>
1179
1180         Allocation sinking SSA Defs are allowed to have replacements
1181         https://bugs.webkit.org/show_bug.cgi?id=156444
1182
1183         Reviewed by Filip Pizlo.
1184
1185         Consider the following program and the annotations that explain why
1186         the SSA defs we create in allocation sinking can have replacements.
1187
1188         function foo(a1) {
1189             let o1 = {x: 20, y: 50};
1190             let o2 = {y: 40, o1: o1};
1191             let o3 = {};
1192         
1193             // We're Defing a new variable here, call it o3_field.
1194             // o3_field is defing the value that is the result of 
1195             // a GetByOffset that gets eliminated through allocation sinking.
1196             o3.field = o1.y;
1197         
1198             dontCSE();
1199         
1200             // This control flow is here to not allow the phase to consult
1201             // its local SSA mapping (which properly handles replacements)
1202             // for the value of o3_field.
1203             if (a1) {
1204                 a1 = true; 
1205             } else {
1206                 a1 = false;
1207             }
1208         
1209             // Here, we ask for the reaching def of o3_field, and assert
1210             // it doesn't have a replacement. It does have a replacement
1211             // though. The original Def was the GetByOffset. We replaced
1212             // that GetByOffset with the value of the o1_y variable.
1213             let value = o3.field;
1214             assert(value === 50);
1215         }
1216
1217         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1218         * tests/stress/allocation-sinking-defs-may-have-replacements.js: Added.
1219         (dontCSE):
1220         (assert):
1221         (foo):
1222
1223 2016-04-09  Commit Queue  <commit-queue@webkit.org>
1224
1225         Unreviewed, rolling out r199242.
1226         https://bugs.webkit.org/show_bug.cgi?id=156442
1227
1228         Caused many many leaks (Requested by ap on #webkit).
1229
1230         Reverted changeset:
1231
1232         "Web Inspector: get rid of InspectorBasicValue and
1233         InspectorString subclasses"
1234         https://bugs.webkit.org/show_bug.cgi?id=156407
1235         http://trac.webkit.org/changeset/199242
1236
1237 2016-04-09  Filip Pizlo  <fpizlo@apple.com>
1238
1239         Debug JSC test failure: stress/multi-put-by-offset-reallocation-butterfly-cse.js.ftl-no-cjit-small-pool
1240         https://bugs.webkit.org/show_bug.cgi?id=156406
1241
1242         Reviewed by Saam Barati.
1243
1244         The failure was because the GC ran from within the butterfly allocation call in a put_by_id
1245         transition AccessCase that had to deal with indexing storage. When the GC runs in a call from a stub,
1246         then we need to be extra careful:
1247
1248         1) The GC may reset the IC and delete the stub. So, the stub needs to tell the GC that it might be on
1249            the stack during GC, so that the GC keeps it alive if it's currently running.
1250         
1251         2) If the stub uses (dereferences or stores) some object after the call, then we need to ensure that
1252            the stub routine knows about that object independently of the IC.
1253         
1254         In the case of put_by_id transitions that use a helper to allocate the butterfly, we have both
1255         issues. A long time ago, we had to deal with (2), and we still had code to handle that case, although
1256         it appears to be dead. This change revives that code and glues it together with PolymorphicAccess.
1257
1258         * bytecode/PolymorphicAccess.cpp:
1259         (JSC::AccessCase::alternateBase):
1260         (JSC::AccessCase::doesCalls):
1261         (JSC::AccessCase::couldStillSucceed):
1262         (JSC::AccessCase::generate):
1263         (JSC::PolymorphicAccess::regenerate):
1264         * bytecode/PolymorphicAccess.h:
1265         (JSC::AccessCase::customSlotBase):
1266         (JSC::AccessCase::isGetter):
1267         (JSC::AccessCase::doesCalls): Deleted.
1268         * jit/GCAwareJITStubRoutine.cpp:
1269         (JSC::GCAwareJITStubRoutine::markRequiredObjectsInternal):
1270         (JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine):
1271         (JSC::MarkingGCAwareJITStubRoutine::~MarkingGCAwareJITStubRoutine):
1272         (JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
1273         (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
1274         (JSC::createJITStubRoutine):
1275         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::MarkingGCAwareJITStubRoutineWithOneObject): Deleted.
1276         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::~MarkingGCAwareJITStubRoutineWithOneObject): Deleted.
1277         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal): Deleted.
1278         * jit/GCAwareJITStubRoutine.h:
1279         (JSC::createJITStubRoutine):
1280
1281 2016-04-08  Joseph Pecoraro  <pecoraro@apple.com>
1282
1283         Web Inspector: XHRs and Web Worker scripts are not searchable
1284         https://bugs.webkit.org/show_bug.cgi?id=154214
1285         <rdar://problem/24643587>
1286
1287         Reviewed by Timothy Hatcher.
1288
1289         * inspector/protocol/Page.json:
1290         Add optional requestId to search results properties and search
1291         parameters for when the frameId and url are not enough. XHR
1292         resources, and "Other" resources will use this.
1293
1294 2016-04-08  Guillaume Emont  <guijemont@igalia.com>
1295
1296         MIPS: support Signed cond in branchTest32()
1297         https://bugs.webkit.org/show_bug.cgi?id=156260
1298
1299         This is needed since r197688 makes use of it.
1300
1301         Reviewed by Mark Lam.
1302
1303         * assembler/MacroAssemblerMIPS.h:
1304         (JSC::MacroAssemblerMIPS::branchTest32):
1305
1306 2016-04-08  Alex Christensen  <achristensen@webkit.org>
1307
1308         Progress towards running CMake WebKit2 on Mac
1309         https://bugs.webkit.org/show_bug.cgi?id=156426
1310
1311         Reviewed by Tim Horton.
1312
1313         * PlatformMac.cmake:
1314
1315 2016-04-08  Saam barati  <sbarati@apple.com>
1316
1317         Debugger may dereference m_currentCallFrame even after the VM has gone idle
1318         https://bugs.webkit.org/show_bug.cgi?id=156413
1319
1320         Reviewed by Mark Lam.
1321
1322         There is a bug where the debugger may dereference its m_currentCallFrame
1323         pointer after that pointer becomes invalid to read from. This happens like so:
1324
1325         We may step over an instruction which causes the end of execution for the
1326         current program. This causes the VM to exit. Then, we perform a GC which
1327         causes us to collect the global object. The global object being collected
1328         causes us to detach the debugger. In detaching, we think we still have a 
1329         valid m_currentCallFrame, we dereference it, and crash. The solution is to
1330         make sure we're paused when dereferencing this pointer inside ::detach().
1331
1332         * debugger/Debugger.cpp:
1333         (JSC::Debugger::detach):
1334
1335 2016-04-08  Brian Burg  <bburg@apple.com>
1336
1337         Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses
1338         https://bugs.webkit.org/show_bug.cgi?id=156407
1339         <rdar://problem/25627659>
1340
1341         Reviewed by Timothy Hatcher.
1342
1343         There's no point having these subclasses as they don't save any space.
1344         Add m_stringValue to the union and merge some implementations of writeJSON.
1345         Move uses of the subclass to InspectorValue and delete redundant methods.
1346         Now, most InspectorValue methods are non-virtual so they can be templated.
1347
1348         * bindings/ScriptValue.cpp:
1349         (Deprecated::jsToInspectorValue):
1350         * inspector/InjectedScriptBase.cpp:
1351         (Inspector::InjectedScriptBase::makeCall):
1352         Don't used deleted subclasses.
1353
1354         * inspector/InspectorValues.cpp:
1355         (Inspector::InspectorValue::null):
1356         (Inspector::InspectorValue::create):
1357         (Inspector::InspectorValue::asValue):
1358         (Inspector::InspectorValue::asBoolean):
1359         (Inspector::InspectorValue::asDouble):
1360         (Inspector::InspectorValue::asInteger):
1361         (Inspector::InspectorValue::asString):
1362         These only need one implementation now.
1363
1364         (Inspector::InspectorValue::writeJSON):
1365         Still a virtual method since Object and Array need their members.
1366
1367         (Inspector::InspectorObjectBase::InspectorObjectBase):
1368         (Inspector::InspectorBasicValue::asBoolean): Deleted.
1369         (Inspector::InspectorBasicValue::asDouble): Deleted.
1370         (Inspector::InspectorBasicValue::asInteger): Deleted.
1371         (Inspector::InspectorBasicValue::writeJSON): Deleted.
1372         (Inspector::InspectorString::asString): Deleted.
1373         (Inspector::InspectorString::writeJSON): Deleted.
1374         (Inspector::InspectorString::create): Deleted.
1375         (Inspector::InspectorBasicValue::create): Deleted.
1376
1377         * inspector/InspectorValues.h:
1378         (Inspector::InspectorObjectBase::setBoolean):
1379         (Inspector::InspectorObjectBase::setInteger):
1380         (Inspector::InspectorObjectBase::setDouble):
1381         (Inspector::InspectorObjectBase::setString):
1382         (Inspector::InspectorArrayBase::pushBoolean):
1383         (Inspector::InspectorArrayBase::pushInteger):
1384         (Inspector::InspectorArrayBase::pushDouble):
1385         (Inspector::InspectorArrayBase::pushString):
1386         Use new factory methods.
1387
1388         * replay/EncodedValue.cpp:
1389         (JSC::ScalarEncodingTraits<bool>::encodeValue):
1390         (JSC::ScalarEncodingTraits<double>::encodeValue):
1391         (JSC::ScalarEncodingTraits<float>::encodeValue):
1392         (JSC::ScalarEncodingTraits<int32_t>::encodeValue):
1393         (JSC::ScalarEncodingTraits<int64_t>::encodeValue):
1394         (JSC::ScalarEncodingTraits<uint32_t>::encodeValue):
1395         (JSC::ScalarEncodingTraits<uint64_t>::encodeValue):
1396         * replay/EncodedValue.h:
1397         Use new factory methods.
1398
1399 2016-04-08  Filip Pizlo  <fpizlo@apple.com>
1400
1401         Add IC support for arguments.length
1402         https://bugs.webkit.org/show_bug.cgi?id=156389
1403
1404         Reviewed by Geoffrey Garen.
1405         
1406         This adds support for caching accesses to arguments.length for both DirectArguments and
1407         ScopedArguments. In strict mode, we already cached these accesses since they were just
1408         normal properties.
1409
1410         Amazingly, we also already supported caching of overridden arguments.length in both
1411         DirectArguments and ScopedArguments. This is because when you override, the property gets
1412         materialized as a normal JS property and the structure is changed.
1413         
1414         This patch painstakingly preserves our previous caching of overridden length while
1415         introducing caching of non-overridden length (i.e. the common case). In fact, we even cache
1416         the case where it could either be overridden or not, since we just end up with an AccessCase
1417         for each and they cascade to each other.
1418
1419         This is a >3x speed-up on microbenchmarks that do arguments.length in a polymorphic context.
1420         Entirely monomorphic accesses were already handled by the DFG.
1421
1422         * bytecode/PolymorphicAccess.cpp:
1423         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
1424         (JSC::AccessCase::guardedByStructureCheck):
1425         (JSC::AccessCase::generateWithGuard):
1426         (JSC::AccessCase::generate):
1427         (WTF::printInternal):
1428         * bytecode/PolymorphicAccess.h:
1429         * jit/ICStats.h:
1430         * jit/JITOperations.cpp:
1431         * jit/Repatch.cpp:
1432         (JSC::tryCacheGetByID):
1433         (JSC::tryCachePutByID):
1434         (JSC::tryRepatchIn):
1435         * tests/stress/direct-arguments-override-length-then-access-normal-length.js: Added.
1436         (args):
1437         (foo):
1438         (result.foo):
1439
1440 2016-04-08  Benjamin Poulain  <bpoulain@apple.com>
1441
1442         UInt32ToNumber should have an Int52 path
1443         https://bugs.webkit.org/show_bug.cgi?id=125704
1444
1445         Reviewed by Filip Pizlo.
1446
1447         When dealing with big numbers, fall back to Int52 instead
1448         of double when possible.
1449
1450         * dfg/DFGAbstractInterpreterInlines.h:
1451         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1452         * dfg/DFGFixupPhase.cpp:
1453         (JSC::DFG::FixupPhase::fixupNode):
1454         * dfg/DFGPredictionPropagationPhase.cpp:
1455         (JSC::DFG::PredictionPropagationPhase::propagate):
1456         * dfg/DFGSpeculativeJIT.cpp:
1457         (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
1458         * ftl/FTLLowerDFGToB3.cpp:
1459         (JSC::FTL::DFG::LowerDFGToB3::compileUInt32ToNumber):
1460
1461 2016-04-08  Brian Burg  <bburg@apple.com>
1462
1463         Web Inspector: protocol generator should emit an error when 'type' is used instead of '$ref'
1464         https://bugs.webkit.org/show_bug.cgi?id=156275
1465         <rdar://problem/25569331>
1466
1467         Reviewed by Darin Adler.
1468
1469         * inspector/protocol/Heap.json: Fix a mistake that's now caught by the protocol generator.
1470
1471         * inspector/scripts/codegen/models.py:
1472         (TypeReference.__init__): Check here if type_kind is on a whitelist of primitive types.
1473         (TypeReference.referenced_name): Update comment.
1474
1475         Add a new test specifically for the case when the type would otherwise be resolved. Rebaseline.
1476
1477         * inspector/scripts/tests/expected/fail-on-type-reference-as-primitive-type.json-error: Added.
1478         * inspector/scripts/tests/expected/fail-on-unknown-type-reference-in-type-declaration.json-error:
1479         * inspector/scripts/tests/fail-on-type-reference-as-primitive-type.json: Added.
1480
1481 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1482
1483         Remove ENABLE(ENABLE_ES6_CLASS_SYNTAX) guards
1484         https://bugs.webkit.org/show_bug.cgi?id=156384
1485
1486         Reviewed by Ryosuke Niwa.
1487
1488         * Configurations/FeatureDefines.xcconfig:
1489         * features.json: Mark as Done.
1490         * parser/Parser.cpp:
1491         (JSC::Parser<LexerType>::parseExportDeclaration):
1492         (JSC::Parser<LexerType>::parseStatementListItem):
1493         (JSC::Parser<LexerType>::parsePrimaryExpression):
1494         (JSC::Parser<LexerType>::parseMemberExpression):
1495
1496 2016-04-07  Filip Pizlo  <fpizlo@apple.com>
1497
1498         Implementing caching transition puts that need to reallocate with indexing storage
1499         https://bugs.webkit.org/show_bug.cgi?id=130914
1500
1501         Reviewed by Saam Barati.
1502
1503         This enables the IC's put_by_id path to handle reallocating the out-of-line storage even if
1504         the butterfly has indexing storage. Like the DFG, we do this by calling operations that
1505         reallocate the butterfly. Those use JSObject API and do all of the nasty work for us, like
1506         triggering a barrier.
1507
1508         This does a bunch of refactoring to how PolymorphicAccess makes calls. It's a lot easier to
1509         do it now because the hard work is hidden under AccessGenerationState methods. This means
1510         that custom accessors now share logic with put_by_id transitions.
1511
1512         * bytecode/PolymorphicAccess.cpp:
1513         (JSC::AccessGenerationState::succeed):
1514         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
1515         (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
1516         (JSC::AccessGenerationState::originalCallSiteIndex):
1517         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
1518         (JSC::AccessCase::AccessCase):
1519         (JSC::AccessCase::transition):
1520         (JSC::AccessCase::generate):
1521         (JSC::PolymorphicAccess::regenerate):
1522         * bytecode/PolymorphicAccess.h:
1523         (JSC::AccessGenerationState::needsToRestoreRegistersIfException):
1524         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
1525         * dfg/DFGOperations.cpp:
1526         * dfg/DFGOperations.h:
1527         * jit/JITOperations.cpp:
1528         * jit/JITOperations.h:
1529
1530 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1531
1532         Remote Inspector: When disallowing remote inspection on a debuggable, a listing is still sent to debuggers
1533         https://bugs.webkit.org/show_bug.cgi?id=156380
1534         <rdar://problem/25323727>
1535
1536         Reviewed by Timothy Hatcher.
1537
1538         * inspector/remote/RemoteInspector.mm:
1539         (Inspector::RemoteInspector::updateTarget):
1540         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1541         When a target has been updated and it no longer generates a listing,
1542         we should remove the old listing as that is now stale and should
1543         not be sent. Not generating a listing means this target is no
1544         longer allowed to be debugged.
1545
1546 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1547
1548         Web Inspector: Not necessary to validate webinspectord connection on iOS
1549         https://bugs.webkit.org/show_bug.cgi?id=156377
1550         <rdar://problem/25612460>
1551
1552         Reviewed by Simon Fraser.
1553
1554         * inspector/remote/RemoteInspectorXPCConnection.h:
1555         * inspector/remote/RemoteInspectorXPCConnection.mm:
1556         (Inspector::RemoteInspectorXPCConnection::handleEvent):
1557
1558 2016-04-07  Keith Miller  <keith_miller@apple.com>
1559
1560         Rename ArrayMode::supportsLength to supportsSelfLength
1561         https://bugs.webkit.org/show_bug.cgi?id=156374
1562
1563         Reviewed by Filip Pizlo.
1564
1565         The name supportsLength is confusing because TypedArray have a
1566         length function however it is on the prototype and not on the
1567         instance. supportsSelfLength makes more sense since we use the
1568         function during fixup to tell if we can intrinsic the length
1569         property lookup on self accesses.
1570
1571         * dfg/DFGArrayMode.h:
1572         (JSC::DFG::ArrayMode::supportsSelfLength):
1573         (JSC::DFG::ArrayMode::supportsLength): Deleted.
1574         * dfg/DFGFixupPhase.cpp:
1575         (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
1576
1577 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1578
1579         Web Inspector: ProfileView source links are off by 1 line, worse in pretty printed code
1580         https://bugs.webkit.org/show_bug.cgi?id=156371
1581
1582         Reviewed by Timothy Hatcher.
1583
1584         * inspector/protocol/ScriptProfiler.json:
1585         Clarify that these locations are 1-based.
1586
1587 2016-04-07  Jon Davis  <jond@apple.com>
1588
1589         Add Web Animations API to Feature Status Page
1590         https://bugs.webkit.org/show_bug.cgi?id=156360
1591
1592         Reviewed by Timothy Hatcher.
1593
1594         * features.json:
1595
1596 2016-04-07  Saam barati  <sbarati@apple.com>
1597
1598         Invalid assertion inside DebuggerScope::getOwnPropertySlot
1599         https://bugs.webkit.org/show_bug.cgi?id=156357
1600
1601         Reviewed by Keith Miller.
1602
1603         The Type Profiler might profile JS code that uses DebuggerScope and accesses properties
1604         on it. Therefore, it may have a DebuggerScope object in its log. Objects in the log
1605         are subject to having their getOwnPropertySlot method called. Therefore, the DebuggerScope
1606         might not always be in a valid state when its getOwnPropertySlot method is called.
1607         Therefore, the assertion invalid.
1608
1609         * debugger/DebuggerScope.cpp:
1610         (JSC::DebuggerScope::getOwnPropertySlot):
1611
1612 2016-04-07  Saam barati  <sbarati@apple.com>
1613
1614         Initial implementation of annex b.3.3 behavior was incorrect
1615         https://bugs.webkit.org/show_bug.cgi?id=156276
1616
1617         Reviewed by Keith Miller.
1618
1619         I almost got annex B.3.3 correct in my first implementation.
1620         There is a subtlety here I got wrong. We always create a local binding for
1621         a function at the very beginning of execution of a block scope. So we
1622         hoist function declarations to their local binding within a given
1623         block scope. When we actually evaluate the function declaration statement
1624         itself, we must lookup the binding in the current scope, and bind the
1625         value to the binding in the "var" scope. We perform the following
1626         abstract operations when executing a function declaration statement.
1627
1628         f = lookupBindingInCurrentScope("func")
1629         store(varScope, "func", f)
1630
1631         I got this wrong by performing the store to the var binding at the beginning
1632         of the block scope instead of when we evaluate the function declaration statement.
1633         This behavior is observable. For example, a program could change the value
1634         of "func" before the actual function declaration statement executes.
1635         Consider the following two functions:
1636         ```
1637         function foo1() {
1638             // func === undefined
1639             {
1640                 // typeof func === "function"
1641                 function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding.
1642                 func = 20 // This sets the local "func" binding to 20.
1643             }
1644             // typeof func === "function"
1645         }
1646
1647         function foo2() {
1648             // func === undefined
1649             {
1650                 // typeof func === "function"
1651                 func = 20 // This sets the local "func" binding to 20.
1652                 function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding.
1653             }
1654             // func === 20
1655         }
1656         ```
1657
1658         * bytecompiler/BytecodeGenerator.cpp:
1659         (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
1660         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
1661         * bytecompiler/BytecodeGenerator.h:
1662         (JSC::BytecodeGenerator::emitNodeForLeftHandSide):
1663         * bytecompiler/NodesCodegen.cpp:
1664         (JSC::FuncDeclNode::emitBytecode):
1665         * tests/stress/sloppy-mode-function-hoisting.js:
1666         (test.foo):
1667         (test):
1668         (test.):
1669         (test.bar):
1670         (test.switch.case.0):
1671         (test.capFoo1):
1672         (test.switch.capFoo2):
1673         (test.outer):
1674         (foo):
1675
1676 2016-04-07  Alex Christensen  <achristensen@webkit.org>
1677
1678         Build fix after r199170
1679
1680         * CMakeLists.txt:
1681
1682 2016-04-07  Keith Miller  <keith_miller@apple.com>
1683
1684         We should support the ability to do a non-effectful getById
1685         https://bugs.webkit.org/show_bug.cgi?id=156116
1686
1687         Reviewed by Benjamin Poulain.
1688
1689         Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
1690         useful because it enables us to take different code paths based on values that we would
1691         otherwise not be able to have knowledge of. This patch adds this new feature called
1692         try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
1693         an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
1694         GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
1695         undefined if the slot is unset.  If the slot is proxied or any other cases then the result
1696         is null. In theory, if we ever wanted to check for null we could add a sentinal object to
1697         the global object that indicates we could not get the result.
1698
1699         In order to implement this feature we add a new enum GetByIdKind that indicates what to do
1700         for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
1701         get_by_id the same way we would for load and return the value at the appropriate offset.
1702         Additionally, in order to make sure the we can properly compare the GetterSetter object
1703         with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
1704         GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
1705         likely to have little to no impact on memory usage as normal accessors are generally rare.
1706
1707         * JavaScriptCore.xcodeproj/project.pbxproj:
1708         * builtins/BuiltinExecutableCreator.cpp: Added.
1709         (JSC::createBuiltinExecutable):
1710         * builtins/BuiltinExecutableCreator.h: Copied from Source/JavaScriptCore/builtins/BuiltinExecutables.h.
1711         * builtins/BuiltinExecutables.cpp:
1712         (JSC::BuiltinExecutables::createDefaultConstructor):
1713         (JSC::BuiltinExecutables::createBuiltinExecutable):
1714         (JSC::createBuiltinExecutable):
1715         (JSC::BuiltinExecutables::createExecutable):
1716         (JSC::createExecutableInternal): Deleted.
1717         * builtins/BuiltinExecutables.h:
1718         * bytecode/BytecodeIntrinsicRegistry.h:
1719         * bytecode/BytecodeList.json:
1720         * bytecode/BytecodeUseDef.h:
1721         (JSC::computeUsesForBytecodeOffset):
1722         (JSC::computeDefsForBytecodeOffset):
1723         * bytecode/CodeBlock.cpp:
1724         (JSC::CodeBlock::dumpBytecode):
1725         * bytecode/PolymorphicAccess.cpp:
1726         (JSC::AccessCase::tryGet):
1727         (JSC::AccessCase::generate):
1728         (WTF::printInternal):
1729         * bytecode/PolymorphicAccess.h:
1730         (JSC::AccessCase::isGet): Deleted.
1731         (JSC::AccessCase::isPut): Deleted.
1732         (JSC::AccessCase::isIn): Deleted.
1733         * bytecode/StructureStubInfo.cpp:
1734         (JSC::StructureStubInfo::reset):
1735         * bytecode/StructureStubInfo.h:
1736         * bytecompiler/BytecodeGenerator.cpp:
1737         (JSC::BytecodeGenerator::emitTryGetById):
1738         * bytecompiler/BytecodeGenerator.h:
1739         * bytecompiler/NodesCodegen.cpp:
1740         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
1741         * dfg/DFGSpeculativeJIT32_64.cpp:
1742         (JSC::DFG::SpeculativeJIT::cachedGetById):
1743         * dfg/DFGSpeculativeJIT64.cpp:
1744         (JSC::DFG::SpeculativeJIT::cachedGetById):
1745         * ftl/FTLLowerDFGToB3.cpp:
1746         (JSC::FTL::DFG::LowerDFGToB3::getById):
1747         * jit/JIT.cpp:
1748         (JSC::JIT::privateCompileMainPass):
1749         (JSC::JIT::privateCompileSlowCases):
1750         * jit/JIT.h:
1751         * jit/JITInlineCacheGenerator.cpp:
1752         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1753         * jit/JITInlineCacheGenerator.h:
1754         * jit/JITInlines.h:
1755         (JSC::JIT::callOperation):
1756         * jit/JITOperations.cpp:
1757         * jit/JITOperations.h:
1758         * jit/JITPropertyAccess.cpp:
1759         (JSC::JIT::emitGetByValWithCachedId):
1760         (JSC::JIT::emit_op_try_get_by_id):
1761         (JSC::JIT::emitSlow_op_try_get_by_id):
1762         (JSC::JIT::emit_op_get_by_id):
1763         * jit/JITPropertyAccess32_64.cpp:
1764         (JSC::JIT::emitGetByValWithCachedId):
1765         (JSC::JIT::emit_op_try_get_by_id):
1766         (JSC::JIT::emitSlow_op_try_get_by_id):
1767         (JSC::JIT::emit_op_get_by_id):
1768         * jit/Repatch.cpp:
1769         (JSC::repatchByIdSelfAccess):
1770         (JSC::appropriateOptimizingGetByIdFunction):
1771         (JSC::appropriateGenericGetByIdFunction):
1772         (JSC::tryCacheGetByID):
1773         (JSC::repatchGetByID):
1774         (JSC::resetGetByID):
1775         * jit/Repatch.h:
1776         * jsc.cpp:
1777         (GlobalObject::finishCreation):
1778         (functionGetGetterSetter):
1779         (functionCreateBuiltin):
1780         * llint/LLIntData.cpp:
1781         (JSC::LLInt::Data::performAssertions):
1782         * llint/LLIntSlowPaths.cpp:
1783         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1784         * llint/LLIntSlowPaths.h:
1785         * llint/LowLevelInterpreter.asm:
1786         * runtime/GetterSetter.cpp:
1787         * runtime/GetterSetter.h:
1788         * runtime/JSType.h:
1789         * runtime/PropertySlot.cpp:
1790         (JSC::PropertySlot::getPureResult):
1791         * runtime/PropertySlot.h:
1792         * runtime/ProxyObject.cpp:
1793         (JSC::ProxyObject::getOwnPropertySlotCommon):
1794         * tests/stress/try-get-by-id.js: Added.
1795         (tryGetByIdText):
1796         (getCaller.obj.1.throw.new.Error.let.func):
1797         (getCaller.obj.1.throw.new.Error):
1798         (throw.new.Error.get let):
1799         (throw.new.Error.):
1800         (throw.new.Error.let.get createBuiltin):
1801         (get let):
1802         (let.get createBuiltin):
1803         (let.func):
1804         (get let.func):
1805         (get throw):
1806
1807 2016-04-07  Filip Pizlo  <fpizlo@apple.com>
1808
1809         Rationalize the makeSpaceForCCall stuff
1810         https://bugs.webkit.org/show_bug.cgi?id=156352
1811
1812         Reviewed by Mark Lam.
1813
1814         I want to add more code to PolymorphicAccess that makes C calls, so that I can finally fix
1815         https://bugs.webkit.org/show_bug.cgi?id=130914 (allow transition caches to handle indexing
1816         headers).
1817
1818         When trying to understand what it takes to make a C call, I came across code that was making
1819         room on the stack for spilled arguments. This logic was guarded with some complicated
1820         condition. At first, I tried to just refactor the code so that the same ugly condition
1821         wouldn't have to be copy-pasted everywhere that we made C calls. But then I started thinking
1822         about the condition, and realized that it was probably wrong: if the outer PolymorphicAccess
1823         harness decides to reuse a register for the scratchGPR then the top of the stack will store
1824         the old value of scratchGPR, but the condition wouldn't necessarily trigger. So if the call
1825         then overwrote something on the stack, we'd have a bad time.
1826
1827         Making room on the stack for a call is a cheap operation. It's orders of magnitude cheaper
1828         than the rest of the call. Therefore, I think that it's best to just unconditionally make
1829         room on the stack.
1830
1831         This patch makes us do just that. I also made the relevant helpers not inline, because I
1832         think that we have too many inline methods in our assemblers. Now it's much easier to make
1833         C calls from PolymorphicAccess because you just call the AssemblyHelper methods for making
1834         space. There are no special conditions or anything like that.
1835
1836         * bytecode/PolymorphicAccess.cpp:
1837         (JSC::AccessCase::generate):
1838         * jit/AssemblyHelpers.cpp:
1839         (JSC::AssemblyHelpers::emitLoadStructure):
1840         (JSC::AssemblyHelpers::makeSpaceOnStackForCCall):
1841         (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall):
1842         (JSC::emitRandomThunkImpl):
1843         * jit/AssemblyHelpers.h:
1844         (JSC::AssemblyHelpers::makeSpaceOnStackForCCall): Deleted.
1845         (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall): Deleted.
1846
1847 2016-04-07  Commit Queue  <commit-queue@webkit.org>
1848
1849         Unreviewed, rolling out r199128 and r199141.
1850         https://bugs.webkit.org/show_bug.cgi?id=156348
1851
1852         Causes crashes on multiple webpages (Requested by keith_mi_ on
1853         #webkit).
1854
1855         Reverted changesets:
1856
1857         "[ES6] Add support for Symbol.isConcatSpreadable."
1858         https://bugs.webkit.org/show_bug.cgi?id=155351
1859         http://trac.webkit.org/changeset/199128
1860
1861         "Unreviewed, uncomment accidentally commented line in test."
1862         http://trac.webkit.org/changeset/199141
1863
1864 2016-04-07  Filip Pizlo  <fpizlo@apple.com>
1865
1866         Rationalize the handling of PutById transitions a bit
1867         https://bugs.webkit.org/show_bug.cgi?id=156330
1868
1869         Reviewed by Mark Lam.
1870
1871         * bytecode/PolymorphicAccess.cpp:
1872         (JSC::AccessCase::generate): Get rid of the specialized slow calls. We can just use the failAndIgnore jump target. We just need to make sure that we don't make observable effects until we're done with all of the fast path checks.
1873         * bytecode/StructureStubInfo.cpp:
1874         (JSC::StructureStubInfo::addAccessCase): MadeNoChanges indicates that we should keep trying to repatch. Currently PutById transitions might trigger the case that addAccessCase() sees null, if the transition involves an indexing header. Doing repatching in that case is probably not good. But, we should just fix this the right way eventually.
1875
1876 2016-04-07  Per Arne Vollan  <peavo@outlook.com>
1877
1878         [Win] Fix for JSC stress test failures.
1879         https://bugs.webkit.org/show_bug.cgi?id=156343
1880
1881         Reviewed by Filip Pizlo.
1882
1883         We need to make it clear to MSVC that the method loadPtr(ImplicitAddress address, RegisterID dest)
1884         should be used, and not loadPtr(const void* address, RegisterID dest).
1885
1886         * jit/CCallHelpers.cpp:
1887         (JSC::CCallHelpers::setupShadowChickenPacket):
1888
1889 2016-04-06  Benjamin Poulain  <bpoulain@apple.com>
1890
1891         [JSC] UInt32ToNumber should be NodeMustGenerate
1892         https://bugs.webkit.org/show_bug.cgi?id=156329
1893
1894         Reviewed by Filip Pizlo.
1895
1896         It exits on negative numbers on the integer path.
1897
1898         * dfg/DFGFixupPhase.cpp:
1899         (JSC::DFG::FixupPhase::fixupNode):
1900         * dfg/DFGNodeType.h:
1901
1902 2016-04-04  Geoffrey Garen  <ggaren@apple.com>
1903
1904         Unreviewed, rolling out r199016.
1905         https://bugs.webkit.org/show_bug.cgi?id=156140
1906
1907         "Perf bots are down, so I can't re-land this right now."
1908
1909         Reverted changeset:
1910
1911         CopiedBlock should be 16kB
1912         https://bugs.webkit.org/show_bug.cgi?id=156168
1913         http://trac.webkit.org/changeset/199016
1914
1915 2016-04-06  Mark Lam  <mark.lam@apple.com>
1916
1917         String.prototype.match() should be calling internal function RegExpCreate.
1918         https://bugs.webkit.org/show_bug.cgi?id=156318
1919
1920         Reviewed by Filip Pizlo.
1921
1922         RegExpCreate is not the same as the RegExp constructor.  The current implementation
1923         invokes new @RegExp which calls the constructor.  This results in failures in
1924         es6/Proxy_internal_get_calls_String.prototype.match.js, and
1925         es6/Proxy_internal_get_calls_String.prototype.search.js due to observable side
1926         effects.
1927
1928         This patch fixes this by factoring out the part of the RegExp constructor that
1929         makes the RegExpCreate function, and changing String's match and search to call
1930         RegExpCreate instead in accordance with the ES6 spec. 
1931
1932         * builtins/StringPrototype.js:
1933         (match):
1934         (search):
1935         * runtime/CommonIdentifiers.h:
1936         * runtime/JSGlobalObject.cpp:
1937         (JSC::JSGlobalObject::init):
1938         * runtime/RegExpConstructor.cpp:
1939         (JSC::toFlags):
1940         (JSC::regExpCreate):
1941         (JSC::constructRegExp):
1942         (JSC::esSpecRegExpCreate):
1943         (JSC::constructWithRegExpConstructor):
1944         * runtime/RegExpConstructor.h:
1945         (JSC::isRegExp):
1946
1947 2016-04-06  Keith Miller  <keith_miller@apple.com>
1948
1949         Unreviewed, uncomment accidentally commented line in test.
1950
1951         * tests/stress/array-concat-spread-object.js:
1952
1953 2016-04-06  Filip Pizlo  <fpizlo@apple.com>
1954
1955         JSC should have a simple way of gathering IC statistics
1956         https://bugs.webkit.org/show_bug.cgi?id=156317
1957
1958         Reviewed by Benjamin Poulain.
1959
1960         This adds a cheap, runtime-enabled way of gathering statistics about why we take the slow
1961         paths for inline caches. This is complementary to our existing bytecode profiler. Eventually
1962         we may want to combine the two things.
1963         
1964         This is not a slow-down on anything because we only do extra work on IC slow paths and if
1965         it's disabled it's just a load-and-branch to skip the stats gathering code.
1966
1967         * CMakeLists.txt:
1968         * JavaScriptCore.xcodeproj/project.pbxproj:
1969         * jit/ICStats.cpp: Added.
1970         * jit/ICStats.h: Added.
1971         * jit/JITOperations.cpp:
1972         * runtime/JSCJSValue.h:
1973         * runtime/JSCJSValueInlines.h:
1974         (JSC::JSValue::inherits):
1975         (JSC::JSValue::classInfoOrNull):
1976         (JSC::JSValue::toThis):
1977         * runtime/Options.h:
1978
1979 2016-04-06  Filip Pizlo  <fpizlo@apple.com>
1980
1981         32-bit JSC stress/multi-put-by-offset-multiple-transitions.js failing
1982         https://bugs.webkit.org/show_bug.cgi?id=156292
1983
1984         Reviewed by Benjamin Poulain.
1985
1986         Make sure that we stash the callsite index before calling operationReallocateStorageAndFinishPut.
1987
1988         * bytecode/PolymorphicAccess.cpp:
1989         (JSC::AccessCase::generate):
1990
1991 2016-04-06  Filip Pizlo  <fpizlo@apple.com>
1992
1993         JSC test stress/arrowfunction-lexical-bind-superproperty.js failing
1994         https://bugs.webkit.org/show_bug.cgi?id=156309
1995
1996         Reviewed by Saam Barati.
1997
1998         Just be honest about the fact that the ArgumentCount and Callee parts of inline callframe runtime
1999         meta-data can be read at any time.
2000         
2001         We only have to say this for the inline callframe forms of ArgumentCount and Callee because we don't
2002         sink any part of the machine prologue. This change just prevents us from sinking the pseudoprologue
2003         of inlined varargs or closure calls.
2004
2005         Shockingly, this is not a regression on anything.
2006
2007         * dfg/DFGClobberize.h:
2008         (JSC::DFG::clobberize):
2009
2010 2016-03-29  Keith Miller  <keith_miller@apple.com>
2011
2012         [ES6] Add support for Symbol.isConcatSpreadable.
2013         https://bugs.webkit.org/show_bug.cgi?id=155351
2014
2015         Reviewed by Saam Barati.
2016
2017         This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the
2018         Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to
2019         a builtin performant. First, four new DFG intrinsics were added.
2020
2021         1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of
2022            the Array.isArray function.
2023         2) IsJSArray: checks the first child is a JSArray object.
2024         3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor.
2025         4) CallObjectConstructor: an intrinsic of the Object constructor.
2026
2027         IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if
2028         we are able to prove that the first child is an Array or for ToObject an Object.
2029
2030         In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy
2031         code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and
2032         were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and
2033         the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this
2034         into a contiguous array).
2035
2036         This patch also adds a new fast path for concat with more than one array argument by using memcpy to append
2037         values onto the result array. This works roughly the same as the two array fast path using the same methodology
2038         to decide if we can memcpy the other butterfly into the result butterfly.
2039
2040         Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private
2041         name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our
2042         dataLog function on it.
2043
2044         Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a
2045         JSValueOperand if the operand's use count is one.
2046
2047         * JavaScriptCore.xcodeproj/project.pbxproj:
2048         * builtins/ArrayPrototype.js:
2049         (concatSlowPath):
2050         (concat):
2051         * bytecode/BytecodeIntrinsicRegistry.cpp:
2052         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
2053         * bytecode/BytecodeIntrinsicRegistry.h:
2054         * dfg/DFGAbstractInterpreterInlines.h:
2055         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2056         * dfg/DFGByteCodeParser.cpp:
2057         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2058         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2059         * dfg/DFGClobberize.h:
2060         (JSC::DFG::clobberize):
2061         * dfg/DFGDoesGC.cpp:
2062         (JSC::DFG::doesGC):
2063         * dfg/DFGFixupPhase.cpp:
2064         (JSC::DFG::FixupPhase::fixupNode):
2065         * dfg/DFGNodeType.h:
2066         * dfg/DFGOperations.cpp:
2067         * dfg/DFGOperations.h:
2068         * dfg/DFGPredictionPropagationPhase.cpp:
2069         (JSC::DFG::PredictionPropagationPhase::propagate):
2070         * dfg/DFGSafeToExecute.h:
2071         (JSC::DFG::safeToExecute):
2072         * dfg/DFGSpeculativeJIT.cpp:
2073         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2074         (JSC::DFG::SpeculativeJIT::compileIsJSArray):
2075         (JSC::DFG::SpeculativeJIT::compileIsArrayObject):
2076         (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor):
2077         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
2078         * dfg/DFGSpeculativeJIT.h:
2079         (JSC::DFG::SpeculativeJIT::callOperation):
2080         * dfg/DFGSpeculativeJIT32_64.cpp:
2081         (JSC::DFG::SpeculativeJIT::compile):
2082         * dfg/DFGSpeculativeJIT64.cpp:
2083         (JSC::DFG::SpeculativeJIT::compile):
2084         * ftl/FTLCapabilities.cpp:
2085         (JSC::FTL::canCompile):
2086         * ftl/FTLLowerDFGToB3.cpp:
2087         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2088         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
2089         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject):
2090         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
2091         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor):
2092         (JSC::FTL::DFG::LowerDFGToB3::isArray):
2093         * jit/JITOperations.h:
2094         * jsc.cpp:
2095         (WTF::RuntimeArray::createStructure):
2096         (GlobalObject::finishCreation):
2097         (functionDebug):
2098         (functionDataLogValue):
2099         * runtime/ArrayConstructor.cpp:
2100         (JSC::ArrayConstructor::finishCreation):
2101         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
2102         * runtime/ArrayConstructor.h:
2103         (JSC::isArrayConstructor):
2104         * runtime/ArrayPrototype.cpp:
2105         (JSC::ArrayPrototype::finishCreation):
2106         (JSC::arrayProtoPrivateFuncIsJSArray):
2107         (JSC::moveElements):
2108         (JSC::arrayProtoPrivateFuncConcatMemcpy):
2109         (JSC::arrayProtoPrivateFuncAppendMemcpy):
2110         (JSC::arrayProtoFuncConcat): Deleted.
2111         * runtime/ArrayPrototype.h:
2112         (JSC::ArrayPrototype::createStructure):
2113         * runtime/CommonIdentifiers.h:
2114         * runtime/Intrinsic.h:
2115         * runtime/JSArray.cpp:
2116         (JSC::JSArray::appendMemcpy):
2117         (JSC::JSArray::fastConcatWith): Deleted.
2118         * runtime/JSArray.h:
2119         (JSC::JSArray::createStructure):
2120         (JSC::JSArray::fastConcatType): Deleted.
2121         * runtime/JSArrayInlines.h: Added.
2122         (JSC::JSArray::memCopyWithIndexingType):
2123         (JSC::JSArray::canFastCopy):
2124         * runtime/JSGlobalObject.cpp:
2125         (JSC::JSGlobalObject::init):
2126         * runtime/JSType.h:
2127         * runtime/ObjectConstructor.h:
2128         (JSC::constructObject):
2129         * tests/es6.yaml:
2130         * tests/stress/array-concat-spread-object.js: Added.
2131         (arrayEq):
2132         * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
2133         (arrayEq):
2134         * tests/stress/array-concat-spread-proxy.js: Added.
2135         (arrayEq):
2136         * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
2137         (arrayEq):
2138         * tests/stress/array-species-config-array-constructor.js:
2139
2140 2016-04-06  Commit Queue  <commit-queue@webkit.org>
2141
2142         Unreviewed, rolling out r199070.
2143         https://bugs.webkit.org/show_bug.cgi?id=156324
2144
2145         "It didn't fix the timeout" (Requested by saamyjoon on
2146         #webkit).
2147
2148         Reverted changeset:
2149
2150         "jsc-layout-tests.yaml/js/script-tests/regress-141098.js
2151         failing on Yosemite Debug after r198989"
2152         https://bugs.webkit.org/show_bug.cgi?id=156187
2153         http://trac.webkit.org/changeset/199070
2154
2155 2016-04-06  Geoffrey Garen  <ggaren@apple.com>
2156
2157         Unreviewed, rolling in r199016.
2158         https://bugs.webkit.org/show_bug.cgi?id=156140
2159
2160         It might work this time without regression because 16kB aligned requests
2161         now take the allocation fast path.
2162
2163         Restored changeset:
2164
2165         CopiedBlock should be 16kB
2166         https://bugs.webkit.org/show_bug.cgi?id=156168
2167         http://trac.webkit.org/changeset/199016
2168
2169 2016-04-06  Mark Lam  <mark.lam@apple.com>
2170
2171         Update es6.yaml to expect es6/Proxy_internal_get_calls_RegExp_constructor.js to pass.
2172         https://bugs.webkit.org/show_bug.cgi?id=156314
2173
2174         Reviewed by Saam Barati.
2175
2176         * tests/es6.yaml:
2177
2178 2016-04-06  Commit Queue  <commit-queue@webkit.org>
2179
2180         Unreviewed, rolling out r199104.
2181         https://bugs.webkit.org/show_bug.cgi?id=156301
2182
2183         Still breaks internal builds (Requested by keith_miller on
2184         #webkit).
2185
2186         Reverted changeset:
2187
2188         "We should support the ability to do a non-effectful getById"
2189         https://bugs.webkit.org/show_bug.cgi?id=156116
2190         http://trac.webkit.org/changeset/199104
2191
2192 2016-04-06  Keith Miller  <keith_miller@apple.com>
2193
2194         RegExp constructor should use Symbol.match and other properties
2195         https://bugs.webkit.org/show_bug.cgi?id=155873
2196
2197         Reviewed by Michael Saboff.
2198
2199         This patch updates the behavior of the RegExp constructor. Now the constructor
2200         should get the Symbol.match property and check if it exists to decide if something
2201         should be constructed like a regexp object.
2202
2203         * runtime/RegExpConstructor.cpp:
2204         (JSC::toFlags):
2205         (JSC::constructRegExp):
2206         (JSC::constructWithRegExpConstructor):
2207         (JSC::callRegExpConstructor):
2208         * runtime/RegExpConstructor.h:
2209         * tests/stress/regexp-constructor.js: Added.
2210         (assert):
2211         (throw.new.Error.get let):
2212         (throw.new.Error.):
2213         (throw.new.Error.get re):
2214
2215 2016-04-06  Keith Miller  <keith_miller@apple.com>
2216
2217         We should support the ability to do a non-effectful getById
2218         https://bugs.webkit.org/show_bug.cgi?id=156116
2219
2220         Reviewed by Benjamin Poulain.
2221
2222         Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
2223         useful because it enables us to take different code paths based on values that we would
2224         otherwise not be able to have knowledge of. This patch adds this new feature called
2225         try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
2226         an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
2227         GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
2228         undefined if the slot is unset.  If the slot is proxied or any other cases then the result
2229         is null. In theory, if we ever wanted to check for null we could add a sentinal object to
2230         the global object that indicates we could not get the result.
2231
2232         In order to implement this feature we add a new enum GetByIdKind that indicates what to do
2233         for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
2234         get_by_id the same way we would for load and return the value at the appropriate offset.
2235         Additionally, in order to make sure the we can properly compare the GetterSetter object
2236         with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
2237         GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
2238         likely to have little to no impact on memory usage as normal accessors are generally rare.
2239
2240         * builtins/BuiltinExecutables.cpp:
2241         (JSC::BuiltinExecutables::createDefaultConstructor):
2242         (JSC::BuiltinExecutables::createBuiltinExecutable):
2243         (JSC::createBuiltinExecutable):
2244         (JSC::BuiltinExecutables::createExecutable):
2245         (JSC::createExecutableInternal): Deleted.
2246         * builtins/BuiltinExecutables.h:
2247         * bytecode/BytecodeIntrinsicRegistry.h:
2248         * bytecode/BytecodeList.json:
2249         * bytecode/BytecodeUseDef.h:
2250         (JSC::computeUsesForBytecodeOffset):
2251         (JSC::computeDefsForBytecodeOffset):
2252         * bytecode/CodeBlock.cpp:
2253         (JSC::CodeBlock::dumpBytecode):
2254         * bytecode/PolymorphicAccess.cpp:
2255         (JSC::AccessCase::tryGet):
2256         (JSC::AccessCase::generate):
2257         (WTF::printInternal):
2258         * bytecode/PolymorphicAccess.h:
2259         (JSC::AccessCase::isGet): Deleted.
2260         (JSC::AccessCase::isPut): Deleted.
2261         (JSC::AccessCase::isIn): Deleted.
2262         * bytecode/StructureStubInfo.cpp:
2263         (JSC::StructureStubInfo::reset):
2264         * bytecode/StructureStubInfo.h:
2265         * bytecompiler/BytecodeGenerator.cpp:
2266         (JSC::BytecodeGenerator::emitTryGetById):
2267         * bytecompiler/BytecodeGenerator.h:
2268         * bytecompiler/NodesCodegen.cpp:
2269         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
2270         * dfg/DFGSpeculativeJIT32_64.cpp:
2271         (JSC::DFG::SpeculativeJIT::cachedGetById):
2272         * dfg/DFGSpeculativeJIT64.cpp:
2273         (JSC::DFG::SpeculativeJIT::cachedGetById):
2274         * ftl/FTLLowerDFGToB3.cpp:
2275         (JSC::FTL::DFG::LowerDFGToB3::getById):
2276         * jit/JIT.cpp:
2277         (JSC::JIT::privateCompileMainPass):
2278         (JSC::JIT::privateCompileSlowCases):
2279         * jit/JIT.h:
2280         * jit/JITInlineCacheGenerator.cpp:
2281         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2282         * jit/JITInlineCacheGenerator.h:
2283         * jit/JITInlines.h:
2284         (JSC::JIT::callOperation):
2285         * jit/JITOperations.cpp:
2286         * jit/JITOperations.h:
2287         * jit/JITPropertyAccess.cpp:
2288         (JSC::JIT::emitGetByValWithCachedId):
2289         (JSC::JIT::emit_op_try_get_by_id):
2290         (JSC::JIT::emitSlow_op_try_get_by_id):
2291         (JSC::JIT::emit_op_get_by_id):
2292         * jit/JITPropertyAccess32_64.cpp:
2293         (JSC::JIT::emitGetByValWithCachedId):
2294         (JSC::JIT::emit_op_try_get_by_id):
2295         (JSC::JIT::emitSlow_op_try_get_by_id):
2296         (JSC::JIT::emit_op_get_by_id):
2297         * jit/Repatch.cpp:
2298         (JSC::repatchByIdSelfAccess):
2299         (JSC::appropriateOptimizingGetByIdFunction):
2300         (JSC::appropriateGenericGetByIdFunction):
2301         (JSC::tryCacheGetByID):
2302         (JSC::repatchGetByID):
2303         (JSC::resetGetByID):
2304         * jit/Repatch.h:
2305         * jsc.cpp:
2306         (GlobalObject::finishCreation):
2307         (functionGetGetterSetter):
2308         (functionCreateBuiltin):
2309         * llint/LLIntData.cpp:
2310         (JSC::LLInt::Data::performAssertions):
2311         * llint/LLIntSlowPaths.cpp:
2312         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2313         * llint/LLIntSlowPaths.h:
2314         * llint/LowLevelInterpreter.asm:
2315         * runtime/GetterSetter.cpp:
2316         * runtime/GetterSetter.h:
2317         * runtime/JSType.h:
2318         * runtime/PropertySlot.cpp:
2319         (JSC::PropertySlot::getPureResult):
2320         * runtime/PropertySlot.h:
2321         * runtime/ProxyObject.cpp:
2322         (JSC::ProxyObject::getOwnPropertySlotCommon):
2323         * tests/stress/try-get-by-id.js: Added.
2324         (tryGetByIdText):
2325         (getCaller.obj.1.throw.new.Error.let.func):
2326         (getCaller.obj.1.throw.new.Error):
2327         (throw.new.Error.get let):
2328         (throw.new.Error.):
2329         (throw.new.Error.let.get createBuiltin):
2330         (get let):
2331         (let.get createBuiltin):
2332         (let.func):
2333         (get let.func):
2334         (get throw):
2335
2336 2016-04-05  Chris Dumez  <cdumez@apple.com>
2337
2338         Add support for [EnabledAtRuntime] operations on DOMWindow
2339         https://bugs.webkit.org/show_bug.cgi?id=156272
2340
2341         Reviewed by Alex Christensen.
2342
2343         Add identifier for 'fetch' so it can be used from the generated
2344         bindings.
2345
2346         * runtime/CommonIdentifiers.h:
2347
2348 2016-04-05  Alex Christensen  <achristensen@webkit.org>
2349
2350         Make CMake-generated binaries on Mac able to run
2351         https://bugs.webkit.org/show_bug.cgi?id=156268
2352
2353         Reviewed by Daniel Bates.
2354
2355         * CMakeLists.txt:
2356
2357 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
2358
2359         Improve some other cases of context-sensitive inlining
2360         https://bugs.webkit.org/show_bug.cgi?id=156277
2361
2362         Reviewed by Benjamin Poulain.
2363         
2364         This implements some improvements for inlining:
2365
2366         - We no longer do guarded inlining when the profiling doesn't come from a stub. Doing so would have
2367           been risky, and according to benchmarks, it wasn't common enough to matter. I think it's better to
2368           err on the side of not inlining.
2369         
2370         - The jneq_ptr pattern for variadic calls no longer breaks the basic block. Not breaking the block
2371           increases the chances of the parser seeing the callee constant. While inlining doesn't require a
2372           callee constant, sometimes it makes a difference. Note that we were previously breaking the block
2373           for no reason at all: if the boundary after jneq_ptr is a jump target from some other jump, then
2374           the parser will automatically break the block for us. There is no reason to add any block breaking
2375           ourselves since we implement jneq_ptr by ignoring the affirmative jump destination and inserting a
2376           check and falling through.
2377         
2378         - get_by_id handling now tries to apply some common sense to its status object. In particular, if
2379           the source is a NewObject and there was no interfering operation that could clobber the structure,
2380           then we know which case of a polymorphic GetByIdStatus we would take. This arises in some
2381           constructor patterns.
2382         
2383         Long term, we should address all of these cases comprehensively by having a late inliner. The inliner
2384         being part of the bytecode parser means that there is a lot of complexity in the parser and it
2385         prevents us from inlining upon learning new information from static analysis. But for now, I think
2386         it's fine to experiment with one-off hacks, if only to learn what the possibilities are.
2387         
2388         This is a 14% speed-up on Octane/raytrace.
2389
2390         * bytecode/CallLinkStatus.cpp:
2391         (JSC::CallLinkStatus::dump):
2392         * bytecode/CallLinkStatus.h:
2393         (JSC::CallLinkStatus::couldTakeSlowPath):
2394         (JSC::CallLinkStatus::setCouldTakeSlowPath):
2395         (JSC::CallLinkStatus::variants):
2396         (JSC::CallLinkStatus::size):
2397         (JSC::CallLinkStatus::at):
2398         * bytecode/GetByIdStatus.cpp:
2399         (JSC::GetByIdStatus::makesCalls):
2400         (JSC::GetByIdStatus::filter):
2401         (JSC::GetByIdStatus::dump):
2402         * bytecode/GetByIdStatus.h:
2403         (JSC::GetByIdStatus::wasSeenInJIT):
2404         * dfg/DFGByteCodeParser.cpp:
2405         (JSC::DFG::ByteCodeParser::handleCall):
2406         (JSC::DFG::ByteCodeParser::refineStatically):
2407         (JSC::DFG::ByteCodeParser::handleVarargsCall):
2408         (JSC::DFG::ByteCodeParser::handleInlining):
2409         (JSC::DFG::ByteCodeParser::handleGetById):
2410         (JSC::DFG::ByteCodeParser::parseBlock):
2411         * runtime/Options.h:
2412
2413 2016-04-05  Saam barati  <sbarati@apple.com>
2414
2415         JSC SamplingProfiler: Use a thread + sleep loop instead of WTF::WorkQueue for taking samples
2416         https://bugs.webkit.org/show_bug.cgi?id=154017
2417
2418         Reviewed by Geoffrey Garen.
2419
2420         By moving to an explicitly created seperate thread + sample-then-sleep
2421         loop, we can remove a lot of the crufty code around WorkQueue.
2422         We're also getting sample rates that are much closer to what we're
2423         asking the OS for. When the sampling handler was built off of WorkQueue,
2424         we'd often get sample rates much higher than the 1ms we asked for. On Kraken,
2425         we would average about 1.7ms sample rates, even though we'd ask for a 1ms rate.
2426         Now, on Kraken, we're getting about 1.2ms rates. Because we're getting
2427         higher rates, this patch is a performance regression. It's slower because
2428         we're sampling more frequently.
2429
2430         Before this patch, the sampling profiler had the following overhead:
2431         - 10% on Kraken
2432         - 12% on octane
2433         - 15% on AsmBench
2434
2435         With this patch, the sampling profiler has the following overhead:
2436         - 16% on Kraken
2437         - 17% on Octane
2438         - 30% on AsmBench
2439
2440         Comparatively, this new patch has the following overhead over the old sampling profiler:
2441         - 5% on Kraken
2442         - 3.5% on Octane
2443         - 13% slower on AsmBench
2444
2445         * inspector/agents/InspectorScriptProfilerAgent.cpp:
2446         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
2447         * runtime/SamplingProfiler.cpp:
2448         (JSC::SamplingProfiler::SamplingProfiler):
2449         (JSC::SamplingProfiler::~SamplingProfiler):
2450         (JSC::SamplingProfiler::createThreadIfNecessary):
2451         (JSC::SamplingProfiler::timerLoop):
2452         (JSC::SamplingProfiler::takeSample):
2453         (JSC::tryGetBytecodeIndex):
2454         (JSC::SamplingProfiler::shutdown):
2455         (JSC::SamplingProfiler::start):
2456         (JSC::SamplingProfiler::pause):
2457         (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
2458         (JSC::SamplingProfiler::noticeJSLockAcquisition):
2459         (JSC::SamplingProfiler::noticeVMEntry):
2460         (JSC::SamplingProfiler::clearData):
2461         (JSC::SamplingProfiler::stop): Deleted.
2462         (JSC::SamplingProfiler::dispatchIfNecessary): Deleted.
2463         (JSC::SamplingProfiler::dispatchFunction): Deleted.
2464         * runtime/SamplingProfiler.h:
2465         (JSC::SamplingProfiler::setTimingInterval):
2466         (JSC::SamplingProfiler::setStopWatch):
2467         * runtime/VM.cpp:
2468         (JSC::VM::VM):
2469
2470 2016-04-05  Commit Queue  <commit-queue@webkit.org>
2471
2472         Unreviewed, rolling out r199073.
2473         https://bugs.webkit.org/show_bug.cgi?id=156261
2474
2475         This change broke internal Mac builds (Requested by ryanhaddad
2476         on #webkit).
2477
2478         Reverted changeset:
2479
2480         "We should support the ability to do a non-effectful getById"
2481         https://bugs.webkit.org/show_bug.cgi?id=156116
2482         http://trac.webkit.org/changeset/199073
2483
2484 2016-04-05  Youenn Fablet  <youenn.fablet@crf.canon.fr>
2485
2486         [Fetch API] Add a runtime flag to fetch API and related constructs
2487         https://bugs.webkit.org/show_bug.cgi?id=156113
2488  
2489         Reviewed by Alex Christensen.
2490
2491         Add a fetch API runtime flag based on preferences.
2492         Disable fetch API by default.
2493  
2494         * runtime/CommonIdentifiers.h:
2495
2496 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
2497
2498         Unreviewed, fix cloop some more.
2499
2500         * runtime/RegExpInlines.h:
2501         (JSC::RegExp::hasCodeFor):
2502         (JSC::RegExp::hasMatchOnlyCodeFor):
2503
2504 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
2505
2506         Unreviewed, fix cloop.
2507
2508         * jit/CCallHelpers.cpp:
2509
2510 2016-03-18  Filip Pizlo  <fpizlo@apple.com>
2511
2512         JSC should use a shadow stack version of CHICKEN so that debuggers have the option of retrieving tail-deleted frames
2513         https://bugs.webkit.org/show_bug.cgi?id=155598
2514
2515         Reviewed by Saam Barati.
2516         
2517         JSC is the first JSVM to have proper tail calls. This means that error.stack and the
2518         debugger will appear to "delete" strict mode stack frames, if the call that this frame made
2519         was in tail position. This is exactly what functional programmers expect - they don't want
2520         the VM to waste resources on tail-deleted frames to ensure that it's legal to loop forever
2521         using tail calls. It's also something that non-functional programmers fear. It's not clear
2522         that tail-deleted frames would actually degrade the debugging experience, but the fear is
2523         real, so it's worthwhile to do something about it.
2524
2525         It turns out that there is at least one tail call implementation that doesn't suffer from
2526         this problem. It implements proper tail calls in the sense that you won't run out of memory
2527         by tail-looping. It also has the power to show you tail-deleted frames in a backtrace, so
2528         long as you haven't yet run out of memory. It's called CHICKEN Scheme, and it's one of my
2529         favorite hacks:
2530         
2531         http://www.more-magic.net/posts/internals-gc.html
2532
2533         CHICKEN does many awesome things. The intuition from CHICKEN that we use here is a simple
2534         one: what if a tail call still kept the tail-deleted frame, and the GC actually deleted that
2535         frame only once we proved that there was insufficient memory to keep it around.
2536         
2537         CHICKEN does this by reshaping the C stack with longjmp/setjmp. We can't do that because we
2538         can have arbitrary native code, and that native code does not have relocatable stack frames.
2539         
2540         But we can do something almost like CHICKEN on a shadow stack. It's a common trick to have a
2541         VM maintain two stacks - the actual execution stack plus a shadow stack that has some extra
2542         information. The shadow stack can be reshaped, moved, etc, since the VM tightly controls its
2543         layout. The main stack can then continue to obey ABI rules.
2544
2545         This patch implements a mechanism for being able to display stack traces that include
2546         tail-deleted frames. It uses a shadow stack that behaves like a CHICKEN stack: it has all
2547         frames all the time, though we will collect the tail-deleted ones if the stack gets too big.
2548         This new mechanism is called ShadowChicken, obviously: it's CHICKEN on a shadow stack.
2549         
2550         ShadowChicken is always on, but individual CodeBlocks may make their own choices about
2551         whether to opt into it. They will do that at bytecompile time based on the debugger mode on
2552         their global object.
2553
2554         When no CodeBlock opts in, there is no overhead, since ShadowChicken ends up doing nothing
2555         in that case. Well, except when exceptions are thrown. Then it might do some work, but it's
2556         minor.
2557
2558         When all CodeBlocks opt in, there is about 6% overhead. That's too much overhead to enable
2559         this all the time, but it's low enough to justify enabling in the Inspector. It's currently
2560         enabled on all CodeBlocks only when you use an Option. Otherwise it will auto-enable if the
2561         debugger is on.
2562
2563         Note that ShadowChicken attempts to gracefully handle the presence of stack frames that have
2564         no logging. This is essential since we *can* have debugging enabled in one GlobalObject and
2565         disabled in another. Also, some frames don't do ShadowChicken because they just haven't been
2566         hacked to do it yet. Native frames fall into this category, as do the VM entry frames.
2567
2568         This doesn't yet wire ShadowChicken into DebuggerCallFrame. That will take more work. It
2569         just makes a ShadowChicken stack walk function available to jsc. It's used from the
2570         shadow-chicken tests.
2571
2572         * API/JSContextRef.cpp:
2573         (BacktraceFunctor::BacktraceFunctor):
2574         (BacktraceFunctor::operator()):
2575         (JSContextCreateBacktrace):
2576         * CMakeLists.txt:
2577         * JavaScriptCore.xcodeproj/project.pbxproj:
2578         * bytecode/BytecodeList.json:
2579         * bytecode/BytecodeUseDef.h:
2580         (JSC::computeUsesForBytecodeOffset):
2581         (JSC::computeDefsForBytecodeOffset):
2582         * bytecode/CodeBlock.cpp:
2583         (JSC::CodeBlock::dumpBytecode):
2584         (JSC::RecursionCheckFunctor::RecursionCheckFunctor):
2585         (JSC::RecursionCheckFunctor::operator()):
2586         (JSC::CodeBlock::noticeIncomingCall):
2587         * bytecompiler/BytecodeGenerator.cpp:
2588         (JSC::BytecodeGenerator::emitEnter):
2589         (JSC::BytecodeGenerator::emitCallInTailPosition):
2590         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
2591         (JSC::BytecodeGenerator::emitCallVarargs):
2592         (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
2593         (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
2594         (JSC::BytecodeGenerator::emitCallDefineProperty):
2595         * bytecompiler/BytecodeGenerator.h:
2596         * debugger/DebuggerCallFrame.cpp:
2597         (JSC::LineAndColumnFunctor::operator()):
2598         (JSC::LineAndColumnFunctor::column):
2599         (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor):
2600         (JSC::FindCallerMidStackFunctor::operator()):
2601         (JSC::DebuggerCallFrame::DebuggerCallFrame):
2602         * dfg/DFGAbstractInterpreterInlines.h:
2603         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2604         * dfg/DFGByteCodeParser.cpp:
2605         (JSC::DFG::ByteCodeParser::parseBlock):
2606         * dfg/DFGClobberize.h:
2607         (JSC::DFG::clobberize):
2608         * dfg/DFGDoesGC.cpp:
2609         (JSC::DFG::doesGC):
2610         * dfg/DFGFixupPhase.cpp:
2611         (JSC::DFG::FixupPhase::fixupNode):
2612         * dfg/DFGNodeType.h:
2613         * dfg/DFGPredictionPropagationPhase.cpp:
2614         (JSC::DFG::PredictionPropagationPhase::propagate):
2615         * dfg/DFGSafeToExecute.h:
2616         (JSC::DFG::safeToExecute):
2617         * dfg/DFGSpeculativeJIT32_64.cpp:
2618         (JSC::DFG::SpeculativeJIT::compile):
2619         * dfg/DFGSpeculativeJIT64.cpp:
2620         (JSC::DFG::SpeculativeJIT::compile):
2621         * ftl/FTLAbstractHeapRepository.cpp:
2622         * ftl/FTLAbstractHeapRepository.h:
2623         * ftl/FTLCapabilities.cpp:
2624         (JSC::FTL::canCompile):
2625         * ftl/FTLLowerDFGToB3.cpp:
2626         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2627         (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
2628         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
2629         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
2630         (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
2631         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
2632         (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket):
2633         (JSC::FTL::DFG::LowerDFGToB3::boolify):
2634         * heap/Heap.cpp:
2635         (JSC::Heap::markRoots):
2636         (JSC::Heap::visitSamplingProfiler):
2637         (JSC::Heap::visitShadowChicken):
2638         (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
2639         (JSC::Heap::collectImpl):
2640         * heap/Heap.h:
2641         * inspector/ScriptCallStackFactory.cpp:
2642         (Inspector::CreateScriptCallStackFunctor::CreateScriptCallStackFunctor):
2643         (Inspector::CreateScriptCallStackFunctor::operator()):
2644         (Inspector::createScriptCallStack):
2645         * interpreter/CallFrame.h:
2646         (JSC::ExecState::iterate):
2647         * interpreter/Interpreter.cpp:
2648         (JSC::DumpRegisterFunctor::DumpRegisterFunctor):
2649         (JSC::DumpRegisterFunctor::operator()):
2650         (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
2651         (JSC::GetStackTraceFunctor::operator()):
2652         (JSC::Interpreter::getStackTrace):
2653         (JSC::GetCatchHandlerFunctor::handler):
2654         (JSC::GetCatchHandlerFunctor::operator()):
2655         (JSC::notifyDebuggerOfUnwinding):
2656         (JSC::UnwindFunctor::UnwindFunctor):
2657         (JSC::UnwindFunctor::operator()):
2658         (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer):
2659         * interpreter/ShadowChicken.cpp: Added.
2660         (JSC::ShadowChicken::Packet::dump):
2661         (JSC::ShadowChicken::Frame::dump):
2662         (JSC::ShadowChicken::ShadowChicken):
2663         (JSC::ShadowChicken::~ShadowChicken):
2664         (JSC::ShadowChicken::log):
2665         (JSC::ShadowChicken::update):
2666         (JSC::ShadowChicken::visitChildren):
2667         (JSC::ShadowChicken::reset):
2668         (JSC::ShadowChicken::dump):
2669         (JSC::ShadowChicken::functionsOnStack):
2670         * interpreter/ShadowChicken.h: Added.
2671         (JSC::ShadowChicken::Packet::Packet):
2672         (JSC::ShadowChicken::Packet::tailMarker):
2673         (JSC::ShadowChicken::Packet::throwMarker):
2674         (JSC::ShadowChicken::Packet::prologue):
2675         (JSC::ShadowChicken::Packet::tail):
2676         (JSC::ShadowChicken::Packet::throwPacket):
2677         (JSC::ShadowChicken::Packet::operator bool):
2678         (JSC::ShadowChicken::Packet::isPrologue):
2679         (JSC::ShadowChicken::Packet::isTail):
2680         (JSC::ShadowChicken::Packet::isThrow):
2681         (JSC::ShadowChicken::Frame::Frame):
2682         (JSC::ShadowChicken::Frame::operator==):
2683         (JSC::ShadowChicken::Frame::operator!=):
2684         (JSC::ShadowChicken::log):
2685         (JSC::ShadowChicken::logSize):
2686         (JSC::ShadowChicken::addressOfLogCursor):
2687         (JSC::ShadowChicken::logEnd):
2688         * interpreter/ShadowChickenInlines.h: Added.
2689         (JSC::ShadowChicken::iterate):
2690         * interpreter/StackVisitor.h:
2691         (JSC::StackVisitor::Frame::callee):
2692         (JSC::StackVisitor::Frame::codeBlock):
2693         (JSC::StackVisitor::Frame::bytecodeOffset):
2694         (JSC::StackVisitor::Frame::inlineCallFrame):
2695         (JSC::StackVisitor::Frame::isJSFrame):
2696         (JSC::StackVisitor::Frame::isInlinedFrame):
2697         (JSC::StackVisitor::visit):
2698         * jit/CCallHelpers.cpp: Added.
2699         (JSC::CCallHelpers::logShadowChickenProloguePacket):
2700         (JSC::CCallHelpers::logShadowChickenTailPacket):
2701         (JSC::CCallHelpers::setupShadowChickenPacket):
2702         * jit/CCallHelpers.h:
2703         (JSC::CCallHelpers::prepareForTailCallSlow):
2704         * jit/JIT.cpp:
2705         (JSC::JIT::privateCompileMainPass):
2706         * jit/JIT.h:
2707         * jit/JITExceptions.cpp:
2708         (JSC::genericUnwind):
2709         * jit/JITOpcodes.cpp:
2710         (JSC::JIT::emit_op_resume):
2711         (JSC::JIT::emit_op_log_shadow_chicken_prologue):
2712         (JSC::JIT::emit_op_log_shadow_chicken_tail):
2713         * jit/JITOperations.cpp:
2714         * jit/JITOperations.h:
2715         * jsc.cpp:
2716         (GlobalObject::finishCreation):
2717         (FunctionJSCStackFunctor::FunctionJSCStackFunctor):
2718         (FunctionJSCStackFunctor::operator()):
2719         (functionClearSamplingFlags):
2720         (functionShadowChickenFunctionsOnStack):
2721         (functionReadline):
2722         * llint/LLIntOffsetsExtractor.cpp:
2723         * llint/LLIntSlowPaths.cpp:
2724         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2725         (JSC::LLInt::llint_throw_stack_overflow_error):
2726         * llint/LLIntSlowPaths.h:
2727         * llint/LowLevelInterpreter.asm:
2728         * profiler/ProfileGenerator.cpp:
2729         (JSC::AddParentForConsoleStartFunctor::foundParent):
2730         (JSC::AddParentForConsoleStartFunctor::operator()):
2731         * runtime/Error.cpp:
2732         (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
2733         (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
2734         (JSC::addErrorInfoAndGetBytecodeOffset):
2735         * runtime/JSFunction.cpp:
2736         (JSC::RetrieveArgumentsFunctor::result):
2737         (JSC::RetrieveArgumentsFunctor::operator()):
2738         (JSC::retrieveArguments):
2739         (JSC::RetrieveCallerFunctionFunctor::result):
2740         (JSC::RetrieveCallerFunctionFunctor::operator()):
2741         (JSC::retrieveCallerFunction):
2742         * runtime/JSGlobalObjectFunctions.cpp:
2743         (JSC::GlobalFuncProtoGetterFunctor::result):
2744         (JSC::GlobalFuncProtoGetterFunctor::operator()):
2745         (JSC::globalFuncProtoGetter):
2746         (JSC::GlobalFuncProtoSetterFunctor::allowsAccess):
2747         (JSC::GlobalFuncProtoSetterFunctor::operator()):
2748         * runtime/NullSetterFunction.cpp:
2749         (JSC::GetCallerStrictnessFunctor::GetCallerStrictnessFunctor):
2750         (JSC::GetCallerStrictnessFunctor::operator()):
2751         (JSC::GetCallerStrictnessFunctor::callerIsStrict):
2752         (JSC::callerIsStrict):
2753         * runtime/ObjectConstructor.cpp:
2754         (JSC::ObjectConstructorGetPrototypeOfFunctor::result):
2755         (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
2756         (JSC::objectConstructorGetPrototypeOf):
2757         * runtime/Options.h:
2758         * runtime/VM.cpp:
2759         (JSC::VM::VM):
2760         (JSC::SetEnabledProfilerFunctor::operator()):
2761         * runtime/VM.h:
2762         (JSC::VM::shouldBuilderPCToCodeOriginMapping):
2763         (JSC::VM::bytecodeIntrinsicRegistry):
2764         (JSC::VM::shadowChicken):
2765         * tests/stress/resources/shadow-chicken-support.js: Added.
2766         (describeFunction):
2767         (describeArray):
2768         (expectStack):
2769         (initialize):
2770         * tests/stress/shadow-chicken-disabled.js: Added.
2771         (test1.foo):
2772         (test1.bar):
2773         (test1.baz):
2774         (test1):
2775         (test2.foo):
2776         (test2.bar):
2777         (test2.baz):
2778         (test2):
2779         (test3.foo):
2780         (test3.bar):
2781         (test3.baz):
2782         (test3):
2783         * tests/stress/shadow-chicken-enabled.js: Added.
2784         (test1.foo):
2785         (test1.bar):
2786         (test1.baz):
2787         (test1):
2788         (test2.foo):
2789         (test2.bar):
2790         (test2.baz):
2791         (test2):
2792         (test3.bob):
2793         (test3.thingy):
2794         (test3.foo):
2795         (test3.bar):
2796         (test3.baz):
2797         (test3):
2798         (test4.bob):
2799         (test4.thingy):
2800         (test4.foo):
2801         (test4.bar):
2802         (test4.baz):
2803         (test4):
2804         (test5.foo):
2805         (test5):
2806         * tools/JSDollarVMPrototype.cpp:
2807         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
2808         (JSC::CallerFrameJITTypeFunctor::operator()):
2809         (JSC::CallerFrameJITTypeFunctor::jitType):
2810         (JSC::functionLLintTrue):
2811         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
2812         (JSC::CellAddressCheckFunctor::operator()):
2813         (JSC::JSDollarVMPrototype::isValidCell):
2814         (JSC::JSDollarVMPrototype::isValidCodeBlock):
2815         (JSC::JSDollarVMPrototype::codeBlockForFrame):
2816         (JSC::PrintFrameFunctor::PrintFrameFunctor):
2817         (JSC::PrintFrameFunctor::operator()):
2818         (JSC::printCallFrame):
2819
2820 2016-03-19  Filip Pizlo  <fpizlo@apple.com>
2821
2822         DFG and FTL should constant-fold RegExpExec, RegExpTest, and StringReplace
2823         https://bugs.webkit.org/show_bug.cgi?id=155270
2824
2825         Reviewed by Saam Barati.
2826
2827         This enables constant-folding of RegExpExec, RegExpTest, and StringReplace.
2828
2829         It's now possible to run Yarr on the JIT threads. Since previous work on constant-folding
2830         strings gave the DFG an API for reasoning about JSString constants in terms of
2831         JIT-thread-local WTF::Strings, it's now super easy to just pass strings to Yarr and build IR
2832         based on the results.
2833
2834         But RegExpExec is hard: the folded version still must allocate a RegExpMatchesArray. We must
2835         use the same Structure that the code would have used or else we'll pollute the program's
2836         inline caches. Also, RegExpMatchesArray.h|cpp will allocate the array and its named
2837         properties in one go - we don't want to lose that optimization. So, this patch enables
2838         MaterializeNewObject to allocate objects or arrays with any number of indexed or named
2839         properties. Previously it could only handle objects (but not arrays) and named properties
2840         (but not indexed ones).
2841
2842         This also adds a few minor things for setting the RegExpConstructor cached result.
2843
2844         This is about a 2x speed-up on microbenchmarks when we fold a match success and about a
2845         8x speed-up when we fold a match failure. It's a 10% speed-up on Octane/regexp.
2846
2847         * JavaScriptCore.xcodeproj/project.pbxproj:
2848         * dfg/DFGAbstractInterpreterInlines.h:
2849         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2850         * dfg/DFGClobberize.h:
2851         (JSC::DFG::clobberize):
2852         * dfg/DFGDoesGC.cpp:
2853         (JSC::DFG::doesGC):
2854         * dfg/DFGFixupPhase.cpp:
2855         (JSC::DFG::FixupPhase::fixupNode):
2856         * dfg/DFGGraph.cpp:
2857         (JSC::DFG::Graph::dump):
2858         * dfg/DFGInsertionSet.cpp:
2859         (JSC::DFG::InsertionSet::insertSlow):
2860         (JSC::DFG::InsertionSet::execute):
2861         * dfg/DFGInsertionSet.h:
2862         (JSC::DFG::InsertionSet::insertCheck):
2863         * dfg/DFGLazyJSValue.cpp:
2864         (JSC::DFG::LazyJSValue::tryGetString):
2865         * dfg/DFGMayExit.cpp:
2866         (JSC::DFG::mayExit):
2867         * dfg/DFGNode.h:
2868         (JSC::DFG::StackAccessData::flushedAt):
2869         (JSC::DFG::OpInfo::OpInfo): Deleted.
2870         * dfg/DFGNodeType.h:
2871         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2872         * dfg/DFGObjectMaterializationData.cpp:
2873         (JSC::DFG::ObjectMaterializationData::dump):
2874         (JSC::DFG::PhantomPropertyValue::dump): Deleted.
2875         (JSC::DFG::ObjectMaterializationData::oneWaySimilarityScore): Deleted.
2876         (JSC::DFG::ObjectMaterializationData::similarityScore): Deleted.
2877         * dfg/DFGObjectMaterializationData.h:
2878         (JSC::DFG::PhantomPropertyValue::PhantomPropertyValue): Deleted.
2879         (JSC::DFG::PhantomPropertyValue::operator==): Deleted.
2880         * dfg/DFGOpInfo.h: Added.
2881         (JSC::DFG::OpInfo::OpInfo):
2882         * dfg/DFGOperations.cpp:
2883         * dfg/DFGOperations.h:
2884         * dfg/DFGPredictionPropagationPhase.cpp:
2885         (JSC::DFG::PredictionPropagationPhase::propagate):
2886         * dfg/DFGPromotedHeapLocation.cpp:
2887         (WTF::printInternal):
2888         * dfg/DFGPromotedHeapLocation.h:
2889         * dfg/DFGSafeToExecute.h:
2890         (JSC::DFG::safeToExecute):
2891         * dfg/DFGSpeculativeJIT.cpp:
2892         (JSC::DFG::SpeculativeJIT::~SpeculativeJIT):
2893         (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
2894         (JSC::DFG::SpeculativeJIT::emitGetLength):
2895         (JSC::DFG::SpeculativeJIT::compileLazyJSConstant):
2896         (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
2897         (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
2898         (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): Deleted.
2899         * dfg/DFGSpeculativeJIT.h:
2900         (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
2901         * dfg/DFGSpeculativeJIT32_64.cpp:
2902         (JSC::DFG::SpeculativeJIT::compile):
2903         * dfg/DFGSpeculativeJIT64.cpp:
2904         (JSC::DFG::SpeculativeJIT::compile):
2905         * dfg/DFGStoreBarrierInsertionPhase.cpp:
2906         * dfg/DFGStrengthReductionPhase.cpp:
2907         (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase):
2908         (JSC::DFG::StrengthReductionPhase::handleNode):
2909         (JSC::DFG::StrengthReductionPhase::handleCommutativity):
2910         (JSC::DFG::StrengthReductionPhase::executeInsertionSet):
2911         * dfg/DFGValidate.cpp:
2912         (JSC::DFG::Validate::validate):
2913         (JSC::DFG::Validate::validateCPS):
2914         * ftl/FTLAbstractHeapRepository.cpp:
2915         * ftl/FTLAbstractHeapRepository.h:
2916         * ftl/FTLCapabilities.cpp:
2917         (JSC::FTL::canCompile):
2918         * ftl/FTLLowerDFGToB3.cpp:
2919         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2920         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
2921         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
2922         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
2923         (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
2924         (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
2925         (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
2926         (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
2927         (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
2928         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
2929         (JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc):
2930         (JSC::FTL::DFG::LowerDFGToB3::unboxDouble):
2931         * ftl/FTLOperations.cpp:
2932         (JSC::FTL::operationPopulateObjectInOSR):
2933         (JSC::FTL::operationNewObjectWithButterfly): Deleted.
2934         * ftl/FTLOperations.h:
2935         * inspector/ContentSearchUtilities.cpp:
2936         * runtime/JSObject.h:
2937         (JSC::JSObject::createRawObject):
2938         (JSC::JSFinalObject::create):
2939         * runtime/RegExp.cpp:
2940         (JSC::RegExp::compile):
2941         (JSC::RegExp::match):
2942         (JSC::RegExp::matchConcurrently):
2943         (JSC::RegExp::compileMatchOnly):
2944         (JSC::RegExp::deleteCode):
2945         * runtime/RegExp.h:
2946         * runtime/RegExpCachedResult.h:
2947         (JSC::RegExpCachedResult::offsetOfLastRegExp):
2948         (JSC::RegExpCachedResult::offsetOfLastInput):
2949         (JSC::RegExpCachedResult::offsetOfResult):
2950         (JSC::RegExpCachedResult::offsetOfReified):
2951         * runtime/RegExpConstructor.h:
2952         (JSC::RegExpConstructor::offsetOfCachedResult):
2953         * runtime/RegExpInlines.h:
2954         (JSC::RegExp::hasCodeFor):
2955         (JSC::RegExp::compileIfNecessary):
2956         (JSC::RegExp::matchInline):
2957         (JSC::RegExp::hasMatchOnlyCodeFor):
2958         (JSC::RegExp::compileIfNecessaryMatchOnly):
2959         * runtime/RegExpObjectInlines.h:
2960         (JSC::RegExpObject::execInline):
2961         * runtime/StringPrototype.cpp:
2962         (JSC::substituteBackreferencesSlow):
2963         (JSC::substituteBackreferencesInline):
2964         (JSC::substituteBackreferences):
2965         (JSC::StringRange::StringRange):
2966         * runtime/StringPrototype.h:
2967         * runtime/VM.h:
2968         * tests/stress/simple-regexp-exec-folding-fail.js: Added.
2969         (foo):
2970         * tests/stress/simple-regexp-exec-folding.js: Added.
2971         (foo):
2972         * tests/stress/simple-regexp-test-folding-fail.js: Added.
2973         (foo):
2974         * tests/stress/simple-regexp-test-folding.js: Added.
2975         (foo):
2976         * yarr/RegularExpression.cpp:
2977         * yarr/Yarr.h:
2978         * yarr/YarrInterpreter.cpp:
2979         (JSC::Yarr::Interpreter::interpret):
2980         (JSC::Yarr::ByteCompiler::ByteCompiler):
2981         (JSC::Yarr::ByteCompiler::compile):
2982         (JSC::Yarr::ByteCompiler::checkInput):
2983         (JSC::Yarr::byteCompile):
2984         (JSC::Yarr::interpret):
2985         * yarr/YarrInterpreter.h:
2986         (JSC::Yarr::BytecodePattern::BytecodePattern):
2987
2988 2016-04-05  Keith Miller  <keith_miller@apple.com>
2989
2990         We should support the ability to do a non-effectful getById
2991         https://bugs.webkit.org/show_bug.cgi?id=156116
2992
2993         Reviewed by Benjamin Poulain.
2994
2995         Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
2996         useful because it enables us to take different code paths based on values that we would
2997         otherwise not be able to have knowledge of. This patch adds this new feature called
2998         try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
2999         an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
3000         GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
3001         undefined if the slot is unset.  If the slot is proxied or any other cases then the result
3002         is null. In theory, if we ever wanted to check for null we could add a sentinal object to
3003         the global object that indicates we could not get the result.
3004
3005         In order to implement this feature we add a new enum GetByIdKind that indicates what to do
3006         for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
3007         get_by_id the same way we would for load and return the value at the appropriate offset.
3008         Additionally, in order to make sure the we can properly compare the GetterSetter object
3009         with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
3010         GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
3011         likely to have little to no impact on memory usage as normal accessors are generally rare.
3012
3013         * JavaScriptCore.xcodeproj/project.pbxproj:
3014         * builtins/BuiltinExecutables.cpp:
3015         (JSC::BuiltinExecutables::createDefaultConstructor):
3016         (JSC::BuiltinExecutables::createBuiltinExecutable):
3017         (JSC::createBuiltinExecutable):
3018         (JSC::BuiltinExecutables::createExecutable):
3019         (JSC::createExecutableInternal): Deleted.
3020         * builtins/BuiltinExecutables.h:
3021         * bytecode/BytecodeIntrinsicRegistry.h:
3022         * bytecode/BytecodeList.json:
3023         * bytecode/BytecodeUseDef.h:
3024         (JSC::computeUsesForBytecodeOffset):
3025         (JSC::computeDefsForBytecodeOffset):
3026         * bytecode/CodeBlock.cpp:
3027         (JSC::CodeBlock::dumpBytecode):
3028         * bytecode/PolymorphicAccess.cpp:
3029         (JSC::AccessCase::tryGet):
3030         (JSC::AccessCase::generate):
3031         (WTF::printInternal):
3032         * bytecode/PolymorphicAccess.h:
3033         (JSC::AccessCase::isGet): Deleted.
3034         (JSC::AccessCase::isPut): Deleted.
3035         (JSC::AccessCase::isIn): Deleted.
3036         * bytecode/StructureStubInfo.cpp:
3037         (JSC::StructureStubInfo::reset):
3038         * bytecode/StructureStubInfo.h:
3039         * bytecompiler/BytecodeGenerator.cpp:
3040         (JSC::BytecodeGenerator::emitTryGetById):
3041         * bytecompiler/BytecodeGenerator.h:
3042         * bytecompiler/NodesCodegen.cpp:
3043         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
3044         * dfg/DFGSpeculativeJIT32_64.cpp:
3045         (JSC::DFG::SpeculativeJIT::cachedGetById):
3046         * dfg/DFGSpeculativeJIT64.cpp:
3047         (JSC::DFG::SpeculativeJIT::cachedGetById):
3048         * ftl/FTLLowerDFGToB3.cpp:
3049         (JSC::FTL::DFG::LowerDFGToB3::getById):
3050         * jit/JIT.cpp:
3051         (JSC::JIT::privateCompileMainPass):
3052         (JSC::JIT::privateCompileSlowCases):
3053         * jit/JIT.h:
3054         * jit/JITInlineCacheGenerator.cpp:
3055         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
3056         * jit/JITInlineCacheGenerator.h:
3057         * jit/JITInlines.h:
3058         (JSC::JIT::callOperation):
3059         * jit/JITOperations.cpp:
3060         * jit/JITOperations.h:
3061         * jit/JITPropertyAccess.cpp:
3062         (JSC::JIT::emitGetByValWithCachedId):
3063         (JSC::JIT::emit_op_try_get_by_id):
3064         (JSC::JIT::emitSlow_op_try_get_by_id):
3065         (JSC::JIT::emit_op_get_by_id):
3066         * jit/JITPropertyAccess32_64.cpp:
3067         (JSC::JIT::emitGetByValWithCachedId):
3068         (JSC::JIT::emit_op_try_get_by_id):
3069         (JSC::JIT::emitSlow_op_try_get_by_id):
3070         (JSC::JIT::emit_op_get_by_id):
3071         * jit/Repatch.cpp:
3072         (JSC::repatchByIdSelfAccess):
3073         (JSC::appropriateOptimizingGetByIdFunction):
3074         (JSC::appropriateGenericGetByIdFunction):
3075         (JSC::tryCacheGetByID):
3076         (JSC::repatchGetByID):
3077         (JSC::resetGetByID):
3078         * jit/Repatch.h:
3079         * jsc.cpp:
3080         (GlobalObject::finishCreation):
3081         (functionGetGetterSetter):
3082         (functionCreateBuiltin):
3083         * llint/LLIntData.cpp:
3084         (JSC::LLInt::Data::performAssertions):
3085         * llint/LLIntSlowPaths.cpp:
3086         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3087         * llint/LLIntSlowPaths.h:
3088         * llint/LowLevelInterpreter.asm:
3089         * runtime/GetterSetter.cpp:
3090         * runtime/GetterSetter.h:
3091         * runtime/JSType.h:
3092         * runtime/PropertySlot.cpp:
3093         (JSC::PropertySlot::getPureResult):
3094         * runtime/PropertySlot.h:
3095         * runtime/ProxyObject.cpp:
3096         (JSC::ProxyObject::getOwnPropertySlotCommon):
3097         * tests/stress/try-get-by-id.js: Added.
3098         (tryGetByIdText):
3099         (getCaller.obj.1.throw.new.Error.let.func):
3100         (getCaller.obj.1.throw.new.Error):
3101         (throw.new.Error.get let):
3102         (throw.new.Error.):
3103         (throw.new.Error.let.get createBuiltin):
3104         (get let):
3105         (let.get createBuiltin):
3106         (let.func):
3107         (get let.func):
3108         (get throw):
3109
3110 2016-04-05  Saam barati  <sbarati@apple.com>
3111
3112         jsc-layout-tests.yaml/js/script-tests/regress-141098.js failing on Yosemite Debug after r198989
3113         https://bugs.webkit.org/show_bug.cgi?id=156187
3114
3115         Reviewed by Filip Pizlo.
3116
3117         This is a speculative fix. Lets see if the prevents the timeout.
3118
3119         * parser/Parser.cpp:
3120         (JSC::Parser<LexerType>::parseStatementListItem):
3121
3122 2016-04-04  Filip Pizlo  <fpizlo@apple.com>
3123
3124         PolymorphicAccess should have a MegamorphicLoad case
3125         https://bugs.webkit.org/show_bug.cgi?id=156182
3126
3127         Reviewed by Geoffrey Garen and Keith Miller.
3128
3129         This introduces a new case to PolymorphicAccess called MegamorphicLoad. This inlines the lookup in
3130         the PropertyTable. It's cheaper than switching on a huge number of cases and it's cheaper than
3131         calling into C++ to do the same job - particularly since inlining the lookup into an access means
3132         that we can precompute the hash code.
3133
3134         When writing the inline code for the hashtable lookup, I found that our hashing algorithm was not
3135         optimal. It used a double-hashing method for reducing collision pathologies. This is great for
3136         improving the performance of some worst-case scenarios. But this misses the point of a hashtable: we
3137         want to optimize the average-case performance. When optimizing for average-case, we can choose to
3138         either focus on maximizing the likelihood of the fast case happening, or to minimize the cost of the
3139         worst-case, or to minimize the cost of the fast case. Even a very basic hashtable will achieve a high
3140         probability of hitting the fast case. So, doing work to reduce the likelihood of a worst-case
3141         pathology only makes sense if it also preserves the good performance of the fast case, or reduces the
3142         likelihood of the worst-case by so much that it's a win for the average case even with a slow-down in
3143         the fast case.
3144
3145         I don't believe, based on looking at how the double-hashing is implemented, that it's possible that
3146         this preserves the good performance of the fast case. It requires at least one more value to be live
3147         around the loop, and dramatically increases the register pressure at key points inside the loop. The
3148         biggest offender is the doubleHash() method itself. There is no getting around how bad this is: if
3149         the compiler live-range-splits that method to death to avoid degrading register pressure elsewhere
3150         then we will pay a steep price anytime we take the second iteration around the loop; but if the
3151         compiler doesn't split around the call then the hashtable lookup fast path will be full of spills on
3152         some architectures (I performed biological register allocation and found that I needed 9 registers
3153         for complete lookup, while x86-64 has only 6 callee-saves; OTOH ARM64 has 10 callee-saves so it might
3154         be better off).
3155
3156         Hence, this patch changes the hashtable lookup to use simple linear probing. This was not a slow-down
3157         on anything, and it made MegamorphicLoad much more sensible since it is less likely to have to spill.
3158
3159         There are some other small changes in this patch, like rationalizing the IC's choice between giving
3160         up after a repatch (i.e. never trying again) and just pretending that nothing happened (so we can
3161         try to repatch again in the future). It looked like the code in Repatch.cpp was set up to be able to
3162         choose between those options, but we weren't fully taking advantage of it because the
3163         regenerateWithCase() method just returned null for any failure, and didn't say whether it was the
3164         sort of failure that renders the inline cache unrepatchable (like memory allocation failure). Now
3165         this is all made explicit. I wanted to make sure this change happened in this patch since the
3166         MegamorphicLoad code automagically generates a MegamorphicLoad case by coalescing other cases. Since
3167         this is intended to avoid blowing out the cache and making it unrepatchable, I wanted to make sure
3168         that the rules for giving up were something that made sense to me.
3169         
3170         This is a big win on microbenchmarks. It's neutral on traditional JS benchmarks. It's a slight
3171         speed-up for page loading, because many real websites like to have megamorphic property accesses.
3172
3173         * bytecode/PolymorphicAccess.cpp:
3174         (JSC::AccessGenerationResult::dump):
3175         (JSC::AccessGenerationState::addWatchpoint):
3176         (JSC::AccessCase::get):
3177         (JSC::AccessCase::megamorphicLoad):
3178         (JSC::AccessCase::replace):
3179         (JSC::AccessCase::guardedByStructureCheck):
3180         (JSC::AccessCase::couldStillSucceed):
3181         (JSC::AccessCase::canBeReplacedByMegamorphicLoad):
3182         (JSC::AccessCase::canReplace):
3183         (JSC::AccessCase::generateWithGuard):
3184         (JSC::AccessCase::generate):
3185         (JSC::PolymorphicAccess::PolymorphicAccess):
3186         (JSC::PolymorphicAccess::~PolymorphicAccess):
3187         (JSC::PolymorphicAccess::regenerateWithCases):
3188         (JSC::PolymorphicAccess::regenerateWithCase):
3189         (WTF::printInternal):
3190         * bytecode/PolymorphicAccess.h:
3191         (JSC::AccessCase::isGet):
3192         (JSC::AccessCase::isPut):
3193         (JSC::AccessCase::isIn):
3194         (JSC::AccessGenerationResult::AccessGenerationResult):
3195         (JSC::AccessGenerationResult::operator==):
3196         (JSC::AccessGenerationResult::operator!=):
3197         (JSC::AccessGenerationResult::operator bool):
3198         (JSC::AccessGenerationResult::kind):
3199         (JSC::AccessGenerationResult::code):
3200         (JSC::AccessGenerationResult::madeNoChanges):
3201         (JSC::AccessGenerationResult::gaveUp):
3202         (JSC::AccessGenerationResult::generatedNewCode):
3203         (JSC::PolymorphicAccess::isEmpty):
3204         (JSC::AccessGenerationState::AccessGenerationState):
3205         * bytecode/StructureStubInfo.cpp:
3206         (JSC::StructureStubInfo::aboutToDie):
3207         (JSC::StructureStubInfo::addAccessCase):
3208         * bytecode/StructureStubInfo.h:
3209         * jit/AssemblyHelpers.cpp:
3210         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
3211         (JSC::AssemblyHelpers::loadProperty):
3212         (JSC::emitRandomThunkImpl):
3213         (JSC::AssemblyHelpers::emitRandomThunk):
3214         (JSC::AssemblyHelpers::emitLoadStructure):
3215         * jit/AssemblyHelpers.h:
3216         (JSC::AssemblyHelpers::loadValue):
3217         (JSC::AssemblyHelpers::moveValueRegs):
3218         (JSC::AssemblyHelpers::argumentsStart):
3219         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
3220         (JSC::AssemblyHelpers::emitLoadStructure): Deleted.
3221         * jit/GPRInfo.cpp:
3222         (JSC::JSValueRegs::dump):
3223         * jit/GPRInfo.h:
3224         (JSC::JSValueRegs::uses):
3225         * jit/Repatch.cpp:
3226         (JSC::replaceWithJump):
3227         (JSC::tryCacheGetByID):
3228         (JSC::tryCachePutByID):
3229         (JSC::tryRepatchIn):
3230         * jit/ThunkGenerators.cpp:
3231         (JSC::virtualThunkFor):
3232         * runtime/Options.h:
3233         * runtime/PropertyMapHashTable.h:
3234         (JSC::PropertyTable::begin):
3235         (JSC::PropertyTable::find):
3236         (JSC::PropertyTable::get):
3237         * runtime/Structure.h:
3238
3239 2016-04-05  Antoine Quint  <graouts@apple.com>
3240
3241         [WebGL2] Turn the ENABLE_WEBGL2 flag on
3242         https://bugs.webkit.org/show_bug.cgi?id=156061
3243         <rdar://problem/25463193>
3244
3245         Reviewed by Alex Christensen.
3246
3247         * Configurations/FeatureDefines.xcconfig:
3248         * runtime/CommonIdentifiers.h:
3249
3250         Define the conditionalized classes WebGL2RenderingContext and WebGLVertexArrayObject. 
3251
3252 2016-04-04  Zan Dobersek  <zdobersek@igalia.com>
3253
3254         Add missing EABI_32BIT_DUMMY_ARG arguments for some callOperation(J_JITOperation_EGReoJ, ...) overloads
3255         https://bugs.webkit.org/show_bug.cgi?id=156161
3256
3257         Reviewed by Yusuke Suzuki.
3258
3259         r197641 added a couple of callOperation(J_JITOperation_EGReoJ, ...) overloads
3260         that handle arguments split into the tag and the payload. The two were split
3261         between the last argument register and the stack on 32-bit ARM EABI systems,
3262         causing incorrect behavior.
3263
3264         Adding EABI_32BIT_DUMMY_ARG pushes the tag and payload together onto the
3265         stack, removing the issue.
3266
3267         * dfg/DFGSpeculativeJIT.h:
3268         (JSC::DFG::SpeculativeJIT::callOperation):
3269
3270 2016-04-04  Joseph Pecoraro  <pecoraro@apple.com>
3271
3272         Avoid copying ModuleLoaderObject.js to resources bundle
3273         https://bugs.webkit.org/show_bug.cgi?id=156188
3274         <rdar://problem/25534383>
3275
3276         Reviewed by Alexey Proskuryakov.
3277
3278         * JavaScriptCore.xcodeproj/project.pbxproj:
3279
3280 2016-04-04  Geoffrey Garen  <ggaren@apple.com>
3281
3282         Unreviewed, rolling out r199016.
3283         https://bugs.webkit.org/show_bug.cgi?id=156140
3284
3285         "Regressed Octane and Kraken on the perf bots."
3286
3287         Reverted changeset:
3288
3289         CopiedBlock should be 16kB
3290         https://bugs.webkit.org/show_bug.cgi?id=156168
3291         http://trac.webkit.org/changeset/199016
3292
3293 2016-04-04  Benjamin Poulain  <bpoulain@apple.com>
3294
3295         [JSC][x86] Fix an assertion in MacroAssembler::branch8()
3296         https://bugs.webkit.org/show_bug.cgi?id=156181
3297
3298         Reviewed by Geoffrey Garen.
3299
3300         * assembler/MacroAssemblerX86Common.h:
3301         (JSC::MacroAssemblerX86Common::branch8):
3302         The test was wrong because valid negative numbers have ones
3303         in the top bits.
3304
3305         I replaced the assertion to be explicit about the valid range.
3306
3307 2016-04-04  Chris Dumez  <cdumez@apple.com>
3308
3309         Regression(r196145): Crash in getOwnPropertyDescriptor on http://www.history.com/shows/vikings
3310         https://bugs.webkit.org/show_bug.cgi?id=156136
3311         <rdar://problem/25410767>
3312
3313         Reviewed by Ryosuke Niwa.
3314
3315         Add a few more identifiers for using in the generated bindings.
3316
3317         * runtime/CommonIdentifiers.h:
3318
3319 2016-04-04  Geoffrey Garen  <ggaren@apple.com>
3320
3321         CopiedBlock should be 16kB
3322         https://bugs.webkit.org/show_bug.cgi?id=156168
3323
3324         Reviewed by Mark Lam.
3325
3326         MarkedBlock is 16kB, and bmalloc's largest fast-path allocation is 16kB,
3327         and the largest page size on Apple devices is 16kB -- so this change
3328         should improve sharing and recycling and keep us on the fast path more.
3329
3330         32kB is also super aggro. At 16kB, we support allocations up to 8kB,
3331         which covers 99.3% of allocations on facebook.com. The 32kB block size
3332         only covered an additional 0.2% of allocations.
3333
3334         * heap/CopiedBlock.h:
3335
3336 2016-04-04  Carlos Garcia Campos  <cgarcia@igalia.com>
3337