FixupPhase should be more eager to demote bit math to untyped
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-05-16  Filip Pizlo  <fpizlo@apple.com>
2
3         FixupPhase should be more eager to demote bit math to untyped
4         https://bugs.webkit.org/show_bug.cgi?id=157746
5
6         Reviewed by Mark Lam.
7         
8         This just makes the logic for how we fixup bit math match the way we do it in other places.
9         This doesn't affect performance on any major benchmark but it's a big win on new
10         microbenchmarks added in this change.
11         
12         Details:
13
14         object-and                                     11.1610+-0.7602     ^      4.8105+-0.1690        ^ definitely 2.3201x faster
15         object-or                                      11.0845+-0.2487     ^      4.7146+-0.0374        ^ definitely 2.3511x faster
16         object-xor                                     10.2946+-0.9946     ^      4.7278+-0.0814        ^ definitely 2.1775x faster
17         object-lshift                                  10.4896+-1.0867     ^      4.7699+-0.0721        ^ definitely 2.1991x faster
18         object-rshift                                  11.1239+-0.5010     ^      4.7194+-0.0445        ^ definitely 2.3570x faster
19         object-urshift                                 10.9745+-0.1315     ^      4.7848+-0.0479        ^ definitely 2.2936x faster
20
21         * dfg/DFGFixupPhase.cpp:
22         (JSC::DFG::FixupPhase::fixupNode):
23
24 2016-05-15  Michael Saboff  <msaboff@apple.com>
25
26         RegExp /y flag incorrect handling of mixed-length alternation
27         https://bugs.webkit.org/show_bug.cgi?id=157723
28
29         Reviewed by Filip Pizlo.
30
31         Previously for sticky patterns, we were bailing out and exiting when backtracking
32         alternatives with dissimilar match lengths.  Deleted that code.  Instead, for
33         sticky patterns we need to process the backtracking except for advancing to the
34         next input index.
35
36         * yarr/YarrJIT.cpp:
37         (JSC::Yarr::YarrGenerator::backtrack):
38
39 2016-05-15  Filip Pizlo  <fpizlo@apple.com>
40
41         DFG::Plan shouldn't read from its VM once it's been cancelled
42         https://bugs.webkit.org/show_bug.cgi?id=157726
43
44         Reviewed by Saam Barati.
45         
46         Plan::vm was a reference, not a pointer, and so wasn't nulled by Plan::cancel(). So, a
47         cancelled plan may have a dangling pointer to a VM: we could delete the VM after cancelling
48         the plan.
49         
50         Prior to http://trac.webkit.org/changeset/200705, this was probably fine because nobody
51         would read Plan::vm if the plan was cancelled. But r200705 changed that. It was a hard
52         regression to spot because usually a cancelled plan will still refer to a valid VM.
53         
54         This change fixes the regression and makes it a lot easier to spot the regression in the
55         future. Plan::vm is now a pointer and we null it in Plan::cancel(). Now if you make this
56         mistake, you will get a crash anytime the Plan is cancelled, not just anytime the plan is
57         cancelled and the VM gets deleted. Also, it's now very clear what to do when you want to
58         use Plan::vm on the cancel path: you can null-check vm; if it's null, assume the worst.
59         
60         Because we null the VM of a cancelled plan, we cannot have Safepoint::vm() return the
61         plan's VM anymore. That's because when we cancel a plan that is at a safepoint, we use the
62         safepoint's VM to determine whether this is one of our safepoints *after* the plan is
63         already cancelled. So, Safepoint now has its own copy of m_vm, and that copy gets nulled
64         when the Safepoint is cancelled. The Safepoint's m_vm will be nulled moments after Plan's
65         vm gets nulled (see Worklist::removeDeadPlans(), which has a cancel path for Plans in one
66         loop and a cancel path for Safepoints in the loop after it).
67
68         * dfg/DFGJITFinalizer.cpp:
69         (JSC::DFG::JITFinalizer::finalizeCommon):
70         * dfg/DFGPlan.cpp:
71         (JSC::DFG::Plan::Plan):
72         (JSC::DFG::Plan::computeCompileTimes):
73         (JSC::DFG::Plan::reportCompileTimes):
74         (JSC::DFG::Plan::compileInThreadImpl):
75         (JSC::DFG::Plan::reallyAdd):
76         (JSC::DFG::Plan::notifyCompiling):
77         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
78         (JSC::DFG::Plan::cancel):
79         * dfg/DFGPlan.h:
80         (JSC::DFG::Plan::canTierUpAndOSREnter):
81         * dfg/DFGSafepoint.cpp:
82         (JSC::DFG::Safepoint::cancel):
83         (JSC::DFG::Safepoint::vm):
84         * dfg/DFGSafepoint.h:
85         * dfg/DFGWorklist.cpp:
86         (JSC::DFG::Worklist::isActiveForVM):
87         (JSC::DFG::Worklist::waitUntilAllPlansForVMAreReady):
88         (JSC::DFG::Worklist::removeAllReadyPlansForVM):
89         (JSC::DFG::Worklist::rememberCodeBlocks):
90         (JSC::DFG::Worklist::visitWeakReferences):
91         (JSC::DFG::Worklist::removeDeadPlans):
92         (JSC::DFG::Worklist::runThread):
93         * ftl/FTLJITFinalizer.cpp:
94         (JSC::FTL::JITFinalizer::finalizeFunction):
95
96 2016-05-15  Yusuke Suzuki  <utatane.tea@gmail.com>
97
98         Modernize Intl constructors; using InternalFunction::createSubclassStructure
99         https://bugs.webkit.org/show_bug.cgi?id=157082
100
101         Reviewed by Darin Adler.
102
103         Previously, Intl constructors retrieve "prototype" to inherit the "new.target".
104         At that time, this mis-assumed that getDirect() always returns meaningful JS value.
105         Actually, it returns an empty value if a property does not exist.
106
107         Instead of fixing this assertion, we now use InternalFunction::createSubclassStructure
108         in Intl constructors. It is modern and preferable way since it can cache the derived
109         structures in InternalFunction.
110
111         This patch also cleans up the workaround in Intl.NumberFormat and Intl.DateTimeFormat.
112         Those code are largely duplicate. This is now extracted into
113         constructIntlInstanceWithWorkaroundForLegacyIntlConstructor. This clean up does not
114         have any behavior changes. They are already tested in LayoutTests/js/intl-datetimeformat
115         and LayoutTests/js/intl-numberformat.
116
117         * JavaScriptCore.xcodeproj/project.pbxproj:
118         * runtime/IntlCollator.cpp:
119         (JSC::IntlCollator::create):
120         * runtime/IntlCollator.h:
121         * runtime/IntlCollatorConstructor.cpp:
122         (JSC::constructIntlCollator):
123         (JSC::callIntlCollator):
124         * runtime/IntlDateTimeFormat.cpp:
125         (JSC::IntlDateTimeFormat::create):
126         * runtime/IntlDateTimeFormat.h:
127         * runtime/IntlDateTimeFormatConstructor.cpp:
128         (JSC::constructIntlDateTimeFormat):
129         (JSC::callIntlDateTimeFormat):
130         * runtime/IntlDateTimeFormatPrototype.cpp:
131         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
132         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
133         * runtime/IntlNumberFormat.cpp:
134         (JSC::IntlNumberFormat::create):
135         * runtime/IntlNumberFormat.h:
136         * runtime/IntlNumberFormatConstructor.cpp:
137         (JSC::constructIntlNumberFormat):
138         (JSC::callIntlNumberFormat):
139         * runtime/IntlNumberFormatPrototype.cpp:
140         (JSC::IntlNumberFormatPrototypeGetterFormat):
141         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
142         * runtime/IntlObjectInlines.h: Added.
143         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
144         * tests/stress/intl-constructors-with-proxy.js: Added.
145         (shouldBe):
146         (throw.new.Error.Empty):
147         (throw.new.Error):
148         (shouldBe.Empty):
149
150 2016-05-14  Joseph Pecoraro  <pecoraro@apple.com>
151
152         Remove LegacyProfiler
153         https://bugs.webkit.org/show_bug.cgi?id=153565
154
155         Reviewed by Mark Lam.
156
157         JavaScriptCore now provides a sampling profiler and it is enabled
158         by all ports. Web Inspector switched months ago to using the
159         sampling profiler and displaying its data. Remove the legacy
160         profiler, as it is no longer being used by anything other then
161         console.profile and tests. We will update console.profile's
162         behavior soon to have new behavior and use the sampling data.
163
164         * API/JSProfilerPrivate.cpp: Removed.
165         * API/JSProfilerPrivate.h: Removed.
166         * CMakeLists.txt:
167         * JavaScriptCore.xcodeproj/project.pbxproj:
168         * bytecode/BytecodeList.json:
169         * bytecode/BytecodeUseDef.h:
170         (JSC::computeUsesForBytecodeOffset): Deleted.
171         (JSC::computeDefsForBytecodeOffset): Deleted.
172         * bytecode/CodeBlock.cpp:
173         (JSC::CodeBlock::dumpBytecode): Deleted.
174         * bytecode/UnlinkedFunctionExecutable.cpp:
175         (JSC::generateUnlinkedFunctionCodeBlock):
176         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
177         * bytecode/UnlinkedFunctionExecutable.h:
178         * bytecompiler/BytecodeGenerator.cpp:
179         (JSC::BytecodeGenerator::BytecodeGenerator):
180         (JSC::BytecodeGenerator::emitCall):
181         (JSC::BytecodeGenerator::emitCallVarargs):
182         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
183         (JSC::BytecodeGenerator::emitConstructVarargs):
184         (JSC::BytecodeGenerator::emitConstruct):
185         * bytecompiler/BytecodeGenerator.h:
186         (JSC::CallArguments::profileHookRegister): Deleted.
187         (JSC::BytecodeGenerator::shouldEmitProfileHooks): Deleted.
188         * bytecompiler/NodesCodegen.cpp:
189         (JSC::CallFunctionCallDotNode::emitBytecode):
190         (JSC::ApplyFunctionCallDotNode::emitBytecode):
191         (JSC::CallArguments::CallArguments): Deleted.
192         * dfg/DFGAbstractInterpreterInlines.h:
193         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects): Deleted.
194         * dfg/DFGByteCodeParser.cpp:
195         (JSC::DFG::ByteCodeParser::parseBlock): Deleted.
196         * dfg/DFGCapabilities.cpp:
197         (JSC::DFG::capabilityLevel): Deleted.
198         * dfg/DFGClobberize.h:
199         (JSC::DFG::clobberize): Deleted.
200         * dfg/DFGDoesGC.cpp:
201         (JSC::DFG::doesGC): Deleted.
202         * dfg/DFGFixupPhase.cpp:
203         (JSC::DFG::FixupPhase::fixupNode): Deleted.
204         * dfg/DFGNodeType.h:
205         * dfg/DFGPredictionPropagationPhase.cpp:
206         * dfg/DFGSafeToExecute.h:
207         (JSC::DFG::safeToExecute): Deleted.
208         * dfg/DFGSpeculativeJIT32_64.cpp:
209         (JSC::DFG::SpeculativeJIT::compile): Deleted.
210         * dfg/DFGSpeculativeJIT64.cpp:
211         (JSC::DFG::SpeculativeJIT::compile): Deleted.
212         * inspector/InjectedScriptBase.cpp:
213         (Inspector::InjectedScriptBase::callFunctionWithEvalEnabled):
214         * inspector/protocol/Timeline.json:
215         * interpreter/Interpreter.cpp:
216         (JSC::UnwindFunctor::operator()): Deleted.
217         (JSC::Interpreter::execute): Deleted.
218         (JSC::Interpreter::executeCall): Deleted.
219         (JSC::Interpreter::executeConstruct): Deleted.
220         * jit/JIT.cpp:
221         (JSC::JIT::privateCompileMainPass): Deleted.
222         * jit/JIT.h:
223         * jit/JITOpcodes.cpp:
224         (JSC::JIT::emit_op_profile_will_call): Deleted.
225         (JSC::JIT::emit_op_profile_did_call): Deleted.
226         * jit/JITOpcodes32_64.cpp:
227         (JSC::JIT::emit_op_profile_will_call): Deleted.
228         (JSC::JIT::emit_op_profile_did_call): Deleted.
229         * jit/JITOperations.cpp:
230         * jit/JITOperations.h:
231         * jsc.cpp:
232         * llint/LLIntSlowPaths.cpp:
233         (JSC::LLInt::LLINT_SLOW_PATH_DECL): Deleted.
234         * llint/LLIntSlowPaths.h:
235         * llint/LowLevelInterpreter.asm:
236         * parser/ParserModes.h:
237         * profiler/CallIdentifier.h: Removed.
238         * profiler/LegacyProfiler.cpp: Removed.
239         * profiler/LegacyProfiler.h: Removed.
240         * profiler/Profile.cpp: Removed.
241         * profiler/Profile.h: Removed.
242         * profiler/ProfileGenerator.cpp: Removed.
243         * profiler/ProfileGenerator.h: Removed.
244         * profiler/ProfileNode.cpp: Removed.
245         * profiler/ProfileNode.h: Removed.
246         * profiler/ProfilerJettisonReason.cpp:
247         (WTF::printInternal): Deleted.
248         * profiler/ProfilerJettisonReason.h:
249         * runtime/CodeCache.cpp:
250         (JSC::CodeCache::getGlobalCodeBlock):
251         (JSC::CodeCache::getProgramCodeBlock):
252         (JSC::CodeCache::getEvalCodeBlock):
253         (JSC::CodeCache::getModuleProgramCodeBlock):
254         * runtime/CodeCache.h:
255         * runtime/Executable.cpp:
256         (JSC::ScriptExecutable::newCodeBlockFor):
257         * runtime/JSGlobalObject.cpp:
258         (JSC::JSGlobalObject::createProgramCodeBlock):
259         (JSC::JSGlobalObject::createEvalCodeBlock):
260         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
261         (JSC::JSGlobalObject::~JSGlobalObject): Deleted.
262         (JSC::JSGlobalObject::hasLegacyProfiler): Deleted.
263         * runtime/JSGlobalObject.h:
264         (JSC::JSGlobalObject::supportsLegacyProfiling): Deleted.
265         * runtime/Options.h:
266         * runtime/VM.cpp:
267         (JSC::VM::VM): Deleted.
268         (JSC::SetEnabledProfilerFunctor::operator()): Deleted.
269         (JSC::VM::setEnabledProfiler): Deleted.
270         * runtime/VM.h:
271         (JSC::VM::enabledProfiler): Deleted.
272         (JSC::VM::enabledProfilerAddress): Deleted.
273
274 2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>
275
276         jsc: samplingProfilerStackTraces() without starting sampling should not cause jsc to crash
277         https://bugs.webkit.org/show_bug.cgi?id=157704
278
279         Reviewed by Saam Barati.
280
281         * jsc.cpp:
282         (functionStartSamplingProfiler):
283         (functionSamplingProfilerStackTraces):
284         Throw an exception instead of crashing if we haven't started sampling.
285
286         * inspector/agents/InspectorScriptProfilerAgent.cpp:
287         (Inspector::InspectorScriptProfilerAgent::startTracking):
288         * runtime/VM.h:
289         * runtime/VM.cpp:
290         (JSC::VM::ensureSamplingProfiler):
291         Switch ensure to returning a reference, like most other ensures.
292
293 2016-05-13  Saam barati  <sbarati@apple.com>
294
295         DFG/FTL have a few bugs in their reasoning about the scope
296         https://bugs.webkit.org/show_bug.cgi?id=157696
297
298         Reviewed by Benjamin Poulain.
299
300         1. When the debugger is enabled, it is easier for the DFG to reason
301         about the scope register by simply claiming all nodes read the scope
302         register. This prevents us from ever entering the runtime where we
303         may take a stack trace but there isn't a scope on the stack.
304
305         2. This patch fixes a bug where the FTL compilation wasn't properly
306         setting the CodeBlock register. It was only doing this when there
307         was inline data, but when the debugger is enabled, we never inline.
308         So this code just needed to be removed from that loop. It was never
309         right for it to be inside the loop.
310
311         * dfg/DFGClobberize.h:
312         (JSC::DFG::clobberize):
313         * ftl/FTLCompile.cpp:
314         (JSC::FTL::compile):
315
316 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
317
318         [JSC] SetLocal without exit do not need phantoms
319         https://bugs.webkit.org/show_bug.cgi?id=157653
320
321         Reviewed by Filip Pizlo.
322
323         I made a mistake in r200498.
324
325         If a SetLocal cannot possibly exit, we were not clearing
326         the source of the operand. As a result, we sometime kept
327         a value alive up to the end of the block.
328
329         That's uncommon because SetLocal typically appear
330         toward the end of blocks. That's probably why there was
331         no perf impact with that fix.
332
333         * dfg/DFGPhantomInsertionPhase.cpp:
334
335 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
336
337         [JSC] Move the CheckTierUp function calls out of the main path
338         https://bugs.webkit.org/show_bug.cgi?id=157668
339
340         Reviewed by Mark Lam.
341
342         If you have a tiny tiny loop (for example, Sunspider's bits-in-byte),
343         the size of CheckTierUp is a problem.
344
345         On multi-issue CPUs, the node is so big that we do not
346         get to run anything from the loop in the instruction fetch.
347
348         On x86, having a bigger loop also pushes us out of the LSD.
349
350         This is a 6% improvement on bits-in-byte. Other Sunspider tests
351         only improves marginally.
352
353         * dfg/DFGSpeculativeJIT.cpp:
354         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
355         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
356         * dfg/DFGSpeculativeJIT.h:
357         (JSC::DFG::SpeculativeJIT::silentSpill):
358         (JSC::DFG::SpeculativeJIT::silentFill):
359         * dfg/DFGSpeculativeJIT64.cpp:
360         (JSC::DFG::SpeculativeJIT::compile):
361
362 2016-05-13  Benjamin Poulain  <bpoulain@apple.com>
363
364         [JSC] Emit the loads of emitLoadWithStructureCheck() in the order they are used
365         https://bugs.webkit.org/show_bug.cgi?id=157671
366
367         Reviewed by Mark Lam.
368
369         This improves the chances of having a value
370         when issuing the TEST.
371
372         * jit/JITPropertyAccess.cpp:
373         (JSC::JIT::emitLoadWithStructureCheck):
374
375 2016-05-13  Joseph Pecoraro  <pecoraro@apple.com>
376
377         Web Inspector: Inform augmenting client when inspector controller is destroyed
378         https://bugs.webkit.org/show_bug.cgi?id=157688
379         <rdar://problem/25832724>
380
381         Reviewed by Timothy Hatcher.
382
383         * inspector/JSGlobalObjectInspectorController.cpp:
384         (Inspector::JSGlobalObjectInspectorController::~JSGlobalObjectInspectorController):
385         * inspector/augmentable/AugmentableInspectorControllerClient.h:
386         There is a weak relationship between the InspectorController and the
387         AugmentingClient. Let the augmenting client know when the controller
388         is destroyed so it doesn't try to use us anymore.
389
390 2016-05-13  Geoffrey Garen  <ggaren@apple.com>
391
392         Runaway malloc memory usage in this simple JSC program
393         https://bugs.webkit.org/show_bug.cgi?id=157682
394
395         Reviewed by Mark Lam.
396
397         * heap/WeakSet.cpp:
398         (JSC::WeakSet::sweep): Whenever we might add a block to
399         m_logicallyEmptyWeakBlocks, be sure also to sweep a block in
400         m_logicallyEmptyWeakBlocks. Otherwise, additions might outpace removals
401         even when all memory is freed.
402
403         We do this whenever we *might* add a block and not just whenever we *do*
404         add a block because we'd like to sweep the entries in
405         m_logicallyEmptyWeakBlocks promptly even when it's not growing, and this
406         is a reasonably rate-limited opportunity to do so.
407
408 2016-05-13  Mark Lam  <mark.lam@apple.com>
409
410         We should have one calleeSaveRegistersBuffer per VMEntryFrame, not one per VM.
411         https://bugs.webkit.org/show_bug.cgi?id=157537
412         <rdar://problem/24794845>
413
414         Reviewed by Michael Saboff.
415
416         The pre-existing code behaves this way:
417
418         1. When JS code throws an exception, it saves callee save registers in
419            the VM calleeSaveRegistersBuffer.  These values are meant to be restored
420            to the callee save registers later either at the catch handler or at the
421            uncaught exception handler.
422
423         2. If the Inspector is enable, the VM will invoke inspector C++ code to inspect
424            the exception.  That C++ code can change the values of the callee save
425            registers.
426
427            The inspector code in turn re-enters the VM to execute JS inspector code.
428
429            The JS inspector code can run hot enough that we do an enterOptimizationCheck
430            on it.  The enterOptimizationCheck first saves all callee save registers
431            into the VM calleeSaveRegistersBuffer.
432
433            This effectively overwrites the values in the VM calleeSaveRegistersBuffer
434            from (1).
435
436         3. Eventually, execution returns to the catch handler or the uncaught exception
437            handler which restores the overwritten values in the VM
438            calleeSaveRegistersBuffer to the callee save registers.
439
440            When execution returns to the C++ code that entered the VM before (1), the
441            values in the callee registers are not what that code expects, and badness
442            and/or crashes ensues.
443
444         This patch applies the following fix:
445         
446         1. Allocate space in the VMEntryFrame for the calleeSaveRegistersBuffer.
447            This ensures that each VM entry session has its own buffer to use, and will
448            not corrupt the one from the previous VM entry session.
449
450            Delete the VM calleeSaveRegistersBuffer.
451
452         2. Change all locations that uses the VM calleeSaveRegistersBuffer to use the
453            calleeSaveRegistersBuffer in the current VMEntryFrame.
454
455         3. Renamed all uses of the term "VMCalleeSavesBuffer" to
456            "VMEntryFrameCalleeSavesBuffer".
457
458         This fix has been tested on the following configurations:
459         1. JSC and layout tests on a debug ASan build for 64-bit x86_64.
460         2. JSC tests on a release ASan build for 32-bit x86.
461         3. JSC tests on a release normal (non-ASan) build for ARM64.
462         4. JSC tests on a release normal (non-ASan) build for ARMv7 and ARMv7s.
463         5. JSC tests on a release ASan CLOOP build for x86_64.
464
465         These test runs did not produce any new crashes.  The ASan CLOOP has some
466         pre-existing crashes which are not due to this patch.
467
468         This bug can be tested by running the inspector/debugger/regress-133182.html test
469         on an ASan build.
470
471         * bytecode/PolymorphicAccess.cpp:
472         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
473         * dfg/DFGJITCompiler.cpp:
474         (JSC::DFG::JITCompiler::compileExceptionHandlers):
475         * dfg/DFGOSREntry.cpp:
476         (JSC::DFG::prepareOSREntry):
477         * dfg/DFGOSRExitCompiler.cpp:
478         * dfg/DFGOSRExitCompiler32_64.cpp:
479         (JSC::DFG::OSRExitCompiler::compileExit):
480         * dfg/DFGOSRExitCompiler64.cpp:
481         (JSC::DFG::OSRExitCompiler::compileExit):
482         * dfg/DFGThunks.cpp:
483         (JSC::DFG::osrEntryThunkGenerator):
484         * ftl/FTLCompile.cpp:
485         (JSC::FTL::compile):
486         * ftl/FTLLowerDFGToB3.cpp:
487         (JSC::FTL::DFG::LowerDFGToB3::lower):
488         * ftl/FTLOSRExitCompiler.cpp:
489         (JSC::FTL::compileStub):
490         * interpreter/Interpreter.cpp:
491         (JSC::UnwindFunctor::operator()):
492         (JSC::UnwindFunctor::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
493         (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer): Deleted.
494         * interpreter/Interpreter.h:
495         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
496         * interpreter/VMEntryRecord.h:
497         (JSC::VMEntryRecord::calleeSaveRegistersBufferOffset):
498         (JSC::VMEntryRecord::prevTopCallFrame):
499         (JSC::VMEntryRecord::unsafePrevTopCallFrame):
500         (JSC::VMEntryFrame::vmEntryRecordOffset):
501         (JSC::VMEntryFrame::calleeSaveRegistersBufferOffset):
502         * jit/AssemblyHelpers.cpp:
503         (JSC::AssemblyHelpers::emitRandomThunk):
504         (JSC::AssemblyHelpers::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
505         (JSC::AssemblyHelpers::restoreCalleeSavesFromVMCalleeSavesBuffer): Deleted.
506         * jit/AssemblyHelpers.h:
507         (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters):
508         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
509         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMEntryFrameCalleeSavesBuffer):
510         (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer): Deleted.
511         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToVMCalleeSavesBuffer): Deleted.
512         * jit/JIT.cpp:
513         (JSC::JIT::emitEnterOptimizationCheck):
514         (JSC::JIT::privateCompileExceptionHandlers):
515         * jit/JITOpcodes.cpp:
516         (JSC::JIT::emit_op_throw):
517         (JSC::JIT::emit_op_catch):
518         (JSC::JIT::emitSlow_op_loop_hint):
519         * jit/JITOpcodes32_64.cpp:
520         (JSC::JIT::emit_op_throw):
521         (JSC::JIT::emit_op_catch):
522         * jit/ThunkGenerators.cpp:
523         (JSC::throwExceptionFromCallSlowPathGenerator):
524         (JSC::nativeForGenerator):
525         * llint/LLIntThunks.cpp:
526         (JSC::vmEntryRecord):
527         * llint/LowLevelInterpreter.asm:
528         * llint/LowLevelInterpreter32_64.asm:
529         * llint/LowLevelInterpreter64.asm:
530         * runtime/VM.h:
531         (JSC::VM::getCTIStub):
532         (JSC::VM::calleeSaveRegistersBufferOffset): Deleted.
533         * wasm/WASMFunctionCompiler.h:
534         (JSC::WASMFunctionCompiler::endFunction):
535
536 2016-05-13  Beth Dakin  <bdakin@apple.com>
537
538         Add dyldSPI.h for linked on or after checks, and add one for link preview
539         https://bugs.webkit.org/show_bug.cgi?id=157401
540         -and corresponding-
541         rdar://problem/26253396
542
543         Reviewed by Darin Adler.
544
545         Import #import <wtf/spi/darwin/dyldSPI.h> which now declares all of the 
546         needed dyld code.
547         * API/JSWrapperMap.mm:
548
549 2016-05-13  Yusuke Suzuki  <utatane.tea@gmail.com>
550
551         Assertion failure for direct eval in non-class method
552         https://bugs.webkit.org/show_bug.cgi?id=157138
553
554         Reviewed by Saam Barati.
555
556         This assertion was incorrect. In method definitions in object literals,
557         it can be sloppy mode, but its DerivedContextType may not be DerivedContextType::None.
558
559         * bytecode/EvalCodeCache.h:
560         (JSC::EvalCodeCache::CacheKey::CacheKey):
561         (JSC::EvalCodeCache::CacheKey::operator==):
562         (JSC::EvalCodeCache::CacheKey::Hash::equal):
563         (JSC::EvalCodeCache::tryGet):
564         (JSC::EvalCodeCache::getSlow):
565         * interpreter/Interpreter.cpp:
566         (JSC::eval):
567         * tests/stress/direct-eval-in-object-literal-methods.js: Added.
568         (shouldBe):
569         (throw.new.Error):
570         (shouldBe.Parent.prototype.l):
571         (shouldBe.Parent):
572         (shouldBe.Derived.prototype.m):
573         (shouldBe.Derived):
574
575 2016-05-13  Skachkov Oleksandr  <gskachkov@gmail.com>
576
577         Assertion failure for super() call in arrow function default parameters
578         https://bugs.webkit.org/show_bug.cgi?id=157079
579
580         Reviewed by Saam Barati.
581
582         Root of the issue that in arrow function we load bounded variables this/super/new.target just after 
583         input parameters were initialized, and did not covered case of default values for 
584         function parameters. 
585         Current patch tried to fix issue and allow to load bounded variables earlier, before the input 
586         parameters are assigned by default values.
587
588         * bytecompiler/BytecodeGenerator.cpp:
589         (JSC::BytecodeGenerator::BytecodeGenerator):
590         * tests/stress/arrowfunction-lexical-bind-this-2.js:
591
592 2016-05-12  Mark Lam  <mark.lam@apple.com>
593
594         Baseline and DFG's JSC_report...CompileTimes needs CodeBlock hashes.
595         https://bugs.webkit.org/show_bug.cgi?id=157643
596
597         Reviewed by Keith Miller.
598
599         * runtime/Options.cpp:
600         (JSC::recomputeDependentOptions):
601
602 2016-05-12  Csaba Osztrogonác  <ossy@webkit.org>
603
604         Remove ENABLE(ES6_ARROWFUNCTION_SYNTAX) guards
605         https://bugs.webkit.org/show_bug.cgi?id=157564
606
607         Reviewed by Darin Adler.
608
609         * Configurations/FeatureDefines.xcconfig:
610         * parser/Parser.cpp:
611
612 2016-05-12  Joseph Pecoraro  <pecoraro@apple.com>
613
614         Web Inspector: CRASH getting internal properties of function with no bound arguments causes
615         https://bugs.webkit.org/show_bug.cgi?id=157613
616         <rdar://problem/26238754>
617
618         Reviewed by Timothy Hatcher.
619
620         * inspector/JSInjectedScriptHost.cpp:
621         (Inspector::JSInjectedScriptHost::getInternalProperties):
622         Gracefully handle a JSBoundFunction with no bound arguments.
623         In this case boundArgs is JSValue() which we don't want to
624         expose as the value of the internal property.
625
626 2016-05-11  Benjamin Poulain  <bpoulain@apple.com>
627
628         [JSC] Make sure StringRange is passed to Vector by register
629         https://bugs.webkit.org/show_bug.cgi?id=157603
630
631         Reviewed by Darin Adler.
632
633         This is bizarre, but on my SDK, Vector::append(StringRange)
634         is passing the values on the stack.
635         The two integers are written to the stack, the address given
636         to append(), then append() reads it back and store it.
637
638         This patch changes the code to use constructAndAppend(), ensuring
639         the values are used directly.
640
641         On my machine, this helps Sunspider and Octane.
642         This might be something wrong with my SDK but the fix is so easy
643         that we might as well do this.
644
645         * runtime/StringPrototype.cpp:
646         (JSC::removeUsingRegExpSearch):
647         (JSC::replaceUsingRegExpSearch):
648
649 2016-05-11  Zan Dobersek  <zdobersek@igalia.com>
650
651         ARMv7Assembler: suppress a -Wnarrowing warning when compiling with GCC
652         https://bugs.webkit.org/show_bug.cgi?id=157576
653
654         Reviewed by Csaba Osztrogonác.
655
656         * assembler/ARMv7Assembler.h:
657         (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2): Explicitly cast the
658         `OP_CMP_reg_T2 | left` value to uint16_t, avoiding a narrowing conversion
659         warning that's being reported when compiling with GCC. The warning is sprung
660         due to RegisterID (which is the type of `left`) being an enum based on int,
661         even when the enum itself only declares 23 values.
662
663 2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>
664
665         Web Inspector: `this` in Scope Chain Sidebar does not have preview, looks poor
666         https://bugs.webkit.org/show_bug.cgi?id=157602
667
668         Reviewed by Timothy Hatcher.
669
670         * inspector/InjectedScriptSource.js:
671         (InjectedScript.CallFrameProxy):
672         Include a preview when creating the RemoteObject for `this`.
673
674 2016-05-11  Keith Miller  <keith_miller@apple.com>
675
676         Unreviewed, correct the title of the ChangeLog for r200667.
677
678 2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>
679
680         JSC test stress/reflect-set.js failing after 200694
681         https://bugs.webkit.org/show_bug.cgi?id=157586
682
683         Unreviewed test rebaseline.
684
685         * tests/stress/reflect-set.js:
686         Update the expected error message. We are in strict mode, so the
687         improved error message makes sense.
688
689 2016-05-11  Filip Pizlo  <fpizlo@apple.com>
690
691         Beef up JSC profiler event log
692         https://bugs.webkit.org/show_bug.cgi?id=157584
693
694         Reviewed by Saam Barati.
695         
696         Also log more about compilation.
697
698         * bytecode/ExecutionCounter.cpp: Changed the meaning of codeBlock to be the codeBlock that is doing the profiling. This will now get the baseline version if it needs it. This is needed for logging the threshold checking event.
699         (JSC::applyMemoryUsageHeuristics):
700         (JSC::ExecutionCounter<countingVariant>::hasCrossedThreshold):
701         * dfg/DFGJITCode.cpp: Pass the right codeBlock.
702         (JSC::DFG::JITCode::checkIfOptimizationThresholdReached):
703         (JSC::DFG::JITCode::optimizeNextInvocation):
704         (JSC::DFG::JITCode::dontOptimizeAnytimeSoon):
705         (JSC::DFG::JITCode::optimizeSoon):
706         (JSC::DFG::JITCode::forceOptimizationSlowPathConcurrently):
707         * dfg/DFGPlan.cpp: Log things about compile times and whether the compiler succeeded or failed.
708         (JSC::DFG::Plan::computeCompileTimes):
709         (JSC::DFG::Plan::reportCompileTimes):
710         (JSC::DFG::Plan::compileInThread):
711         (JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
712         * jit/ExecutableAllocatorFixedVMPool.cpp: Make it possible to look at memory usage, though separately from the log, for now.
713         (JSC::ExecutableAllocator::allocate):
714         * runtime/Options.h:
715
716 2016-05-11  Saam barati  <sbarati@apple.com>
717
718         Air may decide to put the result register of an arithmetic snippet in the tag register
719         https://bugs.webkit.org/show_bug.cgi?id=157548
720
721         Reviewed by Filip Pizlo.
722
723         This patch adds a new ValueRep to B3 called LateRegister. The semantics
724         are similar to Register in that it can be used to pin an argument to
725         a particular register. It differs from ValueRep::Register in that the semantics of
726         LateRegister are that it is used after the result of the node its an argument to
727         is computed. This means that a LateRegister argument will interfere with the result
728         of a node. LateRegister is not a valid result ValueRep.
729
730         This was needed because there was a bug where B3/Air would assign the
731         result of a patchpoint to the TagTypeNumber register. This broke our
732         code when we would box a double into a JSValue in a snippet when the
733         result is the same as the TagTypeNumber register. To fix the issue,
734         we pass TagMaskRegister and TagTypeNumberRegister as ValueRep::LateRegister
735         arguments to various patchpoints.
736
737         * b3/B3LowerToAir.cpp:
738         (JSC::B3::Air::LowerToAir::fillStackmap):
739         * b3/B3PatchpointSpecial.cpp:
740         (JSC::B3::PatchpointSpecial::admitsStack):
741         * b3/B3StackmapSpecial.cpp:
742         (JSC::B3::StackmapSpecial::forEachArgImpl):
743         (JSC::B3::StackmapSpecial::isArgValidForRep):
744         * b3/B3Validate.cpp:
745         * b3/B3ValueRep.cpp:
746         (JSC::B3::ValueRep::addUsedRegistersTo):
747         (JSC::B3::ValueRep::dump):
748         (JSC::B3::ValueRep::emitRestore):
749         (JSC::B3::ValueRep::recoveryForJSValue):
750         (WTF::printInternal):
751         * b3/B3ValueRep.h:
752         (JSC::B3::ValueRep::reg):
753         (JSC::B3::ValueRep::lateReg):
754         (JSC::B3::ValueRep::stack):
755         (JSC::B3::ValueRep::operator==):
756         (JSC::B3::ValueRep::isSomeRegister):
757         (JSC::B3::ValueRep::isReg):
758         * b3/testb3.cpp:
759         (JSC::B3::testSpillUseLargerThanDef):
760         (JSC::B3::testLateRegister):
761         (JSC::B3::zero):
762         (JSC::B3::run):
763         * ftl/FTLLowerDFGToB3.cpp:
764         (JSC::FTL::DFG::LowerDFGToB3::lower):
765         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
766         (JSC::FTL::DFG::LowerDFGToB3::getById):
767         (JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
768         (JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
769         (JSC::FTL::DFG::LowerDFGToB3::emitRightShiftSnippet):
770
771 2016-05-11  Joseph Pecoraro  <pecoraro@apple.com>
772
773         Improve error messages for accessing arguments.callee and similar getters in strict mode
774         https://bugs.webkit.org/show_bug.cgi?id=157545
775
776         Reviewed by Mark Lam.
777
778         * runtime/ClonedArguments.cpp:
779         (JSC::ClonedArguments::getOwnPropertySlot):
780         (JSC::ClonedArguments::materializeSpecials):
781         Provide better error GetterSetter in strict mode.
782
783         * runtime/JSFunction.cpp:
784         (JSC::getThrowTypeErrorGetterSetter):
785         (JSC::JSFunction::defineOwnProperty):
786         Provide better error GetterSetter in strict mode.
787
788         * runtime/JSGlobalObject.cpp:
789         (JSC::JSGlobalObject::init):
790         (JSC::JSGlobalObject::visitChildren):
791         * runtime/JSGlobalObject.h:
792         (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
793         (JSC::JSGlobalObject::throwTypeErrorCalleeAndCallerGetterSetter):
794         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInStrictModeGetterSetter):
795         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerInClassContextGetterSetter):
796         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter): Deleted.
797         * runtime/JSGlobalObjectFunctions.cpp:
798         (JSC::globalFuncThrowTypeErrorCalleeAndCaller):
799         (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInStrictMode):
800         (JSC::globalFuncThrowTypeErrorArgumentsAndCallerInClassContext):
801         (JSC::globalFuncThrowTypeErrorArgumentsAndCaller): Deleted.
802         * runtime/JSGlobalObjectFunctions.h:
803         Rename and expose new handles for new error getter setter native functions.
804
805 2016-05-11  Commit Queue  <commit-queue@webkit.org>
806
807         Unreviewed, rolling out r200481.
808         https://bugs.webkit.org/show_bug.cgi?id=157573
809
810         it's bad news for asm.js (Requested by pizlo on #webkit).
811
812         Reverted changeset:
813
814         "Reduce maximum JIT pool size on X86_64."
815         http://trac.webkit.org/changeset/200481
816
817 2016-05-10  Keith Miller  <keith_miller@apple.com>
818
819         TypedArray.prototype.slice should not use the byteLength of the passed array for memmove
820         https://bugs.webkit.org/show_bug.cgi?id=157551
821         <rdar://problem/26179914>
822
823         Reviewed by Michael Saboff.
824
825         The TypedArray.prototype.slice function would use the byteLength of the passed array
826         to determine the amount of data to copy. It should have been using the passed length
827         times the size of each element. This fixes a crash on JavaPoly.com
828
829         * runtime/JSGenericTypedArrayViewInlines.h:
830         (JSC::JSGenericTypedArrayView<Adaptor>::set):
831         * tests/stress/typedarray-slice.js:
832
833 2016-05-10  Michael Saboff  <msaboff@apple.com>
834
835         REGRESSION(r200447): Unable to build C_LOOP with clang version 800.0.12 or higher
836         https://bugs.webkit.org/show_bug.cgi?id=157549
837
838         Reviewed by Keith Miller.
839
840         Disable debug annotations for C_LOOP builds.  They are inline assembly directives,
841         unnecessary and they cause syntax errors.
842
843         * offlineasm/asm.rb:
844
845 2016-05-10  Filip Pizlo  <fpizlo@apple.com>
846
847         Internal JSC profiler should have a timestamped log of events for each code block
848         https://bugs.webkit.org/show_bug.cgi?id=157538
849
850         Reviewed by Benjamin Poulain.
851         
852         For example, in 3d-cube, I can query the events for MMulti and I get:
853
854         1462917476.17083  MMulti#DTZ7qc                          installCode        
855         1462917476.179663 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
856         1462917476.179664 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline osrEntry           at bc#49
857         1462917476.185651 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1011.214233/1717.000000, -707
858         1462917476.187913 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      installCode        
859         1462917476.187917 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      osrEntry           at bc#49
860         1462917476.205365 MMulti#DTZ7qc MMulti#DTZ7qc-2-DFG      jettison           due to OSRExit, counting = true, detail = (null)
861         1462917476.205368 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#65: BadCache/FromDFG
862         1462917476.205369 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
863         1462917476.205482 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/3434.000000, -1000
864         1462917476.211547 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/3434.000000, -1000
865         1462917476.213721 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      installCode        
866         1462917476.213726 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      osrEntry           at bc#49
867         1462917476.223976 MMulti#DTZ7qc MMulti#DTZ7qc-3-DFG      jettison           due to OSRExit, counting = true, detail = (null)
868         1462917476.223981 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#77: BadCache/FromDFG
869         1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline frequentExit       bc#94: BadCache/FromDFG
870         1462917476.223982 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline installCode        
871         1462917476.224064 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 1013.000000/6868.000000, -1000
872         1462917476.224151 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 2013.000000/6868.000000, -1000
873         1462917476.224258 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 3013.000000/6868.000000, -1000
874         1462917476.224337 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 4023.000000/6868.000000, -1000
875         1462917476.224425 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 5023.000000/6868.000000, -1000
876         1462917476.224785 MMulti#DTZ7qc MMulti#DTZ7qc-1-Baseline delayOptimizeToDFG counter = 6023.396484/6868.000000, -862
877         1462917476.227669 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG      installCode        
878         1462917476.227675 MMulti#DTZ7qc MMulti#DTZ7qc-4-DFG      osrEntry           at bc#0
879         
880         The output is ugly but useful. We can make it less ugly later.
881
882         * CMakeLists.txt:
883         * JavaScriptCore.xcodeproj/project.pbxproj:
884         * bytecode/CodeBlock.cpp:
885         (JSC::CodeBlock::jettison):
886         * bytecode/CodeBlock.h:
887         (JSC::ScriptExecutable::forEachCodeBlock):
888         * bytecode/DFGExitProfile.cpp:
889         (JSC::DFG::ExitProfile::add):
890         * dfg/DFGJITFinalizer.cpp:
891         (JSC::DFG::JITFinalizer::finalizeCommon):
892         * dfg/DFGOperations.cpp:
893         * ftl/FTLJITFinalizer.cpp:
894         (JSC::FTL::JITFinalizer::finalizeFunction):
895         * jit/JIT.cpp:
896         (JSC::JIT::privateCompile):
897         * jit/JITOperations.cpp:
898         * llint/LLIntSlowPaths.cpp:
899         (JSC::LLInt::jitCompileAndSetHeuristics):
900         (JSC::LLInt::entryOSR):
901         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
902         * profiler/ProfilerCompilation.cpp:
903         (JSC::Profiler::Compilation::Compilation):
904         (JSC::Profiler::Compilation::setJettisonReason):
905         (JSC::Profiler::Compilation::dump):
906         (JSC::Profiler::Compilation::toJS):
907         * profiler/ProfilerCompilation.h:
908         (JSC::Profiler::Compilation::uid):
909         * profiler/ProfilerDatabase.cpp:
910         (JSC::Profiler::Database::ensureBytecodesFor):
911         (JSC::Profiler::Database::notifyDestruction):
912         (JSC::Profiler::Database::addCompilation):
913         (JSC::Profiler::Database::toJS):
914         (JSC::Profiler::Database::registerToSaveAtExit):
915         (JSC::Profiler::Database::logEvent):
916         (JSC::Profiler::Database::addDatabaseToAtExit):
917         * profiler/ProfilerDatabase.h:
918         * profiler/ProfilerEvent.cpp: Added.
919         (JSC::Profiler::Event::dump):
920         (JSC::Profiler::Event::toJS):
921         * profiler/ProfilerEvent.h: Added.
922         (JSC::Profiler::Event::Event):
923         (JSC::Profiler::Event::operator bool):
924         (JSC::Profiler::Event::time):
925         (JSC::Profiler::Event::bytecodes):
926         (JSC::Profiler::Event::compilation):
927         (JSC::Profiler::Event::summary):
928         (JSC::Profiler::Event::detail):
929         * profiler/ProfilerUID.cpp: Added.
930         (JSC::Profiler::UID::create):
931         (JSC::Profiler::UID::dump):
932         (JSC::Profiler::UID::toJS):
933         * profiler/ProfilerUID.h: Added.
934         (JSC::Profiler::UID::UID):
935         (JSC::Profiler::UID::fromInt):
936         (JSC::Profiler::UID::toInt):
937         (JSC::Profiler::UID::operator==):
938         (JSC::Profiler::UID::operator!=):
939         (JSC::Profiler::UID::operator bool):
940         (JSC::Profiler::UID::isHashTableDeletedValue):
941         (JSC::Profiler::UID::hash):
942         (JSC::Profiler::UIDHash::hash):
943         (JSC::Profiler::UIDHash::equal):
944         * runtime/CommonIdentifiers.h:
945         * runtime/Executable.cpp:
946         (JSC::ScriptExecutable::installCode):
947         * runtime/VM.h:
948         (JSC::VM::bytecodeIntrinsicRegistry):
949         (JSC::VM::shadowChicken):
950         * runtime/VMInlines.h:
951         (JSC::VM::shouldTriggerTermination):
952         (JSC::VM::logEvent):
953
954 2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>
955
956         Web Inspector: Backend should initiate timeline recordings on page navigations to ensure nothing is missed
957         https://bugs.webkit.org/show_bug.cgi?id=157504
958         <rdar://problem/26188642>
959
960         Reviewed by Brian Burg.
961
962         * inspector/protocol/Timeline.json:
963         Add protocol commands to enable/disable auto capture and list the
964         instruments that should be enabled when auto capture starts.
965         Add protocol event for when the backend starts an auto capture.
966
967 2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>
968
969         Make the different evaluateWithScopeExtension implementations more consistent
970         https://bugs.webkit.org/show_bug.cgi?id=157536
971
972         Reviewed by Timothy Hatcher.
973
974         * inspector/JSInjectedScriptHost.cpp:
975         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
976         Throw the exception consistent with JSJavaScriptCallFrame.
977
978         * inspector/JSJavaScriptCallFrame.cpp:
979         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
980         Better error message consistent with InjectedScriptHost.
981
982         * runtime/Completion.h:
983         * runtime/Completion.cpp:
984         (JSC::evaluateWithScopeExtension):
985         Give this an Exception out parameter like other evaluations
986         so the caller can decide what to do with it.
987
988 2016-05-10  Benjamin Poulain  <bpoulain@apple.com>
989
990         [JSC] FTL can produce GetByVal nodes without proper bounds checking
991         https://bugs.webkit.org/show_bug.cgi?id=157502
992         rdar://problem/26027027
993
994         Reviewed by Filip Pizlo.
995
996         It was possible for FTL to generates GetByVal on arbitrary offsets
997         without any bounds checking.
998
999         The bug is caused by the order of optimization phases:
1000         -First, the Integer Range Optimization proves that a CheckInBounds
1001          test can never fail.
1002          This proof is based on control flow or preceeding instructions
1003          inside a loop.
1004         -The Loop Invariant Code Motion phase finds that the GetByVal does not
1005          depend on anything in the loop and hoist it out of the loop.
1006         -> As a result, the conditions that were necessary to eliminate
1007            the CheckInBounds are no longer met before the GetByVal.
1008
1009         This patch just moves the Integer Range Optimization phase after
1010         Loop Invariant Code Motion to make sure no code is moved after
1011         its integer ranges bounds proofs have been used.
1012
1013         * dfg/DFGPlan.cpp:
1014         (JSC::DFG::Plan::compileInThreadImpl):
1015         * tests/stress/bounds-check-not-eliminated-by-licm.js: Added.
1016         (testInLoopTests):
1017
1018 2016-05-10  Joseph Pecoraro  <pecoraro@apple.com>
1019
1020         Web Inspector: Eliminate the crazy code for evaluateOnCallFrame
1021         https://bugs.webkit.org/show_bug.cgi?id=157510
1022         <rdar://problem/26191332>
1023
1024         Reviewed by Timothy Hatcher.
1025
1026         * debugger/DebuggerCallFrame.cpp:
1027         (JSC::DebuggerCallFrame::evaluateWithScopeExtension):
1028         Set and clear an optional scope extension object.
1029
1030         * inspector/InjectedScriptSource.js:
1031         (InjectedScript.prototype.evaluate):
1032         (InjectedScript.prototype._evaluateOn):
1033         (InjectedScript.prototype.evaluateOnCallFrame):
1034         Unify the code to use the passed in evaluate function and object.
1035         When evaluating on a call frame the evaluate function ends up being
1036         DebuggerCallFrame::evaluateWithScopeExtension. When evaluating globally
1037         this ends up being JSInjectedScriptHost::evaluateWithScopeExtension.
1038         In both cases "object" is the preferred this object to use.
1039
1040         * debugger/DebuggerCallFrame.h:
1041         * inspector/JSJavaScriptCallFrame.cpp:
1042         (Inspector::JSJavaScriptCallFrame::evaluateWithScopeExtension):
1043         (Inspector::JSJavaScriptCallFrame::evaluate): Deleted.
1044         * inspector/JSJavaScriptCallFrame.h:
1045         * inspector/JSJavaScriptCallFramePrototype.cpp:
1046         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
1047         (Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension):
1048         * inspector/JavaScriptCallFrame.h:
1049         (Inspector::JavaScriptCallFrame::evaluateWithScopeExtension):
1050         (Inspector::JavaScriptCallFrame::evaluate): Deleted.
1051         Pass through to DebuggerCallFrame with the proper arguments.
1052
1053         * debugger/Debugger.cpp:
1054         (JSC::Debugger::hasBreakpoint):
1055         * inspector/ScriptDebugServer.cpp:
1056         (Inspector::ScriptDebugServer::evaluateBreakpointAction):
1057         Use the new evaluate on call frame method name and no scope extension object.
1058
1059 2016-05-10  Saam barati  <sbarati@apple.com>
1060
1061         Make super-property-access.js test run for less time because it was timing out in debug builds.
1062
1063         Rubber stamped by Filip Pizlo.
1064
1065         * tests/stress/super-property-access.js:
1066         (test):
1067         (test.value):
1068         (test.foo):
1069         (test.B.prototype.bar):
1070         (test.B):
1071
1072 2016-05-10  Csaba Osztrogonác  <ossy@webkit.org>
1073
1074         [JSC] Fix the !ENABLE(DFG_JIT) build
1075         https://bugs.webkit.org/show_bug.cgi?id=157512
1076
1077         Reviewed by Mark Lam.
1078
1079         * jit/Repatch.cpp:
1080
1081 2016-05-09  Joseph Pecoraro  <pecoraro@apple.com>
1082
1083         Web Inspector: CRASH under JSC::DebuggerCallFrame::thisValue when hitting breakpoint
1084         https://bugs.webkit.org/show_bug.cgi?id=157442
1085         <rdar://problem/24172015>
1086
1087         Reviewed by Saam Barati.
1088
1089         * debugger/DebuggerCallFrame.cpp:
1090         (JSC::DebuggerCallFrame::thisValueForCallFrame):
1091         When the thisValue is JSValue() return undefined and avoid calling
1092         toThisValue which would lead to a crash. Having `this` be an empty
1093         JSValue could happen inside an ES6 class constructor, before
1094         calling super.
1095
1096 2016-05-09  Filip Pizlo  <fpizlo@apple.com>
1097
1098         Unreviewed, fix cloop.
1099
1100         * bytecode/ValueProfile.cpp:
1101         (JSC::ResultProfile::emitDetectNumericness):
1102         (JSC::ResultProfile::emitSetNonNumber):
1103         * bytecode/ValueProfile.h:
1104         (JSC::ResultProfile::addressOfFlags):
1105         (JSC::ResultProfile::addressOfSpecialFastPathCount):
1106         (JSC::ResultProfile::detectNumericness):
1107         (JSC::ResultProfile::hasBits):
1108
1109 2016-05-09  Michael Saboff  <msaboff@apple.com>
1110
1111         Crash beneath ObjCCallbackFunctionImpl::call
1112         https://bugs.webkit.org/show_bug.cgi?id=157491
1113
1114         Reviewed by Saam Barati.
1115
1116         Clear any exceptions after the micro task runs.
1117
1118         Tried creating a test case, but I don't have source for the app.
1119         I can't seem to find the right combination of Promises and ObjC code.
1120
1121         * runtime/JSJob.cpp:
1122         (JSC::JSJobMicrotask::run):
1123
1124 2016-05-09  Filip Pizlo  <fpizlo@apple.com>
1125
1126         Polymorphic operands in operators coerces downstream values to double.
1127         https://bugs.webkit.org/show_bug.cgi?id=151793
1128
1129         Reviewed by Mark Lam.
1130         
1131         Previously if an object flowed into arithmetic, the prediction propagation phase would either
1132         assume that the output of the arithmetic had to be double or sometimes it would assume that it
1133         couldn't be double. We want it to only assume that the output is double if it actually had been.
1134         
1135         The first part of this patch is to roll out http://trac.webkit.org/changeset/200502. That removed
1136         some of the machinery that we had in place to detect whether the output of an operation is int or
1137         double. That changeset claimed that the machinery was "fundamentally broken". It actually wasn't.
1138         The reason why it didn't work was that ByteCodeParser was ignoring it if likelyToTakeSlowCase was
1139         false. I think this was a complete goof-up: the code in ByteCodeParser::makeSafe was structured
1140         in a way that made it non-obvious that the method is a no-op if !likelyToTakeSlowCase. So, this
1141         change rolls out r200502 and makes ResultProfile do its job by reshaping how makeSafe processes
1142         it.
1143         
1144         This also makes two other changes to shore up ResultProfile:
1145         - OSR exit can now refine a ResultProfile the same way that it refines ValueProfile.
1146         - Baseline JIT slow paths now set bits in ResultProfile.
1147         
1148         Based on this stuff, the DFG now predicts int/double/string in op_add/op_sub/op_mul based on
1149         ResultProfiles. To be conservative, we still only use the ResultProfiles if the incoming
1150         prediction is not number-or-boolean. This ensures that we exactly retain our old behavior in
1151         those cases for which it was tuned. But I hope to remove this soon. I believe that ResultProfile
1152         is already strictly better than what prediction propagation was doing before.
1153         
1154         This can be an enormous win. This patch adds some simple microbenchmarks that demonstrate the
1155         problem of assuming that arithmetic on objects returns double. The most extreme of these speeds
1156         up 8x with this change (object-int-add-array).
1157         
1158         * CMakeLists.txt:
1159         * JavaScriptCore.xcodeproj/project.pbxproj:
1160         * bytecode/CodeBlock.h:
1161         (JSC::CodeBlock::addFrequentExitSite):
1162         (JSC::CodeBlock::hasExitSite):
1163         * bytecode/DFGExitProfile.cpp:
1164         (JSC::DFG::FrequentExitSite::dump):
1165         (JSC::DFG::ExitProfile::ExitProfile):
1166         (JSC::DFG::ExitProfile::~ExitProfile):
1167         (JSC::DFG::ExitProfile::add):
1168         * bytecode/DFGExitProfile.h:
1169         (JSC::DFG::FrequentExitSite::isHashTableDeletedValue):
1170         * bytecode/MethodOfGettingAValueProfile.cpp:
1171         (JSC::MethodOfGettingAValueProfile::fromLazyOperand):
1172         (JSC::MethodOfGettingAValueProfile::emitReportValue):
1173         (JSC::MethodOfGettingAValueProfile::getSpecFailBucket): Deleted.
1174         * bytecode/MethodOfGettingAValueProfile.h:
1175         (JSC::MethodOfGettingAValueProfile::MethodOfGettingAValueProfile):
1176         (JSC::MethodOfGettingAValueProfile::operator bool):
1177         (JSC::MethodOfGettingAValueProfile::operator!): Deleted.
1178         * bytecode/PolymorphicAccess.cpp:
1179         (JSC::AccessCase::generateImpl):
1180         * bytecode/ValueProfile.cpp:
1181         (JSC::ResultProfile::emitDetectBitsLight):
1182         (JSC::ResultProfile::emitSetDouble):
1183         (JSC::ResultProfile::emitSetNonNumber):
1184         (WTF::printInternal):
1185         * bytecode/ValueProfile.h:
1186         (JSC::ResultProfile::ResultProfile):
1187         (JSC::ResultProfile::bytecodeOffset):
1188         (JSC::ResultProfile::specialFastPathCount):
1189         (JSC::ResultProfile::didObserveNonInt32):
1190         (JSC::ResultProfile::didObserveDouble):
1191         (JSC::ResultProfile::didObserveNonNegZeroDouble):
1192         (JSC::ResultProfile::didObserveNegZeroDouble):
1193         (JSC::ResultProfile::didObserveNonNumber):
1194         (JSC::ResultProfile::didObserveInt32Overflow):
1195         (JSC::ResultProfile::didObserveInt52Overflow):
1196         (JSC::ResultProfile::setObservedNonNegZeroDouble):
1197         (JSC::ResultProfile::setObservedNegZeroDouble):
1198         (JSC::ResultProfile::setObservedNonNumber):
1199         (JSC::ResultProfile::setObservedInt32Overflow):
1200         (JSC::ResultProfile::addressOfFlags):
1201         (JSC::ResultProfile::addressOfSpecialFastPathCount):
1202         (JSC::ResultProfile::detectBitsLight):
1203         (JSC::ResultProfile::hasBits):
1204         * dfg/DFGByteCodeParser.cpp:
1205         (JSC::DFG::ByteCodeParser::makeSafe):
1206         * dfg/DFGFixupPhase.cpp:
1207         (JSC::DFG::FixupPhase::fixupNode):
1208         * dfg/DFGGraph.cpp:
1209         (JSC::DFG::Graph::ensureNaturalLoops):
1210         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
1211         (JSC::DFG::Graph::valueProfileFor): Deleted.
1212         * dfg/DFGGraph.h:
1213         (JSC::DFG::Graph::hasExitSite):
1214         (JSC::DFG::Graph::numBlocks):
1215         * dfg/DFGNode.h:
1216         (JSC::DFG::Node::arithNodeFlags):
1217         (JSC::DFG::Node::mayHaveNonIntResult):
1218         (JSC::DFG::Node::mayHaveDoubleResult):
1219         (JSC::DFG::Node::mayHaveNonNumberResult):
1220         (JSC::DFG::Node::hasConstantBuffer):
1221         * dfg/DFGNodeFlags.cpp:
1222         (JSC::DFG::dumpNodeFlags):
1223         * dfg/DFGNodeFlags.h:
1224         * dfg/DFGOSRExitCompiler32_64.cpp:
1225         (JSC::DFG::OSRExitCompiler::compileExit):
1226         * dfg/DFGOSRExitCompiler64.cpp:
1227         (JSC::DFG::OSRExitCompiler::compileExit):
1228         * dfg/DFGOperations.cpp:
1229         * dfg/DFGOperations.h:
1230         * dfg/DFGPredictionPropagationPhase.cpp:
1231         * dfg/DFGSpeculativeJIT.h:
1232         (JSC::DFG::SpeculativeJIT::callOperation):
1233         * ftl/FTLOSRExitCompiler.cpp:
1234         (JSC::FTL::compileStub):
1235         * jit/AssemblyHelpers.h:
1236         (JSC::AssemblyHelpers::branchIfEqual):
1237         (JSC::AssemblyHelpers::branchIfNotCell):
1238         (JSC::AssemblyHelpers::branchIfNotNumber):
1239         (JSC::AssemblyHelpers::branchIfNotDoubleKnownNotInt32):
1240         (JSC::AssemblyHelpers::branchIfBoolean):
1241         (JSC::AssemblyHelpers::branchIfEmpty):
1242         (JSC::AssemblyHelpers::branchStructure):
1243         * jit/CCallHelpers.h:
1244         (JSC::CCallHelpers::CCallHelpers):
1245         (JSC::CCallHelpers::setupArguments):
1246         (JSC::CCallHelpers::setupArgumentsWithExecState):
1247         * jit/IntrinsicEmitter.cpp:
1248         (JSC::AccessCase::emitIntrinsicGetter):
1249         * jit/JIT.h:
1250         * jit/JITAddGenerator.cpp:
1251         (JSC::JITAddGenerator::generateFastPath):
1252         * jit/JITAddGenerator.h:
1253         (JSC::JITAddGenerator::JITAddGenerator):
1254         * jit/JITArithmetic.cpp:
1255         (JSC::JIT::emit_op_add):
1256         (JSC::JIT::emitSlow_op_add):
1257         (JSC::JIT::emit_op_div):
1258         (JSC::JIT::emit_op_mul):
1259         (JSC::JIT::emitSlow_op_mul):
1260         (JSC::JIT::emit_op_sub):
1261         (JSC::JIT::emitSlow_op_sub):
1262         * jit/JITInlines.h:
1263         (JSC::JIT::callOperation):
1264         (JSC::JIT::callOperationNoExceptionCheck):
1265         * jit/JITMulGenerator.cpp:
1266         (JSC::JITMulGenerator::generateFastPath):
1267         * jit/JITOperations.cpp:
1268         * jit/JITOperations.h:
1269         * jit/JITSubGenerator.cpp:
1270         (JSC::JITSubGenerator::generateFastPath):
1271         * jit/JITSubGenerator.h:
1272         (JSC::JITSubGenerator::JITSubGenerator):
1273         * jit/TagRegistersMode.cpp: Added.
1274         (WTF::printInternal):
1275         * jit/TagRegistersMode.h: Added.
1276         * runtime/CommonSlowPaths.cpp:
1277         (JSC::updateResultProfileForBinaryArithOp):
1278
1279 2016-05-09  Keith Miller  <keith_miller@apple.com>
1280
1281         CallObjectConstructor should not call operationToThis in the FTL
1282         https://bugs.webkit.org/show_bug.cgi?id=157492
1283         <rdar://problem/26149904>
1284
1285         Reviewed by Mark Lam.
1286
1287         At some point when I was working on intrinsifying the Object
1288         constructor, I realized that the Object constructor was different
1289         from the ToObject operation. I fixed the DFG but I guess I didn't
1290         fix the FTL.
1291
1292         This patch fixes an issue with www.wunderground.com not loading
1293         the 10-day forecast and local map.
1294
1295         * ftl/FTLLowerDFGToB3.cpp:
1296         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
1297         * tests/stress/call-object-constructor.js: Added.
1298         (test):
1299         (assert):
1300
1301 2016-05-09  Saam barati  <sbarati@apple.com>
1302
1303         Getter and setter on super are called with wrong "this" object
1304         https://bugs.webkit.org/show_bug.cgi?id=147064
1305         <rdar://problem/21885916>
1306
1307         Reviewed by Filip Pizlo.
1308
1309         This patch implements calls to 'super' getters and setters.
1310         The problem before is we were passing the 'super' (i.e, the prototype
1311         object) as the this value to these getters/setters, which is wrong. 
1312         We should be passing the caller's this value.
1313
1314         To implement this behavior, I've introduced four new opcodes and their corresponding DFG nodes:
1315         - op_get_by_id_with_this | GetByIdWithThis
1316         - op_put_by_id_with_this | PutByIdWithThis
1317         - op_get_by_val_with_this | GetByValWithThis
1318         - op_put_by_val_with_this | PutByValWithThis
1319
1320         These are implemented with no optimizations. The future plan is 
1321         to unite them with the *by_id and *by_val opcodes and nodes:
1322         https://bugs.webkit.org/show_bug.cgi?id=157215
1323
1324         * bytecode/BytecodeList.json:
1325         * bytecode/BytecodeUseDef.h:
1326         (JSC::computeUsesForBytecodeOffset):
1327         (JSC::computeDefsForBytecodeOffset):
1328         * bytecode/CodeBlock.cpp:
1329         (JSC::CodeBlock::dumpBytecode):
1330         * bytecompiler/BytecodeGenerator.cpp:
1331         (JSC::BytecodeGenerator::emitGetById):
1332         (JSC::BytecodeGenerator::emitPutById):
1333         (JSC::BytecodeGenerator::emitDirectPutById):
1334         (JSC::BytecodeGenerator::emitGetByVal):
1335         (JSC::BytecodeGenerator::emitPutByVal):
1336         (JSC::BytecodeGenerator::emitDirectPutByVal):
1337         (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
1338         (JSC::BytecodeGenerator::ensureThis):
1339         (JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
1340         * bytecompiler/BytecodeGenerator.h:
1341         * bytecompiler/NodesCodegen.cpp:
1342         (JSC::ThisNode::emitBytecode):
1343         (JSC::emitHomeObjectForCallee):
1344         (JSC::emitSuperBaseForCallee):
1345         (JSC::emitGetSuperFunctionForConstruct):
1346         (JSC::SuperNode::emitBytecode):
1347         (JSC::NewTargetNode::emitBytecode):
1348         (JSC::TaggedTemplateNode::emitBytecode):
1349         (JSC::BracketAccessorNode::emitBytecode):
1350         (JSC::DotAccessorNode::emitBytecode):
1351         (JSC::FunctionCallValueNode::emitBytecode):
1352         (JSC::FunctionCallBracketNode::emitBytecode):
1353         (JSC::FunctionCallDotNode::emitBytecode):
1354         (JSC::CallFunctionCallDotNode::emitBytecode):
1355         (JSC::ApplyFunctionCallDotNode::emitBytecode):
1356         (JSC::PostfixNode::emitBracket):
1357         (JSC::PostfixNode::emitDot):
1358         (JSC::PrefixNode::emitBracket):
1359         (JSC::PrefixNode::emitDot):
1360         (JSC::AssignDotNode::emitBytecode):
1361         (JSC::ReadModifyDotNode::emitBytecode):
1362         (JSC::AssignBracketNode::emitBytecode):
1363         (JSC::ReadModifyBracketNode::emitBytecode):
1364         (JSC::ForInNode::emitLoopHeader):
1365         (JSC::ForOfNode::emitBytecode):
1366         (JSC::AssignmentElementNode::bindValue):
1367         * dfg/DFGAbstractInterpreterInlines.h:
1368         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1369         * dfg/DFGByteCodeParser.cpp:
1370         (JSC::DFG::ByteCodeParser::parseBlock):
1371         * dfg/DFGCapabilities.cpp:
1372         (JSC::DFG::capabilityLevel):
1373         * dfg/DFGClobberize.h:
1374         (JSC::DFG::clobberize):
1375         * dfg/DFGDoesGC.cpp:
1376         (JSC::DFG::doesGC):
1377         * dfg/DFGFixupPhase.cpp:
1378         (JSC::DFG::FixupPhase::fixupNode):
1379         * dfg/DFGNode.h:
1380         (JSC::DFG::Node::hasIdentifier):
1381         * dfg/DFGNodeType.h:
1382         * dfg/DFGOperations.cpp:
1383         (JSC::DFG::newTypedArrayWithSize):
1384         (JSC::DFG::putWithThis):
1385         * dfg/DFGOperations.h:
1386         * dfg/DFGPredictionPropagationPhase.cpp:
1387         * dfg/DFGSafeToExecute.h:
1388         (JSC::DFG::safeToExecute):
1389         * dfg/DFGSpeculativeJIT.h:
1390         (JSC::DFG::SpeculativeJIT::callOperation):
1391         * dfg/DFGSpeculativeJIT32_64.cpp:
1392         (JSC::DFG::SpeculativeJIT::compile):
1393         * dfg/DFGSpeculativeJIT64.cpp:
1394         (JSC::DFG::SpeculativeJIT::compile):
1395         * ftl/FTLCapabilities.cpp:
1396         (JSC::FTL::canCompile):
1397         * ftl/FTLLowerDFGToB3.cpp:
1398         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1399         (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
1400         (JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
1401         (JSC::FTL::DFG::LowerDFGToB3::compileGetByValWithThis):
1402         (JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis):
1403         (JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis):
1404         (JSC::FTL::DFG::LowerDFGToB3::compilePutById):
1405         * jit/CCallHelpers.cpp:
1406         (JSC::CCallHelpers::setupShadowChickenPacket):
1407         (JSC::CCallHelpers::setupFourStubArgsGPR):
1408         * jit/CCallHelpers.h:
1409         (JSC::CCallHelpers::setupArgumentsWithExecState):
1410         (JSC::CCallHelpers::setupThreeStubArgsGPR):
1411         (JSC::CCallHelpers::setupTwoStubArgsFPR):
1412         (JSC::CCallHelpers::setupStubArguments134):
1413         * jit/GPRInfo.h:
1414         (JSC::argumentRegisterFor): Deleted.
1415         * jit/JIT.cpp:
1416         (JSC::JIT::privateCompileMainPass):
1417         * jit/JIT.h:
1418         * jit/JITOperations.h:
1419         * jit/JITPropertyAccess.cpp:
1420         (JSC::JIT::emit_op_put_by_val):
1421         (JSC::JIT::emit_op_put_by_val_with_this):
1422         (JSC::JIT::emitGenericContiguousPutByVal):
1423         (JSC::JIT::emit_op_get_by_id):
1424         (JSC::JIT::emit_op_get_by_id_with_this):
1425         (JSC::JIT::emit_op_get_by_val_with_this):
1426         (JSC::JIT::emitSlow_op_get_by_id):
1427         (JSC::JIT::emit_op_put_by_id):
1428         (JSC::JIT::emit_op_put_by_id_with_this):
1429         (JSC::JIT::emitSlow_op_put_by_id):
1430         * jit/JITPropertyAccess32_64.cpp:
1431         (JSC::JIT::emit_op_put_to_arguments):
1432         (JSC::JIT::emit_op_get_by_id_with_this):
1433         (JSC::JIT::emit_op_get_by_val_with_this):
1434         (JSC::JIT::emit_op_put_by_id_with_this):
1435         (JSC::JIT::emit_op_put_by_val_with_this):
1436         * llint/LowLevelInterpreter.asm:
1437         * runtime/CommonSlowPaths.cpp:
1438         (JSC::SLOW_PATH_DECL):
1439         * runtime/CommonSlowPaths.h:
1440         * tests/stress/super-property-access-exceptions.js: Added.
1441         (assert):
1442         (test):
1443         (test.fooProp):
1444         (test.A.prototype.get foo):
1445         (test.A.prototype.get x):
1446         (test.A):
1447         (test.B):
1448         (test.B.prototype.bar):
1449         (test.B.prototype.baz):
1450         (test.foo):
1451         (test.func):
1452         (test.A.prototype.set foo):
1453         * tests/stress/super-property-access-tdz.js: Added.
1454         (assert):
1455         (test):
1456         (shouldThrowTDZ):
1457         (test.A.prototype.get foo):
1458         (test.A.prototype.set foo):
1459         (test.A):
1460         (test.fooProp):
1461         (test.B):
1462         (test.C):
1463         (test.D):
1464         (test.E):
1465         (test.F):
1466         * tests/stress/super-property-access.js: Added.
1467         (assert):
1468         (test):
1469         (func):
1470         (test.A):
1471         (test.A.prototype.set value):
1472         (test.A.prototype.get value):
1473         (test.B.prototype.set value):
1474         (test.B.prototype.get value):
1475         (test.B):
1476         (test.value):
1477         (test.A.prototype.get func):
1478         (test.B.prototype.inc):
1479         (test.B.prototype.dec):
1480         (test.B.prototype.preInc):
1481         (test.B.prototype.preDec):
1482         (test.B.prototype.plusEq):
1483         (test.B.prototype.minusEq):
1484         (test.B.prototype.timesEq):
1485         (test.B.prototype.divEq):
1486         (test.B.prototype.funcDot):
1487         (test.B.prototype.funcBracket):
1488         (test.foo):
1489         (test.B.prototype.baz):
1490         (test.B.prototype.jaz):
1491         (test.B.prototype.bar):
1492         (test.B.prototype.index):
1493         (test.):
1494         (test.prototype.bar):
1495         (test.A.prototype.set foo):
1496         (test.A.prototype.get array):
1497         (test.A.prototype.get foo):
1498         (test.obj):
1499         (test.A.prototype.get call):
1500         (test.A.prototype.get apply):
1501         (test.B.prototype.foo):
1502         (test.A.prototype.get i):
1503
1504 2016-05-08  Chris Dumez  <cdumez@apple.com>
1505
1506         [COCOA] Disable HAVE_DTRACE at build time
1507         https://bugs.webkit.org/show_bug.cgi?id=157433
1508         <rdar://problem/26148841>
1509
1510         Reviewed by Mark Lam.
1511
1512         Drop DTRACE-related code from JSC since it is very old and seems
1513         unused.
1514
1515         * JavaScriptCore.xcodeproj/project.pbxproj:
1516         * PlatformMac.cmake:
1517         * heap/Heap.cpp:
1518         (JSC::Heap::collectImpl): Deleted.
1519         (JSC::Heap::didFinishCollection): Deleted.
1520         * profiler/ProfileGenerator.cpp:
1521         (JSC::ProfileGenerator::willExecute): Deleted.
1522         (JSC::ProfileGenerator::didExecute): Deleted.
1523         * runtime/Tracing.d: Removed.
1524         * runtime/Tracing.h: Removed.
1525
1526 2016-05-07  Mark Lam  <mark.lam@apple.com>
1527
1528         Add JSC options bytecodeRangeToJITCompile and jitWhitelist.
1529         https://bugs.webkit.org/show_bug.cgi?id=157428
1530
1531         Reviewed by Michael Saboff.
1532
1533         1. Added Options::bytecodeRangeToJITCompile and Options::jitWhitelist options.
1534
1535         2. Moved DFGFunctionWhitelist* to FunctionWhitelist* and made it generic so that
1536            it can be used for more than one whitelist instance.  In this case, we now have
1537            two: the dfgWhitelist and the jitWhitelist.
1538
1539         3. Added "can compile" checks in LLInt::shouldJIT() to check
1540            Options::bytecodeRangeToJITCompile and Options::jitWhitelist.
1541
1542         * CMakeLists.txt:
1543         * JavaScriptCore.xcodeproj/project.pbxproj:
1544         * dfg/DFGDriver.cpp:
1545         (JSC::DFG::getNumCompilations):
1546         (JSC::DFG::ensureGlobalDFGWhitelist):
1547         (JSC::DFG::compileImpl):
1548         * dfg/DFGFunctionWhitelist.cpp: Removed.
1549         * dfg/DFGFunctionWhitelist.h: Removed.
1550
1551         * llint/LLIntSlowPaths.cpp:
1552         (JSC::LLInt::ensureGlobalJITWhitelist):
1553         (JSC::LLInt::shouldJIT):
1554
1555         * runtime/Options.h:
1556
1557         * tools/FunctionWhitelist.cpp: Copied from Source/JavaScriptCore/dfg/DFGFunctionWhitelist.cpp.
1558         (JSC::FunctionWhitelist::FunctionWhitelist):
1559         (JSC::FunctionWhitelist::contains):
1560         (JSC::DFG::FunctionWhitelist::ensureGlobalWhitelist): Deleted.
1561         (JSC::DFG::FunctionWhitelist::FunctionWhitelist): Deleted.
1562         (JSC::DFG::FunctionWhitelist::parseFunctionNamesInFile): Deleted.
1563         (JSC::DFG::FunctionWhitelist::contains): Deleted.
1564         * tools/FunctionWhitelist.h: Copied from Source/JavaScriptCore/dfg/DFGFunctionWhitelist.h.
1565
1566 2016-05-07  Benjamin Poulain  <bpoulain@apple.com>
1567
1568         [JSC][32bit] stress/tagged-templates-template-object.js fails in debug
1569         https://bugs.webkit.org/show_bug.cgi?id=157436
1570
1571         Reviewed by Filip Pizlo.
1572
1573         * dfg/DFGSpeculativeJIT32_64.cpp:
1574         (JSC::DFG::SpeculativeJIT::compile):
1575         The node OverridesHasInstance had a speculation after a jump.
1576
1577 2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>
1578
1579         Web Inspector: Misc CommandLineAPI cleanup
1580         https://bugs.webkit.org/show_bug.cgi?id=157450
1581
1582         Reviewed by Ryosuke Niwa.
1583
1584         * inspector/InjectedScriptSource.js:
1585         (BasicCommandLineAPI):
1586         Fix mistake in r200533, and modernize related code.
1587
1588 2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>
1589
1590         Web Inspector: Improve console.count()
1591         https://bugs.webkit.org/show_bug.cgi?id=157439
1592         <rdar://problem/26152654>
1593
1594         Reviewed by Timothy Hatcher.
1595
1596           - make console.count() increment an unnamed global counter.
1597           - make console.count(label) increment a counter with that label name.
1598
1599         * inspector/agents/InspectorConsoleAgent.cpp:
1600         (Inspector::InspectorConsoleAgent::count):
1601
1602 2016-05-06  Simon Fraser  <simon.fraser@apple.com>
1603
1604         Enable IOS_TEXT_AUTOSIZING on Mac and make it testable
1605         https://bugs.webkit.org/show_bug.cgi?id=157432
1606         rdar://problem/16406720
1607
1608         Reviewed by Dean Jackson.
1609
1610         Enable IOS_TEXT_AUTOSIZING on Mac so it can be tested.
1611
1612         * Configurations/FeatureDefines.xcconfig:
1613
1614 2016-05-06  Joseph Pecoraro  <pecoraro@apple.com>
1615
1616         Web Inspector: Console: Variables defined with let/const aren't accessible outside of console's scope
1617         https://bugs.webkit.org/show_bug.cgi?id=150752
1618         <rdar://problem/23343385>
1619
1620         Reviewed by Mark Lam.
1621
1622         This approach allows Web Inspector to hang a "Scope Extension", a
1623         WithObjectScope, off the GlobalObject. When resolving identifiers
1624         in fails to resolve anything in the normal scope chain, consult
1625         the scope extension.
1626
1627         This allows us to eliminate the `with (commandLineAPI) { ... }`
1628         block in global console evaluations, and instead makes it a full
1629         program evaluation, with the commandLineAPI available and safely
1630         shadowed by actual variables as expected.
1631
1632         * inspector/InjectedScriptSource.js:
1633         (InjectedScript.prototype._evaluateOn):
1634         Use the new evaluateWithScopeExtension and provide the CommandLineAPI
1635         object as the scope extension object.
1636
1637         (BasicCommandLineAPI):
1638         (BasicCommandLineAPI.inScopeVariables): Deleted.
1639         Simplify now that we don't need to check for variable shadowing ourselves.
1640
1641         * inspector/JSInjectedScriptHost.cpp:
1642         (Inspector::JSInjectedScriptHost::evaluateWithScopeExtension):
1643         * inspector/JSInjectedScriptHost.h:
1644         * inspector/JSInjectedScriptHostPrototype.cpp:
1645         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
1646         (Inspector::jsInjectedScriptHostPrototypeFunctionEvaluateWithScopeExtension):
1647         Provide a new InjectedScriptHost method to evaluate a program
1648         with a scope extension.
1649
1650         * runtime/Completion.cpp:
1651         (JSC::evaluateWithScopeExtension):
1652         * runtime/Completion.h:
1653         General JSC::evaluate function to evaluate a program with a scope extension.
1654
1655         * runtime/JSGlobalObject.cpp:
1656         (JSC::JSGlobalObject::setGlobalScopeExtension):
1657         (JSC::JSGlobalObject::clearGlobalScopeExtension):
1658         (JSC::JSGlobalObject::visitChildren):
1659         * runtime/JSGlobalObject.h:
1660         (JSC::JSGlobalObject::globalScopeExtension):
1661         Hang a scope extension off the global object.
1662
1663         * runtime/JSScope.cpp:
1664         (JSC::JSScope::resolve):
1665         Consult the scope extension when resolve fails to find anything normally.
1666
1667 2016-05-06  Mark Lam  <mark.lam@apple.com>
1668
1669         Add JSC options reportBaselineCompileTimes and reportDFGCompileTimes.
1670         https://bugs.webkit.org/show_bug.cgi?id=157427
1671
1672         Reviewed by Filip Pizlo and Keith Miller.
1673
1674         The compile times reporting options are now:
1675             reportCompileTimes         -> report compile times in all tiers.
1676             reportBaselineCompileTimes -> report compile times in baseline JIT.
1677             reportDFGCompileTimes      -> report compile times in DFG and FTL.
1678             reportFTLCompileTimes      -> report compile times in FTL.
1679
1680         Also updated reportTotalCompileTimes() to collect stats that include the baseline
1681         JIT.  compileTimeStats() is now moved into JIT.cpp (from DFGPlan.cpp). 
1682
1683         * dfg/DFGPlan.cpp:
1684         (JSC::DFG::Plan::reportCompileTimes):
1685         (JSC::DFG::Plan::compileInThread):
1686         (JSC::DFG::Plan::compileInThreadImpl):
1687         (JSC::DFG::Plan::cancel):
1688         (JSC::DFG::Plan::compileTimeStats): Deleted.
1689         * dfg/DFGPlan.h:
1690         (JSC::DFG::Plan::compileTimeStats): Deleted.
1691         * jit/JIT.cpp:
1692         (JSC::ctiPatchCallByReturnAddress):
1693         (JSC::JIT::privateCompile):
1694         (JSC::JIT::stackPointerOffsetFor):
1695         (JSC::JIT::reportCompileTimes):
1696         (JSC::JIT::computeCompileTimes):
1697         (JSC::JIT::compileTimeStats):
1698         * jit/JIT.h:
1699         (JSC::JIT::shouldEmitProfiling):
1700         * jsc.cpp:
1701         (runJSC):
1702         * runtime/Options.h:
1703
1704 2016-05-05  Benjamin Poulain  <bpoulain@apple.com>
1705
1706         [JSC] Get rid of NonNegZeroDouble, it is broken
1707         https://bugs.webkit.org/show_bug.cgi?id=157399
1708         rdar://problem/25339647
1709
1710         Reviewed by Mark Lam.
1711
1712         The profile "NonNegZeroDouble" is fundamentally broken.
1713
1714         It is used by DFG to predict the result of ArithMul as being a Double
1715         or Int32.
1716         The problem is you are likely to mispredict, and when you do, you are
1717         guaranteed to end up in a recompile loop.
1718
1719         The compile loops usually happen like this:
1720         -We speculate you have Int32 despite producing doubles.
1721         -We OSR exit on another node (ValueToInt32 for example) from the result of this ArithMul.
1722         -When we compile this block again, ArithMul will do the same misprediction
1723          because it unconditionally predicts Int32.
1724
1725         The flag NonNegZeroDouble was very unlikely to be set correctly
1726         in the first place.
1727
1728         In LLINT, the flag is only set on the slow path.
1729         Since double*double is on the fast path, those cases are ignored.
1730
1731         In Baseline, the flag is set for any case that falls back on double
1732         multiplication. BUT, the DFG flag was only set for nodes that spend
1733         many iteration in slow path, which obviously does not apply to double*double.
1734
1735         Given the perf drawbacks and the recompile loops, I removed
1736         the whole flag for now.
1737
1738         * bytecode/ValueProfile.cpp:
1739         (WTF::printInternal):
1740         * bytecode/ValueProfile.h:
1741         (JSC::ResultProfile::didObserveNonInt32): Deleted.
1742         (JSC::ResultProfile::didObserveDouble): Deleted.
1743         (JSC::ResultProfile::didObserveNonNegZeroDouble): Deleted.
1744         (JSC::ResultProfile::setObservedNonNegZeroDouble): Deleted.
1745         * dfg/DFGByteCodeParser.cpp:
1746         (JSC::DFG::ByteCodeParser::makeSafe): Deleted.
1747         * dfg/DFGNode.h:
1748         (JSC::DFG::Node::mayHaveNonIntResult): Deleted.
1749         * dfg/DFGNodeFlags.cpp:
1750         (JSC::DFG::dumpNodeFlags): Deleted.
1751         * dfg/DFGNodeFlags.h:
1752         * dfg/DFGPredictionPropagationPhase.cpp:
1753         * jit/JITMulGenerator.cpp:
1754         (JSC::JITMulGenerator::generateFastPath): Deleted.
1755         * runtime/CommonSlowPaths.cpp:
1756         (JSC::updateResultProfileForBinaryArithOp): Deleted.
1757
1758 2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>
1759
1760         REGRESSION(r200422): Web Inspector: Make new Array Iterator objects play nice with Web Inspector
1761         https://bugs.webkit.org/show_bug.cgi?id=157361
1762         <rdar://problem/26099793>
1763
1764         Reviewed by Timothy Hatcher.
1765
1766         * builtins/ArrayPrototype.js:
1767         (createArrayIterator):
1768         (values):
1769         (keys):
1770         (entries):
1771         * builtins/TypedArrayPrototype.js:
1772         (values):
1773         (keys):
1774         (entries):
1775         * runtime/CommonIdentifiers.h:
1776         Set the kind on the iterator object, that can be shown
1777         to the inspector if the object is shown in the console.
1778
1779         * inspector/InjectedScriptSource.js:
1780         (InjectedScript.prototype._describe):
1781         Get a better name for the new Array Iterator which is just an Object.
1782
1783         * inspector/JSInjectedScriptHost.cpp:
1784         (Inspector::JSInjectedScriptHost::subtype):
1785         (Inspector::JSInjectedScriptHost::getInternalProperties):
1786         Detect and handle ArrayIterator object instances. Porting the code
1787         from the JSArrayIterator code path.
1788
1789 2016-05-05  Benjamin Poulain  <bpoulain@apple.com>
1790
1791         [JSC] In DFG, an OSR Exit on SetLocal can trash its child node
1792         https://bugs.webkit.org/show_bug.cgi?id=157358
1793         rdar://problem/25339647
1794
1795         Reviewed by Filip Pizlo.
1796
1797         When we OSR Exit on SetLocal, the child is never restored if its representation
1798         was changed since the MovHint.
1799
1800         For example, say we have:
1801             @1 = SomethingProducingDouble()
1802             @2 = MovHint(@1)
1803             @3 = ValueRep(@1)
1804             @4 = SetLocal(@3, FlushedInt32)
1805
1806         When we lower SetLocal(), we start by speculating that @3 is an Int32.
1807         Now this can fail if @1 was really a double.
1808         When that happens, we go over the VariableEventStream to find where values
1809         are, and @1 died at @3. Since the speculation failure happens before
1810         the SetLocal event, we don't do anything with @3.
1811
1812         In this patch, I extend the PhantomInsertion phase to keep the MovHint
1813         alive past the SetLocal.
1814
1815         * dfg/DFGPhantomInsertionPhase.cpp:
1816         * tests/stress/multiply-typed-double-and-object.js: Added.
1817         (otherObject.valueOf):
1818         (targetDFG.multiply):
1819         (targetFTL.multiply):
1820
1821 2016-05-05  Oliver Hunt  <oliver@apple.com>
1822
1823         Enable separated heap by default on ios
1824         https://bugs.webkit.org/show_bug.cgi?id=156720
1825
1826         Reviewed by Geoffrey Garen.
1827
1828         We've fixed the xnu side of things, so we can reland this.
1829
1830         * runtime/Options.cpp:
1831         (JSC::recomputeDependentOptions):
1832
1833 2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>
1834
1835         JSContext Inspector: Better CommandLineAPI in JSContext inspection
1836         https://bugs.webkit.org/show_bug.cgi?id=157387
1837         <rdar://problem/22630583>
1838
1839         Reviewed by Timothy Hatcher.
1840
1841         * inspector/InjectedScriptSource.js:
1842         (InjectedScript.prototype._evaluateOn):
1843         (BasicCommandLineAPI.inScopeVariables):
1844         (BasicCommandLineAPI):
1845         When creating a BasicCommandLineAPI, pass the call frame so
1846         that we don't shadow variables in the callstack.
1847
1848         (BasicCommandLineAPI.methods):
1849         (clear):
1850         (table):
1851         (profile):
1852         (profileEnd):
1853         (keys):
1854         (values):
1855         Some just pass through to console, others are tiny methods.
1856         Implement them, and give them the expected toString string.
1857
1858 2016-05-05  Filip Pizlo  <fpizlo@apple.com>
1859
1860         Reduce maximum JIT pool size on X86_64.
1861
1862         Rubber stamped by Geoffrey Garen.
1863         
1864         This changes our maximum pool size to 100MB. The problem with letting a page allocate much
1865         more than this is that we will sometimes call deleteAllCode() or one of its friends. Deleting
1866         a huge amount of memory is expensive in our allocator.
1867         
1868         So long as we allow for such large-scale code death to happen, and so long as it's expensive,
1869         we should bound the amount of code we end up with in the first place.
1870         
1871         In the long run, we should fix our executable allocator so that it's not so expensive to kill
1872         all code.
1873         
1874         * jit/ExecutableAllocator.h:
1875
1876 2016-05-05  Filip Pizlo  <fpizlo@apple.com>
1877
1878         Reduce thresholds that control the maximum IC stub size.
1879
1880         Rubber stamped by Chris Dumez and Benjamin Poulain.
1881         
1882         This reduces the thresholds to before the megamorphic load optimizations to see if that
1883         recovers a PLT regression.
1884
1885         * runtime/Options.h:
1886
1887 2016-05-05  Filip Pizlo  <fpizlo@apple.com>
1888
1889         We shouldn't crash if DFG AI proved that something was unreachable on one run but then decided not to prove it on another run
1890         https://bugs.webkit.org/show_bug.cgi?id=157379
1891
1892         Reviewed by Mark Lam.
1893         
1894         Any run of DFG AI is a fixpoint that loosens the proof until it can't find any more
1895         counterexamples to the proof.  It errs on the side of loosening proofs, i.e., on the side of
1896         proving fewer things.
1897
1898         We run this fixpoint multiple times since there are multiple points in the DFG optimization
1899         pipeline when we run DFG AI.  Each of those runs completes a fixpoint and produces the
1900         tightest proof it can that did not result in counterexamples being found.
1901
1902         It's possible that on run K of DFG AI, we prove some property, but on run K+1, we don't prove
1903         that property. The code could have changed between the two runs due to other phases. Other
1904         phases may modify the code in such a way that it's less amenable to AI's analysis. Our design
1905         allows this because DFG AI is not 100% precise. It defends itself from making unsound choices
1906         or running forever by sometimes punting on proving some property. It must be able to do this,
1907         and so therefore, it might sometimes prove fewer things on a later run.
1908
1909         Currently in trunk if the property that AI proves on run K but fails to prove on run K+1 is
1910         the reachability of a piece of code, then run K+1 will crash on an assertion at the
1911         Unreachable node. It will complain that it reached an Unreachable. But it might be reaching
1912         that Unreachable because it failed to prove that something earlier was always exiting. That's
1913         OK, see above.
1914
1915         So, we should remove the assertion that AI doesn't see Unreachable.
1916         
1917         No new tests because I don't know how to make this happen. I believe that this happens in the
1918         wild based on crash logs.
1919
1920         * dfg/DFGAbstractInterpreterInlines.h:
1921         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1922
1923 2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>
1924
1925         Crash if you type "debugger" in the console and continue
1926         https://bugs.webkit.org/show_bug.cgi?id=156924
1927         <rdar://problem/25884189>
1928
1929         Reviewed by Mark Lam.
1930
1931         * inspector/agents/InspectorDebuggerAgent.cpp:
1932         (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
1933         Bail with an error when we are not paused.
1934
1935         * inspector/agents/InspectorRuntimeAgent.cpp:
1936         (Inspector::InspectorRuntimeAgent::callFunctionOn):
1937         (Inspector::InspectorRuntimeAgent::getProperties):
1938         (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
1939         (Inspector::InspectorRuntimeAgent::getCollectionEntries):
1940         (Inspector::InspectorRuntimeAgent::saveResult):
1941         Update poor error message.
1942
1943 2016-05-05  Keith Miller  <keith_miller@apple.com>
1944
1945         Add support for delete by value to the DFG
1946         https://bugs.webkit.org/show_bug.cgi?id=157372
1947
1948         Reviewed by Filip Pizlo.
1949
1950         This patch adds basic support for delete by value to the DFG. delete by value
1951         just calls out to a C++ operation on each execution. Additionally, this patch
1952         fixes an issue with delete by id where we would crash if the base was null
1953         or undefined.
1954
1955         * dfg/DFGAbstractInterpreterInlines.h:
1956         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1957         * dfg/DFGByteCodeParser.cpp:
1958         (JSC::DFG::ByteCodeParser::parseBlock):
1959         * dfg/DFGCapabilities.cpp:
1960         (JSC::DFG::capabilityLevel):
1961         * dfg/DFGClobberize.h:
1962         (JSC::DFG::clobberize):
1963         * dfg/DFGDoesGC.cpp:
1964         (JSC::DFG::doesGC):
1965         * dfg/DFGFixupPhase.cpp:
1966         (JSC::DFG::FixupPhase::fixupNode):
1967         * dfg/DFGNodeType.h:
1968         * dfg/DFGPredictionPropagationPhase.cpp:
1969         * dfg/DFGSafeToExecute.h:
1970         (JSC::DFG::safeToExecute):
1971         * dfg/DFGSpeculativeJIT.cpp:
1972         (JSC::DFG::SpeculativeJIT::compileDeleteById):
1973         (JSC::DFG::SpeculativeJIT::compileDeleteByVal):
1974         * dfg/DFGSpeculativeJIT.h:
1975         (JSC::DFG::SpeculativeJIT::callOperation):
1976         * dfg/DFGSpeculativeJIT32_64.cpp:
1977         (JSC::DFG::SpeculativeJIT::compile):
1978         * dfg/DFGSpeculativeJIT64.cpp:
1979         (JSC::DFG::SpeculativeJIT::compile):
1980         * jit/JIT.cpp:
1981         (JSC::JIT::privateCompileMainPass):
1982         * jit/JIT.h:
1983         * jit/JITOperations.cpp:
1984         * jit/JITOperations.h:
1985         * jit/JITPropertyAccess.cpp:
1986         (JSC::JIT::emit_op_del_by_val):
1987         * jit/JITPropertyAccess32_64.cpp:
1988         (JSC::JIT::emit_op_del_by_val):
1989         * tests/stress/delete-by-val.js: Added.
1990         (assert):
1991         (test):
1992         * tests/stress/delete-to-object-exception.js: Added.
1993         (assert):
1994         (test):
1995
1996 2016-05-05  Michael Saboff  <msaboff@apple.com>
1997
1998         Unreviewed build fix after change set r200447.
1999
2000         Made the detection of clang version XCode build specific.
2001         Now shouldEnableDebugAnnotations() should return false for all other build types.
2002
2003         * offlineasm/config.rb:
2004
2005 2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>
2006
2007         Create console object lazily
2008         https://bugs.webkit.org/show_bug.cgi?id=157328
2009
2010         Reviewed by Geoffrey Garen.
2011
2012         * runtime/CommonIdentifiers.h:
2013         * runtime/JSGlobalObject.cpp:
2014         (JSC::createConsoleProperty):
2015         (JSC::JSGlobalObject::init): Deleted.
2016
2017 2016-05-04  Michael Saboff  <msaboff@apple.com>
2018
2019         Enable Dwarf2 debug information in offline assembler for clang compiler
2020         https://bugs.webkit.org/show_bug.cgi?id=157364.
2021
2022         Reviewed by Mark Lam.
2023
2024         Added a new function shouldEnableDebugAnnotations() that determines if
2025         we are using clang and a new enough version to support the debug annotations.
2026
2027         * offlineasm/config.rb:
2028         (shouldEnableDebugAnnotations): Added.
2029
2030 2016-05-04  Keith Miller  <keith_miller@apple.com>
2031
2032         Unreviewed, fix test for new ArrayIteratorPrototype.next() error message.
2033
2034         * tests/stress/array-iterators-next-with-call.js:
2035
2036 2016-05-04  Filip Pizlo  <fpizlo@apple.com>
2037
2038         Speed up JSGlobalObject initialization by making some properties lazy
2039         https://bugs.webkit.org/show_bug.cgi?id=157045
2040
2041         Reviewed by Keith Miller.
2042         
2043         This makes about half of JSGlobalObject's state lazy. There are three categories of
2044         state in JSGlobalObject:
2045         
2046         1) C++ fields in JSGlobalObject.
2047         2) JS object properties in JSGlobalObject's JSObject superclass.
2048         3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass.
2049         
2050         State held in JS variables cannot yet be made lazy. That's why this patch only goes
2051         half-way.
2052         
2053         State in JS object properties can be made lazy if we move it to the static property
2054         hashtable. JSGlobalObject already had one of those. This patch makes static property
2055         hashtables a lot more powerful, by adding three new kinds of static properties. These
2056         new kinds allow us to make almost all of JSGlobalObject's object properties lazy.
2057         
2058         State in C++ fields can now be made lazy thanks in part to WTF's support for stateless
2059         lambdas. You can of course make anything lazy by hand, but there are many C++ fields in
2060         JSGlobalObject and we are adding more all the time. We don't want to require that each
2061         of these has a getter with an initialization check and a corresponding out-of-line slow
2062         path that does the initialization. We want this kind of boilerplate to be handled by
2063         some abstractions.
2064         
2065         The primary abstraction introduced in this patch is LazyProperty<Type>. Currently, this
2066         only works where Type is a subclass of JSCell. Such a property holds a pointer to Type.
2067         You can use it like you would a WriteBarrier<Type>. It even has set() and get() methods,
2068         so it's almost a drop-in replacement.
2069         
2070         The key to LazyProperty<Type>'s power is that you can do this:
2071         
2072             class Bar {
2073                 ...
2074                 LazyProperty<Foo> m_foo;
2075             };
2076             ...
2077             m_foo.initLater(
2078                 [] (const LazyProperty<Foo>::Initializer<Bar>& init) {
2079                     init.set(Foo::create(init.vm, init.owner));
2080                 });
2081         
2082         This initLater() call requires that you pass a stateless lambda (see WTF changelog for
2083         the definition). Miraculously, this initLater() call is guaranteed to compile to a store
2084         of a pointer constant to m_foo, as in:
2085         
2086             movabsq 0xBLAH, %rax
2087             movq %rax, &m_foo
2088         
2089         This magical pointer constant points to a callback that was generated by the template
2090         instantiation of initLater(). That callback knows to call your stateless lambda, but
2091         also does some other bookkeeping: it makes sure that you indeed initialized the property
2092         inside the callback and it manages recursive initializations. It's totally legal to call
2093         m_foo.get() inside the initLater() callback. If you do that before you call init.set(),
2094         m_foo.get() will return null. This is an excellent escape hatch if we ever find
2095         ourselves in a dependency cycle. I added this feature because I already had to create a
2096         dependency cycle.
2097         
2098         Note that using LazyProperties from DFG threads is super awkward. It's going to be hard
2099         to get this right. The DFG thread cannot initialize those fields, so it has to make sure
2100         that it does conservative things. But for some nodes this could mean adding a lot of new
2101         logic, like NewTypedArray, which currently is written in such a way that it assumes that
2102         we always have the typed array structure. Currently we take a two-fold approach: for
2103         typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't
2104         initialized, and for everything else we don't make the properties lazy if the DFG needs
2105         them. As we optimize this further we might need to teach the DFG to handle more lazy
2106         properties. I tried to do this for RegExp but found it to be very confusing. With typed
2107         arrays I got lucky.
2108         
2109         There is also a somewhat more powerful construct called LazyClassStructure. We often
2110         need to keep around the structure of some standard JS class, like Date. We also need to
2111         make sure that the constructor ends up in the global object's property table. And we
2112         often need to keep the original value of the constructor for ourselves. In this case, we
2113         want to make sure that the creation of the structure-prototype-constructor constellation
2114         is atomic. We don't want code to start looking at the structure if it points to a
2115         prototype that doesn't have its "constructor" property set yet, for example.
2116         LazyClassStructure solves this by abstracting that whole initialization. You provide the
2117         callback that allocates everything, since we are super inconsistent about the way we
2118         initialize things, but LazyClassStructure establishes the workflow and helps you not
2119         mess up.
2120         
2121         Finally, the new static hashtable attributes allow for all of this to work with the JS
2122         property table:
2123         
2124         PropertyCallback: if you use this attribute, the second column in the table should be
2125         the name of a function to call to initialize this property. This is useful for things
2126         like the Math property. The Math object turns out to be very expensive to allocate.
2127         Delaying its allocation is super easy with the PropertyCallback attribute.
2128         
2129         CellProperty: with this attribute the second column should be a C++ field name like
2130         JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of
2131         this property, and when it needs to be initialized, Lookup will assume you have a
2132         LazyProperty<JSCell> and call its get() method. It will initialize the property to
2133         whatever get() returned. Note that it's legal to cast a LazyProperty<Anything> to
2134         LazyProperty<JSCell> for the purpose of calling get() because the get() method will just
2135         call whatever callback function pointer is encoded in the property and it does not need
2136         to know anything about what type that callback will instantiate.
2137         
2138         ClassStructure: with this attribute the second column should be a C++ field name. The
2139         static hashtable will initialize the property by treating the field as a
2140         LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole
2141         initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns,
2142         the property in question will already be set. By convention, we have LazyClassStructure
2143         initialize the property with a pointer to the constructor, since that's how all of our
2144         classes work: "globalObject.Date" points to the DateConstructor.
2145         
2146         This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that
2147         calls our C API. This is a 1% speed-up on SunSpider and JSRegress.
2148         
2149         Rolling this back in after fixing the function pointer alignment issue. The last version
2150         relied on function pointers being aligned to a 4-byte boundary. We cannot rely on this,
2151         especially since ARMv7 uses the low bit of function pointers as a tag to indicate the
2152         instruction set. This version adds an extra indirection, so that
2153         LazyProperty<>::m_pointer points to a pointer that points to the function. A pointer to
2154         a pointer is guaranteed to be at least 4-byte aligned.
2155
2156         * API/JSCallbackFunction.cpp:
2157         (JSC::JSCallbackFunction::create):
2158         * API/ObjCCallbackFunction.h:
2159         (JSC::ObjCCallbackFunction::impl):
2160         * API/ObjCCallbackFunction.mm:
2161         (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
2162         (JSC::ObjCCallbackFunction::create):
2163         * CMakeLists.txt:
2164         * JavaScriptCore.xcodeproj/project.pbxproj:
2165         * create_hash_table:
2166         * debugger/DebuggerScope.cpp:
2167         (JSC::DebuggerScope::create):
2168         (JSC::DebuggerScope::DebuggerScope):
2169         * debugger/DebuggerScope.h:
2170         (JSC::DebuggerScope::jsScope):
2171         (JSC::DebuggerScope::create): Deleted.
2172         * dfg/DFGAbstractInterpreterInlines.h:
2173         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2174         * dfg/DFGAbstractValue.cpp:
2175         (JSC::DFG::AbstractValue::set):
2176         * dfg/DFGArrayMode.cpp:
2177         (JSC::DFG::ArrayMode::originalArrayStructure):
2178         * dfg/DFGByteCodeParser.cpp:
2179         (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
2180         * dfg/DFGSpeculativeJIT.cpp:
2181         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
2182         * dfg/DFGSpeculativeJIT32_64.cpp:
2183         (JSC::DFG::SpeculativeJIT::compile):
2184         * dfg/DFGSpeculativeJIT64.cpp:
2185         (JSC::DFG::SpeculativeJIT::compile):
2186         * dfg/DFGStructureRegistrationPhase.cpp:
2187         (JSC::DFG::StructureRegistrationPhase::run):
2188         * ftl/FTLLowerDFGToB3.cpp:
2189         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2190         * runtime/ClonedArguments.cpp:
2191         (JSC::ClonedArguments::getOwnPropertySlot):
2192         (JSC::ClonedArguments::materializeSpecials):
2193         * runtime/CommonSlowPaths.cpp:
2194         (JSC::SLOW_PATH_DECL):
2195         * runtime/FunctionPrototype.cpp:
2196         (JSC::functionProtoFuncToString):
2197         * runtime/InternalFunction.cpp:
2198         (JSC::InternalFunction::visitChildren):
2199         (JSC::InternalFunction::name):
2200         (JSC::InternalFunction::calculatedDisplayName):
2201         (JSC::InternalFunction::createSubclassStructure):
2202         * runtime/InternalFunction.h:
2203         * runtime/JSBoundFunction.cpp:
2204         (JSC::JSBoundFunction::finishCreation):
2205         (JSC::JSBoundFunction::visitChildren):
2206         * runtime/JSBoundSlotBaseFunction.cpp:
2207         (JSC::JSBoundSlotBaseFunction::create):
2208         * runtime/JSFunction.cpp:
2209         (JSC::retrieveCallerFunction):
2210         (JSC::getThrowTypeErrorGetterSetter):
2211         (JSC::JSFunction::callerGetter):
2212         (JSC::JSFunction::getOwnPropertySlot):
2213         (JSC::JSFunction::defineOwnProperty):
2214         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
2215         (JSC::constructGenericTypedArrayView):
2216         * runtime/JSGlobalObject.cpp:
2217         (JSC::createProxyProperty):
2218         (JSC::createJSONProperty):
2219         (JSC::createMathProperty):
2220         (JSC::JSGlobalObject::init):
2221         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
2222         (JSC::JSGlobalObject::resetPrototype):
2223         (JSC::JSGlobalObject::visitChildren):
2224         (JSC::JSGlobalObject::toThis):
2225         (JSC::JSGlobalObject::getOwnPropertySlot):
2226         (JSC::JSGlobalObject::createThrowTypeError): Deleted.
2227         (JSC::JSGlobalObject::createThrowTypeErrorArgumentsAndCaller): Deleted.
2228         * runtime/JSGlobalObject.h:
2229         (JSC::JSGlobalObject::objectConstructor):
2230         (JSC::JSGlobalObject::promiseConstructor):
2231         (JSC::JSGlobalObject::internalPromiseConstructor):
2232         (JSC::JSGlobalObject::evalErrorConstructor):
2233         (JSC::JSGlobalObject::rangeErrorConstructor):
2234         (JSC::JSGlobalObject::referenceErrorConstructor):
2235         (JSC::JSGlobalObject::syntaxErrorConstructor):
2236         (JSC::JSGlobalObject::typeErrorConstructor):
2237         (JSC::JSGlobalObject::URIErrorConstructor):
2238         (JSC::JSGlobalObject::nullGetterFunction):
2239         (JSC::JSGlobalObject::nullSetterFunction):
2240         (JSC::JSGlobalObject::callFunction):
2241         (JSC::JSGlobalObject::applyFunction):
2242         (JSC::JSGlobalObject::definePropertyFunction):
2243         (JSC::JSGlobalObject::arrayProtoValuesFunction):
2244         (JSC::JSGlobalObject::initializePromiseFunction):
2245         (JSC::JSGlobalObject::newPromiseCapabilityFunction):
2246         (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
2247         (JSC::JSGlobalObject::regExpProtoExecFunction):
2248         (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
2249         (JSC::JSGlobalObject::regExpProtoGlobalGetter):
2250         (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
2251         (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
2252         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter):
2253         (JSC::JSGlobalObject::moduleLoader):
2254         (JSC::JSGlobalObject::objectPrototype):
2255         (JSC::JSGlobalObject::functionPrototype):
2256         (JSC::JSGlobalObject::arrayPrototype):
2257         (JSC::JSGlobalObject::booleanPrototype):
2258         (JSC::JSGlobalObject::stringPrototype):
2259         (JSC::JSGlobalObject::symbolPrototype):
2260         (JSC::JSGlobalObject::numberPrototype):
2261         (JSC::JSGlobalObject::datePrototype):
2262         (JSC::JSGlobalObject::regExpPrototype):
2263         (JSC::JSGlobalObject::errorPrototype):
2264         (JSC::JSGlobalObject::iteratorPrototype):
2265         (JSC::JSGlobalObject::generatorFunctionPrototype):
2266         (JSC::JSGlobalObject::generatorPrototype):
2267         (JSC::JSGlobalObject::debuggerScopeStructure):
2268         (JSC::JSGlobalObject::withScopeStructure):
2269         (JSC::JSGlobalObject::strictEvalActivationStructure):
2270         (JSC::JSGlobalObject::activationStructure):
2271         (JSC::JSGlobalObject::moduleEnvironmentStructure):
2272         (JSC::JSGlobalObject::directArgumentsStructure):
2273         (JSC::JSGlobalObject::scopedArgumentsStructure):
2274         (JSC::JSGlobalObject::clonedArgumentsStructure):
2275         (JSC::JSGlobalObject::isOriginalArrayStructure):
2276         (JSC::JSGlobalObject::booleanObjectStructure):
2277         (JSC::JSGlobalObject::callbackConstructorStructure):
2278         (JSC::JSGlobalObject::callbackFunctionStructure):
2279         (JSC::JSGlobalObject::callbackObjectStructure):
2280         (JSC::JSGlobalObject::propertyNameIteratorStructure):
2281         (JSC::JSGlobalObject::objcCallbackFunctionStructure):
2282         (JSC::JSGlobalObject::objcWrapperObjectStructure):
2283         (JSC::JSGlobalObject::dateStructure):
2284         (JSC::JSGlobalObject::nullPrototypeObjectStructure):
2285         (JSC::JSGlobalObject::errorStructure):
2286         (JSC::JSGlobalObject::calleeStructure):
2287         (JSC::JSGlobalObject::functionStructure):
2288         (JSC::JSGlobalObject::boundFunctionStructure):
2289         (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
2290         (JSC::JSGlobalObject::getterSetterStructure):
2291         (JSC::JSGlobalObject::nativeStdFunctionStructure):
2292         (JSC::JSGlobalObject::namedFunctionStructure):
2293         (JSC::JSGlobalObject::functionNameOffset):
2294         (JSC::JSGlobalObject::numberObjectStructure):
2295         (JSC::JSGlobalObject::privateNameStructure):
2296         (JSC::JSGlobalObject::mapStructure):
2297         (JSC::JSGlobalObject::regExpStructure):
2298         (JSC::JSGlobalObject::generatorFunctionStructure):
2299         (JSC::JSGlobalObject::setStructure):
2300         (JSC::JSGlobalObject::stringObjectStructure):
2301         (JSC::JSGlobalObject::symbolObjectStructure):
2302         (JSC::JSGlobalObject::iteratorResultObjectStructure):
2303         (JSC::JSGlobalObject::lazyTypedArrayStructure):
2304         (JSC::JSGlobalObject::typedArrayStructure):
2305         (JSC::JSGlobalObject::typedArrayStructureConcurrently):
2306         (JSC::JSGlobalObject::isOriginalTypedArrayStructure):
2307         (JSC::JSGlobalObject::typedArrayConstructor):
2308         (JSC::JSGlobalObject::actualPointerFor):
2309         (JSC::JSGlobalObject::internalFunctionStructure): Deleted.
2310         * runtime/JSNativeStdFunction.cpp:
2311         (JSC::JSNativeStdFunction::create):
2312         * runtime/JSWithScope.cpp:
2313         (JSC::JSWithScope::create):
2314         (JSC::JSWithScope::visitChildren):
2315         (JSC::JSWithScope::createStructure):
2316         (JSC::JSWithScope::JSWithScope):
2317         * runtime/JSWithScope.h:
2318         (JSC::JSWithScope::object):
2319         (JSC::JSWithScope::create): Deleted.
2320         (JSC::JSWithScope::createStructure): Deleted.
2321         (JSC::JSWithScope::JSWithScope): Deleted.
2322         * runtime/LazyClassStructure.cpp: Added.
2323         (JSC::LazyClassStructure::Initializer::Initializer):
2324         (JSC::LazyClassStructure::Initializer::setPrototype):
2325         (JSC::LazyClassStructure::Initializer::setStructure):
2326         (JSC::LazyClassStructure::Initializer::setConstructor):
2327         (JSC::LazyClassStructure::visit):
2328         (JSC::LazyClassStructure::dump):
2329         * runtime/LazyClassStructure.h: Added.
2330         (JSC::LazyClassStructure::LazyClassStructure):
2331         (JSC::LazyClassStructure::get):
2332         (JSC::LazyClassStructure::prototype):
2333         (JSC::LazyClassStructure::constructor):
2334         (JSC::LazyClassStructure::getConcurrently):
2335         (JSC::LazyClassStructure::prototypeConcurrently):
2336         (JSC::LazyClassStructure::constructorConcurrently):
2337         * runtime/LazyClassStructureInlines.h: Added.
2338         (JSC::LazyClassStructure::initLater):
2339         * runtime/LazyProperty.h: Added.
2340         (JSC::LazyProperty::Initializer::Initializer):
2341         (JSC::LazyProperty::LazyProperty):
2342         (JSC::LazyProperty::get):
2343         (JSC::LazyProperty::getConcurrently):
2344         * runtime/LazyPropertyInlines.h: Added.
2345         (JSC::ElementType>::Initializer::set):
2346         (JSC::ElementType>::initLater):
2347         (JSC::ElementType>::setMayBeNull):
2348         (JSC::ElementType>::set):
2349         (JSC::ElementType>::visit):
2350         (JSC::ElementType>::dump):
2351         (JSC::ElementType>::callFunc):
2352         * runtime/Lookup.cpp:
2353         (JSC::setUpStaticFunctionSlot):
2354         * runtime/Lookup.h:
2355         (JSC::HashTableValue::function):
2356         (JSC::HashTableValue::functionLength):
2357         (JSC::HashTableValue::propertyGetter):
2358         (JSC::HashTableValue::propertyPutter):
2359         (JSC::HashTableValue::accessorGetter):
2360         (JSC::HashTableValue::accessorSetter):
2361         (JSC::HashTableValue::constantInteger):
2362         (JSC::HashTableValue::lexerValue):
2363         (JSC::HashTableValue::lazyCellPropertyOffset):
2364         (JSC::HashTableValue::lazyClassStructureOffset):
2365         (JSC::HashTableValue::lazyPropertyCallback):
2366         (JSC::getStaticPropertySlot):
2367         (JSC::getStaticValueSlot):
2368         (JSC::putEntry):
2369         (JSC::reifyStaticProperty):
2370         * runtime/PropertySlot.h:
2371         * runtime/TypedArrayType.h:
2372
2373 2016-05-04  Joseph Pecoraro  <pecoraro@apple.com>
2374
2375         Improve the grammar of some error messages 'a argument list' => 'an argument list'
2376         https://bugs.webkit.org/show_bug.cgi?id=157350
2377         <rdar://problem/26082108>
2378
2379         Reviewed by Mark Lam.
2380
2381         * parser/Parser.cpp:
2382         (JSC::Parser<LexerType>::parseIfStatement):
2383         (JSC::Parser<LexerType>::parseImportDeclaration):
2384         (JSC::Parser<LexerType>::parseExportDeclaration):
2385         (JSC::Parser<LexerType>::parseObjectLiteral):
2386         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
2387         (JSC::Parser<LexerType>::parseArguments):
2388         Use the alternate error message formatter macro which outputs 'an'
2389         instead of 'a' preceding the last argument.
2390
2391 2016-05-04  Keith Miller  <keith_miller@apple.com>
2392
2393         Corrections to r200422
2394         https://bugs.webkit.org/show_bug.cgi?id=157351
2395
2396         Reviewed by Joseph Pecoraro.
2397
2398         Fix some typos in various files. Also, make separate error messages
2399         for the this value being undefined vs null in the ArrayIteratorprototype
2400         next function and add test.
2401
2402         * Scripts/builtins/builtins_model.py:
2403         * builtins/ArrayIteratorPrototype.js:
2404         (next):
2405         (arrayIteratorValueNext):
2406         (arrayIteratorKeyNext):
2407         (arrayIteratorKeyValueNext):
2408         * builtins/ArrayPrototype.js:
2409         (keys):
2410         (entries):
2411         * builtins/TypedArrayPrototype.js:
2412         * runtime/JSGlobalObject.cpp:
2413         (JSC::JSGlobalObject::init): Deleted.
2414         * tests/stress/array-iterators-next-error-messages.js: Added.
2415         (assert):
2416         (catch):
2417
2418 2016-05-04  Keith Miller  <keith_miller@apple.com>
2419
2420         Unreviewed, reland r200149 since the rollout had inconclusive PLT AB testing results.
2421
2422 2016-05-04  Mark Lam  <mark.lam@apple.com>
2423
2424         ES6 Function.name inferred from property names of literal objects can break some websites.
2425         https://bugs.webkit.org/show_bug.cgi?id=157246
2426
2427         Reviewed by Geoffrey Garen.
2428
2429         Specifically, the library mathjs (see http://mathjs.org and https://github.com/josdejong/mathjs)
2430         uses an idiom where it created literal objects with property names that look like
2431         this: 'number | BigNumber | Unit'.  Later, this name is used in a string to create
2432         function source code that gets eval'ed.  Since 'number | BigNumber | Unit' is not
2433         a valid function name, we get a syntax error.
2434
2435         Here are the details:
2436
2437         1. mathjs uses object literals with the funky property names for its function members.
2438            For example, 
2439
2440               // helper function to type check the middle value of the array
2441               var middle = typed({
2442                 'number | BigNumber | Unit': function (value) {
2443                   return value;
2444                 }
2445               });
2446
2447         2. mathjs' getName() uses Function.name to get the name of functions (hence, picks
2448            up the property name as inferred value of Function.name as specified by ES6):
2449
2450                 /**
2451                  * Retrieve the function name from a set of functions, and check
2452                  * whether the name of all functions match (if given)
2453                  ...
2454                  */
2455                 function getName (fns) {
2456                   var name = '';
2457
2458                   for (var i = 0; i < fns.length; i++) {
2459                     var fn = fns[i];
2460                     ...
2461                         name = fn.name;
2462                     ...
2463                   return name;
2464                 }
2465
2466         3. mathjs uses that name to assembler new function source code that gets eval'ed:
2467
2468                 /**
2469                  * Compose a function from sub-functions each handling a single type signature.
2470                  ...
2471                  */
2472                 function _typed(name, signatures) {
2473                   ...
2474                   // generate code for the typed function
2475                   var code = [];
2476                   var _name = name || '';
2477                   ...
2478                   code.push('function ' + _name + '(' + _args.join(', ') + ') {');
2479                   code.push('  "use strict";');
2480                   code.push('  var name = \'' + _name + '\';');
2481                   code.push(node.toCode(refs, '  '));
2482                   code.push('}');
2483
2484                   // generate body for the factory function
2485                   var body = [
2486                     refs.toCode(),
2487                     'return ' + code.join('\n')
2488                   ].join('\n');
2489
2490                   // evaluate the JavaScript code and attach function references
2491                   var factory = (new Function(refs.name, 'createError', body));  // <== Syntax Error here!
2492                   var fn = factory(refs, createError);
2493                   ...
2494                   return fn;
2495                 }
2496
2497         Until mathjs (and any other frameworks that does similar things) and sites that
2498         uses mathjs has been updated to work with ES6, we'll need a compatibility hack to
2499         work around it.
2500
2501         Here's what we'll do:
2502         1. Introduce a needsSiteSpecificQuirks flag in JSGlobalObject.
2503         2. Have WebCore's JSDOMWindowBase set that flag if the browser's
2504            needsSiteSpecificQuirks is enabled in its settings.
2505         3. If needsSiteSpecificQuirks is enabled, have JSFunction::reifyName() check for
2506            ' ' or '|' in the name string it will use to reify the Function.name property.
2507            If those characters exists in the name, we'll replace the name string with a
2508            null string.
2509
2510         * runtime/JSFunction.cpp:
2511         (JSC::JSFunction::reifyName):
2512         * runtime/JSGlobalObject.h:
2513         (JSC::JSGlobalObject::needsSiteSpecificQuirks):
2514         (JSC::JSGlobalObject::GlobalPropertyInfo::GlobalPropertyInfo):
2515         (JSC::JSGlobalObject::setNeedsSiteSpecificQuirks):
2516
2517 2016-05-04  Keith Miller  <keith_miller@apple.com>
2518
2519         Speedup array iterators
2520         https://bugs.webkit.org/show_bug.cgi?id=157315
2521
2522         Reviewed by Michael Saboff.
2523
2524         This patch improves the performance of Array iterators in ES6. There are two main changes
2525         that make things faster. The first is that the value, keys and entries functions have been
2526         moved to JS. This enables us to inline the construction of the iterator. Thus, when we get
2527         to the FTL we are able to sink the allocation of the iterator object. This significantly
2528         improves the performance of any for-of loop since we are now able to have both the iteration
2529         counter and the iterated object in local variables rather than in the heap.
2530
2531         Secondly, instead of using a number to store the iteratation kind we now use a virtual
2532         method on the iteration object to indicate which next function to use. This ends up being
2533         helpful because it means we can eliminate the branches in the old next function that decide
2534         what value to return. With those branches gone the various next functions are now small
2535         enough to inline. Once the next functions are inlined then the FTL is able to sink the
2536         allocation of next() result object. There is still room for optimization in the loop since
2537         we currently don't recognize that the array access in the next function is in bounds or that
2538         the increment to the loop counter cannot overflow.
2539
2540         The overall performance changes appear to be a ~4-6x speedup in a simple microbenchmark that
2541         computes the sum of an array with some extra arithmetic. The variance depends on the exact
2542         body of the loop. Additionally, on a new regress test that changes all the loops in
2543         deltablue into for-of loops this patch is a 1.8x progression. Overall, it still looks like
2544         for-of loops are significantly slower than an indexed for loop. In the first test it's ~2-4x
2545         slower with the difference depending on the body of the loop. If the loop is just the sum
2546         then we see a much larger regression than if the loop does even simple arithmetic. It looks
2547         like the indexed for loop without extra arithmetic is small enough to fit into the x86
2548         replay buffer on my machine, which would explain why there is such a big difference between
2549         the for of loop in that case. On the deltablue benchmark it's 1.4x slower. It's clear from
2550         these numbers that there is still a lot of work we can do to make for of loops faster.
2551
2552         This patch also makes some changes to the way that we decorate our builtin js
2553         functions. Instead of the old syntax (putting the decorated values in [] before the function
2554         declaration i.e. [intrinsic=foo]) this patch changes the syntax to be closer to the way that
2555         decorators are proposed in a future ECMAScript proposal (using @ followed by the entry on a
2556         new line before the function declaration i.e. @intrinsic=foo).
2557
2558         Finally, in the builtin scripts regular expressions re.S has been changed to re.DOTALL since
2559         DOTALL is easier to understand without going to the reference page for python regular
2560         expressions.
2561
2562         * Scripts/builtins/builtins_model.py:
2563         * builtins/ArrayIteratorPrototype.js:
2564         (next):
2565         (arrayIteratorValueNext):
2566         (arrayIteratorKeyNext):
2567         (arrayIteratorKeyValueNext):
2568         * builtins/ArrayPrototype.js:
2569         (createArrayIterator):
2570         (values):
2571         (keys):
2572         (entries):
2573         * builtins/RegExpPrototype.js:
2574         (intrinsic.RegExpTestIntrinsic.test):
2575         * builtins/StringPrototype.js:
2576         (intrinsic.StringPrototypeReplaceIntrinsic.replace):
2577         * builtins/TypedArrayPrototype.js:
2578         (values):
2579         (keys):
2580         (entries):
2581         * inspector/JSInjectedScriptHost.cpp:
2582         (Inspector::cloneArrayIteratorObject):
2583         (Inspector::JSInjectedScriptHost::iteratorEntries):
2584         * jit/ThunkGenerators.cpp:
2585         * runtime/ArrayPrototype.cpp:
2586         (JSC::ArrayPrototype::finishCreation):
2587         (JSC::arrayProtoFuncValues): Deleted.
2588         (JSC::arrayProtoFuncEntries): Deleted.
2589         (JSC::arrayProtoFuncKeys): Deleted.
2590         * runtime/CommonIdentifiers.h:
2591         * runtime/JSArrayIterator.cpp:
2592         (JSC::JSArrayIterator::clone): Deleted.
2593         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
2594         (JSC::genericTypedArrayViewProtoFuncEntries): Deleted.
2595         (JSC::genericTypedArrayViewProtoFuncKeys): Deleted.
2596         (JSC::typedArrayViewProtoFuncValues): Deleted.
2597         * runtime/JSGlobalObject.cpp:
2598         (JSC::JSGlobalObject::init):
2599         * runtime/JSGlobalObject.h:
2600         * runtime/JSTypedArrayViewPrototype.cpp:
2601         (JSC::JSTypedArrayViewPrototype::finishCreation):
2602         (JSC::typedArrayViewProtoFuncEntries): Deleted.
2603         (JSC::typedArrayViewProtoFuncKeys): Deleted.
2604         (JSC::typedArrayViewProtoFuncValues): Deleted.
2605         * runtime/MapPrototype.cpp:
2606         (JSC::MapPrototype::finishCreation):
2607         * runtime/SetPrototype.cpp:
2608         (JSC::SetPrototype::finishCreation):
2609
2610 2016-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>
2611
2612         [JSC] Object constructor need to be aware of new.target
2613         https://bugs.webkit.org/show_bug.cgi?id=157196
2614
2615         Reviewed by Darin Adler.
2616
2617         Object constructor should be aware of new.target.
2618         When the new.target is specified, we should store it.prototype to the newly created
2619         object's [[Prototype]].
2620
2621         * runtime/JSGlobalObject.cpp:
2622         (JSC::JSGlobalObject::init):
2623         (JSC::JSGlobalObject::visitChildren):
2624         Take the design that caches the structure used for empty object.
2625         This structure is also used in constructEmptyObject frequently.
2626
2627         * runtime/JSGlobalObject.h:
2628         (JSC::JSGlobalObject::objectStructureForObjectConstructor):
2629         * runtime/ObjectConstructor.cpp:
2630         (JSC::constructObject):
2631         (JSC::constructWithObjectConstructor):
2632         (JSC::callObjectConstructor):
2633         * runtime/ObjectConstructor.h:
2634         (JSC::constructEmptyObject):
2635         Construct the object by using the plain structure that is also used in the ObjectConstructor.
2636
2637         * tests/stress/object-constructor-should-be-new-target-aware.js: Added.
2638         (shouldBe):
2639         (Hello):
2640
2641 2016-05-04  Chris Dumez  <cdumez@apple.com>
2642
2643         Unreviewed, rolling out r200383 and r200406.
2644
2645         Seems to have caused crashes on iOS / ARMv7s
2646
2647         Reverted changesets:
2648
2649         "Speed up JSGlobalObject initialization by making some
2650         properties lazy"
2651         https://bugs.webkit.org/show_bug.cgi?id=157045
2652         http://trac.webkit.org/changeset/200383
2653
2654         "REGRESSION(r200383): Setting lazily initialized properties
2655         across frame boundaries crashes"
2656         https://bugs.webkit.org/show_bug.cgi?id=157333
2657         http://trac.webkit.org/changeset/200406
2658
2659 2016-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>
2660
2661         Assertion failure for super() call in direct eval in method function
2662         https://bugs.webkit.org/show_bug.cgi?id=157091
2663
2664         Reviewed by Darin Adler.
2665
2666         While we ensure that direct super is under the correct context,
2667         we don't check it for the eval code. This patch moves the check from the end of parsing the function
2668         to the places where we found the direct super or the super bindings. This covers the direct eval that
2669         contains the direct super calls.
2670
2671         * parser/Parser.cpp:
2672         (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
2673         (JSC::Parser<LexerType>::parseFunctionInfo):
2674         (JSC::Parser<LexerType>::parseMemberExpression):
2675         * parser/Parser.h:
2676         (JSC::Scope::hasDirectSuper):
2677         (JSC::Scope::setHasDirectSuper):
2678         (JSC::Scope::needsSuperBinding):
2679         (JSC::Scope::setNeedsSuperBinding):
2680         (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
2681         * tests/stress/eval-and-super.js: Added.
2682         (shouldBe):
2683         (shouldThrow):
2684         (prototype.m):
2685         (prototype.n):
2686         * tests/stress/generator-and-super.js: Added.
2687         (testSyntaxError):
2688         (testSyntaxError.Base.prototype.hello):
2689         (testSyntaxError.Base.prototype.ok):
2690         (testSyntaxError.Base):
2691         (Hello.prototype.gen):
2692         (Hello):
2693         (testSyntaxError.hello):
2694
2695 2016-05-03  Filip Pizlo  <fpizlo@apple.com>
2696
2697         REGRESSION(r200383): Setting lazily initialized properties across frame boundaries crashes
2698         https://bugs.webkit.org/show_bug.cgi?id=157333
2699
2700         Reviewed by Benjamin Poulain.
2701         
2702         I forgot to add logic for lazy properties in putEntry(). It turns out that it's easy to
2703         add.
2704
2705         * runtime/Lookup.h:
2706         (JSC::putEntry):
2707         * runtime/PropertySlot.h:
2708
2709 2016-05-03  Filip Pizlo  <fpizlo@apple.com>
2710
2711         References from code to Structures should be stronger than weak
2712         https://bugs.webkit.org/show_bug.cgi?id=157324
2713
2714         Reviewed by Mark Lam.
2715         
2716         If code refers to a Structure and the Structure dies, then previously we'd kill the code. 
2717         This makes sense because the Structure could be the only thing left referring to some global
2718         object or prototype.
2719
2720         But this also causes unnecessary churn. Sometimes there will be a structure that we just
2721         haven't really done anything with recently and so it appears dead. The approach we use
2722         elsewhere in our type inference is that the type that the code uses is general enough to
2723         handle every past execution. Having the GC clear code when some Structure it uses dies means
2724         that we forget that the code used that Structure. We'll either assume that the code is more
2725         monomorphic than it really is (because after GC we patch in some other structure but not the
2726         deleted one, so it looks like we only ever saw the new structure), or we'll assume that it's
2727         crazier than it really is (because we'll remember that there had been some structure that
2728         caused deletion, so we'll assume that deletions might happen in the future, so we'll use a
2729         fully dynamic IC).
2730
2731         This change introduces a more nuanced policy: if it's cheap to mark a dead Structure then we
2732         should mark it just so that all of the code that refers to it remembers that there had been
2733         this exact Structure in the past. If the code often goes through different Structures then
2734         we already have great mechanisms to realize that the code is nutty (namely, the
2735         PolymorphicAccess size limit). But if the code just does this a handful of times then
2736         remembering this old Structure is probably net good:
2737
2738         - It obeys the "handle all past executions" law.
2739         - It preserves the history of the property access, allowing a precise measure of its past
2740           polymorphism.
2741         - It makes the code ready to run fast if the user decides to use that Structure again.
2742           Marking the Structure means it will stay in whatever property transition tables it was in,
2743           so if the program does the same thing it did in the past, it will get this old Structure.
2744
2745         It looks like this is a progression in gbemu and it makes gbemu perform more
2746         deterministically. Also, it seems that this makes JetStream run faster.
2747         
2748         Over five in-browser runs of JetStream, here's what we see before and after:
2749         
2750         Geometric Mean:
2751             Before              After
2752             229.23 +- 8.2523    230.70 +- 12.888
2753             232.91 +- 15.638    239.04 +- 13.766
2754             234.79 +- 12.760    236.32 +- 15.562
2755             236.20 +- 23.125    242.02 +- 3.3865
2756             237.22 +- 2.1929    237.23 +- 17.664
2757         
2758         Just gbemu:
2759             Before              After
2760             541.0 +- 135.8      481.7 +- 143.4
2761             518.9 +- 15.65      508.1 +- 136.3
2762             362.5 +- 0.8884     489.7 +- 101.4
2763             470.7 +- 313.3      530.7 +- 11.49
2764             418.7 +- 180.6      537.2 +- 6.514
2765         
2766         Notice that there is plenty of noise before and after, but the noise is now far less severe.
2767         After this change I did not see any runs like "470.7 +- 313.3" where the size of the 
2768         confidence interval (313.3 * 2) is greater than the score (470.7). Also, notice that the
2769         least noisy run before the change also got a lower score than we ever observed after the
2770         change (36.5 +- 0.8884). The noise, and these occasional very low scores, are due to a
2771         pathology where the GC would reset some stubs at an unfortunate time during profiling,
2772         causing the optimizing compiler to make many poor decisions. That pathology doesn't exist
2773         anymore.
2774         
2775         On the other hand, prior to this change it was possible for gbemu to sometimes run sooooper
2776         fast because the GC would cause the profiler to forget gbemu's behavior on the first tick
2777         and focus only on its behavior in subsequent ticks. So, in steady state, we'd optimize gbemu
2778         for its later behavior rather than a combination of its early behavior and later behavior.
2779         We rarely got lucky this way, so it's not fair to view this quirk as a feature.
2780         
2781         * bytecode/CodeBlock.cpp:
2782         (JSC::CodeBlock::propagateTransitions):
2783         * bytecode/PolymorphicAccess.cpp:
2784         (JSC::AccessCase::visitWeak):
2785         (JSC::AccessCase::propagateTransitions):
2786         (JSC::AccessCase::generateWithGuard):
2787         (JSC::PolymorphicAccess::visitWeak):
2788         (JSC::PolymorphicAccess::propagateTransitions):
2789         (JSC::PolymorphicAccess::dump):
2790         * bytecode/PolymorphicAccess.h:
2791         * bytecode/StructureStubInfo.cpp:
2792         (JSC::StructureStubInfo::visitWeakReferences):
2793         (JSC::StructureStubInfo::propagateTransitions):
2794         (JSC::StructureStubInfo::containsPC):
2795         * bytecode/StructureStubInfo.h:
2796         (JSC::StructureStubInfo::considerCaching):
2797         * runtime/Structure.cpp:
2798         (JSC::Structure::visitChildren):
2799         (JSC::Structure::isCheapDuringGC):
2800         (JSC::Structure::markIfCheap):
2801         (JSC::Structure::prototypeChainMayInterceptStoreTo):
2802         * runtime/Structure.h:
2803
2804 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
2805
2806         Web Inspector: Simplify console.clear
2807         https://bugs.webkit.org/show_bug.cgi?id=157316
2808
2809         Reviewed by Timothy Hatcher.
2810
2811         * inspector/ScriptArguments.cpp:
2812         (Inspector::ScriptArguments::createEmpty):
2813         (Inspector::ScriptArguments::ScriptArguments):
2814         * inspector/ScriptArguments.h:
2815         Provide a way to create an empty list.
2816
2817         * runtime/ConsoleClient.cpp:
2818         (JSC::ConsoleClient::clear):
2819         * runtime/ConsoleClient.h:
2820         Drop unnecessary parameter.
2821
2822         * runtime/ConsoleObject.cpp:
2823         (JSC::consoleProtoFuncClear):
2824         No need to parse arguments.
2825
2826 2016-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>
2827
2828         Improve Symbol() to string coercion error message
2829         https://bugs.webkit.org/show_bug.cgi?id=157317
2830
2831         Reviewed by Geoffrey Garen.
2832
2833         Improve error messages related to Symbols.
2834
2835         * runtime/JSCJSValue.cpp:
2836         (JSC::JSValue::toStringSlowCase):
2837         * runtime/Symbol.cpp:
2838         (JSC::Symbol::toNumber):
2839         * runtime/SymbolConstructor.cpp:
2840         (JSC::symbolConstructorKeyFor):
2841         * runtime/SymbolPrototype.cpp:
2842         (JSC::symbolProtoFuncToString):
2843         (JSC::symbolProtoFuncValueOf):
2844         * tests/stress/dfg-to-primitive-pass-symbol.js:
2845         * tests/stress/floating-point-div-to-mul.js:
2846         (i.catch):
2847         * tests/stress/string-from-code-point.js:
2848         (shouldThrow):
2849         (string_appeared_here.shouldThrow):
2850         * tests/stress/symbol-error-messages.js: Added.
2851         (shouldThrow):
2852         * tests/stress/symbol-registry.js:
2853
2854 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
2855
2856         Web Inspector: Give console.time/timeEnd a default label and warnings
2857         https://bugs.webkit.org/show_bug.cgi?id=157325
2858         <rdar://problem/26073290>
2859
2860         Reviewed by Timothy Hatcher.
2861
2862         Provide more user friendly console.time/timeEnd. The timer name
2863         is now optional, and is "default" if not provided. Also provide
2864         warnings when attempting to start an already started timer,
2865         or stop a timer that does not exist.
2866
2867         * inspector/agents/InspectorConsoleAgent.cpp:
2868         (Inspector::InspectorConsoleAgent::startTiming):
2869         (Inspector::InspectorConsoleAgent::stopTiming):
2870         Warnings for bad cases.
2871
2872         * runtime/ConsoleObject.cpp:
2873         (JSC::defaultLabelString):
2874         (JSC::consoleProtoFuncTime):
2875         (JSC::consoleProtoFuncTimeEnd):
2876         Optional label becomes "default".
2877
2878 2016-05-03  Xan Lopez  <xlopez@igalia.com>
2879
2880         Fix the ENABLE(WEBASSEMBLY) build
2881         https://bugs.webkit.org/show_bug.cgi?id=157312
2882
2883         Reviewed by Darin Adler.
2884
2885         * runtime/Executable.cpp:
2886         (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
2887         * wasm/WASMFunctionCompiler.h:
2888         (JSC::WASMFunctionCompiler::convertValueToDouble):
2889
2890 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
2891
2892         Web Inspector: Remove unused parameter of ScriptArguments::getFirstArgumentAsString
2893         https://bugs.webkit.org/show_bug.cgi?id=157301
2894
2895         Reviewed by Timothy Hatcher.
2896
2897         * inspector/ScriptArguments.cpp:
2898         (Inspector::ScriptArguments::getFirstArgumentAsString):
2899         * inspector/ScriptArguments.h:
2900         Remove unused argument and related code.
2901
2902         * runtime/ConsoleClient.cpp:
2903         (JSC::ConsoleClient::printConsoleMessageWithArguments):
2904         Drive by remove unnecessary cast.
2905
2906 2016-05-03  Michael Saboff  <msaboff@apple.com>
2907
2908         Crash: Array.prototype.slice() and .splice() can call fastSlice() after an array is truncated
2909         https://bugs.webkit.org/show_bug.cgi?id=157322
2910
2911         Reviewed by Filip Pizlo.
2912
2913         Check to see if the source array has changed length before calling fastSlice().
2914         If it has, take the slow path.
2915
2916         * runtime/ArrayPrototype.cpp:
2917         (JSC::arrayProtoFuncSlice):
2918         (JSC::arrayProtoFuncSplice):
2919         * tests/stress/regress-157322.js: New test.
2920
2921 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
2922
2923         Eliminate PassRefPtr conversion from ConsoleObject
2924         https://bugs.webkit.org/show_bug.cgi?id=157300
2925
2926         Reviewed by Timothy Hatcher.
2927
2928         * runtime/ConsoleObject.cpp:
2929         (JSC::consoleLogWithLevel):
2930         (JSC::consoleProtoFuncClear):
2931         (JSC::consoleProtoFuncDir):
2932         (JSC::consoleProtoFuncDirXML):
2933         (JSC::consoleProtoFuncTable):
2934         (JSC::consoleProtoFuncTrace):
2935         (JSC::consoleProtoFuncAssert):
2936         (JSC::consoleProtoFuncCount):
2937         (JSC::consoleProtoFuncTimeStamp):
2938         (JSC::consoleProtoFuncGroup):
2939         (JSC::consoleProtoFuncGroupCollapsed):
2940         (JSC::consoleProtoFuncGroupEnd):
2941         No need to release to a PassRefPtr, we can just move into the RefPtr<>&&.
2942
2943 2016-05-01  Filip Pizlo  <fpizlo@apple.com>
2944
2945         Speed up JSGlobalObject initialization by making some properties lazy
2946         https://bugs.webkit.org/show_bug.cgi?id=157045
2947
2948         Reviewed by Keith Miller.
2949         
2950         This makes about half of JSGlobalObject's state lazy. There are three categories of
2951         state in JSGlobalObject:
2952         
2953         1) C++ fields in JSGlobalObject.
2954         2) JS object properties in JSGlobalObject's JSObject superclass.
2955         3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass.
2956         
2957         State held in JS variables cannot yet be made lazy. That's why this patch only goes
2958         half-way.
2959         
2960         State in JS object properties can be made lazy if we move it to the static property
2961         hashtable. JSGlobalObject already had one of those. This patch makes static property
2962         hashtables a lot more powerful, by adding three new kinds of static properties. These
2963         new kinds allow us to make almost all of JSGlobalObject's object properties lazy.
2964         
2965         State in C++ fields can now be made lazy thanks in part to WTF's support for stateless
2966         lambdas. You can of course make anything lazy by hand, but there are many C++ fields in
2967         JSGlobalObject and we are adding more all the time. We don't want to require that each
2968         of these has a getter with an initialization check and a corresponding out-of-line slow
2969         path that does the initialization. We want this kind of boilerplate to be handled by
2970         some abstractions.
2971         
2972         The primary abstraction introduced in this patch is LazyProperty<Type>. Currently, this
2973         only works where Type is a subclass of JSCell. Such a property holds a pointer to Type.
2974         You can use it like you would a WriteBarrier<Type>. It even has set() and get() methods,
2975         so it's almost a drop-in replacement.
2976         
2977         The key to LazyProperty<Type>'s power is that you can do this:
2978         
2979             class Bar {
2980                 ...
2981                 LazyProperty<Foo> m_foo;
2982             };
2983             ...
2984             m_foo.initLater(
2985                 [] (const LazyProperty<Foo>::Initializer<Bar>& init) {
2986                     init.set(Foo::create(init.vm, init.owner));
2987                 });
2988         
2989         This initLater() call requires that you pass a stateless lambda (see WTF changelog for
2990         the definition). Miraculously, this initLater() call is guaranteed to compile to a store
2991         of a pointer constant to m_foo, as in:
2992         
2993             movabsq 0xBLAH, %rax
2994             movq %rax, &m_foo
2995         
2996         This magical pointer constant points to a callback that was generated by the template
2997         instantiation of initLater(). That callback knows to call your stateless lambda, but
2998         also does some other bookkeeping: it makes sure that you indeed initialized the property
2999         inside the callback and it manages recursive initializations. It's totally legal to call
3000         m_foo.get() inside the initLater() callback. If you do that before you call init.set(),
3001         m_foo.get() will return null. This is an excellent escape hatch if we ever find
3002         ourselves in a dependency cycle. I added this feature because I already had to create a
3003         dependency cycle.
3004         
3005         Note that using LazyProperties from DFG threads is super awkward. It's going to be hard
3006         to get this right. The DFG thread cannot initialize those fields, so it has to make sure
3007         that it does conservative things. But for some nodes this could mean adding a lot of new
3008         logic, like NewTypedArray, which currently is written in such a way that it assumes that
3009         we always have the typed array structure. Currently we take a two-fold approach: for
3010         typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't
3011         initialized, and for everything else we don't make the properties lazy if the DFG needs
3012         them. As we optimize this further we might need to teach the DFG to handle more lazy
3013         properties. I tried to do this for RegExp but found it to be very confusing. With typed
3014         arrays I got lucky.
3015         
3016         There is also a somewhat more powerful construct called LazyClassStructure. We often
3017         need to keep around the structure of some standard JS class, like Date. We also need to
3018         make sure that the constructor ends up in the global object's property table. And we
3019         often need to keep the original value of the constructor for ourselves. In this case, we
3020         want to make sure that the creation of the structure-prototype-constructor constellation
3021         is atomic. We don't want code to start looking at the structure if it points to a
3022         prototype that doesn't have its "constructor" property set yet, for example.
3023         LazyClassStructure solves this by abstracting that whole initialization. You provide the
3024         callback that allocates everything, since we are super inconsistent about the way we
3025         initialize things, but LazyClassStructure establishes the workflow and helps you not
3026         mess up.
3027         
3028         Finally, the new static hashtable attributes allow for all of this to work with the JS
3029         property table:
3030         
3031         PropertyCallback: if you use this attribute, the second column in the table should be
3032         the name of a function to call to initialize this property. This is useful for things
3033         like the Math property. The Math object turns out to be very expensive to allocate.
3034         Delaying its allocation is super easy with the PropertyCallback attribute.
3035         
3036         CellProperty: with this attribute the second column should be a C++ field name like
3037         JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of
3038         this property, and when it needs to be initialized, Lookup will assume you have a
3039         LazyProperty<JSCell> and call its get() method. It will initialize the property to
3040         whatever get() returned. Note that it's legal to cast a LazyProperty<Anything> to
3041         LazyProperty<JSCell> for the purpose of calling get() because the get() method will just
3042         call whatever callback function pointer is encoded in the property and it does not need
3043         to know anything about what type that callback will instantiate.
3044         
3045         ClassStructure: with this attribute the second column should be a C++ field name. The
3046         static hashtable will initialize the property by treating the field as a
3047         LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole
3048         initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns,
3049         the property in question will already be set. By convention, we have LazyClassStructure
3050         initialize the property with a pointer to the constructor, since that's how all of our
3051         classes work: "globalObject.Date" points to the DateConstructor.
3052         
3053         This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that
3054         calls our C API. This is a 1% speed-up on SunSpider and JSRegress.
3055
3056         * API/JSCallbackFunction.cpp:
3057         (JSC::JSCallbackFunction::create):
3058         * API/ObjCCallbackFunction.h:
3059         (JSC::ObjCCallbackFunction::impl):
3060         * API/ObjCCallbackFunction.mm:
3061         (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
3062         (JSC::ObjCCallbackFunction::create):
3063         * CMakeLists.txt:
3064         * JavaScriptCore.xcodeproj/project.pbxproj:
3065         * create_hash_table:
3066         * dfg/DFGAbstractInterpreterInlines.h:
3067         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3068         * dfg/DFGAbstractValue.cpp:
3069         (JSC::DFG::AbstractValue::set):
3070         * dfg/DFGArrayMode.cpp:
3071         (JSC::DFG::ArrayMode::originalArrayStructure):
3072         * dfg/DFGByteCodeParser.cpp:
3073         (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
3074         * dfg/DFGSpeculativeJIT.cpp:
3075         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
3076         * dfg/DFGSpeculativeJIT32_64.cpp:
3077         (JSC::DFG::SpeculativeJIT::compile):
3078         * dfg/DFGSpeculativeJIT64.cpp:
3079         (JSC::DFG::SpeculativeJIT::compile):
3080         * dfg/DFGStructureRegistrationPhase.cpp:
3081         (JSC::DFG::StructureRegistrationPhase::run):
3082         * ftl/FTLLowerDFGToB3.cpp:
3083         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
3084         * runtime/ClonedArguments.cpp:
3085         (JSC::ClonedArguments::getOwnPropertySlot):
3086         (JSC::ClonedArguments::materializeSpecials):
3087         * runtime/CommonSlowPaths.cpp:
3088         (JSC::SLOW_PATH_DECL):
3089         * runtime/FunctionPrototype.cpp:
3090         (JSC::functionProtoFuncToString):
3091         * runtime/InternalFunction.cpp:
3092         (JSC::InternalFunction::visitChildren):
3093         (JSC::InternalFunction::name):
3094         (JSC::InternalFunction::calculatedDisplayName):
3095         (JSC::InternalFunction::createSubclassStructure):
3096         * runtime/InternalFunction.h:
3097         * runtime/JSBoundFunction.cpp:
3098         (JSC::JSBoundFunction::finishCreation):
3099         (JSC::JSBoundFunction::visitChildren):
3100         * runtime/JSFunction.cpp:
3101         (JSC::JSFunction::getOwnPropertySlot):
3102         (JSC::JSFunction::defineOwnProperty):
3103         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
3104         (JSC::constructGenericTypedArrayView):
3105         * runtime/JSGlobalObject.cpp:
3106         (JSC::createProxyProperty):
3107         (JSC::createJSONProperty):
3108         (JSC::createMathProperty):
3109         (JSC::JSGlobalObject::init):
3110         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
3111         (JSC::JSGlobalObject::resetPrototype):
3112         (JSC::JSGlobalObject::visitChildren):
3113         (JSC::JSGlobalObject::toThis):
3114         (JSC::JSGlobalObject::getOwnPropertySlot):
3115         (JSC::JSGlobalObject::createThrowTypeError): Deleted.
3116         * runtime/JSGlobalObject.h:
3117         (JSC::JSGlobalObject::objectConstructor):
3118         (JSC::JSGlobalObject::promiseConstructor):
3119         (JSC::JSGlobalObject::internalPromiseConstructor):
3120         (JSC::JSGlobalObject::evalErrorConstructor):
3121         (JSC::JSGlobalObject::rangeErrorConstructor):
3122         (JSC::JSGlobalObject::referenceErrorConstructor):
3123         (JSC::JSGlobalObject::syntaxErrorConstructor):
3124         (JSC::JSGlobalObject::typeErrorConstructor):
3125         (JSC::JSGlobalObject::URIErrorConstructor):
3126         (JSC::JSGlobalObject::nullGetterFunction):
3127         (JSC::JSGlobalObject::nullSetterFunction):
3128         (JSC::JSGlobalObject::callFunction):
3129         (JSC::JSGlobalObject::applyFunction):
3130         (JSC::JSGlobalObject::definePropertyFunction):
3131         (JSC::JSGlobalObject::arrayProtoValuesFunction):
3132         (JSC::JSGlobalObject::initializePromiseFunction):
3133         (JSC::JSGlobalObject::newPromiseCapabilityFunction):
3134         (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
3135         (JSC::JSGlobalObject::regExpProtoExecFunction):
3136         (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
3137         (JSC::JSGlobalObject::regExpProtoGlobalGetter):
3138         (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
3139         (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
3140         (JSC::JSGlobalObject::moduleLoader):
3141         (JSC::JSGlobalObject::objectPrototype):
3142         (JSC::JSGlobalObject::functionPrototype):
3143         (JSC::JSGlobalObject::arrayPrototype):
3144         (JSC::JSGlobalObject::booleanPrototype):
3145         (JSC::JSGlobalObject::stringPrototype):
3146         (JSC::JSGlobalObject::symbolPrototype):
3147         (JSC::JSGlobalObject::numberPrototype):
3148         (JSC::JSGlobalObject::datePrototype):
3149         (JSC::JSGlobalObject::regExpPrototype):
3150         (JSC::JSGlobalObject::errorPrototype):
3151         (JSC::JSGlobalObject::iteratorPrototype):
3152         (JSC::JSGlobalObject::generatorFunctionPrototype):
3153         (JSC::JSGlobalObject::generatorPrototype):
3154         (JSC::JSGlobalObject::debuggerScopeStructure):
3155         (JSC::JSGlobalObject::withScopeStructure):
3156         (JSC::JSGlobalObject::strictEvalActivationStructure):
3157         (JSC::JSGlobalObject::activationStructure):
3158         (JSC::JSGlobalObject::moduleEnvironmentStructure):
3159         (JSC::JSGlobalObject::directArgumentsStructure):
3160         (JSC::JSGlobalObject::scopedArgumentsStructure):
3161         (JSC::JSGlobalObject::clonedArgumentsStructure):
3162         (JSC::JSGlobalObject::isOriginalArrayStructure):
3163         (JSC::JSGlobalObject::booleanObjectStructure):
3164         (JSC::JSGlobalObject::callbackConstructorStructure):
3165         (JSC::JSGlobalObject::callbackFunctionStructure):
3166         (JSC::JSGlobalObject::callbackObjectStructure):
3167         (JSC::JSGlobalObject::propertyNameIteratorStructure):
3168         (JSC::JSGlobalObject::objcCallbackFunctionStructure):
3169         (JSC::JSGlobalObject::objcWrapperObjectStructure):
3170         (JSC::JSGlobalObject::dateStructure):
3171         (JSC::JSGlobalObject::nullPrototypeObjectStructure):
3172         (JSC::JSGlobalObject::errorStructure):
3173         (JSC::JSGlobalObject::calleeStructure):
3174         (JSC::JSGlobalObject::functionStructure):
3175         (JSC::JSGlobalObject::boundFunctionStructure):
3176         (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
3177         (JSC::JSGlobalObject::getterSetterStructure):
3178         (JSC::JSGlobalObject::nativeStdFunctionStructure):
3179         (JSC::JSGlobalObject::namedFunctionStructure):
3180         (JSC::JSGlobalObject::functionNameOffset):
3181         (JSC::JSGlobalObject::numberObjectStructure):
3182         (JSC::JSGlobalObject::privateNameStructure):
3183         (JSC::JSGlobalObject::mapStructure):
3184         (JSC::JSGlobalObject::regExpStructure):
3185         (JSC::JSGlobalObject::generatorFunctionStructure):
3186         (JSC::JSGlobalObject::setStructure):
3187         (JSC::JSGlobalObject::stringObjectStructure):
3188         (JSC::JSGlobalObject::symbolObjectStructure):
3189         (JSC::JSGlobalObject::iteratorResultObjectStructure):
3190         (JSC::JSGlobalObject::lazyTypedArrayStructure):
3191         (JSC::JSGlobalObject::typedArrayStructure):
3192         (JSC::JSGlobalObject::typedArrayStructureConcurrently):
3193         (JSC::JSGlobalObject::isOriginalTypedArrayStructure):
3194         (JSC::JSGlobalObject::typedArrayConstructor):
3195         (JSC::JSGlobalObject::actualPointerFor):
3196         (JSC::JSGlobalObject::internalFunctionStructure): Deleted.
3197         * runtime/JSNativeStdFunction.cpp:
3198         (JSC::JSNativeStdFunction::create):
3199         * runtime/JSWithScope.cpp:
3200         (JSC::JSWithScope::create):
3201         (JSC::JSWithScope::visitChildren):
3202         (JSC::JSWithScope::createStructure):
3203         (JSC::JSWithScope::JSWithScope):
3204         * runtime/JSWithScope.h:
3205         (JSC::JSWithScope::object):
3206         (JSC::JSWithScope::create): Deleted.
3207         (JSC::JSWithScope::createStructure): Deleted.
3208         (JSC::JSWithScope::JSWithScope): Deleted.
3209         * runtime/LazyClassStructure.cpp: Added.
3210         (JSC::LazyClassStructure::Initializer::Initializer):
3211         (JSC::LazyClassStructure::Initializer::setPrototype):
3212         (JSC::LazyClassStructure::Initializer::setStructure):
3213         (JSC::LazyClassStructure::Initializer::setConstructor):
3214         (JSC::LazyClassStructure::visit):
3215         (JSC::LazyClassStructure::dump):
3216         * runtime/LazyClassStructure.h: Added.
3217         (JSC::LazyClassStructure::LazyClassStructure):
3218         (JSC::LazyClassStructure::get):
3219         (JSC::LazyClassStructure::prototype):
3220         (JSC::LazyClassStructure::constructor):
3221         (JSC::LazyClassStructure::getConcurrently):
3222         (JSC::LazyClassStructure::prototypeConcurrently):
3223         (JSC::LazyClassStructure::constructorConcurrently):
3224         * runtime/LazyClassStructureInlines.h: Added.
3225         (JSC::LazyClassStructure::initLater):
3226         * runtime/LazyProperty.h: Added.
3227         (JSC::LazyProperty::Initializer::Initializer):
3228         (JSC::LazyProperty::LazyProperty):
3229         (JSC::LazyProperty::get):
3230         (JSC::LazyProperty::getConcurrently):
3231         * runtime/LazyPropertyInlines.h: Added.
3232         (JSC::LazyProperty<ElementType>::Initializer<OwnerType>::set):
3233         (JSC::LazyProperty<ElementType>::initLater):
3234         (JSC::LazyProperty<ElementType>::setMayBeNull):
3235         (JSC::LazyProperty<ElementType>::set):
3236         (JSC::LazyProperty<ElementType>::visit):
3237         (JSC::LazyProperty<ElementType>::dump):
3238         (JSC::LazyProperty<ElementType>::callFunc):
3239         * runtime/Lookup.cpp:
3240         (JSC::setUpStaticFunctionSlot):
3241         * runtime/Lookup.h:
3242         (JSC::HashTableValue::function):
3243         (JSC::HashTableValue::functionLength):
3244         (JSC::HashTableValue::propertyGetter):
3245         (JSC::HashTableValue::propertyPutter):
3246         (JSC::HashTableValue::accessorGetter):
3247         (JSC::HashTableValue::accessorSetter):
3248         (JSC::HashTableValue::constantInteger):
3249         (JSC::HashTableValue::lexerValue):
3250         (JSC::HashTableValue::lazyCellPropertyOffset):
3251         (JSC::HashTableValue::lazyClassStructureOffset):
3252         (JSC::HashTableValue::lazyPropertyCallback):
3253         (JSC::getStaticPropertySlot):
3254         (JSC::getStaticValueSlot):
3255         (JSC::reifyStaticProperty):
3256         * runtime/PropertySlot.h:
3257         * runtime/TypedArrayType.h:
3258
3259 2016-05-03  Per Arne Vollan  <peavo@outlook.com>
3260
3261         [Win] Remove Windows XP Compatibility Requirements
3262         https://bugs.webkit.org/show_bug.cgi?id=152899
3263
3264         Reviewed by Brent Fulgham.
3265
3266         Windows XP is not supported anymore, we can remove workarounds.
3267
3268         * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp:
3269         (enableTerminationOnHeapCorruption):
3270
3271 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
3272
3273         Web Inspector: console.assert should do far less work when the assertion is true
3274         https://bugs.webkit.org/show_bug.cgi?id=157297
3275         <rdar://problem/26056556>
3276
3277         Reviewed by Timothy Hatcher.
3278
3279         * runtime/ConsoleClient.h:
3280         * runtime/ConsoleClient.cpp:
3281         (JSC::ConsoleClient::assertion):
3282         (JSC::ConsoleClient::assertCondition): Deleted.
3283         Rename, now that this will only get called when the assertion failed.
3284
3285         * runtime/ConsoleObject.cpp:
3286         (JSC::consoleProtoFuncAssert):
3287         Avoid doing any work if the assertion succeeded.
3288
3289 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
3290
3291         Unreviewed follow-up testapi fix after r200355.
3292
3293         * runtime/JSGlobalObject.cpp:
3294         (JSC::JSGlobalObject::init):
<