1 2016-04-12 Mark Lam <mark.lam@apple.com>
3 ES6: Implement String.prototype.split and RegExp.prototype[@@split].
4 https://bugs.webkit.org/show_bug.cgi?id=156013
6 Reviewed by Keith Miller.
9 * JavaScriptCore.xcodeproj/project.pbxproj:
10 * builtins/GlobalObject.js:
12 * builtins/PromisePrototype.js:
13 - refactored to use the @speciesConstructor internal function.
15 * builtins/RegExpPrototype.js:
17 - refactored from @advanceStringIndexUnicode() to be match the spec.
18 Benchmarks show that there's no advantage in doing the unicode check outside
19 of the advanceStringIndexUnicode part. So, I simplified the code to match the
20 spec (especially since @@split needs to call advanceStringIndex from more than
23 - Removed an unnecessary call to @Object because it was already proven above.
24 - Changed to use advanceStringIndex instead of advanceStringIndexUnicode.
25 Again, there's no perf regression for this.
27 (hasObservableSideEffectsForRegExpSplit):
29 (advanceStringIndexUnicode): Deleted.
31 * builtins/StringPrototype.js:
33 - Modified to use RegExp.prototype[@@split].
35 * bytecode/BytecodeIntrinsicRegistry.cpp:
36 (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
37 (JSC::BytecodeIntrinsicRegistry::lookup):
38 * bytecode/BytecodeIntrinsicRegistry.h:
39 - Added the @@split symbol.
41 * runtime/CommonIdentifiers.h:
42 * runtime/ECMAScriptSpecInternalFunctions.cpp: Added.
43 (JSC::esSpecIsConstructor):
44 (JSC::esSpecIsRegExp):
45 * runtime/ECMAScriptSpecInternalFunctions.h: Added.
47 * runtime/JSGlobalObject.cpp:
49 (JSC::JSGlobalObject::init):
51 * runtime/PropertyDescriptor.cpp:
52 (JSC::PropertyDescriptor::setDescriptor):
53 - Removed an assert that is no longer valid.
55 * runtime/RegExpObject.h:
56 - Made advanceStringUnicode() public so that it can be re-used by the regexp split
59 * runtime/RegExpPrototype.cpp:
60 (JSC::RegExpPrototype::finishCreation):
61 (JSC::regExpProtoFuncExec):
62 (JSC::regExpProtoFuncSearch):
63 (JSC::advanceStringIndex):
64 (JSC::regExpProtoFuncSplitFast):
65 * runtime/RegExpPrototype.h:
67 * runtime/StringObject.h:
68 (JSC::jsStringWithReuse):
70 - Hoisted some utility functions from StringPrototype.cpp so that they can be
71 reused by the regexp split fast path.
73 * runtime/StringPrototype.cpp:
74 (JSC::StringPrototype::finishCreation):
75 (JSC::stringProtoFuncSplitFast):
76 (JSC::stringProtoFuncSubstr):
77 (JSC::builtinStringSubstrInternal):
78 (JSC::stringProtoFuncSubstring):
79 (JSC::stringIncludesImpl):
80 (JSC::stringProtoFuncIncludes):
81 (JSC::builtinStringIncludesInternal):
82 (JSC::jsStringWithReuse): Deleted.
83 (JSC::jsSubstring): Deleted.
84 (JSC::stringProtoFuncSplit): Deleted.
85 * runtime/StringPrototype.h:
89 2016-04-12 Keith Miller <keith_miller@apple.com>
91 AbstractValue should use the result type to filter structures
92 https://bugs.webkit.org/show_bug.cgi?id=156516
94 Reviewed by Geoffrey Garen.
96 When filtering an AbstractValue with a SpeculatedType we would not use the merged type when
97 filtering out the valid structures (despite what the comment directly above said). This
98 would cause us to crash if our structure-set was Top and the two speculated types were
99 different kinds of cells.
101 * dfg/DFGAbstractValue.cpp:
102 (JSC::DFG::AbstractValue::filter):
103 * tests/stress/ai-consistency-filter-cells.js: Added.
105 (attribute.value.get record):
106 (attribute.attrs.get this):
108 (let.thisValue.return.serialize):
109 (let.thisValue.transformFor):
111 2016-04-12 Filip Pizlo <fpizlo@apple.com>
113 Unreviewed, remove FIXME for https://bugs.webkit.org/show_bug.cgi?id=156457 and replace it
114 with a comment that describes what we do now.
116 * bytecode/PolymorphicAccess.h:
118 2016-04-12 Saam barati <sbarati@apple.com>
120 isLocked() assertion broke builds because ConcurrentJITLock isn't always a real lock.
122 Rubber-stamped by Filip Pizlo.
124 * bytecode/CodeBlock.cpp:
125 (JSC::CodeBlock::resultProfileForBytecodeOffset):
126 (JSC::CodeBlock::ensureResultProfile):
128 2016-04-11 Filip Pizlo <fpizlo@apple.com>
130 PolymorphicAccess should buffer AccessCases before regenerating
131 https://bugs.webkit.org/show_bug.cgi?id=156457
133 Reviewed by Benjamin Poulain.
135 Prior to this change, whenever we added an AccessCase to a PolymorphicAccess, we would
136 regenerate the whole stub. That meant that we'd do O(N^2) work for N access cases.
138 One way to fix this is to have each AccessCase generate a stub just for itself, which
139 cascades down to the already-generated cases. But that removes the binary switch
140 optimization, which makes the IC perform great even when there are many cases.
142 This change fixes the issue by buffering access cases. When we take slow path and try to add
143 a new case, the StructureStubInfo will usually just buffer the new case without generating
144 new code. We simply guarantee that after we buffer a case, we will take at most
145 Options::repatchBufferingCountdown() slow path calls before generating code for it. That
146 option is currently 7. Taking 7 more slow paths means that we have 7 more opportunities to
147 gather more access cases, or to realize that this IC is too crazy to bother with.
149 This change ensures that the DFG still gets the same kind of profiling. This is because the
150 buffered AccessCases are still part of PolymorphicAccess and so are still scanned by
151 GetByIdStatus and PutByIdStatus. The fact that the AccessCases hadn't been generated and so
152 hadn't executed doesn't change much. Mainly, it increases the likelihood that the DFG will
153 see an access case that !couldStillSucceed(). The DFG's existing profile parsing logic can
154 handle this just fine.
156 There are a bunch of algorithmic changes here. StructureStubInfo now caches the set of
157 structures that it has seen as a guard to prevent adding lots of redundant cases, in case
158 we see the same 7 cases after buffering the first one. This cache means we won't wastefully
159 allocate 7 identical AccessCase instances. PolymorphicAccess is now restructured around
160 having separate addCase() and regenerate() calls. That means a bit more moving data around.
161 So far that seems OK for performance, probably since it's O(N) work rather than O(N^2) work.
162 There is room for improvement for future patches, to be sure.
164 This is benchmarking as slightly positive or neutral on JS benchmarks. It's meant to reduce
165 pathologies I saw in page loads.
167 * bytecode/GetByIdStatus.cpp:
168 (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
169 * bytecode/PolymorphicAccess.cpp:
170 (JSC::PolymorphicAccess::PolymorphicAccess):
171 (JSC::PolymorphicAccess::~PolymorphicAccess):
172 (JSC::PolymorphicAccess::addCases):
173 (JSC::PolymorphicAccess::addCase):
174 (JSC::PolymorphicAccess::visitWeak):
175 (JSC::PolymorphicAccess::dump):
176 (JSC::PolymorphicAccess::commit):
177 (JSC::PolymorphicAccess::regenerate):
178 (JSC::PolymorphicAccess::aboutToDie):
179 (WTF::printInternal):
180 (JSC::PolymorphicAccess::regenerateWithCases): Deleted.
181 (JSC::PolymorphicAccess::regenerateWithCase): Deleted.
182 * bytecode/PolymorphicAccess.h:
183 (JSC::AccessCase::isGetter):
184 (JSC::AccessCase::callLinkInfo):
185 (JSC::AccessGenerationResult::AccessGenerationResult):
186 (JSC::AccessGenerationResult::madeNoChanges):
187 (JSC::AccessGenerationResult::gaveUp):
188 (JSC::AccessGenerationResult::buffered):
189 (JSC::AccessGenerationResult::generatedNewCode):
190 (JSC::AccessGenerationResult::generatedFinalCode):
191 (JSC::AccessGenerationResult::shouldGiveUpNow):
192 (JSC::AccessGenerationResult::generatedSomeCode):
193 (JSC::PolymorphicAccess::isEmpty):
194 (JSC::PolymorphicAccess::size):
195 (JSC::PolymorphicAccess::at):
196 * bytecode/PutByIdStatus.cpp:
197 (JSC::PutByIdStatus::computeForStubInfo):
198 * bytecode/StructureStubInfo.cpp:
199 (JSC::StructureStubInfo::StructureStubInfo):
200 (JSC::StructureStubInfo::addAccessCase):
201 (JSC::StructureStubInfo::reset):
202 (JSC::StructureStubInfo::visitWeakReferences):
203 * bytecode/StructureStubInfo.h:
204 (JSC::StructureStubInfo::considerCaching):
205 (JSC::StructureStubInfo::willRepatch): Deleted.
206 (JSC::StructureStubInfo::willCoolDown): Deleted.
207 * jit/JITOperations.cpp:
209 (JSC::tryCacheGetByID):
210 (JSC::repatchGetByID):
211 (JSC::tryCachePutByID):
212 (JSC::repatchPutByID):
215 * runtime/JSCJSValue.h:
216 * runtime/JSCJSValueInlines.h:
217 (JSC::JSValue::putByIndex):
218 (JSC::JSValue::structureOrNull):
219 (JSC::JSValue::structureOrUndefined):
222 2016-04-12 Saam barati <sbarati@apple.com>
224 There is a race with the compiler thread and the main thread with result profiles
225 https://bugs.webkit.org/show_bug.cgi?id=156503
227 Reviewed by Filip Pizlo.
229 The compiler thread should not be asking for a result
230 profile while the execution thread is creating one.
231 We must guard against such races with a lock.
233 * bytecode/CodeBlock.cpp:
234 (JSC::CodeBlock::resultProfileForBytecodeOffset):
235 (JSC::CodeBlock::ensureResultProfile):
236 (JSC::CodeBlock::capabilityLevel):
237 * bytecode/CodeBlock.h:
238 (JSC::CodeBlock::couldTakeSlowCase):
239 (JSC::CodeBlock::numberOfResultProfiles):
240 (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
241 (JSC::CodeBlock::ensureResultProfile): Deleted.
243 2016-04-12 Commit Queue <commit-queue@webkit.org>
245 Unreviewed, rolling out r199339.
246 https://bugs.webkit.org/show_bug.cgi?id=156505
248 memset_s is indeed necessary (Requested by alexchristensen_ on
253 "Build fix after r199299."
254 https://bugs.webkit.org/show_bug.cgi?id=155508
255 http://trac.webkit.org/changeset/199339
257 2016-04-12 Guillaume Emont <guijemont@igalia.com>
259 MIPS: add MacroAssemblerMIPS::store8(TrustedImm32,ImplicitAddress)
260 https://bugs.webkit.org/show_bug.cgi?id=156481
262 This method with this signature is used by r199075, and therefore
263 WebKit doesn't build on MIPS since then.
265 Reviewed by Mark Lam.
267 * assembler/MacroAssemblerMIPS.h:
268 (JSC::MacroAssemblerMIPS::store8):
270 2016-04-12 Saam barati <sbarati@apple.com>
272 We incorrectly parse arrow function expressions
273 https://bugs.webkit.org/show_bug.cgi?id=156373
275 Reviewed by Mark Lam.
277 This patch removes the notion of "isEndOfArrowFunction".
278 This was a very weird function and it was incorrect.
279 It checked that the arrow functions with concise body
280 grammar production "had a valid ending". "had a valid
281 ending" is in quotes because concise body arrow functions
282 have a valid ending as long as their body has a valid
283 assignment expression. I've removed all notion of this
284 function because it was wrong and was causing us
285 to throw syntax errors on valid programs.
288 (JSC::Lexer<T>::nextTokenIsColon):
289 (JSC::Lexer<T>::lex):
290 (JSC::Lexer<T>::setTokenPosition): Deleted.
292 (JSC::Lexer::setIsReparsingFunction):
293 (JSC::Lexer::isReparsingFunction):
294 (JSC::Lexer::lineNumber):
296 (JSC::Parser<LexerType>::parseInner):
297 (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
298 (JSC::Parser<LexerType>::parseFunctionInfo):
300 (JSC::Parser::matchIdentifierOrKeyword):
301 (JSC::Parser::tokenStart):
302 (JSC::Parser::autoSemiColon):
303 (JSC::Parser::canRecurse):
304 (JSC::Parser::isEndOfArrowFunction): Deleted.
305 (JSC::Parser::setEndOfStatement): Deleted.
306 * tests/stress/arrowfunction-others.js:
308 (simpleArrowFunction):
312 2016-04-12 Yusuke Suzuki <utatane.tea@gmail.com>
314 [JSC] addStaticGlobals should emit SymbolTableEntry watchpoints to encourage constant folding in DFG
315 https://bugs.webkit.org/show_bug.cgi?id=155110
317 Reviewed by Saam Barati.
319 `addStaticGlobals` does not emit SymbolTableEntry watchpoints for the added entries.
320 So, all the global variable lookups pointing to these static globals are not converted
321 into constants in DFGBytecodeGenerator: this fact leaves these lookups as GetGlobalVar.
322 Such thing avoids constant folding chance and emits CheckCell for @privateFunction inlining.
323 This operation is pure overhead.
325 Static globals are not configurable, and they are typically non-writable.
326 So they are constants in almost all the cases.
328 This patch initializes watchpoints for these static globals.
329 These watchpoints allow DFG to convert these nodes into constants in DFG BytecodeParser.
330 These watchpoints includes many builtin operations and `undefined`.
332 The microbenchmark, many-foreach-calls shows 5 - 7% improvement since it removes unnecessary CheckCell.
334 * bytecode/VariableWriteFireDetail.h:
335 * runtime/JSGlobalObject.cpp:
336 (JSC::JSGlobalObject::addGlobalVar):
337 (JSC::JSGlobalObject::addStaticGlobals):
338 * runtime/JSSymbolTableObject.h:
339 (JSC::symbolTablePutTouchWatchpointSet):
340 (JSC::symbolTablePutInvalidateWatchpointSet):
341 (JSC::symbolTablePut):
342 (JSC::symbolTablePutWithAttributesTouchWatchpointSet): Deleted.
343 * runtime/SymbolTable.h:
344 (JSC::SymbolTableEntry::SymbolTableEntry):
345 (JSC::SymbolTableEntry::operator=):
346 (JSC::SymbolTableEntry::swap):
348 2016-04-12 Alex Christensen <achristensen@webkit.org>
350 Build fix after r199299.
351 https://bugs.webkit.org/show_bug.cgi?id=155508
353 * jit/ExecutableAllocatorFixedVMPool.cpp:
354 (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
355 memset_s is not defined. __STDC_WANT_LIB_EXT1__ is not defined anywhere.
356 Since the return value is unused and set_constraint_handler_s is never called
357 I'm chaning it to memset.
359 2016-04-11 Benjamin Poulain <bpoulain@apple.com>
361 [JSC] B3 can use undefined bits or not defined required bits when spilling
362 https://bugs.webkit.org/show_bug.cgi?id=156486
364 Reviewed by Filip Pizlo.
366 Spilling had issues when replacing arguments in place.
369 1) If we have a 32bit stackslot, a x86 instruction could still try to load 64bits from it.
370 2) If we have a 64bit stackslot, Move32 would only set half the bits.
371 3) We were reducing Move to Move32 even if the top bits are read from the stack slot.
373 The case 1 appear with something like this:
375 Op64 %tmp1, %tmp2, %tmp3
376 When we spill %tmp1, the stack slot is 32bit, Move32 sets 32bits
377 but Op64 supports addressing for %tmp1. When we substitute %tmp1 in Op64,
378 we are creating a 64bit read for a 32bit stack slot.
380 The case 2 is an other common one. If we have:
390 We have a stack slot of 64bits. When spilling %tmp1 in #1, we are
391 effectively doing a 32bit store on the stack slot, leaving the top bits undefined.
393 Case 3 is pretty much the same as 2 but we create the Move32 ourself
394 because the source is a 32bit with ZDef.
396 Case (1) is solved by requiring that the stack slot is at least as large as the largest
399 Case (2) and (3) are solved by not replacing a Tmp by an Address if the Def
400 is smaller than the stack slot.
402 * b3/air/AirIteratedRegisterCoalescing.cpp:
404 (JSC::B3::testSpillDefSmallerThanUse):
405 (JSC::B3::testSpillUseLargerThanDef):
408 2016-04-11 Brian Burg <bburg@apple.com>
410 Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses
411 https://bugs.webkit.org/show_bug.cgi?id=156407
412 <rdar://problem/25627659>
414 Reviewed by Joseph Pecoraro.
416 There's no point having these subclasses as they don't save any space.
417 Add a StringImpl to the union and merge some implementations of writeJSON.
419 Rename m_data to m_map and explicitly name the union as InspectorValue::m_value.
420 If the value is a string and the string is not empty or null (i.e., it has a
421 StringImpl), then we need to ref() and deref() the string as the InspectorValue
422 is created or destroyed.
424 Move uses of the subclass to InspectorValue and delete redundant methods.
425 Now, most InspectorValue methods are non-virtual so they can be templated.
427 * bindings/ScriptValue.cpp:
428 (Deprecated::jsToInspectorValue):
429 * inspector/InjectedScriptBase.cpp:
430 (Inspector::InjectedScriptBase::makeCall):
431 Don't used deleted subclasses.
433 * inspector/InspectorValues.cpp:
434 (Inspector::InspectorValue::null):
435 (Inspector::InspectorValue::create):
436 (Inspector::InspectorValue::asValue):
437 (Inspector::InspectorValue::asBoolean):
438 (Inspector::InspectorValue::asDouble):
439 (Inspector::InspectorValue::asInteger):
440 (Inspector::InspectorValue::asString):
441 These only need one implementation now.
443 (Inspector::InspectorValue::writeJSON):
444 Still a virtual method since Object and Array need their members.
446 (Inspector::InspectorObjectBase::InspectorObjectBase):
447 (Inspector::InspectorBasicValue::asBoolean): Deleted.
448 (Inspector::InspectorBasicValue::asDouble): Deleted.
449 (Inspector::InspectorBasicValue::asInteger): Deleted.
450 (Inspector::InspectorBasicValue::writeJSON): Deleted.
451 (Inspector::InspectorString::asString): Deleted.
452 (Inspector::InspectorString::writeJSON): Deleted.
453 (Inspector::InspectorString::create): Deleted.
454 (Inspector::InspectorBasicValue::create): Deleted.
456 * inspector/InspectorValues.h:
457 (Inspector::InspectorObjectBase::find):
458 (Inspector::InspectorObjectBase::setBoolean):
459 (Inspector::InspectorObjectBase::setInteger):
460 (Inspector::InspectorObjectBase::setDouble):
461 (Inspector::InspectorObjectBase::setString):
462 (Inspector::InspectorObjectBase::setValue):
463 (Inspector::InspectorObjectBase::setObject):
464 (Inspector::InspectorObjectBase::setArray):
465 (Inspector::InspectorArrayBase::pushBoolean):
466 (Inspector::InspectorArrayBase::pushInteger):
467 (Inspector::InspectorArrayBase::pushDouble):
468 (Inspector::InspectorArrayBase::pushString):
469 (Inspector::InspectorArrayBase::pushValue):
470 (Inspector::InspectorArrayBase::pushObject):
471 (Inspector::InspectorArrayBase::pushArray):
472 Use new factory methods.
474 * replay/EncodedValue.cpp:
475 (JSC::ScalarEncodingTraits<bool>::encodeValue):
476 (JSC::ScalarEncodingTraits<double>::encodeValue):
477 (JSC::ScalarEncodingTraits<float>::encodeValue):
478 (JSC::ScalarEncodingTraits<int32_t>::encodeValue):
479 (JSC::ScalarEncodingTraits<int64_t>::encodeValue):
480 (JSC::ScalarEncodingTraits<uint32_t>::encodeValue):
481 (JSC::ScalarEncodingTraits<uint64_t>::encodeValue):
482 * replay/EncodedValue.h:
483 Use new factory methods.
485 2016-04-11 Filip Pizlo <fpizlo@apple.com>
487 It should be possible to edit StructureStubInfo without recompiling the world
488 https://bugs.webkit.org/show_bug.cgi?id=156470
490 Reviewed by Keith Miller.
492 This change makes it less painful to make changes to the IC code. It used to be that any
493 change to StructureStubInfo caused every JIT-related file to get recompiled. Now only a
494 smaller set of files - ones that actually peek into StructureStubInfo - will recompile. This
495 is mainly because CodeBlock.h no longer includes StructureStubInfo.h.
497 * bytecode/ByValInfo.h:
498 * bytecode/CodeBlock.cpp:
499 * bytecode/CodeBlock.h:
500 * bytecode/GetByIdStatus.cpp:
501 * bytecode/GetByIdStatus.h:
502 * bytecode/PutByIdStatus.cpp:
503 * bytecode/PutByIdStatus.h:
504 * bytecode/StructureStubInfo.h:
505 (JSC::getStructureStubInfoCodeOrigin):
506 * dfg/DFGByteCodeParser.cpp:
507 * dfg/DFGJITCompiler.cpp:
508 * dfg/DFGOSRExitCompilerCommon.cpp:
509 * dfg/DFGSpeculativeJIT.h:
510 * ftl/FTLLowerDFGToB3.cpp:
511 * ftl/FTLSlowPathCall.h:
512 * jit/IntrinsicEmitter.cpp:
513 * jit/JITInlineCacheGenerator.cpp:
514 * jit/JITInlineCacheGenerator.h:
515 * jit/JITOperations.cpp:
516 * jit/JITPropertyAccess.cpp:
517 * jit/JITPropertyAccess32_64.cpp:
519 2016-04-11 Skachkov Oleksandr <gskachkov@gmail.com>
521 Remove NewArrowFunction from DFG IR
522 https://bugs.webkit.org/show_bug.cgi?id=156439
524 Reviewed by Saam Barati.
526 It seems that NewArrowFunction was left in DFG IR during refactoring by mistake.
528 * dfg/DFGAbstractInterpreterInlines.h:
529 * dfg/DFGClobberize.h:
530 (JSC::DFG::clobberize):
531 * dfg/DFGClobbersExitState.cpp:
533 * dfg/DFGFixupPhase.cpp:
534 * dfg/DFGMayExit.cpp:
536 (JSC::DFG::Node::convertToPhantomNewFunction):
538 * dfg/DFGObjectAllocationSinkingPhase.cpp:
539 * dfg/DFGPredictionPropagationPhase.cpp:
540 * dfg/DFGSafeToExecute.h:
541 * dfg/DFGSpeculativeJIT.cpp:
542 (JSC::DFG::SpeculativeJIT::compileNewFunction):
543 * dfg/DFGSpeculativeJIT32_64.cpp:
544 * dfg/DFGSpeculativeJIT64.cpp:
545 * dfg/DFGStoreBarrierInsertionPhase.cpp:
546 * dfg/DFGStructureRegistrationPhase.cpp:
547 * ftl/FTLCapabilities.cpp:
548 * ftl/FTLLowerDFGToB3.cpp:
549 (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
551 2016-04-05 Oliver Hunt <oliver@apple.com>
553 Remove compile time define for SEPARATED_HEAP
554 https://bugs.webkit.org/show_bug.cgi?id=155508
556 Reviewed by Mark Lam.
558 Remove the SEPARATED_HEAP compile time flag. The separated
559 heap is available, but off by default, on x86_64, ARMv7, and
562 Working through the issues that happened last time essentially
563 required implementing the ARMv7 path for the separated heap
564 just so I could find all the ways it was going wrong.
566 We fixed all the logic by making the branch and jump logic in
567 the linker and assemblers take two parameters, the location to
568 write to, and the location we'll actually be writing to. We
569 need to do this because it's no longer sufficient to compute
570 jumps relative to region the linker is writing to.
572 The repatching jump, branch, and call functions only need the
573 executable address as the patching is performed directly using
574 performJITMemcpy function which works in terms of the executable
577 There is no performance impact on jsc-benchmarks with the separate
578 heap either emabled or disabled.
580 * Configurations/FeatureDefines.xcconfig:
581 * assembler/ARM64Assembler.h:
582 (JSC::ARM64Assembler::linkJump):
583 (JSC::ARM64Assembler::linkCall):
584 (JSC::ARM64Assembler::relinkJump):
585 (JSC::ARM64Assembler::relinkCall):
586 (JSC::ARM64Assembler::link):
587 (JSC::ARM64Assembler::linkJumpOrCall):
588 (JSC::ARM64Assembler::linkCompareAndBranch):
589 (JSC::ARM64Assembler::linkConditionalBranch):
590 (JSC::ARM64Assembler::linkTestAndBranch):
591 (JSC::ARM64Assembler::relinkJumpOrCall):
592 * assembler/ARMv7Assembler.h:
593 (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2):
594 (JSC::ARMv7Assembler::revertJumpTo_movT3):
595 (JSC::ARMv7Assembler::link):
596 (JSC::ARMv7Assembler::linkJump):
597 (JSC::ARMv7Assembler::relinkJump):
598 (JSC::ARMv7Assembler::repatchCompact):
599 (JSC::ARMv7Assembler::replaceWithJump):
600 (JSC::ARMv7Assembler::replaceWithLoad):
601 (JSC::ARMv7Assembler::replaceWithAddressComputation):
602 (JSC::ARMv7Assembler::setInt32):
603 (JSC::ARMv7Assembler::setUInt7ForLoad):
604 (JSC::ARMv7Assembler::isB):
605 (JSC::ARMv7Assembler::isBX):
606 (JSC::ARMv7Assembler::isMOV_imm_T3):
607 (JSC::ARMv7Assembler::isMOVT):
608 (JSC::ARMv7Assembler::isNOP_T1):
609 (JSC::ARMv7Assembler::isNOP_T2):
610 (JSC::ARMv7Assembler::linkJumpT1):
611 (JSC::ARMv7Assembler::linkJumpT2):
612 (JSC::ARMv7Assembler::linkJumpT3):
613 (JSC::ARMv7Assembler::linkJumpT4):
614 (JSC::ARMv7Assembler::linkConditionalJumpT4):
615 (JSC::ARMv7Assembler::linkBX):
616 (JSC::ARMv7Assembler::linkConditionalBX):
617 (JSC::ARMv7Assembler::linkJumpAbsolute):
618 * assembler/LinkBuffer.cpp:
619 (JSC::LinkBuffer::copyCompactAndLinkCode):
620 * assembler/MacroAssemblerARM64.h:
621 (JSC::MacroAssemblerARM64::link):
622 * assembler/MacroAssemblerARMv7.h:
623 (JSC::MacroAssemblerARMv7::link):
624 * jit/ExecutableAllocator.h:
625 (JSC::performJITMemcpy):
626 * jit/ExecutableAllocatorFixedVMPool.cpp:
627 (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
628 (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
629 (JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion):
630 (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Deleted.
631 * runtime/Options.cpp:
632 (JSC::recomputeDependentOptions):
635 2016-04-10 Filip Pizlo <fpizlo@apple.com>
637 Clean up how we reason about the states of AccessCases
638 https://bugs.webkit.org/show_bug.cgi?id=156454
640 Reviewed by Mark Lam.
642 Currently when we add an AccessCase to a PolymorphicAccess stub, we regenerate the stub.
643 That means that as we grow a stub to have N cases, we will do O(N^2) generation work. I want
644 to explore buffering AccessCases so that we can do O(N) generation work instead. But to
645 before I go there, I want to make sure that the statefulness of AccessCase makes sense. So,
646 I broke it down into three different states and added assertions about the transitions. I
647 also broke out a separate operation called AccessCase::commit(), which is the work that
648 cannot be buffered since there cannot be any JS effects between when the AccessCase was
649 created and when we do the work in commit().
651 This opens up a fairly obvious path to buffering AccessCases: add them to the list without
652 regenerating. Then when we do eventually trigger regeneration, those cases will get cloned
653 and generated automagically. This patch doesn't implement this technique yet, but gives us
654 an opportunity to independently test the scaffolding necessary to do it.
656 This is perf-neutral on lots of tests.
658 * bytecode/PolymorphicAccess.cpp:
659 (JSC::AccessGenerationResult::dump):
660 (JSC::AccessCase::clone):
661 (JSC::AccessCase::commit):
662 (JSC::AccessCase::guardedByStructureCheck):
663 (JSC::AccessCase::dump):
664 (JSC::AccessCase::generateWithGuard):
665 (JSC::AccessCase::generate):
666 (JSC::AccessCase::generateImpl):
667 (JSC::PolymorphicAccess::regenerateWithCases):
668 (JSC::PolymorphicAccess::regenerate):
669 (WTF::printInternal):
670 * bytecode/PolymorphicAccess.h:
671 (JSC::AccessCase::type):
672 (JSC::AccessCase::state):
673 (JSC::AccessCase::offset):
674 (JSC::AccessCase::viaProxy):
675 (JSC::AccessCase::callLinkInfo):
676 * bytecode/StructureStubInfo.cpp:
677 (JSC::StructureStubInfo::addAccessCase):
678 * bytecode/Watchpoint.h:
679 * dfg/DFGOperations.cpp:
681 (JSC::repatchGetByID):
682 (JSC::repatchPutByID):
685 (JSC::VM::dumpRegExpTrace):
686 (JSC::VM::ensureWatchpointSetForImpureProperty):
687 (JSC::VM::registerWatchpointForImpureProperty):
688 (JSC::VM::addImpureProperty):
691 2016-04-11 Fujii Hironori <Hironori.Fujii@jp.sony.com>
693 [CMake] Make FOLDER property INHERITED
694 https://bugs.webkit.org/show_bug.cgi?id=156460
696 Reviewed by Brent Fulgham.
699 * shell/CMakeLists.txt:
700 * shell/PlatformWin.cmake:
701 Set FOLDER property as a directory property not a target property
703 2016-04-09 Keith Miller <keith_miller@apple.com>
705 tryGetById should be supported by the DFG/FTL
706 https://bugs.webkit.org/show_bug.cgi?id=156378
708 Reviewed by Filip Pizlo.
710 This patch adds support for tryGetById in the DFG/FTL. It adds a new DFG node
711 TryGetById, which acts similarly to the normal GetById DFG node. One key
712 difference between GetById and TryGetById is that in the LLInt and Baseline
713 we do not profile the result type. This profiling is unnessary for the current
714 use case of tryGetById, which is expected to be a strict equality comparision
715 against a specific object or undefined. In either case other DFG optimizations
716 will make this equally fast with or without the profiling information.
718 Additionally, this patch adds new reuse modes for JSValueRegsTemporary that take
719 an operand and attempt to reuse the registers for that operand if they are free
720 after the current DFG node.
722 * bytecode/GetByIdStatus.cpp:
723 (JSC::GetByIdStatus::computeFromLLInt):
724 (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
725 * dfg/DFGAbstractInterpreterInlines.h:
726 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
727 * dfg/DFGByteCodeParser.cpp:
728 (JSC::DFG::ByteCodeParser::handleGetById):
729 (JSC::DFG::ByteCodeParser::parseBlock):
730 * dfg/DFGCapabilities.cpp:
731 (JSC::DFG::capabilityLevel):
732 * dfg/DFGClobberize.h:
733 (JSC::DFG::clobberize):
736 * dfg/DFGFixupPhase.cpp:
737 (JSC::DFG::FixupPhase::fixupNode):
739 (JSC::DFG::Node::hasIdentifier):
741 * dfg/DFGPredictionPropagationPhase.cpp:
742 (JSC::DFG::PredictionPropagationPhase::propagate):
743 * dfg/DFGSafeToExecute.h:
744 (JSC::DFG::safeToExecute):
745 * dfg/DFGSpeculativeJIT.cpp:
746 (JSC::DFG::SpeculativeJIT::compileTryGetById):
747 (JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):
748 * dfg/DFGSpeculativeJIT.h:
749 (JSC::DFG::GPRTemporary::operator=):
750 * dfg/DFGSpeculativeJIT32_64.cpp:
751 (JSC::DFG::SpeculativeJIT::cachedGetById):
752 (JSC::DFG::SpeculativeJIT::compile):
753 * dfg/DFGSpeculativeJIT64.cpp:
754 (JSC::DFG::SpeculativeJIT::cachedGetById):
755 (JSC::DFG::SpeculativeJIT::compile):
756 * ftl/FTLCapabilities.cpp:
757 (JSC::FTL::canCompile):
758 * ftl/FTLLowerDFGToB3.cpp:
759 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
760 (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
761 (JSC::FTL::DFG::LowerDFGToB3::getById):
762 * jit/JITOperations.cpp:
763 * jit/JITOperations.h:
764 * tests/stress/try-get-by-id.js:
765 (tryGetByIdTextStrict):
767 (let.get createBuiltin):
769 (getCaller.obj.1.throw.new.Error): Deleted.
771 2016-04-09 Saam barati <sbarati@apple.com>
773 Allocation sinking SSA Defs are allowed to have replacements
774 https://bugs.webkit.org/show_bug.cgi?id=156444
776 Reviewed by Filip Pizlo.
778 Consider the following program and the annotations that explain why
779 the SSA defs we create in allocation sinking can have replacements.
782 let o1 = {x: 20, y: 50};
783 let o2 = {y: 40, o1: o1};
786 // We're Defing a new variable here, call it o3_field.
787 // o3_field is defing the value that is the result of
788 // a GetByOffset that gets eliminated through allocation sinking.
793 // This control flow is here to not allow the phase to consult
794 // its local SSA mapping (which properly handles replacements)
795 // for the value of o3_field.
802 // Here, we ask for the reaching def of o3_field, and assert
803 // it doesn't have a replacement. It does have a replacement
804 // though. The original Def was the GetByOffset. We replaced
805 // that GetByOffset with the value of the o1_y variable.
806 let value = o3.field;
807 assert(value === 50);
810 * dfg/DFGObjectAllocationSinkingPhase.cpp:
811 * tests/stress/allocation-sinking-defs-may-have-replacements.js: Added.
816 2016-04-09 Commit Queue <commit-queue@webkit.org>
818 Unreviewed, rolling out r199242.
819 https://bugs.webkit.org/show_bug.cgi?id=156442
821 Caused many many leaks (Requested by ap on #webkit).
825 "Web Inspector: get rid of InspectorBasicValue and
826 InspectorString subclasses"
827 https://bugs.webkit.org/show_bug.cgi?id=156407
828 http://trac.webkit.org/changeset/199242
830 2016-04-09 Filip Pizlo <fpizlo@apple.com>
832 Debug JSC test failure: stress/multi-put-by-offset-reallocation-butterfly-cse.js.ftl-no-cjit-small-pool
833 https://bugs.webkit.org/show_bug.cgi?id=156406
835 Reviewed by Saam Barati.
837 The failure was because the GC ran from within the butterfly allocation call in a put_by_id
838 transition AccessCase that had to deal with indexing storage. When the GC runs in a call from a stub,
839 then we need to be extra careful:
841 1) The GC may reset the IC and delete the stub. So, the stub needs to tell the GC that it might be on
842 the stack during GC, so that the GC keeps it alive if it's currently running.
844 2) If the stub uses (dereferences or stores) some object after the call, then we need to ensure that
845 the stub routine knows about that object independently of the IC.
847 In the case of put_by_id transitions that use a helper to allocate the butterfly, we have both
848 issues. A long time ago, we had to deal with (2), and we still had code to handle that case, although
849 it appears to be dead. This change revives that code and glues it together with PolymorphicAccess.
851 * bytecode/PolymorphicAccess.cpp:
852 (JSC::AccessCase::alternateBase):
853 (JSC::AccessCase::doesCalls):
854 (JSC::AccessCase::couldStillSucceed):
855 (JSC::AccessCase::generate):
856 (JSC::PolymorphicAccess::regenerate):
857 * bytecode/PolymorphicAccess.h:
858 (JSC::AccessCase::customSlotBase):
859 (JSC::AccessCase::isGetter):
860 (JSC::AccessCase::doesCalls): Deleted.
861 * jit/GCAwareJITStubRoutine.cpp:
862 (JSC::GCAwareJITStubRoutine::markRequiredObjectsInternal):
863 (JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine):
864 (JSC::MarkingGCAwareJITStubRoutine::~MarkingGCAwareJITStubRoutine):
865 (JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
866 (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
867 (JSC::createJITStubRoutine):
868 (JSC::MarkingGCAwareJITStubRoutineWithOneObject::MarkingGCAwareJITStubRoutineWithOneObject): Deleted.
869 (JSC::MarkingGCAwareJITStubRoutineWithOneObject::~MarkingGCAwareJITStubRoutineWithOneObject): Deleted.
870 (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal): Deleted.
871 * jit/GCAwareJITStubRoutine.h:
872 (JSC::createJITStubRoutine):
874 2016-04-08 Joseph Pecoraro <pecoraro@apple.com>
876 Web Inspector: XHRs and Web Worker scripts are not searchable
877 https://bugs.webkit.org/show_bug.cgi?id=154214
878 <rdar://problem/24643587>
880 Reviewed by Timothy Hatcher.
882 * inspector/protocol/Page.json:
883 Add optional requestId to search results properties and search
884 parameters for when the frameId and url are not enough. XHR
885 resources, and "Other" resources will use this.
887 2016-04-08 Guillaume Emont <guijemont@igalia.com>
889 MIPS: support Signed cond in branchTest32()
890 https://bugs.webkit.org/show_bug.cgi?id=156260
892 This is needed since r197688 makes use of it.
894 Reviewed by Mark Lam.
896 * assembler/MacroAssemblerMIPS.h:
897 (JSC::MacroAssemblerMIPS::branchTest32):
899 2016-04-08 Alex Christensen <achristensen@webkit.org>
901 Progress towards running CMake WebKit2 on Mac
902 https://bugs.webkit.org/show_bug.cgi?id=156426
904 Reviewed by Tim Horton.
908 2016-04-08 Saam barati <sbarati@apple.com>
910 Debugger may dereference m_currentCallFrame even after the VM has gone idle
911 https://bugs.webkit.org/show_bug.cgi?id=156413
913 Reviewed by Mark Lam.
915 There is a bug where the debugger may dereference its m_currentCallFrame
916 pointer after that pointer becomes invalid to read from. This happens like so:
918 We may step over an instruction which causes the end of execution for the
919 current program. This causes the VM to exit. Then, we perform a GC which
920 causes us to collect the global object. The global object being collected
921 causes us to detach the debugger. In detaching, we think we still have a
922 valid m_currentCallFrame, we dereference it, and crash. The solution is to
923 make sure we're paused when dereferencing this pointer inside ::detach().
925 * debugger/Debugger.cpp:
926 (JSC::Debugger::detach):
928 2016-04-08 Brian Burg <bburg@apple.com>
930 Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses
931 https://bugs.webkit.org/show_bug.cgi?id=156407
932 <rdar://problem/25627659>
934 Reviewed by Timothy Hatcher.
936 There's no point having these subclasses as they don't save any space.
937 Add m_stringValue to the union and merge some implementations of writeJSON.
938 Move uses of the subclass to InspectorValue and delete redundant methods.
939 Now, most InspectorValue methods are non-virtual so they can be templated.
941 * bindings/ScriptValue.cpp:
942 (Deprecated::jsToInspectorValue):
943 * inspector/InjectedScriptBase.cpp:
944 (Inspector::InjectedScriptBase::makeCall):
945 Don't used deleted subclasses.
947 * inspector/InspectorValues.cpp:
948 (Inspector::InspectorValue::null):
949 (Inspector::InspectorValue::create):
950 (Inspector::InspectorValue::asValue):
951 (Inspector::InspectorValue::asBoolean):
952 (Inspector::InspectorValue::asDouble):
953 (Inspector::InspectorValue::asInteger):
954 (Inspector::InspectorValue::asString):
955 These only need one implementation now.
957 (Inspector::InspectorValue::writeJSON):
958 Still a virtual method since Object and Array need their members.
960 (Inspector::InspectorObjectBase::InspectorObjectBase):
961 (Inspector::InspectorBasicValue::asBoolean): Deleted.
962 (Inspector::InspectorBasicValue::asDouble): Deleted.
963 (Inspector::InspectorBasicValue::asInteger): Deleted.
964 (Inspector::InspectorBasicValue::writeJSON): Deleted.
965 (Inspector::InspectorString::asString): Deleted.
966 (Inspector::InspectorString::writeJSON): Deleted.
967 (Inspector::InspectorString::create): Deleted.
968 (Inspector::InspectorBasicValue::create): Deleted.
970 * inspector/InspectorValues.h:
971 (Inspector::InspectorObjectBase::setBoolean):
972 (Inspector::InspectorObjectBase::setInteger):
973 (Inspector::InspectorObjectBase::setDouble):
974 (Inspector::InspectorObjectBase::setString):
975 (Inspector::InspectorArrayBase::pushBoolean):
976 (Inspector::InspectorArrayBase::pushInteger):
977 (Inspector::InspectorArrayBase::pushDouble):
978 (Inspector::InspectorArrayBase::pushString):
979 Use new factory methods.
981 * replay/EncodedValue.cpp:
982 (JSC::ScalarEncodingTraits<bool>::encodeValue):
983 (JSC::ScalarEncodingTraits<double>::encodeValue):
984 (JSC::ScalarEncodingTraits<float>::encodeValue):
985 (JSC::ScalarEncodingTraits<int32_t>::encodeValue):
986 (JSC::ScalarEncodingTraits<int64_t>::encodeValue):
987 (JSC::ScalarEncodingTraits<uint32_t>::encodeValue):
988 (JSC::ScalarEncodingTraits<uint64_t>::encodeValue):
989 * replay/EncodedValue.h:
990 Use new factory methods.
992 2016-04-08 Filip Pizlo <fpizlo@apple.com>
994 Add IC support for arguments.length
995 https://bugs.webkit.org/show_bug.cgi?id=156389
997 Reviewed by Geoffrey Garen.
999 This adds support for caching accesses to arguments.length for both DirectArguments and
1000 ScopedArguments. In strict mode, we already cached these accesses since they were just
1003 Amazingly, we also already supported caching of overridden arguments.length in both
1004 DirectArguments and ScopedArguments. This is because when you override, the property gets
1005 materialized as a normal JS property and the structure is changed.
1007 This patch painstakingly preserves our previous caching of overridden length while
1008 introducing caching of non-overridden length (i.e. the common case). In fact, we even cache
1009 the case where it could either be overridden or not, since we just end up with an AccessCase
1010 for each and they cascade to each other.
1012 This is a >3x speed-up on microbenchmarks that do arguments.length in a polymorphic context.
1013 Entirely monomorphic accesses were already handled by the DFG.
1015 * bytecode/PolymorphicAccess.cpp:
1016 (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
1017 (JSC::AccessCase::guardedByStructureCheck):
1018 (JSC::AccessCase::generateWithGuard):
1019 (JSC::AccessCase::generate):
1020 (WTF::printInternal):
1021 * bytecode/PolymorphicAccess.h:
1023 * jit/JITOperations.cpp:
1025 (JSC::tryCacheGetByID):
1026 (JSC::tryCachePutByID):
1027 (JSC::tryRepatchIn):
1028 * tests/stress/direct-arguments-override-length-then-access-normal-length.js: Added.
1033 2016-04-08 Benjamin Poulain <bpoulain@apple.com>
1035 UInt32ToNumber should have an Int52 path
1036 https://bugs.webkit.org/show_bug.cgi?id=125704
1038 Reviewed by Filip Pizlo.
1040 When dealing with big numbers, fall back to Int52 instead
1041 of double when possible.
1043 * dfg/DFGAbstractInterpreterInlines.h:
1044 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1045 * dfg/DFGFixupPhase.cpp:
1046 (JSC::DFG::FixupPhase::fixupNode):
1047 * dfg/DFGPredictionPropagationPhase.cpp:
1048 (JSC::DFG::PredictionPropagationPhase::propagate):
1049 * dfg/DFGSpeculativeJIT.cpp:
1050 (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
1051 * ftl/FTLLowerDFGToB3.cpp:
1052 (JSC::FTL::DFG::LowerDFGToB3::compileUInt32ToNumber):
1054 2016-04-08 Brian Burg <bburg@apple.com>
1056 Web Inspector: protocol generator should emit an error when 'type' is used instead of '$ref'
1057 https://bugs.webkit.org/show_bug.cgi?id=156275
1058 <rdar://problem/25569331>
1060 Reviewed by Darin Adler.
1062 * inspector/protocol/Heap.json: Fix a mistake that's now caught by the protocol generator.
1064 * inspector/scripts/codegen/models.py:
1065 (TypeReference.__init__): Check here if type_kind is on a whitelist of primitive types.
1066 (TypeReference.referenced_name): Update comment.
1068 Add a new test specifically for the case when the type would otherwise be resolved. Rebaseline.
1070 * inspector/scripts/tests/expected/fail-on-type-reference-as-primitive-type.json-error: Added.
1071 * inspector/scripts/tests/expected/fail-on-unknown-type-reference-in-type-declaration.json-error:
1072 * inspector/scripts/tests/fail-on-type-reference-as-primitive-type.json: Added.
1074 2016-04-07 Joseph Pecoraro <pecoraro@apple.com>
1076 Remove ENABLE(ENABLE_ES6_CLASS_SYNTAX) guards
1077 https://bugs.webkit.org/show_bug.cgi?id=156384
1079 Reviewed by Ryosuke Niwa.
1081 * Configurations/FeatureDefines.xcconfig:
1082 * features.json: Mark as Done.
1083 * parser/Parser.cpp:
1084 (JSC::Parser<LexerType>::parseExportDeclaration):
1085 (JSC::Parser<LexerType>::parseStatementListItem):
1086 (JSC::Parser<LexerType>::parsePrimaryExpression):
1087 (JSC::Parser<LexerType>::parseMemberExpression):
1089 2016-04-07 Filip Pizlo <fpizlo@apple.com>
1091 Implementing caching transition puts that need to reallocate with indexing storage
1092 https://bugs.webkit.org/show_bug.cgi?id=130914
1094 Reviewed by Saam Barati.
1096 This enables the IC's put_by_id path to handle reallocating the out-of-line storage even if
1097 the butterfly has indexing storage. Like the DFG, we do this by calling operations that
1098 reallocate the butterfly. Those use JSObject API and do all of the nasty work for us, like
1099 triggering a barrier.
1101 This does a bunch of refactoring to how PolymorphicAccess makes calls. It's a lot easier to
1102 do it now because the hard work is hidden under AccessGenerationState methods. This means
1103 that custom accessors now share logic with put_by_id transitions.
1105 * bytecode/PolymorphicAccess.cpp:
1106 (JSC::AccessGenerationState::succeed):
1107 (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
1108 (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
1109 (JSC::AccessGenerationState::originalCallSiteIndex):
1110 (JSC::AccessGenerationState::emitExplicitExceptionHandler):
1111 (JSC::AccessCase::AccessCase):
1112 (JSC::AccessCase::transition):
1113 (JSC::AccessCase::generate):
1114 (JSC::PolymorphicAccess::regenerate):
1115 * bytecode/PolymorphicAccess.h:
1116 (JSC::AccessGenerationState::needsToRestoreRegistersIfException):
1117 (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
1118 * dfg/DFGOperations.cpp:
1119 * dfg/DFGOperations.h:
1120 * jit/JITOperations.cpp:
1121 * jit/JITOperations.h:
1123 2016-04-07 Joseph Pecoraro <pecoraro@apple.com>
1125 Remote Inspector: When disallowing remote inspection on a debuggable, a listing is still sent to debuggers
1126 https://bugs.webkit.org/show_bug.cgi?id=156380
1127 <rdar://problem/25323727>
1129 Reviewed by Timothy Hatcher.
1131 * inspector/remote/RemoteInspector.mm:
1132 (Inspector::RemoteInspector::updateTarget):
1133 (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1134 When a target has been updated and it no longer generates a listing,
1135 we should remove the old listing as that is now stale and should
1136 not be sent. Not generating a listing means this target is no
1137 longer allowed to be debugged.
1139 2016-04-07 Joseph Pecoraro <pecoraro@apple.com>
1141 Web Inspector: Not necessary to validate webinspectord connection on iOS
1142 https://bugs.webkit.org/show_bug.cgi?id=156377
1143 <rdar://problem/25612460>
1145 Reviewed by Simon Fraser.
1147 * inspector/remote/RemoteInspectorXPCConnection.h:
1148 * inspector/remote/RemoteInspectorXPCConnection.mm:
1149 (Inspector::RemoteInspectorXPCConnection::handleEvent):
1151 2016-04-07 Keith Miller <keith_miller@apple.com>
1153 Rename ArrayMode::supportsLength to supportsSelfLength
1154 https://bugs.webkit.org/show_bug.cgi?id=156374
1156 Reviewed by Filip Pizlo.
1158 The name supportsLength is confusing because TypedArray have a
1159 length function however it is on the prototype and not on the
1160 instance. supportsSelfLength makes more sense since we use the
1161 function during fixup to tell if we can intrinsic the length
1162 property lookup on self accesses.
1164 * dfg/DFGArrayMode.h:
1165 (JSC::DFG::ArrayMode::supportsSelfLength):
1166 (JSC::DFG::ArrayMode::supportsLength): Deleted.
1167 * dfg/DFGFixupPhase.cpp:
1168 (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
1170 2016-04-07 Joseph Pecoraro <pecoraro@apple.com>
1172 Web Inspector: ProfileView source links are off by 1 line, worse in pretty printed code
1173 https://bugs.webkit.org/show_bug.cgi?id=156371
1175 Reviewed by Timothy Hatcher.
1177 * inspector/protocol/ScriptProfiler.json:
1178 Clarify that these locations are 1-based.
1180 2016-04-07 Jon Davis <jond@apple.com>
1182 Add Web Animations API to Feature Status Page
1183 https://bugs.webkit.org/show_bug.cgi?id=156360
1185 Reviewed by Timothy Hatcher.
1189 2016-04-07 Saam barati <sbarati@apple.com>
1191 Invalid assertion inside DebuggerScope::getOwnPropertySlot
1192 https://bugs.webkit.org/show_bug.cgi?id=156357
1194 Reviewed by Keith Miller.
1196 The Type Profiler might profile JS code that uses DebuggerScope and accesses properties
1197 on it. Therefore, it may have a DebuggerScope object in its log. Objects in the log
1198 are subject to having their getOwnPropertySlot method called. Therefore, the DebuggerScope
1199 might not always be in a valid state when its getOwnPropertySlot method is called.
1200 Therefore, the assertion invalid.
1202 * debugger/DebuggerScope.cpp:
1203 (JSC::DebuggerScope::getOwnPropertySlot):
1205 2016-04-07 Saam barati <sbarati@apple.com>
1207 Initial implementation of annex b.3.3 behavior was incorrect
1208 https://bugs.webkit.org/show_bug.cgi?id=156276
1210 Reviewed by Keith Miller.
1212 I almost got annex B.3.3 correct in my first implementation.
1213 There is a subtlety here I got wrong. We always create a local binding for
1214 a function at the very beginning of execution of a block scope. So we
1215 hoist function declarations to their local binding within a given
1216 block scope. When we actually evaluate the function declaration statement
1217 itself, we must lookup the binding in the current scope, and bind the
1218 value to the binding in the "var" scope. We perform the following
1219 abstract operations when executing a function declaration statement.
1221 f = lookupBindingInCurrentScope("func")
1222 store(varScope, "func", f)
1224 I got this wrong by performing the store to the var binding at the beginning
1225 of the block scope instead of when we evaluate the function declaration statement.
1226 This behavior is observable. For example, a program could change the value
1227 of "func" before the actual function declaration statement executes.
1228 Consider the following two functions:
1231 // func === undefined
1233 // typeof func === "function"
1234 function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding.
1235 func = 20 // This sets the local "func" binding to 20.
1237 // typeof func === "function"
1241 // func === undefined
1243 // typeof func === "function"
1244 func = 20 // This sets the local "func" binding to 20.
1245 function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding.
1251 * bytecompiler/BytecodeGenerator.cpp:
1252 (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
1253 (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
1254 * bytecompiler/BytecodeGenerator.h:
1255 (JSC::BytecodeGenerator::emitNodeForLeftHandSide):
1256 * bytecompiler/NodesCodegen.cpp:
1257 (JSC::FuncDeclNode::emitBytecode):
1258 * tests/stress/sloppy-mode-function-hoisting.js:
1263 (test.switch.case.0):
1265 (test.switch.capFoo2):
1269 2016-04-07 Alex Christensen <achristensen@webkit.org>
1271 Build fix after r199170
1275 2016-04-07 Keith Miller <keith_miller@apple.com>
1277 We should support the ability to do a non-effectful getById
1278 https://bugs.webkit.org/show_bug.cgi?id=156116
1280 Reviewed by Benjamin Poulain.
1282 Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
1283 useful because it enables us to take different code paths based on values that we would
1284 otherwise not be able to have knowledge of. This patch adds this new feature called
1285 try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
1286 an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
1287 GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
1288 undefined if the slot is unset. If the slot is proxied or any other cases then the result
1289 is null. In theory, if we ever wanted to check for null we could add a sentinal object to
1290 the global object that indicates we could not get the result.
1292 In order to implement this feature we add a new enum GetByIdKind that indicates what to do
1293 for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
1294 get_by_id the same way we would for load and return the value at the appropriate offset.
1295 Additionally, in order to make sure the we can properly compare the GetterSetter object
1296 with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
1297 GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
1298 likely to have little to no impact on memory usage as normal accessors are generally rare.
1300 * JavaScriptCore.xcodeproj/project.pbxproj:
1301 * builtins/BuiltinExecutableCreator.cpp: Added.
1302 (JSC::createBuiltinExecutable):
1303 * builtins/BuiltinExecutableCreator.h: Copied from Source/JavaScriptCore/builtins/BuiltinExecutables.h.
1304 * builtins/BuiltinExecutables.cpp:
1305 (JSC::BuiltinExecutables::createDefaultConstructor):
1306 (JSC::BuiltinExecutables::createBuiltinExecutable):
1307 (JSC::createBuiltinExecutable):
1308 (JSC::BuiltinExecutables::createExecutable):
1309 (JSC::createExecutableInternal): Deleted.
1310 * builtins/BuiltinExecutables.h:
1311 * bytecode/BytecodeIntrinsicRegistry.h:
1312 * bytecode/BytecodeList.json:
1313 * bytecode/BytecodeUseDef.h:
1314 (JSC::computeUsesForBytecodeOffset):
1315 (JSC::computeDefsForBytecodeOffset):
1316 * bytecode/CodeBlock.cpp:
1317 (JSC::CodeBlock::dumpBytecode):
1318 * bytecode/PolymorphicAccess.cpp:
1319 (JSC::AccessCase::tryGet):
1320 (JSC::AccessCase::generate):
1321 (WTF::printInternal):
1322 * bytecode/PolymorphicAccess.h:
1323 (JSC::AccessCase::isGet): Deleted.
1324 (JSC::AccessCase::isPut): Deleted.
1325 (JSC::AccessCase::isIn): Deleted.
1326 * bytecode/StructureStubInfo.cpp:
1327 (JSC::StructureStubInfo::reset):
1328 * bytecode/StructureStubInfo.h:
1329 * bytecompiler/BytecodeGenerator.cpp:
1330 (JSC::BytecodeGenerator::emitTryGetById):
1331 * bytecompiler/BytecodeGenerator.h:
1332 * bytecompiler/NodesCodegen.cpp:
1333 (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
1334 * dfg/DFGSpeculativeJIT32_64.cpp:
1335 (JSC::DFG::SpeculativeJIT::cachedGetById):
1336 * dfg/DFGSpeculativeJIT64.cpp:
1337 (JSC::DFG::SpeculativeJIT::cachedGetById):
1338 * ftl/FTLLowerDFGToB3.cpp:
1339 (JSC::FTL::DFG::LowerDFGToB3::getById):
1341 (JSC::JIT::privateCompileMainPass):
1342 (JSC::JIT::privateCompileSlowCases):
1344 * jit/JITInlineCacheGenerator.cpp:
1345 (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1346 * jit/JITInlineCacheGenerator.h:
1348 (JSC::JIT::callOperation):
1349 * jit/JITOperations.cpp:
1350 * jit/JITOperations.h:
1351 * jit/JITPropertyAccess.cpp:
1352 (JSC::JIT::emitGetByValWithCachedId):
1353 (JSC::JIT::emit_op_try_get_by_id):
1354 (JSC::JIT::emitSlow_op_try_get_by_id):
1355 (JSC::JIT::emit_op_get_by_id):
1356 * jit/JITPropertyAccess32_64.cpp:
1357 (JSC::JIT::emitGetByValWithCachedId):
1358 (JSC::JIT::emit_op_try_get_by_id):
1359 (JSC::JIT::emitSlow_op_try_get_by_id):
1360 (JSC::JIT::emit_op_get_by_id):
1362 (JSC::repatchByIdSelfAccess):
1363 (JSC::appropriateOptimizingGetByIdFunction):
1364 (JSC::appropriateGenericGetByIdFunction):
1365 (JSC::tryCacheGetByID):
1366 (JSC::repatchGetByID):
1367 (JSC::resetGetByID):
1370 (GlobalObject::finishCreation):
1371 (functionGetGetterSetter):
1372 (functionCreateBuiltin):
1373 * llint/LLIntData.cpp:
1374 (JSC::LLInt::Data::performAssertions):
1375 * llint/LLIntSlowPaths.cpp:
1376 (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1377 * llint/LLIntSlowPaths.h:
1378 * llint/LowLevelInterpreter.asm:
1379 * runtime/GetterSetter.cpp:
1380 * runtime/GetterSetter.h:
1382 * runtime/PropertySlot.cpp:
1383 (JSC::PropertySlot::getPureResult):
1384 * runtime/PropertySlot.h:
1385 * runtime/ProxyObject.cpp:
1386 (JSC::ProxyObject::getOwnPropertySlotCommon):
1387 * tests/stress/try-get-by-id.js: Added.
1389 (getCaller.obj.1.throw.new.Error.let.func):
1390 (getCaller.obj.1.throw.new.Error):
1391 (throw.new.Error.get let):
1393 (throw.new.Error.let.get createBuiltin):
1395 (let.get createBuiltin):
1400 2016-04-07 Filip Pizlo <fpizlo@apple.com>
1402 Rationalize the makeSpaceForCCall stuff
1403 https://bugs.webkit.org/show_bug.cgi?id=156352
1405 Reviewed by Mark Lam.
1407 I want to add more code to PolymorphicAccess that makes C calls, so that I can finally fix
1408 https://bugs.webkit.org/show_bug.cgi?id=130914 (allow transition caches to handle indexing
1411 When trying to understand what it takes to make a C call, I came across code that was making
1412 room on the stack for spilled arguments. This logic was guarded with some complicated
1413 condition. At first, I tried to just refactor the code so that the same ugly condition
1414 wouldn't have to be copy-pasted everywhere that we made C calls. But then I started thinking
1415 about the condition, and realized that it was probably wrong: if the outer PolymorphicAccess
1416 harness decides to reuse a register for the scratchGPR then the top of the stack will store
1417 the old value of scratchGPR, but the condition wouldn't necessarily trigger. So if the call
1418 then overwrote something on the stack, we'd have a bad time.
1420 Making room on the stack for a call is a cheap operation. It's orders of magnitude cheaper
1421 than the rest of the call. Therefore, I think that it's best to just unconditionally make
1424 This patch makes us do just that. I also made the relevant helpers not inline, because I
1425 think that we have too many inline methods in our assemblers. Now it's much easier to make
1426 C calls from PolymorphicAccess because you just call the AssemblyHelper methods for making
1427 space. There are no special conditions or anything like that.
1429 * bytecode/PolymorphicAccess.cpp:
1430 (JSC::AccessCase::generate):
1431 * jit/AssemblyHelpers.cpp:
1432 (JSC::AssemblyHelpers::emitLoadStructure):
1433 (JSC::AssemblyHelpers::makeSpaceOnStackForCCall):
1434 (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall):
1435 (JSC::emitRandomThunkImpl):
1436 * jit/AssemblyHelpers.h:
1437 (JSC::AssemblyHelpers::makeSpaceOnStackForCCall): Deleted.
1438 (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall): Deleted.
1440 2016-04-07 Commit Queue <commit-queue@webkit.org>
1442 Unreviewed, rolling out r199128 and r199141.
1443 https://bugs.webkit.org/show_bug.cgi?id=156348
1445 Causes crashes on multiple webpages (Requested by keith_mi_ on
1448 Reverted changesets:
1450 "[ES6] Add support for Symbol.isConcatSpreadable."
1451 https://bugs.webkit.org/show_bug.cgi?id=155351
1452 http://trac.webkit.org/changeset/199128
1454 "Unreviewed, uncomment accidentally commented line in test."
1455 http://trac.webkit.org/changeset/199141
1457 2016-04-07 Filip Pizlo <fpizlo@apple.com>
1459 Rationalize the handling of PutById transitions a bit
1460 https://bugs.webkit.org/show_bug.cgi?id=156330
1462 Reviewed by Mark Lam.
1464 * bytecode/PolymorphicAccess.cpp:
1465 (JSC::AccessCase::generate): Get rid of the specialized slow calls. We can just use the failAndIgnore jump target. We just need to make sure that we don't make observable effects until we're done with all of the fast path checks.
1466 * bytecode/StructureStubInfo.cpp:
1467 (JSC::StructureStubInfo::addAccessCase): MadeNoChanges indicates that we should keep trying to repatch. Currently PutById transitions might trigger the case that addAccessCase() sees null, if the transition involves an indexing header. Doing repatching in that case is probably not good. But, we should just fix this the right way eventually.
1469 2016-04-07 Per Arne Vollan <peavo@outlook.com>
1471 [Win] Fix for JSC stress test failures.
1472 https://bugs.webkit.org/show_bug.cgi?id=156343
1474 Reviewed by Filip Pizlo.
1476 We need to make it clear to MSVC that the method loadPtr(ImplicitAddress address, RegisterID dest)
1477 should be used, and not loadPtr(const void* address, RegisterID dest).
1479 * jit/CCallHelpers.cpp:
1480 (JSC::CCallHelpers::setupShadowChickenPacket):
1482 2016-04-06 Benjamin Poulain <bpoulain@apple.com>
1484 [JSC] UInt32ToNumber should be NodeMustGenerate
1485 https://bugs.webkit.org/show_bug.cgi?id=156329
1487 Reviewed by Filip Pizlo.
1489 It exits on negative numbers on the integer path.
1491 * dfg/DFGFixupPhase.cpp:
1492 (JSC::DFG::FixupPhase::fixupNode):
1493 * dfg/DFGNodeType.h:
1495 2016-04-04 Geoffrey Garen <ggaren@apple.com>
1497 Unreviewed, rolling out r199016.
1498 https://bugs.webkit.org/show_bug.cgi?id=156140
1500 "Perf bots are down, so I can't re-land this right now."
1504 CopiedBlock should be 16kB
1505 https://bugs.webkit.org/show_bug.cgi?id=156168
1506 http://trac.webkit.org/changeset/199016
1508 2016-04-06 Mark Lam <mark.lam@apple.com>
1510 String.prototype.match() should be calling internal function RegExpCreate.
1511 https://bugs.webkit.org/show_bug.cgi?id=156318
1513 Reviewed by Filip Pizlo.
1515 RegExpCreate is not the same as the RegExp constructor. The current implementation
1516 invokes new @RegExp which calls the constructor. This results in failures in
1517 es6/Proxy_internal_get_calls_String.prototype.match.js, and
1518 es6/Proxy_internal_get_calls_String.prototype.search.js due to observable side
1521 This patch fixes this by factoring out the part of the RegExp constructor that
1522 makes the RegExpCreate function, and changing String's match and search to call
1523 RegExpCreate instead in accordance with the ES6 spec.
1525 * builtins/StringPrototype.js:
1528 * runtime/CommonIdentifiers.h:
1529 * runtime/JSGlobalObject.cpp:
1530 (JSC::JSGlobalObject::init):
1531 * runtime/RegExpConstructor.cpp:
1533 (JSC::regExpCreate):
1534 (JSC::constructRegExp):
1535 (JSC::esSpecRegExpCreate):
1536 (JSC::constructWithRegExpConstructor):
1537 * runtime/RegExpConstructor.h:
1540 2016-04-06 Keith Miller <keith_miller@apple.com>
1542 Unreviewed, uncomment accidentally commented line in test.
1544 * tests/stress/array-concat-spread-object.js:
1546 2016-04-06 Filip Pizlo <fpizlo@apple.com>
1548 JSC should have a simple way of gathering IC statistics
1549 https://bugs.webkit.org/show_bug.cgi?id=156317
1551 Reviewed by Benjamin Poulain.
1553 This adds a cheap, runtime-enabled way of gathering statistics about why we take the slow
1554 paths for inline caches. This is complementary to our existing bytecode profiler. Eventually
1555 we may want to combine the two things.
1557 This is not a slow-down on anything because we only do extra work on IC slow paths and if
1558 it's disabled it's just a load-and-branch to skip the stats gathering code.
1561 * JavaScriptCore.xcodeproj/project.pbxproj:
1562 * jit/ICStats.cpp: Added.
1563 * jit/ICStats.h: Added.
1564 * jit/JITOperations.cpp:
1565 * runtime/JSCJSValue.h:
1566 * runtime/JSCJSValueInlines.h:
1567 (JSC::JSValue::inherits):
1568 (JSC::JSValue::classInfoOrNull):
1569 (JSC::JSValue::toThis):
1570 * runtime/Options.h:
1572 2016-04-06 Filip Pizlo <fpizlo@apple.com>
1574 32-bit JSC stress/multi-put-by-offset-multiple-transitions.js failing
1575 https://bugs.webkit.org/show_bug.cgi?id=156292
1577 Reviewed by Benjamin Poulain.
1579 Make sure that we stash the callsite index before calling operationReallocateStorageAndFinishPut.
1581 * bytecode/PolymorphicAccess.cpp:
1582 (JSC::AccessCase::generate):
1584 2016-04-06 Filip Pizlo <fpizlo@apple.com>
1586 JSC test stress/arrowfunction-lexical-bind-superproperty.js failing
1587 https://bugs.webkit.org/show_bug.cgi?id=156309
1589 Reviewed by Saam Barati.
1591 Just be honest about the fact that the ArgumentCount and Callee parts of inline callframe runtime
1592 meta-data can be read at any time.
1594 We only have to say this for the inline callframe forms of ArgumentCount and Callee because we don't
1595 sink any part of the machine prologue. This change just prevents us from sinking the pseudoprologue
1596 of inlined varargs or closure calls.
1598 Shockingly, this is not a regression on anything.
1600 * dfg/DFGClobberize.h:
1601 (JSC::DFG::clobberize):
1603 2016-03-29 Keith Miller <keith_miller@apple.com>
1605 [ES6] Add support for Symbol.isConcatSpreadable.
1606 https://bugs.webkit.org/show_bug.cgi?id=155351
1608 Reviewed by Saam Barati.
1610 This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the
1611 Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to
1612 a builtin performant. First, four new DFG intrinsics were added.
1614 1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of
1615 the Array.isArray function.
1616 2) IsJSArray: checks the first child is a JSArray object.
1617 3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor.
1618 4) CallObjectConstructor: an intrinsic of the Object constructor.
1620 IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if
1621 we are able to prove that the first child is an Array or for ToObject an Object.
1623 In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy
1624 code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and
1625 were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and
1626 the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this
1627 into a contiguous array).
1629 This patch also adds a new fast path for concat with more than one array argument by using memcpy to append
1630 values onto the result array. This works roughly the same as the two array fast path using the same methodology
1631 to decide if we can memcpy the other butterfly into the result butterfly.
1633 Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private
1634 name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our
1635 dataLog function on it.
1637 Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a
1638 JSValueOperand if the operand's use count is one.
1640 * JavaScriptCore.xcodeproj/project.pbxproj:
1641 * builtins/ArrayPrototype.js:
1644 * bytecode/BytecodeIntrinsicRegistry.cpp:
1645 (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
1646 * bytecode/BytecodeIntrinsicRegistry.h:
1647 * dfg/DFGAbstractInterpreterInlines.h:
1648 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1649 * dfg/DFGByteCodeParser.cpp:
1650 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1651 (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
1652 * dfg/DFGClobberize.h:
1653 (JSC::DFG::clobberize):
1654 * dfg/DFGDoesGC.cpp:
1656 * dfg/DFGFixupPhase.cpp:
1657 (JSC::DFG::FixupPhase::fixupNode):
1658 * dfg/DFGNodeType.h:
1659 * dfg/DFGOperations.cpp:
1660 * dfg/DFGOperations.h:
1661 * dfg/DFGPredictionPropagationPhase.cpp:
1662 (JSC::DFG::PredictionPropagationPhase::propagate):
1663 * dfg/DFGSafeToExecute.h:
1664 (JSC::DFG::safeToExecute):
1665 * dfg/DFGSpeculativeJIT.cpp:
1666 (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1667 (JSC::DFG::SpeculativeJIT::compileIsJSArray):
1668 (JSC::DFG::SpeculativeJIT::compileIsArrayObject):
1669 (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor):
1670 (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
1671 * dfg/DFGSpeculativeJIT.h:
1672 (JSC::DFG::SpeculativeJIT::callOperation):
1673 * dfg/DFGSpeculativeJIT32_64.cpp:
1674 (JSC::DFG::SpeculativeJIT::compile):
1675 * dfg/DFGSpeculativeJIT64.cpp:
1676 (JSC::DFG::SpeculativeJIT::compile):
1677 * ftl/FTLCapabilities.cpp:
1678 (JSC::FTL::canCompile):
1679 * ftl/FTLLowerDFGToB3.cpp:
1680 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1681 (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
1682 (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject):
1683 (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
1684 (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor):
1685 (JSC::FTL::DFG::LowerDFGToB3::isArray):
1686 * jit/JITOperations.h:
1688 (WTF::RuntimeArray::createStructure):
1689 (GlobalObject::finishCreation):
1691 (functionDataLogValue):
1692 * runtime/ArrayConstructor.cpp:
1693 (JSC::ArrayConstructor::finishCreation):
1694 (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
1695 * runtime/ArrayConstructor.h:
1696 (JSC::isArrayConstructor):
1697 * runtime/ArrayPrototype.cpp:
1698 (JSC::ArrayPrototype::finishCreation):
1699 (JSC::arrayProtoPrivateFuncIsJSArray):
1700 (JSC::moveElements):
1701 (JSC::arrayProtoPrivateFuncConcatMemcpy):
1702 (JSC::arrayProtoPrivateFuncAppendMemcpy):
1703 (JSC::arrayProtoFuncConcat): Deleted.
1704 * runtime/ArrayPrototype.h:
1705 (JSC::ArrayPrototype::createStructure):
1706 * runtime/CommonIdentifiers.h:
1707 * runtime/Intrinsic.h:
1708 * runtime/JSArray.cpp:
1709 (JSC::JSArray::appendMemcpy):
1710 (JSC::JSArray::fastConcatWith): Deleted.
1711 * runtime/JSArray.h:
1712 (JSC::JSArray::createStructure):
1713 (JSC::JSArray::fastConcatType): Deleted.
1714 * runtime/JSArrayInlines.h: Added.
1715 (JSC::JSArray::memCopyWithIndexingType):
1716 (JSC::JSArray::canFastCopy):
1717 * runtime/JSGlobalObject.cpp:
1718 (JSC::JSGlobalObject::init):
1720 * runtime/ObjectConstructor.h:
1721 (JSC::constructObject):
1723 * tests/stress/array-concat-spread-object.js: Added.
1725 * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
1727 * tests/stress/array-concat-spread-proxy.js: Added.
1729 * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
1731 * tests/stress/array-species-config-array-constructor.js:
1733 2016-04-06 Commit Queue <commit-queue@webkit.org>
1735 Unreviewed, rolling out r199070.
1736 https://bugs.webkit.org/show_bug.cgi?id=156324
1738 "It didn't fix the timeout" (Requested by saamyjoon on
1743 "jsc-layout-tests.yaml/js/script-tests/regress-141098.js
1744 failing on Yosemite Debug after r198989"
1745 https://bugs.webkit.org/show_bug.cgi?id=156187
1746 http://trac.webkit.org/changeset/199070
1748 2016-04-06 Geoffrey Garen <ggaren@apple.com>
1750 Unreviewed, rolling in r199016.
1751 https://bugs.webkit.org/show_bug.cgi?id=156140
1753 It might work this time without regression because 16kB aligned requests
1754 now take the allocation fast path.
1758 CopiedBlock should be 16kB
1759 https://bugs.webkit.org/show_bug.cgi?id=156168
1760 http://trac.webkit.org/changeset/199016
1762 2016-04-06 Mark Lam <mark.lam@apple.com>
1764 Update es6.yaml to expect es6/Proxy_internal_get_calls_RegExp_constructor.js to pass.
1765 https://bugs.webkit.org/show_bug.cgi?id=156314
1767 Reviewed by Saam Barati.
1771 2016-04-06 Commit Queue <commit-queue@webkit.org>
1773 Unreviewed, rolling out r199104.
1774 https://bugs.webkit.org/show_bug.cgi?id=156301
1776 Still breaks internal builds (Requested by keith_miller on
1781 "We should support the ability to do a non-effectful getById"
1782 https://bugs.webkit.org/show_bug.cgi?id=156116
1783 http://trac.webkit.org/changeset/199104
1785 2016-04-06 Keith Miller <keith_miller@apple.com>
1787 RegExp constructor should use Symbol.match and other properties
1788 https://bugs.webkit.org/show_bug.cgi?id=155873
1790 Reviewed by Michael Saboff.
1792 This patch updates the behavior of the RegExp constructor. Now the constructor
1793 should get the Symbol.match property and check if it exists to decide if something
1794 should be constructed like a regexp object.
1796 * runtime/RegExpConstructor.cpp:
1798 (JSC::constructRegExp):
1799 (JSC::constructWithRegExpConstructor):
1800 (JSC::callRegExpConstructor):
1801 * runtime/RegExpConstructor.h:
1802 * tests/stress/regexp-constructor.js: Added.
1804 (throw.new.Error.get let):
1806 (throw.new.Error.get re):
1808 2016-04-06 Keith Miller <keith_miller@apple.com>
1810 We should support the ability to do a non-effectful getById
1811 https://bugs.webkit.org/show_bug.cgi?id=156116
1813 Reviewed by Benjamin Poulain.
1815 Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
1816 useful because it enables us to take different code paths based on values that we would
1817 otherwise not be able to have knowledge of. This patch adds this new feature called
1818 try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
1819 an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
1820 GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
1821 undefined if the slot is unset. If the slot is proxied or any other cases then the result
1822 is null. In theory, if we ever wanted to check for null we could add a sentinal object to
1823 the global object that indicates we could not get the result.
1825 In order to implement this feature we add a new enum GetByIdKind that indicates what to do
1826 for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
1827 get_by_id the same way we would for load and return the value at the appropriate offset.
1828 Additionally, in order to make sure the we can properly compare the GetterSetter object
1829 with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
1830 GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
1831 likely to have little to no impact on memory usage as normal accessors are generally rare.
1833 * builtins/BuiltinExecutables.cpp:
1834 (JSC::BuiltinExecutables::createDefaultConstructor):
1835 (JSC::BuiltinExecutables::createBuiltinExecutable):
1836 (JSC::createBuiltinExecutable):
1837 (JSC::BuiltinExecutables::createExecutable):
1838 (JSC::createExecutableInternal): Deleted.
1839 * builtins/BuiltinExecutables.h:
1840 * bytecode/BytecodeIntrinsicRegistry.h:
1841 * bytecode/BytecodeList.json:
1842 * bytecode/BytecodeUseDef.h:
1843 (JSC::computeUsesForBytecodeOffset):
1844 (JSC::computeDefsForBytecodeOffset):
1845 * bytecode/CodeBlock.cpp:
1846 (JSC::CodeBlock::dumpBytecode):
1847 * bytecode/PolymorphicAccess.cpp:
1848 (JSC::AccessCase::tryGet):
1849 (JSC::AccessCase::generate):
1850 (WTF::printInternal):
1851 * bytecode/PolymorphicAccess.h:
1852 (JSC::AccessCase::isGet): Deleted.
1853 (JSC::AccessCase::isPut): Deleted.
1854 (JSC::AccessCase::isIn): Deleted.
1855 * bytecode/StructureStubInfo.cpp:
1856 (JSC::StructureStubInfo::reset):
1857 * bytecode/StructureStubInfo.h:
1858 * bytecompiler/BytecodeGenerator.cpp:
1859 (JSC::BytecodeGenerator::emitTryGetById):
1860 * bytecompiler/BytecodeGenerator.h:
1861 * bytecompiler/NodesCodegen.cpp:
1862 (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
1863 * dfg/DFGSpeculativeJIT32_64.cpp:
1864 (JSC::DFG::SpeculativeJIT::cachedGetById):
1865 * dfg/DFGSpeculativeJIT64.cpp:
1866 (JSC::DFG::SpeculativeJIT::cachedGetById):
1867 * ftl/FTLLowerDFGToB3.cpp:
1868 (JSC::FTL::DFG::LowerDFGToB3::getById):
1870 (JSC::JIT::privateCompileMainPass):
1871 (JSC::JIT::privateCompileSlowCases):
1873 * jit/JITInlineCacheGenerator.cpp:
1874 (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1875 * jit/JITInlineCacheGenerator.h:
1877 (JSC::JIT::callOperation):
1878 * jit/JITOperations.cpp:
1879 * jit/JITOperations.h:
1880 * jit/JITPropertyAccess.cpp:
1881 (JSC::JIT::emitGetByValWithCachedId):
1882 (JSC::JIT::emit_op_try_get_by_id):
1883 (JSC::JIT::emitSlow_op_try_get_by_id):
1884 (JSC::JIT::emit_op_get_by_id):
1885 * jit/JITPropertyAccess32_64.cpp:
1886 (JSC::JIT::emitGetByValWithCachedId):
1887 (JSC::JIT::emit_op_try_get_by_id):
1888 (JSC::JIT::emitSlow_op_try_get_by_id):
1889 (JSC::JIT::emit_op_get_by_id):
1891 (JSC::repatchByIdSelfAccess):
1892 (JSC::appropriateOptimizingGetByIdFunction):
1893 (JSC::appropriateGenericGetByIdFunction):
1894 (JSC::tryCacheGetByID):
1895 (JSC::repatchGetByID):
1896 (JSC::resetGetByID):
1899 (GlobalObject::finishCreation):
1900 (functionGetGetterSetter):
1901 (functionCreateBuiltin):
1902 * llint/LLIntData.cpp:
1903 (JSC::LLInt::Data::performAssertions):
1904 * llint/LLIntSlowPaths.cpp:
1905 (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1906 * llint/LLIntSlowPaths.h:
1907 * llint/LowLevelInterpreter.asm:
1908 * runtime/GetterSetter.cpp:
1909 * runtime/GetterSetter.h:
1911 * runtime/PropertySlot.cpp:
1912 (JSC::PropertySlot::getPureResult):
1913 * runtime/PropertySlot.h:
1914 * runtime/ProxyObject.cpp:
1915 (JSC::ProxyObject::getOwnPropertySlotCommon):
1916 * tests/stress/try-get-by-id.js: Added.
1918 (getCaller.obj.1.throw.new.Error.let.func):
1919 (getCaller.obj.1.throw.new.Error):
1920 (throw.new.Error.get let):
1922 (throw.new.Error.let.get createBuiltin):
1924 (let.get createBuiltin):
1929 2016-04-05 Chris Dumez <cdumez@apple.com>
1931 Add support for [EnabledAtRuntime] operations on DOMWindow
1932 https://bugs.webkit.org/show_bug.cgi?id=156272
1934 Reviewed by Alex Christensen.
1936 Add identifier for 'fetch' so it can be used from the generated
1939 * runtime/CommonIdentifiers.h:
1941 2016-04-05 Alex Christensen <achristensen@webkit.org>
1943 Make CMake-generated binaries on Mac able to run
1944 https://bugs.webkit.org/show_bug.cgi?id=156268
1946 Reviewed by Daniel Bates.
1950 2016-04-05 Filip Pizlo <fpizlo@apple.com>
1952 Improve some other cases of context-sensitive inlining
1953 https://bugs.webkit.org/show_bug.cgi?id=156277
1955 Reviewed by Benjamin Poulain.
1957 This implements some improvements for inlining:
1959 - We no longer do guarded inlining when the profiling doesn't come from a stub. Doing so would have
1960 been risky, and according to benchmarks, it wasn't common enough to matter. I think it's better to
1961 err on the side of not inlining.
1963 - The jneq_ptr pattern for variadic calls no longer breaks the basic block. Not breaking the block
1964 increases the chances of the parser seeing the callee constant. While inlining doesn't require a
1965 callee constant, sometimes it makes a difference. Note that we were previously breaking the block
1966 for no reason at all: if the boundary after jneq_ptr is a jump target from some other jump, then
1967 the parser will automatically break the block for us. There is no reason to add any block breaking
1968 ourselves since we implement jneq_ptr by ignoring the affirmative jump destination and inserting a
1969 check and falling through.
1971 - get_by_id handling now tries to apply some common sense to its status object. In particular, if
1972 the source is a NewObject and there was no interfering operation that could clobber the structure,
1973 then we know which case of a polymorphic GetByIdStatus we would take. This arises in some
1974 constructor patterns.
1976 Long term, we should address all of these cases comprehensively by having a late inliner. The inliner
1977 being part of the bytecode parser means that there is a lot of complexity in the parser and it
1978 prevents us from inlining upon learning new information from static analysis. But for now, I think
1979 it's fine to experiment with one-off hacks, if only to learn what the possibilities are.
1981 This is a 14% speed-up on Octane/raytrace.
1983 * bytecode/CallLinkStatus.cpp:
1984 (JSC::CallLinkStatus::dump):
1985 * bytecode/CallLinkStatus.h:
1986 (JSC::CallLinkStatus::couldTakeSlowPath):
1987 (JSC::CallLinkStatus::setCouldTakeSlowPath):
1988 (JSC::CallLinkStatus::variants):
1989 (JSC::CallLinkStatus::size):
1990 (JSC::CallLinkStatus::at):
1991 * bytecode/GetByIdStatus.cpp:
1992 (JSC::GetByIdStatus::makesCalls):
1993 (JSC::GetByIdStatus::filter):
1994 (JSC::GetByIdStatus::dump):
1995 * bytecode/GetByIdStatus.h:
1996 (JSC::GetByIdStatus::wasSeenInJIT):
1997 * dfg/DFGByteCodeParser.cpp:
1998 (JSC::DFG::ByteCodeParser::handleCall):
1999 (JSC::DFG::ByteCodeParser::refineStatically):
2000 (JSC::DFG::ByteCodeParser::handleVarargsCall):
2001 (JSC::DFG::ByteCodeParser::handleInlining):
2002 (JSC::DFG::ByteCodeParser::handleGetById):
2003 (JSC::DFG::ByteCodeParser::parseBlock):
2004 * runtime/Options.h:
2006 2016-04-05 Saam barati <sbarati@apple.com>
2008 JSC SamplingProfiler: Use a thread + sleep loop instead of WTF::WorkQueue for taking samples
2009 https://bugs.webkit.org/show_bug.cgi?id=154017
2011 Reviewed by Geoffrey Garen.
2013 By moving to an explicitly created seperate thread + sample-then-sleep
2014 loop, we can remove a lot of the crufty code around WorkQueue.
2015 We're also getting sample rates that are much closer to what we're
2016 asking the OS for. When the sampling handler was built off of WorkQueue,
2017 we'd often get sample rates much higher than the 1ms we asked for. On Kraken,
2018 we would average about 1.7ms sample rates, even though we'd ask for a 1ms rate.
2019 Now, on Kraken, we're getting about 1.2ms rates. Because we're getting
2020 higher rates, this patch is a performance regression. It's slower because
2021 we're sampling more frequently.
2023 Before this patch, the sampling profiler had the following overhead:
2028 With this patch, the sampling profiler has the following overhead:
2033 Comparatively, this new patch has the following overhead over the old sampling profiler:
2036 - 13% slower on AsmBench
2038 * inspector/agents/InspectorScriptProfilerAgent.cpp:
2039 (Inspector::InspectorScriptProfilerAgent::trackingComplete):
2040 * runtime/SamplingProfiler.cpp:
2041 (JSC::SamplingProfiler::SamplingProfiler):
2042 (JSC::SamplingProfiler::~SamplingProfiler):
2043 (JSC::SamplingProfiler::createThreadIfNecessary):
2044 (JSC::SamplingProfiler::timerLoop):
2045 (JSC::SamplingProfiler::takeSample):
2046 (JSC::tryGetBytecodeIndex):
2047 (JSC::SamplingProfiler::shutdown):
2048 (JSC::SamplingProfiler::start):
2049 (JSC::SamplingProfiler::pause):
2050 (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
2051 (JSC::SamplingProfiler::noticeJSLockAcquisition):
2052 (JSC::SamplingProfiler::noticeVMEntry):
2053 (JSC::SamplingProfiler::clearData):
2054 (JSC::SamplingProfiler::stop): Deleted.
2055 (JSC::SamplingProfiler::dispatchIfNecessary): Deleted.
2056 (JSC::SamplingProfiler::dispatchFunction): Deleted.
2057 * runtime/SamplingProfiler.h:
2058 (JSC::SamplingProfiler::setTimingInterval):
2059 (JSC::SamplingProfiler::setStopWatch):
2063 2016-04-05 Commit Queue <commit-queue@webkit.org>
2065 Unreviewed, rolling out r199073.
2066 https://bugs.webkit.org/show_bug.cgi?id=156261
2068 This change broke internal Mac builds (Requested by ryanhaddad
2073 "We should support the ability to do a non-effectful getById"
2074 https://bugs.webkit.org/show_bug.cgi?id=156116
2075 http://trac.webkit.org/changeset/199073
2077 2016-04-05 Youenn Fablet <youenn.fablet@crf.canon.fr>
2079 [Fetch API] Add a runtime flag to fetch API and related constructs
2080 https://bugs.webkit.org/show_bug.cgi?id=156113
2082 Reviewed by Alex Christensen.
2084 Add a fetch API runtime flag based on preferences.
2085 Disable fetch API by default.
2087 * runtime/CommonIdentifiers.h:
2089 2016-04-05 Filip Pizlo <fpizlo@apple.com>
2091 Unreviewed, fix cloop some more.
2093 * runtime/RegExpInlines.h:
2094 (JSC::RegExp::hasCodeFor):
2095 (JSC::RegExp::hasMatchOnlyCodeFor):
2097 2016-04-05 Filip Pizlo <fpizlo@apple.com>
2099 Unreviewed, fix cloop.
2101 * jit/CCallHelpers.cpp:
2103 2016-03-18 Filip Pizlo <fpizlo@apple.com>
2105 JSC should use a shadow stack version of CHICKEN so that debuggers have the option of retrieving tail-deleted frames
2106 https://bugs.webkit.org/show_bug.cgi?id=155598
2108 Reviewed by Saam Barati.
2110 JSC is the first JSVM to have proper tail calls. This means that error.stack and the
2111 debugger will appear to "delete" strict mode stack frames, if the call that this frame made
2112 was in tail position. This is exactly what functional programmers expect - they don't want
2113 the VM to waste resources on tail-deleted frames to ensure that it's legal to loop forever
2114 using tail calls. It's also something that non-functional programmers fear. It's not clear
2115 that tail-deleted frames would actually degrade the debugging experience, but the fear is
2116 real, so it's worthwhile to do something about it.
2118 It turns out that there is at least one tail call implementation that doesn't suffer from
2119 this problem. It implements proper tail calls in the sense that you won't run out of memory
2120 by tail-looping. It also has the power to show you tail-deleted frames in a backtrace, so
2121 long as you haven't yet run out of memory. It's called CHICKEN Scheme, and it's one of my
2124 http://www.more-magic.net/posts/internals-gc.html
2126 CHICKEN does many awesome things. The intuition from CHICKEN that we use here is a simple
2127 one: what if a tail call still kept the tail-deleted frame, and the GC actually deleted that
2128 frame only once we proved that there was insufficient memory to keep it around.
2130 CHICKEN does this by reshaping the C stack with longjmp/setjmp. We can't do that because we
2131 can have arbitrary native code, and that native code does not have relocatable stack frames.
2133 But we can do something almost like CHICKEN on a shadow stack. It's a common trick to have a
2134 VM maintain two stacks - the actual execution stack plus a shadow stack that has some extra
2135 information. The shadow stack can be reshaped, moved, etc, since the VM tightly controls its
2136 layout. The main stack can then continue to obey ABI rules.
2138 This patch implements a mechanism for being able to display stack traces that include
2139 tail-deleted frames. It uses a shadow stack that behaves like a CHICKEN stack: it has all
2140 frames all the time, though we will collect the tail-deleted ones if the stack gets too big.
2141 This new mechanism is called ShadowChicken, obviously: it's CHICKEN on a shadow stack.
2143 ShadowChicken is always on, but individual CodeBlocks may make their own choices about
2144 whether to opt into it. They will do that at bytecompile time based on the debugger mode on
2145 their global object.
2147 When no CodeBlock opts in, there is no overhead, since ShadowChicken ends up doing nothing
2148 in that case. Well, except when exceptions are thrown. Then it might do some work, but it's
2151 When all CodeBlocks opt in, there is about 6% overhead. That's too much overhead to enable
2152 this all the time, but it's low enough to justify enabling in the Inspector. It's currently
2153 enabled on all CodeBlocks only when you use an Option. Otherwise it will auto-enable if the
2156 Note that ShadowChicken attempts to gracefully handle the presence of stack frames that have
2157 no logging. This is essential since we *can* have debugging enabled in one GlobalObject and
2158 disabled in another. Also, some frames don't do ShadowChicken because they just haven't been
2159 hacked to do it yet. Native frames fall into this category, as do the VM entry frames.
2161 This doesn't yet wire ShadowChicken into DebuggerCallFrame. That will take more work. It
2162 just makes a ShadowChicken stack walk function available to jsc. It's used from the
2163 shadow-chicken tests.
2165 * API/JSContextRef.cpp:
2166 (BacktraceFunctor::BacktraceFunctor):
2167 (BacktraceFunctor::operator()):
2168 (JSContextCreateBacktrace):
2170 * JavaScriptCore.xcodeproj/project.pbxproj:
2171 * bytecode/BytecodeList.json:
2172 * bytecode/BytecodeUseDef.h:
2173 (JSC::computeUsesForBytecodeOffset):
2174 (JSC::computeDefsForBytecodeOffset):
2175 * bytecode/CodeBlock.cpp:
2176 (JSC::CodeBlock::dumpBytecode):
2177 (JSC::RecursionCheckFunctor::RecursionCheckFunctor):
2178 (JSC::RecursionCheckFunctor::operator()):
2179 (JSC::CodeBlock::noticeIncomingCall):
2180 * bytecompiler/BytecodeGenerator.cpp:
2181 (JSC::BytecodeGenerator::emitEnter):
2182 (JSC::BytecodeGenerator::emitCallInTailPosition):
2183 (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
2184 (JSC::BytecodeGenerator::emitCallVarargs):
2185 (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
2186 (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
2187 (JSC::BytecodeGenerator::emitCallDefineProperty):
2188 * bytecompiler/BytecodeGenerator.h:
2189 * debugger/DebuggerCallFrame.cpp:
2190 (JSC::LineAndColumnFunctor::operator()):
2191 (JSC::LineAndColumnFunctor::column):
2192 (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor):
2193 (JSC::FindCallerMidStackFunctor::operator()):
2194 (JSC::DebuggerCallFrame::DebuggerCallFrame):
2195 * dfg/DFGAbstractInterpreterInlines.h:
2196 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2197 * dfg/DFGByteCodeParser.cpp:
2198 (JSC::DFG::ByteCodeParser::parseBlock):
2199 * dfg/DFGClobberize.h:
2200 (JSC::DFG::clobberize):
2201 * dfg/DFGDoesGC.cpp:
2203 * dfg/DFGFixupPhase.cpp:
2204 (JSC::DFG::FixupPhase::fixupNode):
2205 * dfg/DFGNodeType.h:
2206 * dfg/DFGPredictionPropagationPhase.cpp:
2207 (JSC::DFG::PredictionPropagationPhase::propagate):
2208 * dfg/DFGSafeToExecute.h:
2209 (JSC::DFG::safeToExecute):
2210 * dfg/DFGSpeculativeJIT32_64.cpp:
2211 (JSC::DFG::SpeculativeJIT::compile):
2212 * dfg/DFGSpeculativeJIT64.cpp:
2213 (JSC::DFG::SpeculativeJIT::compile):
2214 * ftl/FTLAbstractHeapRepository.cpp:
2215 * ftl/FTLAbstractHeapRepository.h:
2216 * ftl/FTLCapabilities.cpp:
2217 (JSC::FTL::canCompile):
2218 * ftl/FTLLowerDFGToB3.cpp:
2219 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2220 (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
2221 (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
2222 (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
2223 (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
2224 (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
2225 (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket):
2226 (JSC::FTL::DFG::LowerDFGToB3::boolify):
2228 (JSC::Heap::markRoots):
2229 (JSC::Heap::visitSamplingProfiler):
2230 (JSC::Heap::visitShadowChicken):
2231 (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
2232 (JSC::Heap::collectImpl):
2234 * inspector/ScriptCallStackFactory.cpp:
2235 (Inspector::CreateScriptCallStackFunctor::CreateScriptCallStackFunctor):
2236 (Inspector::CreateScriptCallStackFunctor::operator()):
2237 (Inspector::createScriptCallStack):
2238 * interpreter/CallFrame.h:
2239 (JSC::ExecState::iterate):
2240 * interpreter/Interpreter.cpp:
2241 (JSC::DumpRegisterFunctor::DumpRegisterFunctor):
2242 (JSC::DumpRegisterFunctor::operator()):
2243 (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
2244 (JSC::GetStackTraceFunctor::operator()):
2245 (JSC::Interpreter::getStackTrace):
2246 (JSC::GetCatchHandlerFunctor::handler):
2247 (JSC::GetCatchHandlerFunctor::operator()):
2248 (JSC::notifyDebuggerOfUnwinding):
2249 (JSC::UnwindFunctor::UnwindFunctor):
2250 (JSC::UnwindFunctor::operator()):
2251 (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer):
2252 * interpreter/ShadowChicken.cpp: Added.
2253 (JSC::ShadowChicken::Packet::dump):
2254 (JSC::ShadowChicken::Frame::dump):
2255 (JSC::ShadowChicken::ShadowChicken):
2256 (JSC::ShadowChicken::~ShadowChicken):
2257 (JSC::ShadowChicken::log):
2258 (JSC::ShadowChicken::update):
2259 (JSC::ShadowChicken::visitChildren):
2260 (JSC::ShadowChicken::reset):
2261 (JSC::ShadowChicken::dump):
2262 (JSC::ShadowChicken::functionsOnStack):
2263 * interpreter/ShadowChicken.h: Added.
2264 (JSC::ShadowChicken::Packet::Packet):
2265 (JSC::ShadowChicken::Packet::tailMarker):
2266 (JSC::ShadowChicken::Packet::throwMarker):
2267 (JSC::ShadowChicken::Packet::prologue):
2268 (JSC::ShadowChicken::Packet::tail):
2269 (JSC::ShadowChicken::Packet::throwPacket):
2270 (JSC::ShadowChicken::Packet::operator bool):
2271 (JSC::ShadowChicken::Packet::isPrologue):
2272 (JSC::ShadowChicken::Packet::isTail):
2273 (JSC::ShadowChicken::Packet::isThrow):
2274 (JSC::ShadowChicken::Frame::Frame):
2275 (JSC::ShadowChicken::Frame::operator==):
2276 (JSC::ShadowChicken::Frame::operator!=):
2277 (JSC::ShadowChicken::log):
2278 (JSC::ShadowChicken::logSize):
2279 (JSC::ShadowChicken::addressOfLogCursor):
2280 (JSC::ShadowChicken::logEnd):
2281 * interpreter/ShadowChickenInlines.h: Added.
2282 (JSC::ShadowChicken::iterate):
2283 * interpreter/StackVisitor.h:
2284 (JSC::StackVisitor::Frame::callee):
2285 (JSC::StackVisitor::Frame::codeBlock):
2286 (JSC::StackVisitor::Frame::bytecodeOffset):
2287 (JSC::StackVisitor::Frame::inlineCallFrame):
2288 (JSC::StackVisitor::Frame::isJSFrame):
2289 (JSC::StackVisitor::Frame::isInlinedFrame):
2290 (JSC::StackVisitor::visit):
2291 * jit/CCallHelpers.cpp: Added.
2292 (JSC::CCallHelpers::logShadowChickenProloguePacket):
2293 (JSC::CCallHelpers::logShadowChickenTailPacket):
2294 (JSC::CCallHelpers::setupShadowChickenPacket):
2295 * jit/CCallHelpers.h:
2296 (JSC::CCallHelpers::prepareForTailCallSlow):
2298 (JSC::JIT::privateCompileMainPass):
2300 * jit/JITExceptions.cpp:
2301 (JSC::genericUnwind):
2302 * jit/JITOpcodes.cpp:
2303 (JSC::JIT::emit_op_resume):
2304 (JSC::JIT::emit_op_log_shadow_chicken_prologue):
2305 (JSC::JIT::emit_op_log_shadow_chicken_tail):
2306 * jit/JITOperations.cpp:
2307 * jit/JITOperations.h:
2309 (GlobalObject::finishCreation):
2310 (FunctionJSCStackFunctor::FunctionJSCStackFunctor):
2311 (FunctionJSCStackFunctor::operator()):
2312 (functionClearSamplingFlags):
2313 (functionShadowChickenFunctionsOnStack):
2315 * llint/LLIntOffsetsExtractor.cpp:
2316 * llint/LLIntSlowPaths.cpp:
2317 (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2318 (JSC::LLInt::llint_throw_stack_overflow_error):
2319 * llint/LLIntSlowPaths.h:
2320 * llint/LowLevelInterpreter.asm:
2321 * profiler/ProfileGenerator.cpp:
2322 (JSC::AddParentForConsoleStartFunctor::foundParent):
2323 (JSC::AddParentForConsoleStartFunctor::operator()):
2324 * runtime/Error.cpp:
2325 (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
2326 (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
2327 (JSC::addErrorInfoAndGetBytecodeOffset):
2328 * runtime/JSFunction.cpp:
2329 (JSC::RetrieveArgumentsFunctor::result):
2330 (JSC::RetrieveArgumentsFunctor::operator()):
2331 (JSC::retrieveArguments):
2332 (JSC::RetrieveCallerFunctionFunctor::result):
2333 (JSC::RetrieveCallerFunctionFunctor::operator()):
2334 (JSC::retrieveCallerFunction):
2335 * runtime/JSGlobalObjectFunctions.cpp:
2336 (JSC::GlobalFuncProtoGetterFunctor::result):
2337 (JSC::GlobalFuncProtoGetterFunctor::operator()):
2338 (JSC::globalFuncProtoGetter):
2339 (JSC::GlobalFuncProtoSetterFunctor::allowsAccess):
2340 (JSC::GlobalFuncProtoSetterFunctor::operator()):
2341 * runtime/NullSetterFunction.cpp:
2342 (JSC::GetCallerStrictnessFunctor::GetCallerStrictnessFunctor):
2343 (JSC::GetCallerStrictnessFunctor::operator()):
2344 (JSC::GetCallerStrictnessFunctor::callerIsStrict):
2345 (JSC::callerIsStrict):
2346 * runtime/ObjectConstructor.cpp:
2347 (JSC::ObjectConstructorGetPrototypeOfFunctor::result):
2348 (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
2349 (JSC::objectConstructorGetPrototypeOf):
2350 * runtime/Options.h:
2353 (JSC::SetEnabledProfilerFunctor::operator()):
2355 (JSC::VM::shouldBuilderPCToCodeOriginMapping):
2356 (JSC::VM::bytecodeIntrinsicRegistry):
2357 (JSC::VM::shadowChicken):
2358 * tests/stress/resources/shadow-chicken-support.js: Added.
2363 * tests/stress/shadow-chicken-disabled.js: Added.
2376 * tests/stress/shadow-chicken-enabled.js: Added.
2399 * tools/JSDollarVMPrototype.cpp:
2400 (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
2401 (JSC::CallerFrameJITTypeFunctor::operator()):
2402 (JSC::CallerFrameJITTypeFunctor::jitType):
2403 (JSC::functionLLintTrue):
2404 (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
2405 (JSC::CellAddressCheckFunctor::operator()):
2406 (JSC::JSDollarVMPrototype::isValidCell):
2407 (JSC::JSDollarVMPrototype::isValidCodeBlock):
2408 (JSC::JSDollarVMPrototype::codeBlockForFrame):
2409 (JSC::PrintFrameFunctor::PrintFrameFunctor):
2410 (JSC::PrintFrameFunctor::operator()):
2411 (JSC::printCallFrame):
2413 2016-03-19 Filip Pizlo <fpizlo@apple.com>
2415 DFG and FTL should constant-fold RegExpExec, RegExpTest, and StringReplace
2416 https://bugs.webkit.org/show_bug.cgi?id=155270
2418 Reviewed by Saam Barati.
2420 This enables constant-folding of RegExpExec, RegExpTest, and StringReplace.
2422 It's now possible to run Yarr on the JIT threads. Since previous work on constant-folding
2423 strings gave the DFG an API for reasoning about JSString constants in terms of
2424 JIT-thread-local WTF::Strings, it's now super easy to just pass strings to Yarr and build IR
2425 based on the results.
2427 But RegExpExec is hard: the folded version still must allocate a RegExpMatchesArray. We must
2428 use the same Structure that the code would have used or else we'll pollute the program's
2429 inline caches. Also, RegExpMatchesArray.h|cpp will allocate the array and its named
2430 properties in one go - we don't want to lose that optimization. So, this patch enables
2431 MaterializeNewObject to allocate objects or arrays with any number of indexed or named
2432 properties. Previously it could only handle objects (but not arrays) and named properties
2433 (but not indexed ones).
2435 This also adds a few minor things for setting the RegExpConstructor cached result.
2437 This is about a 2x speed-up on microbenchmarks when we fold a match success and about a
2438 8x speed-up when we fold a match failure. It's a 10% speed-up on Octane/regexp.
2440 * JavaScriptCore.xcodeproj/project.pbxproj:
2441 * dfg/DFGAbstractInterpreterInlines.h:
2442 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2443 * dfg/DFGClobberize.h:
2444 (JSC::DFG::clobberize):
2445 * dfg/DFGDoesGC.cpp:
2447 * dfg/DFGFixupPhase.cpp:
2448 (JSC::DFG::FixupPhase::fixupNode):
2450 (JSC::DFG::Graph::dump):
2451 * dfg/DFGInsertionSet.cpp:
2452 (JSC::DFG::InsertionSet::insertSlow):
2453 (JSC::DFG::InsertionSet::execute):
2454 * dfg/DFGInsertionSet.h:
2455 (JSC::DFG::InsertionSet::insertCheck):
2456 * dfg/DFGLazyJSValue.cpp:
2457 (JSC::DFG::LazyJSValue::tryGetString):
2458 * dfg/DFGMayExit.cpp:
2459 (JSC::DFG::mayExit):
2461 (JSC::DFG::StackAccessData::flushedAt):
2462 (JSC::DFG::OpInfo::OpInfo): Deleted.
2463 * dfg/DFGNodeType.h:
2464 * dfg/DFGObjectAllocationSinkingPhase.cpp:
2465 * dfg/DFGObjectMaterializationData.cpp:
2466 (JSC::DFG::ObjectMaterializationData::dump):
2467 (JSC::DFG::PhantomPropertyValue::dump): Deleted.
2468 (JSC::DFG::ObjectMaterializationData::oneWaySimilarityScore): Deleted.
2469 (JSC::DFG::ObjectMaterializationData::similarityScore): Deleted.
2470 * dfg/DFGObjectMaterializationData.h:
2471 (JSC::DFG::PhantomPropertyValue::PhantomPropertyValue): Deleted.
2472 (JSC::DFG::PhantomPropertyValue::operator==): Deleted.
2473 * dfg/DFGOpInfo.h: Added.
2474 (JSC::DFG::OpInfo::OpInfo):
2475 * dfg/DFGOperations.cpp:
2476 * dfg/DFGOperations.h:
2477 * dfg/DFGPredictionPropagationPhase.cpp:
2478 (JSC::DFG::PredictionPropagationPhase::propagate):
2479 * dfg/DFGPromotedHeapLocation.cpp:
2480 (WTF::printInternal):
2481 * dfg/DFGPromotedHeapLocation.h:
2482 * dfg/DFGSafeToExecute.h:
2483 (JSC::DFG::safeToExecute):
2484 * dfg/DFGSpeculativeJIT.cpp:
2485 (JSC::DFG::SpeculativeJIT::~SpeculativeJIT):
2486 (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
2487 (JSC::DFG::SpeculativeJIT::emitGetLength):
2488 (JSC::DFG::SpeculativeJIT::compileLazyJSConstant):
2489 (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
2490 (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
2491 (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): Deleted.
2492 * dfg/DFGSpeculativeJIT.h:
2493 (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
2494 * dfg/DFGSpeculativeJIT32_64.cpp:
2495 (JSC::DFG::SpeculativeJIT::compile):
2496 * dfg/DFGSpeculativeJIT64.cpp:
2497 (JSC::DFG::SpeculativeJIT::compile):
2498 * dfg/DFGStoreBarrierInsertionPhase.cpp:
2499 * dfg/DFGStrengthReductionPhase.cpp:
2500 (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase):
2501 (JSC::DFG::StrengthReductionPhase::handleNode):
2502 (JSC::DFG::StrengthReductionPhase::handleCommutativity):
2503 (JSC::DFG::StrengthReductionPhase::executeInsertionSet):
2504 * dfg/DFGValidate.cpp:
2505 (JSC::DFG::Validate::validate):
2506 (JSC::DFG::Validate::validateCPS):
2507 * ftl/FTLAbstractHeapRepository.cpp:
2508 * ftl/FTLAbstractHeapRepository.h:
2509 * ftl/FTLCapabilities.cpp:
2510 (JSC::FTL::canCompile):
2511 * ftl/FTLLowerDFGToB3.cpp:
2512 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2513 (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
2514 (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
2515 (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
2516 (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
2517 (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
2518 (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
2519 (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
2520 (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
2521 (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
2522 (JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc):
2523 (JSC::FTL::DFG::LowerDFGToB3::unboxDouble):
2524 * ftl/FTLOperations.cpp:
2525 (JSC::FTL::operationPopulateObjectInOSR):
2526 (JSC::FTL::operationNewObjectWithButterfly): Deleted.
2527 * ftl/FTLOperations.h:
2528 * inspector/ContentSearchUtilities.cpp:
2529 * runtime/JSObject.h:
2530 (JSC::JSObject::createRawObject):
2531 (JSC::JSFinalObject::create):
2532 * runtime/RegExp.cpp:
2533 (JSC::RegExp::compile):
2534 (JSC::RegExp::match):
2535 (JSC::RegExp::matchConcurrently):
2536 (JSC::RegExp::compileMatchOnly):
2537 (JSC::RegExp::deleteCode):
2539 * runtime/RegExpCachedResult.h:
2540 (JSC::RegExpCachedResult::offsetOfLastRegExp):
2541 (JSC::RegExpCachedResult::offsetOfLastInput):
2542 (JSC::RegExpCachedResult::offsetOfResult):
2543 (JSC::RegExpCachedResult::offsetOfReified):
2544 * runtime/RegExpConstructor.h:
2545 (JSC::RegExpConstructor::offsetOfCachedResult):
2546 * runtime/RegExpInlines.h:
2547 (JSC::RegExp::hasCodeFor):
2548 (JSC::RegExp::compileIfNecessary):
2549 (JSC::RegExp::matchInline):
2550 (JSC::RegExp::hasMatchOnlyCodeFor):
2551 (JSC::RegExp::compileIfNecessaryMatchOnly):
2552 * runtime/RegExpObjectInlines.h:
2553 (JSC::RegExpObject::execInline):
2554 * runtime/StringPrototype.cpp:
2555 (JSC::substituteBackreferencesSlow):
2556 (JSC::substituteBackreferencesInline):
2557 (JSC::substituteBackreferences):
2558 (JSC::StringRange::StringRange):
2559 * runtime/StringPrototype.h:
2561 * tests/stress/simple-regexp-exec-folding-fail.js: Added.
2563 * tests/stress/simple-regexp-exec-folding.js: Added.
2565 * tests/stress/simple-regexp-test-folding-fail.js: Added.
2567 * tests/stress/simple-regexp-test-folding.js: Added.
2569 * yarr/RegularExpression.cpp:
2571 * yarr/YarrInterpreter.cpp:
2572 (JSC::Yarr::Interpreter::interpret):
2573 (JSC::Yarr::ByteCompiler::ByteCompiler):
2574 (JSC::Yarr::ByteCompiler::compile):
2575 (JSC::Yarr::ByteCompiler::checkInput):
2576 (JSC::Yarr::byteCompile):
2577 (JSC::Yarr::interpret):
2578 * yarr/YarrInterpreter.h:
2579 (JSC::Yarr::BytecodePattern::BytecodePattern):
2581 2016-04-05 Keith Miller <keith_miller@apple.com>
2583 We should support the ability to do a non-effectful getById
2584 https://bugs.webkit.org/show_bug.cgi?id=156116
2586 Reviewed by Benjamin Poulain.
2588 Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
2589 useful because it enables us to take different code paths based on values that we would
2590 otherwise not be able to have knowledge of. This patch adds this new feature called
2591 try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
2592 an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
2593 GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
2594 undefined if the slot is unset. If the slot is proxied or any other cases then the result
2595 is null. In theory, if we ever wanted to check for null we could add a sentinal object to
2596 the global object that indicates we could not get the result.
2598 In order to implement this feature we add a new enum GetByIdKind that indicates what to do
2599 for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
2600 get_by_id the same way we would for load and return the value at the appropriate offset.
2601 Additionally, in order to make sure the we can properly compare the GetterSetter object
2602 with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
2603 GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
2604 likely to have little to no impact on memory usage as normal accessors are generally rare.
2606 * JavaScriptCore.xcodeproj/project.pbxproj:
2607 * builtins/BuiltinExecutables.cpp:
2608 (JSC::BuiltinExecutables::createDefaultConstructor):
2609 (JSC::BuiltinExecutables::createBuiltinExecutable):
2610 (JSC::createBuiltinExecutable):
2611 (JSC::BuiltinExecutables::createExecutable):
2612 (JSC::createExecutableInternal): Deleted.
2613 * builtins/BuiltinExecutables.h:
2614 * bytecode/BytecodeIntrinsicRegistry.h:
2615 * bytecode/BytecodeList.json:
2616 * bytecode/BytecodeUseDef.h:
2617 (JSC::computeUsesForBytecodeOffset):
2618 (JSC::computeDefsForBytecodeOffset):
2619 * bytecode/CodeBlock.cpp:
2620 (JSC::CodeBlock::dumpBytecode):
2621 * bytecode/PolymorphicAccess.cpp:
2622 (JSC::AccessCase::tryGet):
2623 (JSC::AccessCase::generate):
2624 (WTF::printInternal):
2625 * bytecode/PolymorphicAccess.h:
2626 (JSC::AccessCase::isGet): Deleted.
2627 (JSC::AccessCase::isPut): Deleted.
2628 (JSC::AccessCase::isIn): Deleted.
2629 * bytecode/StructureStubInfo.cpp:
2630 (JSC::StructureStubInfo::reset):
2631 * bytecode/StructureStubInfo.h:
2632 * bytecompiler/BytecodeGenerator.cpp:
2633 (JSC::BytecodeGenerator::emitTryGetById):
2634 * bytecompiler/BytecodeGenerator.h:
2635 * bytecompiler/NodesCodegen.cpp:
2636 (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
2637 * dfg/DFGSpeculativeJIT32_64.cpp:
2638 (JSC::DFG::SpeculativeJIT::cachedGetById):
2639 * dfg/DFGSpeculativeJIT64.cpp:
2640 (JSC::DFG::SpeculativeJIT::cachedGetById):
2641 * ftl/FTLLowerDFGToB3.cpp:
2642 (JSC::FTL::DFG::LowerDFGToB3::getById):
2644 (JSC::JIT::privateCompileMainPass):
2645 (JSC::JIT::privateCompileSlowCases):
2647 * jit/JITInlineCacheGenerator.cpp:
2648 (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2649 * jit/JITInlineCacheGenerator.h:
2651 (JSC::JIT::callOperation):
2652 * jit/JITOperations.cpp:
2653 * jit/JITOperations.h:
2654 * jit/JITPropertyAccess.cpp:
2655 (JSC::JIT::emitGetByValWithCachedId):
2656 (JSC::JIT::emit_op_try_get_by_id):
2657 (JSC::JIT::emitSlow_op_try_get_by_id):
2658 (JSC::JIT::emit_op_get_by_id):
2659 * jit/JITPropertyAccess32_64.cpp:
2660 (JSC::JIT::emitGetByValWithCachedId):
2661 (JSC::JIT::emit_op_try_get_by_id):
2662 (JSC::JIT::emitSlow_op_try_get_by_id):
2663 (JSC::JIT::emit_op_get_by_id):
2665 (JSC::repatchByIdSelfAccess):
2666 (JSC::appropriateOptimizingGetByIdFunction):
2667 (JSC::appropriateGenericGetByIdFunction):
2668 (JSC::tryCacheGetByID):
2669 (JSC::repatchGetByID):
2670 (JSC::resetGetByID):
2673 (GlobalObject::finishCreation):
2674 (functionGetGetterSetter):
2675 (functionCreateBuiltin):
2676 * llint/LLIntData.cpp:
2677 (JSC::LLInt::Data::performAssertions):
2678 * llint/LLIntSlowPaths.cpp:
2679 (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2680 * llint/LLIntSlowPaths.h:
2681 * llint/LowLevelInterpreter.asm:
2682 * runtime/GetterSetter.cpp:
2683 * runtime/GetterSetter.h:
2685 * runtime/PropertySlot.cpp:
2686 (JSC::PropertySlot::getPureResult):
2687 * runtime/PropertySlot.h:
2688 * runtime/ProxyObject.cpp:
2689 (JSC::ProxyObject::getOwnPropertySlotCommon):
2690 * tests/stress/try-get-by-id.js: Added.
2692 (getCaller.obj.1.throw.new.Error.let.func):
2693 (getCaller.obj.1.throw.new.Error):
2694 (throw.new.Error.get let):
2696 (throw.new.Error.let.get createBuiltin):
2698 (let.get createBuiltin):
2703 2016-04-05 Saam barati <sbarati@apple.com>
2705 jsc-layout-tests.yaml/js/script-tests/regress-141098.js failing on Yosemite Debug after r198989
2706 https://bugs.webkit.org/show_bug.cgi?id=156187
2708 Reviewed by Filip Pizlo.
2710 This is a speculative fix. Lets see if the prevents the timeout.
2712 * parser/Parser.cpp:
2713 (JSC::Parser<LexerType>::parseStatementListItem):
2715 2016-04-04 Filip Pizlo <fpizlo@apple.com>
2717 PolymorphicAccess should have a MegamorphicLoad case
2718 https://bugs.webkit.org/show_bug.cgi?id=156182
2720 Reviewed by Geoffrey Garen and Keith Miller.
2722 This introduces a new case to PolymorphicAccess called MegamorphicLoad. This inlines the lookup in
2723 the PropertyTable. It's cheaper than switching on a huge number of cases and it's cheaper than
2724 calling into C++ to do the same job - particularly since inlining the lookup into an access means
2725 that we can precompute the hash code.
2727 When writing the inline code for the hashtable lookup, I found that our hashing algorithm was not
2728 optimal. It used a double-hashing method for reducing collision pathologies. This is great for
2729 improving the performance of some worst-case scenarios. But this misses the point of a hashtable: we
2730 want to optimize the average-case performance. When optimizing for average-case, we can choose to
2731 either focus on maximizing the likelihood of the fast case happening, or to minimize the cost of the
2732 worst-case, or to minimize the cost of the fast case. Even a very basic hashtable will achieve a high
2733 probability of hitting the fast case. So, doing work to reduce the likelihood of a worst-case
2734 pathology only makes sense if it also preserves the good performance of the fast case, or reduces the
2735 likelihood of the worst-case by so much that it's a win for the average case even with a slow-down in
2738 I don't believe, based on looking at how the double-hashing is implemented, that it's possible that
2739 this preserves the good performance of the fast case. It requires at least one more value to be live
2740 around the loop, and dramatically increases the register pressure at key points inside the loop. The
2741 biggest offender is the doubleHash() method itself. There is no getting around how bad this is: if
2742 the compiler live-range-splits that method to death to avoid degrading register pressure elsewhere
2743 then we will pay a steep price anytime we take the second iteration around the loop; but if the
2744 compiler doesn't split around the call then the hashtable lookup fast path will be full of spills on
2745 some architectures (I performed biological register allocation and found that I needed 9 registers
2746 for complete lookup, while x86-64 has only 6 callee-saves; OTOH ARM64 has 10 callee-saves so it might
2749 Hence, this patch changes the hashtable lookup to use simple linear probing. This was not a slow-down
2750 on anything, and it made MegamorphicLoad much more sensible since it is less likely to have to spill.
2752 There are some other small changes in this patch, like rationalizing the IC's choice between giving
2753 up after a repatch (i.e. never trying again) and just pretending that nothing happened (so we can
2754 try to repatch again in the future). It looked like the code in Repatch.cpp was set up to be able to
2755 choose between those options, but we weren't fully taking advantage of it because the
2756 regenerateWithCase() method just returned null for any failure, and didn't say whether it was the
2757 sort of failure that renders the inline cache unrepatchable (like memory allocation failure). Now
2758 this is all made explicit. I wanted to make sure this change happened in this patch since the
2759 MegamorphicLoad code automagically generates a MegamorphicLoad case by coalescing other cases. Since
2760 this is intended to avoid blowing out the cache and making it unrepatchable, I wanted to make sure
2761 that the rules for giving up were something that made sense to me.
2763 This is a big win on microbenchmarks. It's neutral on traditional JS benchmarks. It's a slight
2764 speed-up for page loading, because many real websites like to have megamorphic property accesses.
2766 * bytecode/PolymorphicAccess.cpp:
2767 (JSC::AccessGenerationResult::dump):
2768 (JSC::AccessGenerationState::addWatchpoint):
2769 (JSC::AccessCase::get):
2770 (JSC::AccessCase::megamorphicLoad):
2771 (JSC::AccessCase::replace):
2772 (JSC::AccessCase::guardedByStructureCheck):
2773 (JSC::AccessCase::couldStillSucceed):
2774 (JSC::AccessCase::canBeReplacedByMegamorphicLoad):
2775 (JSC::AccessCase::canReplace):
2776 (JSC::AccessCase::generateWithGuard):
2777 (JSC::AccessCase::generate):
2778 (JSC::PolymorphicAccess::PolymorphicAccess):
2779 (JSC::PolymorphicAccess::~PolymorphicAccess):
2780 (JSC::PolymorphicAccess::regenerateWithCases):
2781 (JSC::PolymorphicAccess::regenerateWithCase):
2782 (WTF::printInternal):
2783 * bytecode/PolymorphicAccess.h:
2784 (JSC::AccessCase::isGet):
2785 (JSC::AccessCase::isPut):
2786 (JSC::AccessCase::isIn):
2787 (JSC::AccessGenerationResult::AccessGenerationResult):
2788 (JSC::AccessGenerationResult::operator==):
2789 (JSC::AccessGenerationResult::operator!=):
2790 (JSC::AccessGenerationResult::operator bool):
2791 (JSC::AccessGenerationResult::kind):
2792 (JSC::AccessGenerationResult::code):
2793 (JSC::AccessGenerationResult::madeNoChanges):
2794 (JSC::AccessGenerationResult::gaveUp):
2795 (JSC::AccessGenerationResult::generatedNewCode):
2796 (JSC::PolymorphicAccess::isEmpty):
2797 (JSC::AccessGenerationState::AccessGenerationState):
2798 * bytecode/StructureStubInfo.cpp:
2799 (JSC::StructureStubInfo::aboutToDie):
2800 (JSC::StructureStubInfo::addAccessCase):
2801 * bytecode/StructureStubInfo.h:
2802 * jit/AssemblyHelpers.cpp:
2803 (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
2804 (JSC::AssemblyHelpers::loadProperty):
2805 (JSC::emitRandomThunkImpl):
2806 (JSC::AssemblyHelpers::emitRandomThunk):
2807 (JSC::AssemblyHelpers::emitLoadStructure):
2808 * jit/AssemblyHelpers.h:
2809 (JSC::AssemblyHelpers::loadValue):
2810 (JSC::AssemblyHelpers::moveValueRegs):
2811 (JSC::AssemblyHelpers::argumentsStart):
2812 (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
2813 (JSC::AssemblyHelpers::emitLoadStructure): Deleted.
2815 (JSC::JSValueRegs::dump):
2817 (JSC::JSValueRegs::uses):
2819 (JSC::replaceWithJump):
2820 (JSC::tryCacheGetByID):
2821 (JSC::tryCachePutByID):
2822 (JSC::tryRepatchIn):
2823 * jit/ThunkGenerators.cpp:
2824 (JSC::virtualThunkFor):
2825 * runtime/Options.h:
2826 * runtime/PropertyMapHashTable.h:
2827 (JSC::PropertyTable::begin):
2828 (JSC::PropertyTable::find):
2829 (JSC::PropertyTable::get):
2830 * runtime/Structure.h:
2832 2016-04-05 Antoine Quint <graouts@apple.com>
2834 [WebGL2] Turn the ENABLE_WEBGL2 flag on
2835 https://bugs.webkit.org/show_bug.cgi?id=156061
2836 <rdar://problem/25463193>
2838 Reviewed by Alex Christensen.
2840 * Configurations/FeatureDefines.xcconfig:
2841 * runtime/CommonIdentifiers.h:
2843 Define the conditionalized classes WebGL2RenderingContext and WebGLVertexArrayObject.
2845 2016-04-04 Zan Dobersek <zdobersek@igalia.com>
2847 Add missing EABI_32BIT_DUMMY_ARG arguments for some callOperation(J_JITOperation_EGReoJ, ...) overloads
2848 https://bugs.webkit.org/show_bug.cgi?id=156161
2850 Reviewed by Yusuke Suzuki.
2852 r197641 added a couple of callOperation(J_JITOperation_EGReoJ, ...) overloads
2853 that handle arguments split into the tag and the payload. The two were split
2854 between the last argument register and the stack on 32-bit ARM EABI systems,
2855 causing incorrect behavior.
2857 Adding EABI_32BIT_DUMMY_ARG pushes the tag and payload together onto the
2858 stack, removing the issue.
2860 * dfg/DFGSpeculativeJIT.h:
2861 (JSC::DFG::SpeculativeJIT::callOperation):
2863 2016-04-04 Joseph Pecoraro <pecoraro@apple.com>
2865 Avoid copying ModuleLoaderObject.js to resources bundle
2866 https://bugs.webkit.org/show_bug.cgi?id=156188
2867 <rdar://problem/25534383>
2869 Reviewed by Alexey Proskuryakov.
2871 * JavaScriptCore.xcodeproj/project.pbxproj:
2873 2016-04-04 Geoffrey Garen <ggaren@apple.com>
2875 Unreviewed, rolling out r199016.
2876 https://bugs.webkit.org/show_bug.cgi?id=156140
2878 "Regressed Octane and Kraken on the perf bots."
2882 CopiedBlock should be 16kB
2883 https://bugs.webkit.org/show_bug.cgi?id=156168
2884 http://trac.webkit.org/changeset/199016
2886 2016-04-04 Benjamin Poulain <bpoulain@apple.com>
2888 [JSC][x86] Fix an assertion in MacroAssembler::branch8()
2889 https://bugs.webkit.org/show_bug.cgi?id=156181
2891 Reviewed by Geoffrey Garen.
2893 * assembler/MacroAssemblerX86Common.h:
2894 (JSC::MacroAssemblerX86Common::branch8):
2895 The test was wrong because valid negative numbers have ones
2898 I replaced the assertion to be explicit about the valid range.
2900 2016-04-04 Chris Dumez <cdumez@apple.com>
2902 Regression(r196145): Crash in getOwnPropertyDescriptor on http://www.history.com/shows/vikings
2903 https://bugs.webkit.org/show_bug.cgi?id=156136
2904 <rdar://problem/25410767>
2906 Reviewed by Ryosuke Niwa.
2908 Add a few more identifiers for using in the generated bindings.
2910 * runtime/CommonIdentifiers.h:
2912 2016-04-04 Geoffrey Garen <ggaren@apple.com>
2914 CopiedBlock should be 16kB
2915 https://bugs.webkit.org/show_bug.cgi?id=156168
2917 Reviewed by Mark Lam.
2919 MarkedBlock is 16kB, and bmalloc's largest fast-path allocation is 16kB,
2920 and the largest page size on Apple devices is 16kB -- so this change
2921 should improve sharing and recycling and keep us on the fast path more.
2923 32kB is also super aggro. At 16kB, we support allocations up to 8kB,
2924 which covers 99.3% of allocations on facebook.com. The 32kB block size
2925 only covered an additional 0.2% of allocations.
2927 * heap/CopiedBlock.h:
2929 2016-04-04 Carlos Garcia Campos <cgarcia@igalia.com>
2931 REGRESSION(r198792): [GTK] Inspector crashes in Inspector::Protocol::getEnumConstantValue since r198792
2932 https://bugs.webkit.org/show_bug.cgi?id=155745
2933 <rdar://problem/25289456>
2935 Reviewed by Brian Burg.
2937 The problem is that we are generating the Inspector::Protocol::getEnumConstantValue() method and the
2938 enum_constant_values array for every framework that has enum values. So, in case of GTK port we have two
2939 implementations, one for the inspector in JavaScriptCore and another one for Web Automation in WebKit2, but when
2940 using the inspector in WebKit2 we always end up using the one in WebKit2. Since the enum_constant_values array
2941 is smaller in WebKit2 than the one in JavaScriptCore, we crash every time we receive an enum value higher than
2942 the array size. We need to disambiguate the getEnumConstantValue() generated and used for every framework, so we
2943 can use a specific namespace for the enum conversion methods.
2945 * inspector/agents/InspectorDebuggerAgent.cpp:
2946 (Inspector::breakpointActionTypeForString): Use Inspector::Protocol::InspectorHelpers.
2947 * inspector/scripts/codegen/cpp_generator.py:
2948 (CppGenerator.helpers_namespace): Return the namespace name that should be used for the helper methods.
2949 * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
2950 (CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain): Use
2951 CppGenerator.helpers_namespace() to use the right namespace when using getEnumConstantValue().
2952 (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): Ditto.
2953 * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
2954 (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event): Ditto.
2955 * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
2956 (CppProtocolTypesHeaderGenerator.generate_output): Move declaration of getEnumConstantValue to a helper function.
2957 (_generate_enum_constant_value_conversion_methods): Do not emit any code if there aren't enums and ensure all
2958 conversion methods are declared inside the helpers namespace.
2959 (_generate_builder_setter_for_member): Use CppGenerator.helpers_namespace() to use the right namespace when
2960 using getEnumConstantValue().
2961 (_generate_unchecked_setter_for_member): Ditto.
2962 (_generate_declarations_for_enum_conversion_methods): Return a list instead of a string so that we can return an
2963 empty list in case of not emitting any code. The caller will use extend() that has no effect when an empty list
2965 * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
2966 (CppProtocolTypesImplementationGenerator.generate_output): Use the new helper function to generate both the enum
2967 mapping and conversion methods inside the helpers namespace.
2968 (CppProtocolTypesImplementationGenerator._generate_enum_mapping): Return a list instead of a string so that we
2969 can return an empty list in case of not emitting any code.
2970 (CppProtocolTypesImplementationGenerator._generate_enum_mapping_and_conversion_methods): Ensure we only emit
2971 code when there are enum values, and it's generated inside the helpers namespace.
2972 * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2973 * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2974 * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
2975 * inspector/scripts/tests/expected/enum-values.json-result:
2976 * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2977 * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
2978 * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
2979 * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
2980 * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
2981 * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
2982 * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
2983 * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
2984 * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
2986 2016-04-04 Csaba Osztrogonác <ossy@webkit.org>
2988 Unreviewed ARM buildfix after r198981.
2990 * assembler/MacroAssemblerARM.h:
2991 (JSC::MacroAssemblerARM::roundTowardZeroDouble):
2993 2016-04-03 Saam barati <sbarati@apple.com>
2995 Implement Annex B.3.3 function hoisting rules for function code
2996 https://bugs.webkit.org/show_bug.cgi?id=155672
2998 Reviewed by Geoffrey Garen.
3000 The spec states that functions declared inside a function
3001 inside a block scope are subject to the rules of Annex B.3.3:
3002 https://tc39.github.io/ecma262/#sec-block-level-function-declarations-web-legacy-compatibility-semantics
3004 The rule states that functions declared in such blocks should
3005 be local bindings of the block. If declaring the function's name
3006 as a "var" in the function would not lead to a syntax error (i.e,
3007 if we don't have a let/const/class variable with the same name)
3008 and if we don't have a parameter with the same name, then we
3009 implictly also declare the funcion name as a "var". When evaluating
3010 the block statement we bind the hoisted "var" to be the value
3011 of the local function binding.
3013 There is one more thing we do for web compatibility. We allow
3014 function declarations inside if/else statements that aren't
3015 blocks. For such statements, we transform the code as if the
3016 function were declared inside a block statement. For example:
3017 ``` function foo() { if (cond) function baz() { } }```
3018 is transformed into:
3019 ``` function foo() { if (cond) { function baz() { } } }```
3021 * bytecompiler/BytecodeGenerator.cpp:
3022 (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
3023 (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
3024 * bytecompiler/BytecodeGenerator.h:
3026 (JSC::ScopeNode::ScopeNode):
3027 (JSC::ProgramNode::ProgramNode):
3028 (JSC::ModuleProgramNode::ModuleProgramNode):
3029 (JSC::EvalNode::EvalNode):
3030 (JSC::FunctionNode::FunctionNode):
3032 (JSC::ScopeNode::hasCapturedVariables):
3033 (JSC::ScopeNode::captures):
3034 (JSC::ScopeNode::hasSloppyModeHoistedFunction):
3035 (JSC::ScopeNode::varDeclarations):
3036 (JSC::ProgramNode::startColumn):
3037 (JSC::ProgramNode::endColumn):
3038 (JSC::EvalNode::startColumn):
3039 (JSC::EvalNode::endColumn):
3040 (JSC::ModuleProgramNode::startColumn):
3041 (JSC::ModuleProgramNode::endColumn):
3042 * parser/Parser.cpp:
3043 (JSC::Parser<LexerType>::Parser):
3044 (JSC::Parser<LexerType>::parseInner):
3045 (JSC::Parser<LexerType>::didFinishParsing):
3046 (JSC::Parser<LexerType>::parseStatement):
3047 (JSC::Parser<LexerType>::parseIfStatement):
3049 (JSC::Scope::declareVariable):
3050 (JSC::Scope::declareFunction):
3051 (JSC::Scope::addSloppyModeHoistableFunctionCandidate):
3052 (JSC::Scope::appendFunction):
3053 (JSC::Scope::declareParameter):
3054 (JSC::Scope::mergeInnerArrowFunctionFeatures):
3055 (JSC::Scope::getSloppyModeHoistedFunctions):
3056 (JSC::Scope::getCapturedVars):
3057 (JSC::ScopeRef::containingScope):
3058 (JSC::ScopeRef::operator==):
3059 (JSC::ScopeRef::operator!=):
3060 (JSC::Parser::declareFunction):
3061 (JSC::Parser::hasDeclaredVariable):
3062 (JSC::Parser::isFunctionMetadataNode):
3063 (JSC::Parser::DepthManager::DepthManager):
3064 (JSC::Parser<LexerType>::parse):
3065 * parser/VariableEnvironment.h:
3066 (JSC::VariableEnvironmentEntry::isImported):
3067 (JSC::VariableEnvironmentEntry::isImportedNamespace):
3068 (JSC::VariableEnvironmentEntry::isFunction):
3069 (JSC::VariableEnvironmentEntry::isParameter):
3070 (JSC::VariableEnvironmentEntry::isSloppyModeHoistingCandidate):
3071 (JSC::VariableEnvironmentEntry::setIsCaptured):
3072 (JSC::VariableEnvironmentEntry::setIsConst):
3073 (JSC::VariableEnvironmentEntry::setIsImported):
3074 (JSC::VariableEnvironmentEntry::setIsImportedNamespace):
3075 (JSC::VariableEnvironmentEntry::setIsFunction):
3076 (JSC::VariableEnvironmentEntry::setIsParameter):
3077 (JSC::VariableEnvironmentEntry::setIsSloppyModeHoistingCandidate):
3078 (JSC::VariableEnvironmentEntry::clearIsVar):
3079 * runtime/CodeCache.h:
3080 (JSC::SourceCodeValue::SourceCodeValue):
3081 * runtime/JSScope.cpp:
3082 * runtime/JSScope.h:
3084 * tests/stress/sloppy-mode-function-hoisting.js: Added.
3096 (test.switch.case.0):
3128 2016-04-03 Yusuke Suzuki <utatane.tea@gmail.com>
3130 Unreviewed, turn ES6 for-in loop test success
3131 https://bugs.webkit.org/show_bug.cgi?id=155451
3135 2016-04-03 Yusuke Suzuki <utatane.tea@gmail.com>
3137 [JSC] Add truncate operation (rounding to zero)
3138 https://bugs.webkit.org/show_bug.cgi?id=156072
3140 Reviewed by Saam Barati.
3142 Add TruncIntrinsic for Math.trunc. DFG handles it as ArithTrunc.
3143 In DFG, ArithTrunc behaves similar to ArithRound, ArithCeil, and ArithFloor.
3144 ArithTrunc rounds the value towards zero.
3146 And we rewrite @toInteger to use @trunc instead of @abs, @floor, negation and branch.
3147 This is completely the same to what we do in JSValue::toInteger.
3149 Since DFG recognize it, DFG can convert ArithTrunc to Identity if the given argument is Int32.
3150 This is useful because almost all the argument is Int32 in @toLength -> @toInteger -> @trunc case.
3151 In such cases, we can eliminate trunc() call.
3153 As a bonus, to speed up Math.trunc operation, we use x86 SSE round and frintz in ARM64 for ArithRound.
3154 In DFG, we emit these instructions. In FTL, we use Patchpoint to emit these instructions to avoid adding a new B3 IR.
3156 * assembler/MacroAssemblerARM64.h:
3157 (JSC::MacroAssemblerARM64::roundTowardZeroDouble):
3158 (JSC::MacroAssemblerARM64::roundTowardZeroFloat):
3159 * assembler/MacroAssemblerARMv7.h:
3160 (JSC::MacroAssemblerARMv7::roundTowardZeroDouble):
3161 * assembler/MacroAssemblerMIPS.h:
3162 (JSC::MacroAssemblerMIPS::roundTowardZeroDouble):
3163 * assembler/MacroAssemblerSH4.h:
3164 (JSC::MacroAssemblerSH4::roundTowardZeroDouble):
3165 * assembler/MacroAssemblerX86Common.h:
3166 (JSC::MacroAssemblerX86Common::roundTowardZeroDouble):
3167 (JSC::MacroAssemblerX86Common::roundTowardZeroFloat):
3168 * builtins/GlobalObject.js:
3170 * dfg/DFGAbstractInterpreterInlines.h:
3171 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3172 * dfg/DFGByteCodeParser.cpp:
3173 (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
3174 * dfg/DFGClobberize.h:
3175 (JSC::DFG::clobberize):
3176 * dfg/DFGDoesGC.cpp:
3178 * dfg/DFGFixupPhase.cpp:
3179 (JSC::DFG::FixupPhase::fixupNode):
3181 (JSC::DFG::Graph::roundShouldSpeculateInt32):
3183 (JSC::DFG::Node::arithNodeFlags):
3184 (JSC::DFG::Node::hasHeapPrediction):
3185 (JSC::DFG::Node::hasArithRoundingMode):
3186 * dfg/DFGNodeType.h:
3187 * dfg/DFGPredictionPropagationPhase.cpp:
3188 (JSC::DFG::PredictionPropagationPhase::propagate):
3189 * dfg/DFGSafeToExecute.h:
3190 (JSC::DFG::safeToExecute):
3191 * dfg/DFGSpeculativeJIT.cpp:
3192 (JSC::DFG::SpeculativeJIT::compileArithRounding):
3193 * dfg/DFGSpeculativeJIT.h:
3194 * dfg/DFGSpeculativeJIT32_64.cpp:
3195 (JSC::DFG::SpeculativeJIT::compile):
3196 * dfg/DFGSpeculativeJIT64.cpp:
3197 (JSC::DFG::SpeculativeJIT::compile):
3198 * ftl/FTLCapabilities.cpp:
3199 (JSC::FTL::canCompile):
3200 * ftl/FTLLowerDFGToB3.cpp:
3201 (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3202 (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
3203 * ftl/FTLOutput.cpp:
3204 (JSC::FTL::Output::doubleTrunc):
3206 * jit/ThunkGenerators.cpp:
3207 (JSC::truncThunkGenerator):
3208 * jit/ThunkGenerators.h:
3209 * runtime/CommonIdentifiers.h:
3210 * runtime/Intrinsic.h:
3211 * runtime/JSGlobalObject.cpp:
3212 (JSC::JSGlobalObject::init):
3213 * runtime/MathObject.cpp:
3214 (JSC::MathObject::finishCreation):
3215 * runtime/MathObject.h:
3217 (JSC::thunkGeneratorForIntrinsic):
3218 * tests/stress/math-rounding-infinity.js:
3220 * tests/stress/math-rounding-nan.js:
3222 * tests/stress/math-rounding-negative-zero.js:
3224 * tests/stress/math-trunc-arith-rounding-mode.js: Added.
3225 (firstCareAboutZeroSecondDoesNot):
3226 (firstDoNotCareAboutZeroSecondDoes):
3228 (verifyNegativeZeroIsPreserved):
3229 * tests/stress/math-trunc-basics.js: Added.
3230 (mathTruncOnIntegers):
3231 (mathTruncOnDoubles):
3232 (mathTruncOnBooleans):
3234 (mathTruncWithOverflow):
3235 (mathTruncConsumedAsDouble):
3236 (mathTruncDoesNotCareAboutMinusZero):
3237 (mathTruncNoArguments):
3238 (mathTruncTooManyArguments):
3239 (testMathTruncOnConstants):
3240 (mathTruncStructTransition):
3242 * tests/stress/math-trunc-should-be-truncate.js: Added.
3245 2016-04-03 Skachkov Oleksandr <gskachkov@gmail.com>
3247 [ES6] Class syntax. Access to new.target inside of the eval should not lead to SyntaxError
3248 https://bugs.webkit.org/show_bug.cgi?id=155545
3250 Reviewed by Saam Barati.
3252 Current patch allow to invoke new.target in eval if this eval is executed within function,
3253 otherwise this will lead to Syntax error
3255 * bytecode/EvalCodeCache.h:
3256 (JSC::EvalCodeCache::getSlow):
3257 * bytecode/ExecutableInfo.h:
3258 (JSC::ExecutableInfo::ExecutableInfo):
3259 (JSC::ExecutableInfo::evalContextType):
3260 * bytecode/UnlinkedCodeBlock.cpp:
3261 (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
3262 * bytecode/UnlinkedCodeBlock.h:
3263 (JSC::UnlinkedCodeBlock::evalContextType):
3264 * bytecode/UnlinkedFunctionExecutable.cpp:
3265 (JSC::generateUnlinkedFunctionCodeBlock):
3266 * debugger/DebuggerCallFrame.cpp:
3267 (JSC::DebuggerCallFrame::evaluate):
3268 * interpreter/Interpreter.cpp:
3270 * parser/Parser.cpp:
3271 (JSC::Parser<LexerType>::Parser):
3272 (JSC::Parser<LexerType>::parseMemberExpression):
3274 (JSC::Scope::Scope):
3275 (JSC::Scope::setEvalContextType):
3276 (JSC::Scope::evalContextType):
3278 * runtime/CodeCache.cpp:
3279 (JSC::CodeCache::getGlobalCodeBlock):
3280 (JSC::CodeCache::getProgramCodeBlock):
3281 (JSC::CodeCache::getEvalCodeBlock):
3282 (JSC::CodeCache::getModuleProgramCodeBlock):
3283 * runtime/CodeCache.h:
3284 * runtime/Executable.cpp:
3285 (JSC::ScriptExecutable::ScriptExecutable):
3286 (JSC::EvalExecutable::create):
3287 (JSC::EvalExecutable::EvalExecutable):
3288 (JSC::ProgramExecutable::ProgramExecutable):
3289 (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
3290 (JSC::FunctionExecutable::FunctionExecutable):
3291 * runtime/Executable.h:
3292 (JSC::ScriptExecutable::evalContextType):
3293 * runtime/JSGlobalObject.cpp:
3294 (JSC::JSGlobalObject::createEvalCodeBlock):
3295 * runtime/JSGlobalObjectFunctions.cpp:
3296 (JSC::globalFuncEval):
3297 * tests/stress/arrowfunction-lexical-bind-newtarget.js:
3298 * tests/stress/new-target.js:
3300 2016-04-02 Commit Queue <commit-queue@webkit.org>
3302 Unreviewed, rolling out r198976.
3303 https://bugs.webkit.org/show_bug.cgi?id=156140
3305 "Causes js/regress/array-nonarray-polymorhpic-access.html to
3306 crash." (Requested by ddkilzer on #webkit).
3310 "[JSC] Initialize SSA's live values at tail lazily"
3311 https://bugs.webkit.org/show_bug.cgi?id=156126
3312 http://trac.webkit.org/changeset/198976
3314 2016-04-02 Benjamin Poulain <bpoulain@apple.com>
3316 [JSC] Initialize SSA's live values at tail lazily
3317 https://bugs.webkit.org/show_bug.cgi?id=156126
3319 Reviewed by Mark Lam.
3321 Setting up the clean state early looks harmless but it is
3322 actually quite expensive.
3324 The problem is AbstractValue is gigantic, you really want
3325 to minimize how much you touch that memory.
3327 By removing the initialization, most blocks only
3328 get 2 or 3 accesses. Once to setup the value, and a few
3329 queries for merging the current block with the successors.
3331 * dfg/DFGInPlaceAbstractState.cpp:
3332 (JSC::DFG::InPlaceAbstractState::endBasicBlock):
3333 (JSC::DFG::setLiveValues): Deleted.
3334 (JSC::DFG::InPlaceAbstractState::initialize): Deleted.
3336 2016-04-02 Benjamin Poulain <bpoulain@apple.com>
3338 [JSC] Add an option to avoid disassembling baseline code for the JSC Profiler
3339 https://bugs.webkit.org/show_bug.cgi?id=156127
3341 Reviewed by Mark Lam.
3343 The profiler run out of memory on big programs if you dump
3344 the baseline disassembly.
3347 (JSC::JIT::privateCompile):
3348 * runtime/Options.h:
3350 2016-04-02 Dan Bernstein <mitz@apple.com>
3352 jsc binary embedded in relocatable JavaScriptCore.framework links against system JavaScriptCore.framework
3353 https://bugs.webkit.org/show_bug.cgi?id=156134
3354 <rdar://problem/25443824>
3356 Reviewed by Mark Lam.
3358 * Configurations/JSC.xcconfig: Define WK_RELOCATABLE_FRAMEWORKS_LDFLAGS when building
3359 relocatable frameworks to include a -dyld_env option setting DYLD_FRAMEWORK_PATH to point
3360 to the directory containing JavaScript.framework, and add
3361 WK_RELOCATABLE_FRAMEWORKS_LDFLAGS to OTHER_LDFLAGS.
3363 2016-04-01 Benjamin Poulain <bpoulain@apple.com>
3365 [JSC][x86] Add the 3 operands form of floating point substraction
3366 https://bugs.webkit.org/show_bug.cgi?id=156095
3368 Reviewed by Geoffrey Garen.
3370 Same old, same old. Add the AVX form of subsd and subss.
3372 Unfortunately, we cannot benefit from the 3 register form
3373 in B3 yet because the Air script does not support CPU flags yet.
3374 That can be fixed later.
3376 * assembler/MacroAssemblerX86Common.h:
3377 (JSC::MacroAssemblerX86Common::subDouble):
3378 (JSC::MacroAssemblerX86Common::subFloat):
3379 * assembler/X86Assembler.h:
3380 (JSC::X86Assembler::vsubsd_rr):
3381 (JSC::X86Assembler::subsd_mr):
3382 (JSC::X86Assembler::vsubsd_mr):
3383 (JSC::X86Assembler::vsubss_rr):
3384 (JSC::X86Assembler::subss_mr):
3385 (JSC::X86Assembler::vsubss_mr):
3386 (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
3387 * b3/air/AirOpcode.opcodes:
3389 2016-04-01 Alberto Garcia <berto@igalia.com>
3391 [JSC] Missing PATH_MAX definition
3392 https://bugs.webkit.org/show_bug.cgi?id=156102
3394 Reviewed by Yusuke Suzuki.
3396 Not all systems define PATH_MAX, so add a fallback value that is
3401 2016-03-31 Benjamin Poulain <bpoulain@apple.com>
3403 [JSC] CFA's valuesAtHead should be a list, not a map
3404 https://bugs.webkit.org/show_bug.cgi?id=156087
3406 Reviewed by Mark Lam.
3408 One more step toward moving to the Air-style of liveness analysis:
3410 Make DFG's valuesAtHead a list of Node*-AbstractValue.
3411 This patch alone is already a speedup because our many CFAs
3412 spend an unreasonable amount of time updating at block boundaries.
3414 * dfg/DFGBasicBlock.h:
3415 * dfg/DFGCFAPhase.cpp:
3416 (JSC::DFG::CFAPhase::performBlockCFA):
3418 (JSC::DFG::Graph::dump):
3419 * dfg/DFGInPlaceAbstractState.cpp:
3420 (JSC::DFG::InPlaceAbstractState::beginBasicBlock):
3421 (JSC::DFG::setLiveValues):
3422 (JSC::DFG::InPlaceAbstractState::merge):
3424 (JSC::DFG::nodeValuePairComparator):
3425 (JSC::DFG::nodeValuePairListDump):
3427 2016-03-31 Saam barati <sbarati@apple.com>
3429 Revert rewrite const as var workaround
3430 https://bugs.webkit.org/show_bug.cgi?id=155393
3432 Reviewed by Mark Lam.
3435 (JSC::Parser::next):
3436 (JSC::Parser::nextExpectIdentifier):
3438 (JSC::VM::setShouldRewriteConstAsVar): Deleted.
3439 (JSC::VM::shouldRewriteConstAsVar): Deleted.
3441 2016-03-31 Saam barati <sbarati@apple.com>
3443 [ES6] Disallow var assignments in for-in loops
3444 https://bugs.webkit.org/show_bug.cgi?id=155451
3446 Reviewed by Mark Lam.
3448 We're doing this in its own patch instead of the patch for https://bugs.webkit.org/show_bug.cgi?id=155384
3449 because last time we made this change it broke some websites. Lets try making
3450 it again because it's what the ES6 mandates. If it still breaks things we will
3453 * parser/Parser.cpp:
3454 (JSC::Parser<LexerType>::parseForStatement):
3456 2016-03-31 Saam barati <sbarati@apple.com>
3458 parsing arrow function expressions slows down the parser by 8% lets recoup some loss
3459 https://bugs.webkit.org/show_bug.cgi?id=155988
3461 Reviewed by Benjamin Poulain.
3463 We used to eagerly check if we're parsing an arrow function.
3464 We did this inside parseAssignmentExpression(), and it was
3465 very costly. The reason it was costly is that arrow functions
3466 might start with an identifier. This means anytime we saw an
3467 identifier we would have to do a lookahead, and then most likely
3468 backtrack because more often than not, we wouldn't see "=>"
3471 In this patch I implement a new approach. We just parse
3472 the lhs of an assignment expression eagerly without doing any
3473 lookahead. Retroactively, if we see that we might have started
3474 with an arrow function, and we don't have a valid lhs or the
3475 next token is a "=>", we try to parse as an arrow function.
3477 Here are a few examples motivating why this is valid:
3481 - "x" is a valid arrow function starting point.
3482 - "x" also happens to be a valid lhs
3483 - because we see "=>" as the next token, we parse as an arrow function and succeed.
3487 - "(" is a valid arrow function starting point.
3488 - "(x)" also happens to be a valid lhs
3489 - because we see "=>" as the next token, we parse as an arrow function and succeed.
3493 - "(" is a valid arrow function starting point.
3494 - "({x = 30})" is NOT a valid lhs. Because of this, we try to parse it as an arrow function and succeed.
3496 There is one interesting implementation detail where we might
3497 parse something that is both a valid LHS but happens
3498 to actually be the arrow function parameters. The valid LHS
3499 parsing might declare such variables as "uses" which would cause
3500 weird capture analysis. This patch also introduces a mechanism
3501 to backtrack on used variable analysis.
3503 This is a 3.5%-4.5% octane code load speedup.
3506 (JSC::Lexer::sawError):
3507 (JSC::Lexer::setSawError):
3508 (JSC::Lexer::getErrorMessage):
3509 (JSC::Lexer::setErrorMessage):
3510 (JSC::Lexer::sourceURL):
3511 (JSC::Lexer::sourceMappingURL):
3512 * parser/Parser.cpp:
3513 (JSC::Parser<LexerType>::isArrowFunctionParameters):
3514 (JSC::Parser<LexerType>::parseAssignmentExpression):
3515 (JSC::Parser<LexerType>::parsePrimaryExpression):
3517 (JSC::Scope::Scope):
3518 (JSC::Scope::startSwitch):
3519 (JSC::Scope::declareParameter):
3520 (JSC::Scope::usedVariablesContains):
3521 (JSC::Scope::useVariable):
3522 (JSC::Scope::pushUsedVariableSet):
3523 (JSC::Scope::currentUsedVariablesSize):
3524 (JSC::Scope::revertToPreviousUsedVariables):
3525 (JSC::Scope::setNeedsFullActivation):
3526 (JSC::Scope::needsFullActivation):
3527 (JSC::Scope::isArrowFunctionBoundary):
3528 (JSC::Scope::setInnerArrowFunctionUsesEvalAndUseArgumentsIfNeeded):
3529 (JSC::Scope::collectFreeVariables):
3530 (JSC::Scope::fillParametersForSourceProviderCache):
3531 (JSC::Scope::restoreFromSourceProviderCache):
3532 (JSC::Scope::setIsModule):
3534 2016-03-31 Yusuke Suzuki <utatane.tea@gmail.com>
3536 Fails to build in Linux / PowerPC due to different ucontext_t definition
3537 https://bugs.webkit.org/show_bug.cgi?id=156015
3539 Reviewed by Michael Catanzaro.
3541 PPC does not have mcontext_t in ucontext_t::uc_mcontext.
3542 So we take the special way to retrieve mcontext_t in PPC.
3544 * heap/MachineStackMarker.cpp:
3545 (pthreadSignalHandlerSuspendResume):
3547 2016-03-31 Benjamin Poulain <benjamin@webkit.org>
3549 [JSC][x86] Add the indexed forms of floating point addition and multiplication
3550 https://bugs.webkit.org/show_bug.cgi?id=156058
3552 Reviewed by Geoffrey Garen.
3554 B3 supports lowering [base, index] addresses into
3555 arbitrary instructions but we were not using that feature.
3557 This patch adds the missing support for the lowering
3560 * assembler/MacroAssemblerX86Common.h:
3561 (JSC::MacroAssemblerX86Common::addDouble):
3562 (JSC::MacroAssemblerX86Common::addFloat):
3563 (JSC::MacroAssemblerX86Common::mulDouble):
3564 (JSC::MacroAssemblerX86Common::mulFloat):
3565 * assembler/X86Assembler.h:
3566 (JSC::X86Assembler::addsd_mr):
3567 (JSC::X86Assembler::vaddsd_mr):
3568 (JSC::X86Assembler::addss_mr):
3569 (JSC::X86Assembler::vaddss_mr):
3570 (JSC::X86Assembler::mulsd_mr):
3571 (JSC::X86Assembler::vmulsd_mr):
3572 (JSC::X86Assembler::mulss_mr):
3573 (JSC::X86Assembler::vmulss_mr):
3574 (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
3575 * b3/B3LowerToAir.cpp:
3576 (JSC::B3::Air::LowerToAir::appendBinOp):
3577 Unlike the Addr form, we never need to transform a Tmp
3578 into an Index for spilling.
3580 Instead of duplicating all the code in MacroAssembler, I can
3581 just have the lowering phase try using addresses for the first
3582 argument when possible.
3584 * b3/air/AirOpcode.opcodes:
3585 * b3/air/testair.cpp:
3586 (JSC::B3::Air::testX86VMULSDBaseNeedsRex):
3587 (JSC::B3::Air::testX86VMULSDIndexNeedsRex):
3588 (JSC::B3::Air::testX86VMULSDBaseIndexNeedRex):
3589 (JSC::B3::Air::run):
3591 2016-03-31 Saam barati <sbarati@apple.com>
3593 DFG JIT bug in typeof constant folding where the input to typeof is an object or function
3594 https://bugs.webkit.org/show_bug.cgi?id=156034
3595 <rdar://problem/25446785>
3597 Reviewed by Ryosuke Niwa.
3599 AI would constant fold TypeOf to the string "object" if it saw that
3600 its input type didn't expand past the types contained in the set
3601 "SpecObject - SpecObjectOther". But, SpecObject contains SpecFunction.
3602 And typeof of a function should return "function". This patch fixes
3603 this bug by making sure we constant fold to object iff the type
3604 doesn't expand past the set "SpecObject - SpecObjectOther - SpecFunction".
3606 * dfg/DFGAbstractInterpreterInlines.h:
3607 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3608 * tests/stress/typeof-dfg-function-or-object.js: Added.
3613 2016-03-31 Mark Lam <mark.lam@apple.com>
3615 Gardening: Build and logic fix after r198873.
3616 https://bugs.webkit.org/show_bug.cgi?id=156043
3620 * assembler/MacroAssemblerX86Common.h:
3621 (JSC::MacroAssemblerX86Common::addFloat):
3622 - 2 args were meant to be ordered differently in order to call the other addFloat.
3623 Instead, there was an infinite recursion bug. This is now fixed.
3625 2016-03-30 Benjamin Poulain <benjamin@webkit.org>
3627 [JSC][x86] Add the 3 operands forms of floating point addition and multiplication
3628 https://bugs.webkit.org/show_bug.cgi?id=156043
3630 Reviewed by Geoffrey Garen.
3632 When they are available, VADD and VMUL are better options to lower
3633 floating point addition and multiplication.
3635 In the simple cases when one of the operands is aliased to the destination,
3636 those forms have the same size or 1 byte shorter depending on the registers.
3638 In the more advanced cases, we gain nice advantages with the new forms:
3639 -We can get rid of the MoveDouble in front the instruction when we cannot
3641 -We can disable aliasing entirely in Air. That is useful for latency
3642 since computing coalescing is not exactly cheap.
3644 * assembler/MacroAssemblerX86Common.cpp:
3645 * assembler/MacroAssemblerX86Common.h:
3646 (JSC::MacroAssemblerX86Common::and32):
3647 (JSC::MacroAssemblerX86Common::mul32):
3648 (JSC::MacroAssemblerX86Common::or32):
3649 (JSC::MacroAssemblerX86Common::xor32):
3650 (JSC::MacroAssemblerX86Common::branchAdd32):
3651 The change in B3LowerToAir exposed a bug in the fake 3 operands
3652 forms of those instructions. If the address is equal to
3653 the destination, we were nuking the address.
3656 Add32([%r11], %eax, %r11)
3662 I updated codegen of those cases to support that case through
3666 The weird case were all arguments have the same registers
3669 (JSC::MacroAssemblerX86Common::addDouble):
3670 (JSC::MacroAssemblerX86Common::addFloat):
3671 (JSC::MacroAssemblerX86Common::mulDouble):
3672 (JSC::MacroAssemblerX86Common::mulFloat):
3673 (JSC::MacroAssemblerX86Common::supportsFloatingPointRounding):
3674 (JSC::MacroAssemblerX86Common::supportsAVX):
3675 (JSC::MacroAssemblerX86Common::updateEax1EcxFlags):
3676 * assembler/MacroAssemblerX86_64.h:
3677 (JSC::MacroAssemblerX86_64::branchAdd64):
3678 * assembler/X86Assembler.h:
3679 (JSC::X86Assembler::vaddsd_rr):
3680 (JSC::X86Assembler::vaddsd_mr):
3681 (JSC::X86Assembler::vaddss_rr):
3682 (JSC::X86Assembler::vaddss_mr):
3683 (JSC::X86Assembler::vmulsd_rr):
3684 (JSC::X86Assembler::vmulsd_mr):
3685 (JSC::X86Assembler::vmulss_rr):
3686 (JSC::X86Assembler::vmulss_mr):
3687 (JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
3688 * b3/B3LowerToAir.cpp:
3689 (JSC::B3::Air::LowerToAir::appendBinOp):
3690 Add the 3 operand forms so that we lower Add and Mul
3691 to the best form directly.
3693 I will change how we lower the fake 3 operands instructions
3694 but the codegen should end up the same in most cases.
3695 The new codegen is the load32 + op above.
3697 * b3/air/AirInstInlines.h:
3698 (JSC::B3::Air::Inst::shouldTryAliasingDef):
3699 * b3/air/testair.cpp:
3700 (JSC::B3::Air::testX86VMULSD):
3701 (JSC::B3::Air::testX86VMULSDDestRex):
3702 (JSC::B3::Air::testX86VMULSDOp1DestRex):
3703 (JSC::B3::Air::testX86VMULSDOp2DestRex):
3704 (JSC::B3::Air::testX86VMULSDOpsDestRex):
3705 (JSC::B3::Air::testX86VMULSDAddr):
3706 (JSC::B3::Air::testX86VMULSDAddrOpRexAddr):
3707 (JSC::B3::Air::testX86VMULSDDestRexAddr):
3708 (JSC::B3::Air::testX86VMULSDRegOpDestRexAddr):
3709 (JSC::B3::Air::testX86VMULSDAddrOpDestRexAddr):
3710 Make sure we have some coverage for AVX encoding of instructions.
3712 2016-03-30 Saam Barati <sbarati@apple.com>
3714 Change some release asserts in CodeBlock linking into debug asserts
3715 https://bugs.webkit.org/show_bug.cgi?id=155500
3717 Reviewed by Filip Pizlo.
3719 * bytecode/CodeBlock.cpp:
3720 (JSC::CodeBlock::finishCreation):
3722 2016-03-30 Joseph Pecoraro <pecoraro@apple.com>
3724 Remove unused ScriptProfiler.Samples.totalTime
3725 https://bugs.webkit.org/show_bug.cgi?id=156002
3727 Reviewed by Saam Barati.
3729 * inspector/agents/InspectorScriptProfilerAgent.cpp:
3730 (Inspector::buildSamples):
3731 (Inspector::InspectorScriptProfilerAgent::trackingComplete):
3732 * inspector/protocol/ScriptProfiler.json:
3735 * runtime/SamplingProfiler.cpp:
3736 (JSC::SamplingProfiler::SamplingProfiler): Deleted.
3737 * runtime/SamplingProfiler.h:
3738 (JSC::SamplingProfiler::totalTime): Deleted.
3739 Remove now unused m_totalTime.
3741 2016-03-30 Michael Saboff <msaboff@apple.com>
3743 [ES6] Quantified unicode regular expressions do not work for counts greater than 1
3744 https://bugs.webkit.org/show_bug.cgi?id=156044
3746 Reviewed by Mark Lam.
3748 Fixed incorrect indexing of non-BMP characters in fixed patterns. The old code
3749 was indexing by character units, a single JS character, instead of code points
3750 which is 2 JS characters.
3752 * yarr/YarrInterpreter.cpp:
3753 (JSC::Yarr::Interpreter::matchDisjunction):
3755 2016-03-30 Mark Lam <mark.lam@apple.com>
3757 Make the $vm debugging tools available to builtins as @$vm.
3758 https://bugs.webkit.org/show_bug.cgi?id=156012
3760 Reviewed by Saam Barati.
3762 We also need some debugging tools for builtin development. The $vm object will
3763 be made available to builtins as @$vm, which gives us, amongst many goodies,
3764 @$vm.print() (which prints the toString() values of its args) and
3765 @$vm.printValue() (which dataLogs its arg as a JSValue). @$vm will only be
3766 available if we run with JSC_useDollarVM=true.
3768 Also changed @$vm.print() to not automatically insert a space between the
3769 printing of each of its args. This makes it clearer as to what will be printed
3770 i.e. it will only print what is passed to it.
3772 * builtins/BuiltinNames.h:
3773 (JSC::BuiltinNames::BuiltinNames):
3774 (JSC::BuiltinNames::dollarVMPublicName):
3775 (JSC::BuiltinNames::dollarVMPrivateName):
3776 * runtime/JSGlobalObject.cpp:
3777 (JSC::JSGlobalObject::init):
3778 * tools/JSDollarVMPrototype.cpp:
3779 (JSC::functionPrint):
3781 2016-03-30 Keith Miller <keith_miller@apple.com>
3783 Unreviewed, buildfix.
3785 * bytecode/BytecodeIntrinsicRegistry.h:
3787 2016-03-30 Keith Miller <keith_miller@apple.com>
3789 Unreviewed, rollout r198808. The patch causes crashes on 32-bit and appears to be a JSBench regression.
3791 2016-03-30 Yusuke Suzuki <utatane.tea@gmail.com>
3793 [JSC] Implement String.prototype.repeat in builtins JS
3794 https://bugs.webkit.org/show_bug.cgi?id=155974
3796 Reviewed by Darin Adler.
3798 This patch converts C++ String.prototype.repeat implementation into JS builtins.
3799 |this| in strict mode is correctly inferred as String[1]. This fact encourages us
3800 to write PrimitiveTypes.prototype.XXX methods in builtin JS.
3802 LayoutTests/js/string-repeat.html already covers the tests for this change.
3804 Note: String.prototype.repeat functionality is similar to Harmony's
3805 String.prototype.{padStart, padEnd}. It's nice to port them to builtin JS in
3808 The existing C++ code has the fast path for singleCharacterString repeating.
3809 Since this use is important (e.g. generating N length spaces: ' '.repeat(N)),
3810 we keep this fast path as @repeatCharacter().
3812 The performance results show that, while the performance of the single character fast path
3813 is neutral, other string repeating has significant speed up.
3814 There are two reasons.
3816 1. Not resolving string rope.
3818 We added several tests postfixed "not-resolving". In that tests, we do not touch the content
3819 of the generated string. As a result, the generated rope is not resolved.
3821 2. O(log N) intermediate JSRopeStrings.
3823 In the existing C++ implementation, we use JSString::RopeBuilder. We iterate N times and append
3824 the given string to the builder.
3825 In this case, the intermediate rope strings generated in JSString::RopeBuilder is O(N).
3826 In JS builtin implementation, we only iterate log N times. As a result, the number of the
3827 intermediate rope strings becomes O(log N).
3829 [1]: http://trac.webkit.org/changeset/195938
3831 * builtins/StringPrototype.js:
3834 * bytecode/BytecodeIntrinsicRegistry.cpp:
3835 (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
3836 * bytecode/BytecodeIntrinsicRegistry.h:
3837 * runtime/CommonIdentifiers.h:
3838 * runtime/JSGlobalObject.cpp:
3839 (JSC::JSGlobalObject::init):
3840 * runtime/StringPrototype.cpp:
3841 (JSC::stringProtoFuncRepeatCharacter):
3842 (JSC::StringPrototype::finishCreation): Deleted.
3843 (JSC::stringProtoFuncRepeat): Deleted.
3844 * runtime/StringPrototype.h:
3845 * tests/stress/string-repeat-edge-cases.js: Added.
3847 (let.object.toString):
3851 2016-03-30 Benjamin Poulain <benjamin@webkit.org>
3854 https://bugs.webkit.org/show_bug.cgi?id=156005
3856 Reviewed by Geoffrey Garen.
3859 * DerivedSources.make:
3860 * JavaScriptCore.xcodeproj/project.pbxproj:
3861 * disassembler/udis86/differences.txt:
3862 * disassembler/udis86/itab.py: Removed.
3863 * disassembler/udis86/optable.xml:
3864 * disassembler/udis86/ud_itab.py: Added.
3865 * disassembler/udis86/ud_opcode.py:
3866 * disassembler/udis86/ud_optable.py: Removed.
3867 * disassembler/udis86/udis86.c:
3868 * disassembler/udis86/udis86_decode.c:
3869 * disassembler/udis86/udis86_decode.h:
3870 * disassembler/udis86/udis86_extern.h:
3871 * disassembler/udis86/udis86_input.c: Removed.
3872 * disassembler/udis86/udis86_input.h: Removed.
3873 * disassembler/udis86/udis86_syn-att.c:
3874 * disassembler/udis86/udis86_syn.h:
3875 * disassembler/udis86/udis86_types.h:
3876 * disassembler/udis86/udis86_udint.h:
3878 2016-03-30 Benjamin Poulain <bpoulain@apple.com>
3880 [JSC] Get rid of operationInitGlobalConst(), it is useless
3881 https://bugs.webkit.org/show_bug.cgi?id=156010
3883 Reviewed by Geoffrey Garen.
3885 * jit/JITOperations.cpp:
3886 * jit/JITOperations.h:
3888 2016-03-29 Saam barati <sbarati@apple.com>
3890 Fix typos in our error messages and remove some trailing periods
3891 https://bugs.webkit.org/show_bug.cgi?id=155985
3893 Reviewed by Mark Lam.