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