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