1 2015-08-30 Yusuke Suzuki <utatane.tea@gmail.com>
3 [ES6] JSON.stringify should ignore object properties that have symbol values and convert the symbol values in array to null
4 https://bugs.webkit.org/show_bug.cgi?id=148628
6 Reviewed by Saam Barati.
10 1. JSON.stringify should ignore object properties that have symbol values.
12 SerializeJSONProperty[1] will return undefined if the value of the property is a symbol.
13 In this case, SerializeJSONObject[2] does not append any string for this property.
15 2. JSON.stringify should convert the symbol values in array to null
17 As the same to the object case, SerializeJSONProperty will return undefined if the value of the property is a symbol.
18 But in the case of arrays, if the result of SerializeJSONProperty is undefined, it will emit "null"[3].
19 This behavior is already implemented in the existing JSON.stringify. Added tests to ensure that.
21 [1]: http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonproperty
22 [2]: http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonobject
23 [3]: http://www.ecma-international.org/ecma-262/6.0/#sec-serializejsonarray
25 * runtime/JSONObject.cpp:
26 (JSC::unwrapBoxedPrimitive):
27 (JSC::Stringifier::appendStringifiedValue):
28 (JSC::Stringifier::Holder::appendNextProperty):
29 * tests/stress/symbol-with-json.js:
32 2015-08-30 Filip Pizlo <fpizlo@apple.com>
34 JSC property attributes should fit in a byte
35 https://bugs.webkit.org/show_bug.cgi?id=148611
37 Reviewed by Sam Weinig.
39 I want to make room in PropertyMapEntry for more things to support property type inference (see
40 https://bugs.webkit.org/show_bug.cgi?id=148610). The most obvious candidate for a size reduction is
41 attributes, since we only have a small number of attribute bits. Even without complex changes, it
42 would have been possible to reduce the attribute field from 32 bits to 16 bits. Specifically, prior
43 to this change, the attributes field needed 9 bits. This made it very tempting to trim it so that
44 it could fit in a byte.
46 Luckily, many of the attributes bits are for the static lookup hashtables that we use for lazily
47 building objects in the standard library. Those bits don't need to stay around after the property
48 has been created, since they are just for telling the code in Lookup how to create the property.
49 So, this change separates the attributes bits into those that are interesting for Structure and
50 those that aren't. The ones used by Structure sit in the low 8 bits, allowing for the attributes
51 field in PropertyMapEntry to be a uint8_t. The attributes bits used only by Lookup use the higher
52 bits. In production, the conversion from the Lookup attributes to the Structure attributes is just
53 a cast to uint8_t. In debug, we assert that those bits are not dropped by accident. Code that
54 intentionally drops those bits calls attributesForStructure().
56 It turned out that there was a lot of code that was using the Function bit even in code that didn't
57 involve Lookup. This change removes those uses of Function. Structure does not need to know if we
58 think that a property points to a function.
61 (GlobalObject::finishCreation):
62 * runtime/JSGlobalObject.cpp:
63 (JSC::JSGlobalObject::init):
66 (JSC::setUpStaticFunctionSlot):
68 (JSC::getStaticPropertySlot):
69 (JSC::getStaticValueSlot):
70 (JSC::reifyStaticProperties):
71 * runtime/MathObject.cpp:
72 (JSC::MathObject::finishCreation):
73 * runtime/NumberConstructor.cpp:
74 (JSC::NumberConstructor::finishCreation):
75 * runtime/PropertySlot.h:
76 (JSC::attributesForStructure):
77 (JSC::PropertySlot::setValue):
78 (JSC::PropertySlot::setCustom):
79 (JSC::PropertySlot::setCacheableCustom):
80 (JSC::PropertySlot::setGetterSlot):
81 (JSC::PropertySlot::setCacheableGetterSlot):
82 * runtime/Structure.h:
83 (JSC::PropertyMapEntry::PropertyMapEntry):
85 2015-08-29 Chris Dumez <cdumez@apple.com>
87 Unreviewed, fix PropertyName::isNull() that was introduced in r188994.
89 The condition was reversed.
91 * runtime/PropertyName.h:
92 (JSC::PropertyName::isNull):
94 2015-08-28 Commit Queue <commit-queue@webkit.org>
96 Unreviewed, rolling out r189136.
97 https://bugs.webkit.org/show_bug.cgi?id=148608
99 Made JSC tests flaky (Requested by ap on #webkit).
103 "[JSC][x86] Improve the compare functions when comparing with
105 https://bugs.webkit.org/show_bug.cgi?id=148536
106 http://trac.webkit.org/changeset/189136
108 2015-08-28 Benjamin Poulain <bpoulain@apple.com>
110 [JSC] Get rid of DFG's MergeMode
111 https://bugs.webkit.org/show_bug.cgi?id=148245
113 Reviewed by Mark Lam.
115 That code has become useless, the merge mode is always MergeToSuccessors.
117 * JavaScriptCore.xcodeproj/project.pbxproj:
118 * dfg/DFGCFAPhase.cpp:
119 (JSC::DFG::CFAPhase::performBlockCFA):
120 * dfg/DFGInPlaceAbstractState.cpp:
121 (JSC::DFG::InPlaceAbstractState::endBasicBlock):
122 * dfg/DFGInPlaceAbstractState.h:
123 * dfg/DFGMergeMode.h: Removed.
125 2015-08-28 Benjamin Poulain <bpoulain@apple.com>
127 [JSC][x86] Improve the compare functions when comparing with zero
128 https://bugs.webkit.org/show_bug.cgi?id=148536
130 Reviewed by Geoffrey Garen.
132 This patch has two parts:
133 1) The macro assembler gets an additional cmp->test optimization
134 for LessThan and GreaterThanOrEqual.
135 Instead of comparing the value with an immediate, test the value
136 with itself and use the flag.
137 2) Extend the DFG JIT optimization of compare.
138 In particular, use the same optimization in compileInt32Compare()
139 as we have in compilePeepHoleBooleanBranch().
140 The generator compileInt32Compare() is unfortunately very
141 common due to MoveHints placed between the Compare node and the Branch
144 * assembler/MacroAssembler.h:
145 (JSC::MacroAssembler::compare32):
146 * assembler/MacroAssemblerX86Common.h:
147 (JSC::MacroAssemblerX86Common::branch32):
148 (JSC::MacroAssemblerX86Common::compare32):
149 * dfg/DFGSpeculativeJIT.cpp:
150 (JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch):
151 * dfg/DFGSpeculativeJIT64.cpp:
152 (JSC::DFG::SpeculativeJIT::compileInt32Compare):
154 2015-08-28 Mark Lam <mark.lam@apple.com>
156 Add MacroAssemblerPrinter support for printing memory.
157 https://bugs.webkit.org/show_bug.cgi?id=148600
159 Reviewed by Saam Barati.
161 Previously, we can dump registers at runtime. Now we can dump memory too.
162 See comment in MacroAssemblerPrinter.h for examples of how to do this.
164 * assembler/MacroAssemblerPrinter.cpp:
166 (JSC::MacroAssemblerPrinter::printCallback):
167 * assembler/MacroAssemblerPrinter.h:
168 (JSC::Memory::Memory):
169 (JSC::MemWord::MemWord):
170 (JSC::MacroAssemblerPrinter::PrintArg::PrintArg):
172 2015-08-28 Khem Raj <raj.khem@gmail.com>
174 JavaScriptCore fails to build using GCC 5
175 https://bugs.webkit.org/show_bug.cgi?id=147815
177 Reviewed by Filip Pizlo.
179 * runtime/JSObject.cpp: Explicitly instantiate all variants of
180 putByIndexBeyondVectorLengthWithAttributes used by JSArray.cpp.
182 2015-08-28 Mark Lam <mark.lam@apple.com>
184 Refactor the JIT printer out of the AbstractMacroAssembler into MacroAssemblerPrinter.
185 https://bugs.webkit.org/show_bug.cgi?id=148595
187 Reviewed by Geoffrey Garen.
190 1. MacroAssembler::print() code (except for the prototype) need no longer be parsed
191 when compiling C++ files that don't need it.
192 2. Adding support for more printable types to MacroAssemblerPrinter::PrintArg
193 triggers recompilation of less files.
194 3. The printing code is for most the part common between all target platforms and
195 was previously duplicated by cut-and-paste to all the varieties of MacroAssemblers
196 that support the MASM_PROBE mechanism. Now, there is only one copy in
197 MacroAssemblerPrinter.
200 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
201 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
202 * JavaScriptCore.xcodeproj/project.pbxproj:
204 * assembler/AbstractMacroAssembler.h:
205 (JSC::AbstractMacroAssembler::ProbeContext::print): Deleted.
206 - Removed this function because it is no longer useful since we have this more
207 flexible print() functionality.
209 (JSC::AbstractMacroAssembler::printIndent): Deleted.
210 (JSC::AbstractMacroAssembler::printCPU): Deleted.
211 (JSC::AbstractMacroAssembler::print): Deleted.
212 (JSC::AbstractMacroAssembler::PrintArg::PrintArg): Deleted.
213 (JSC::AbstractMacroAssembler::appendPrintArg): Deleted.
214 (JSC::AbstractMacroAssembler::printInternal): Deleted.
215 (JSC::AbstractMacroAssembler::printCallback): Deleted.
216 - These got moved into MacroAssemblerPrinter.cpp.
218 * assembler/MacroAssembler.h:
219 * assembler/MacroAssemblerARM.cpp:
220 (JSC::MacroAssemblerARM::printCPURegisters): Deleted.
221 (JSC::MacroAssemblerARM::printRegister): Deleted.
222 * assembler/MacroAssemblerARM.h:
223 * assembler/MacroAssemblerARMv7.cpp:
224 (JSC::MacroAssemblerARMv7::printCPURegisters): Deleted.
225 (JSC::MacroAssemblerARMv7::printRegister): Deleted.
226 * assembler/MacroAssemblerARMv7.h:
227 * assembler/MacroAssemblerX86Common.cpp:
228 (JSC::MacroAssemblerX86Common::printCPURegisters): Deleted.
229 (JSC::MacroAssemblerX86Common::printRegister): Deleted.
230 * assembler/MacroAssemblerX86Common.h:
231 - Deleted a whole bunch of mostly duplicated code.
233 * assembler/MacroAssemblerPrinter.cpp: Added.
236 (JSC::printCPURegisters):
237 (JSC::printRegister):
238 (JSC::MacroAssemblerPrinter::printCallback):
239 * assembler/MacroAssemblerPrinter.h: Added.
240 (JSC::MacroAssemblerPrinter::print):
241 (JSC::MacroAssemblerPrinter::PrintArg::PrintArg):
242 (JSC::MacroAssemblerPrinter::appendPrintArg):
243 (JSC::MacroAssembler::print):
245 2015-08-28 Filip Pizlo <fpizlo@apple.com>
247 LICM should be sound even if the CFG has changed
248 https://bugs.webkit.org/show_bug.cgi?id=148259
250 Reviewed by Benjamin Poulain.
252 Prior to this change, LICM expected a certain CFG shape around a loop: broken critical edges,
253 a pre-header, and the pre-header's terminal has exitOK. LICM would either crash on an
254 assertion, or generate code that fails validation, if these conditions weren't met.
256 The broken critical edge assumption is fine; so far we are assuming that SSA means broken
257 critical edges. We may revisit this, but we don't have to right now.
259 The other assumptions are not fine, because it's hard to guarantee that every phase will
260 preserve the presence of pre-headers. Even if we required that pre-headers are regenerated
261 before LICM, that regeneration wouldn't be guaranteed to create pre-headers that have exitOK at
262 the terminal. That's because once in SSA, the loop header probably has exitOK=false at the
263 head because of Phi's. Pre-header creation has no choice but to use the Node::origin from the
264 loop header, which means creating a pre-header that has exitOK=false. Regardless of whether
265 that's a fixable problem, it seems that our best short-term approach is just to be defensive
266 and turn undesirable pathologies into performance bugs and not crashes.
268 For the foreseeable future, once pre-headers are created they will probably not be removed. Our
269 current CFG simplification phase doesn't have a rule for removing pre-headers (since it doesn't
270 have any jump threading). So, it wouldn't be profitable to put effort towards reneration of
271 pre-headers for LICM's benefit.
273 Also, we cannot guarantee that some sequence of CFG transformations will not create a loop that
274 doesn't have a pre-header. This would be super rare. But you could imagine that some program
275 has control flow encoded using relooping (like
276 https://github.com/kripken/Relooper/blob/master/paper.pdf). If that happens, our compiler will
277 probably incrementally discover the "original" CFG. That may happen only after SSA conversion,
278 and so after pre-header generation. This is super unlikely for a bunch of reasons, but it
281 So, this patch just makes sure that if pre-headers are missing or cannot be exited from, LICM
282 will simply avoid hoisting out of that block. At some point later, we can worry about a more
283 comprehensive solution to the pre-header problem. That's covered by this bug:
284 https://bugs.webkit.org/show_bug.cgi?id=148586
286 * dfg/DFGLICMPhase.cpp:
287 (JSC::DFG::LICMPhase::run):
288 (JSC::DFG::LICMPhase::attemptHoist):
290 (JSC::DFG::Plan::compileInThreadImpl):
292 * tests/stress/licm-no-pre-header.js: Added.
294 * tests/stress/licm-pre-header-cannot-exit.js: Added.
297 2015-08-28 Yusuke Suzuki <utatane.tea@gmail.com>
299 Move std::function from JSFunction into NativeStdFunctionCell to correctly destroy the heap allocated std::function
300 https://bugs.webkit.org/show_bug.cgi?id=148262
302 Reviewed by Filip Pizlo.
304 std::function is heap allocated value. So if this is held in the JSCell, the cell should be destructible.
305 Before this patch, it is held in the JSStdFunction. JSStdFunction is the derived class from the JSFunction,
306 and they are not destructible. So it leaked the memory.
308 This patch extracts std::function field from the JSStdFunction to the NativeStdFunctionCell. NativeStdFunctionCell
309 is responsible for destructing the held std::function.
310 Instead of moving std::function to the ExecutableBase, we move it to the newly created NativeStdFunctionCell cell.
311 The reason is the following.
313 - Each NativeExecutable (in 64_32 JIT environment) has the trampolines to call given host functions.
314 And the address of the host function is directly embedded on the JIT-compiled trampoline code.
315 - To suppress the overuse of the executable memory (which is used to generate the trampoline), NativeExecutable
316 is cached. The host function address is used as the key to look up the cached executable from the table.
317 - In all the JSStdFunction, we use the same host function that immediately calls the each std::function.
318 - As a result, without any change, all the JSStdFunction hit the same cached NativeExecutable even if the held
319 std::function is different.
320 - To solve it, if we put the std::function in the NativeExecutable, we need to add this std::function
321 identity (like address) to the cache key, because the address of the stub host function (that calls the
322 std::function) is the same in the all JSStdFunction.
323 - But since the std::function will be allocated in the heap, this address is always different. So caching has
325 - If we do not cache the NativeExecutable that holds the std::function, each time when creating the JSStdFunction,
326 we need to regenerate the completely same trampolines (since it just calls the same host function stub that
327 calls the std::function).
329 And this patch drops JSArrowFunction::destroy because (1) JSArrowFunction is not destructible and (2) it no longer
330 holds any fields that require destructions.
333 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
334 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
335 * JavaScriptCore.xcodeproj/project.pbxproj:
338 * runtime/JSArrowFunction.cpp:
339 (JSC::JSArrowFunction::destroy): Deleted.
340 * runtime/JSArrowFunction.h:
341 * runtime/JSFunction.cpp:
342 (JSC::JSFunction::lookUpOrCreateNativeExecutable):
343 (JSC::JSFunction::create):
344 (JSC::getNativeExecutable): Deleted.
345 (JSC::JSStdFunction::JSStdFunction): Deleted.
346 (JSC::runStdFunction): Deleted.
347 * runtime/JSFunction.h:
348 * runtime/JSGlobalObject.cpp:
349 (JSC::JSGlobalObject::init):
350 (JSC::JSGlobalObject::visitChildren):
351 * runtime/JSGlobalObject.h:
352 (JSC::JSGlobalObject::nativeStdFunctionStructure):
353 * runtime/JSNativeStdFunction.cpp: Added.
354 (JSC::JSNativeStdFunction::JSNativeStdFunction):
355 (JSC::JSNativeStdFunction::visitChildren):
356 (JSC::JSNativeStdFunction::finishCreation):
357 (JSC::runStdFunction):
358 (JSC::JSNativeStdFunction::create):
359 * runtime/JSNativeStdFunction.h: Copied from Source/JavaScriptCore/runtime/JSArrowFunction.h.
360 (JSC::JSNativeStdFunction::createStructure):
361 (JSC::JSNativeStdFunction::nativeStdFunctionCell):
362 * runtime/NativeStdFunctionCell.cpp: Added.
363 (JSC::NativeStdFunctionCell::create):
364 (JSC::NativeStdFunctionCell::NativeStdFunctionCell):
365 (JSC::NativeStdFunctionCell::destroy):
366 * runtime/NativeStdFunctionCell.h: Added.
367 (JSC::NativeStdFunctionCell::createStructure):
368 (JSC::NativeStdFunctionCell::function):
373 2015-08-28 Sukolsak Sakshuwong <sukolsak@gmail.com>
375 Create WebAssembly functions
376 https://bugs.webkit.org/show_bug.cgi?id=148373
378 Reviewed by Filip Pizlo.
380 Create functions from WebAssembly files generated by pack-asmjs
381 <https://github.com/WebAssembly/polyfill-prototype-1>.
382 WebAssembly functions created by this patch can only return 0.
383 Actual code generation will be implemented in subsequent patches.
385 This patch introduces WebAssemblyExecutable, a new subclass of
386 ExecutableBase for WebAssembly functions. CodeBlocks can now have
387 an owner that is not a ScriptExecutable. This patch changes the
388 return type of CodeBlock::ownerExecutable() from ScriptExecutable*
389 to ExecutableBase*. It also changes code that calls ScriptExecutable's
390 methods on CodeBlock::ownerExecutable() to use
391 CodeBlock::ownerScriptExecutable(), which does jsCast<ScriptExecutable*>.
393 Since ownerScriptExecutable() is called from WebCore and it uses
394 jsCast<ScriptExecutable*>, this patch needs to export
395 ScriptExecutable::info(). This should fix the build error in
396 https://bugs.webkit.org/show_bug.cgi?id=148555
398 * bytecode/CodeBlock.cpp:
399 (JSC::CodeBlock::hash):
400 (JSC::CodeBlock::sourceCodeForTools):
401 (JSC::CodeBlock::dumpAssumingJITType):
402 (JSC::CodeBlock::dumpSource):
403 (JSC::CodeBlock::CodeBlock):
404 (JSC::CodeBlock::finalizeUnconditionally):
405 (JSC::CodeBlock::lineNumberForBytecodeOffset):
406 (JSC::CodeBlock::expressionRangeForBytecodeOffset):
407 (JSC::CodeBlock::install):
408 (JSC::CodeBlock::newReplacement):
409 (JSC::WebAssemblyCodeBlock::replacement):
410 (JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
411 (JSC::CodeBlock::updateAllPredictions):
412 (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
413 * bytecode/CodeBlock.h:
414 (JSC::CodeBlock::ownerExecutable):
415 (JSC::CodeBlock::ownerScriptExecutable):
416 (JSC::CodeBlock::codeType):
417 (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
418 * debugger/Debugger.cpp:
419 (JSC::Debugger::toggleBreakpoint):
420 * debugger/DebuggerCallFrame.cpp:
421 (JSC::DebuggerCallFrame::sourceIDForCallFrame):
422 * dfg/DFGByteCodeParser.cpp:
423 (JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
424 (JSC::DFG::ByteCodeParser::inliningCost):
425 (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
426 (JSC::DFG::ByteCodeParser::parseCodeBlock):
427 * dfg/DFGCapabilities.cpp:
428 (JSC::DFG::isSupportedForInlining):
429 (JSC::DFG::mightCompileEval):
430 (JSC::DFG::mightCompileProgram):
431 (JSC::DFG::mightCompileFunctionForCall):
432 (JSC::DFG::mightCompileFunctionForConstruct):
434 (JSC::DFG::Graph::executableFor):
435 * dfg/DFGOSREntry.cpp:
436 (JSC::DFG::prepareOSREntry):
437 * inspector/ScriptCallStackFactory.cpp:
438 (Inspector::CreateScriptCallStackFunctor::operator()):
439 * interpreter/Interpreter.cpp:
441 (JSC::isWebAssemblyExecutable):
442 (JSC::GetStackTraceFunctor::operator()):
443 (JSC::UnwindFunctor::operator()):
444 * interpreter/StackVisitor.cpp:
445 (JSC::StackVisitor::Frame::sourceURL):
446 (JSC::StackVisitor::Frame::computeLineAndColumn):
447 * jit/JITOperations.cpp:
449 (JSC::linkPolymorphicCall):
450 * llint/LLIntData.cpp:
451 (JSC::LLInt::Data::performAssertions):
452 * llint/LLIntSlowPaths.cpp:
453 (JSC::LLInt::setUpCall):
454 * llint/LowLevelInterpreter.asm:
455 * runtime/CommonSlowPaths.cpp:
456 (JSC::SLOW_PATH_DECL):
457 * runtime/Executable.cpp:
458 (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
459 (JSC::WebAssemblyExecutable::destroy):
460 (JSC::WebAssemblyExecutable::visitChildren):
461 (JSC::WebAssemblyExecutable::clearCode):
462 (JSC::WebAssemblyExecutable::prepareForExecution):
463 * runtime/Executable.h:
464 (JSC::ExecutableBase::isEvalExecutable):
465 (JSC::ExecutableBase::isFunctionExecutable):
466 (JSC::ExecutableBase::isProgramExecutable):
467 (JSC::ExecutableBase::isWebAssemblyExecutable):
468 (JSC::ExecutableBase::clearCodeVirtual):
469 * runtime/JSFunction.cpp:
470 (JSC::JSFunction::create):
471 * runtime/JSFunction.h:
472 * runtime/JSFunctionInlines.h:
473 (JSC::JSFunction::JSFunction):
474 (JSC::JSFunction::isBuiltinFunction):
479 * wasm/JSWASMModule.h:
480 (JSC::JSWASMModule::functions):
481 * wasm/WASMFunctionParser.cpp:
482 (JSC::WASMFunctionParser::compile):
483 * wasm/WASMFunctionParser.h:
484 * wasm/WASMModuleParser.cpp:
485 (JSC::WASMModuleParser::WASMModuleParser):
486 (JSC::WASMModuleParser::parse):
487 (JSC::WASMModuleParser::parseFunctionDeclarationSection):
488 (JSC::WASMModuleParser::parseFunctionDefinition):
489 (JSC::WASMModuleParser::parseExportSection):
490 (JSC::parseWebAssembly):
491 * wasm/WASMModuleParser.h:
493 2015-08-28 Mark Lam <mark.lam@apple.com>
495 [Follow up] ScratchRegisterAllocator::preserveReusedRegistersByPushing() should allow room for C helper calls and keep sp properly aligned.
496 https://bugs.webkit.org/show_bug.cgi?id=148564
500 Updated the test to run with //@ runNoCJITNoAccessInlining instead of specifying
501 the JSC option directly via //@ run(). This is the right thing to do in order
502 to guarantee that the test will be compiled by the DFG.
504 * tests/stress/regress-148564.js:
506 2015-08-28 Joseph Pecoraro <pecoraro@apple.com>
508 Web Inspector: Separate creating a style sheet from adding a new rule in the protocol
509 https://bugs.webkit.org/show_bug.cgi?id=148502
511 Reviewed by Timothy Hatcher.
513 * inspector/protocol/CSS.json:
514 Add CSS.createStyleSheet. Modify CSS.addRule.
516 2015-08-28 Mark Lam <mark.lam@apple.com>
518 ScratchRegisterAllocator::preserveReusedRegistersByPushing() should allow room for C helper calls and keep sp properly aligned.
519 https://bugs.webkit.org/show_bug.cgi?id=148564
521 Reviewed by Saam Barati.
523 ScratchRegisterAllocator::preserveReusedRegistersByPushing() pushes registers on
524 the stack in order to preserve them. But emitPutTransitionStub() (which uses
525 preserveReusedRegistersByPushing()) may also emit a call to a C helper function
526 to flush the heap write barrier buffer. The code for emitting a C helper call
527 expects the stack pointer (sp) to already be pointing to a location on the stack
528 where there's adequate space reserved for storing the arguments to the C helper,
529 and that space is expected to be at the top of the stack. Hence, there is a
530 conflict of expectations. As a result, the arguments for the C helper will
531 overwrite and corrupt the values that are pushed on the stack by
532 preserveReusedRegistersByPushing().
534 In addition, JIT compiled functions always position the sp such that it will be
535 aligned (according to platform ABI dictates) after a C call is made (i.e. after
536 the frame pointer and return address is pushed on to the stack).
537 preserveReusedRegistersByPushing()'s arbitrary pushing of a number of saved
538 register values may mess up this alignment.
540 The fix is to have preserveReusedRegistersByPushing(), after it has pushed the
541 saved register values, adjust the sp to reserve an additional amount of stack
542 space needed for C call helpers plus any padding needed to restore proper sp
543 alignment. The stack's ReservedZone will ensure that we have enough stack space
544 for this. ScratchRegisterAllocator::restoreReusedRegistersByPopping() also
545 needs to be updated to perform the complement of this behavior.
548 (JSC::emitPutReplaceStub):
549 (JSC::emitPutTransitionStub):
550 * jit/ScratchRegisterAllocator.cpp:
551 (JSC::ScratchRegisterAllocator::allocateScratchGPR):
552 (JSC::ScratchRegisterAllocator::allocateScratchFPR):
553 (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
554 (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
555 * jit/ScratchRegisterAllocator.h:
556 (JSC::ScratchRegisterAllocator::numberOfReusedRegisters):
557 * tests/stress/regress-148564.js: Added.
561 2015-08-28 Csaba Osztrogonác <ossy@webkit.org>
563 Unreviewed Windows buildfix.
565 Revert part of r189072 since the original change was rolled out by r189085.
567 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
568 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
570 2015-08-28 Csaba Osztrogonác <ossy@webkit.org>
572 Unreviewed Windows buildfix.
574 Revert r189077 since the original change was rolled out by r189085.
576 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
577 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
579 2015-08-27 Yusuke Suzuki <utatane.tea@gmail.com>
581 [ES6] Implement Module execution and Loader's ready / link phase
582 https://bugs.webkit.org/show_bug.cgi?id=148172
584 Reviewed by Saam Barati.
586 This patch adds the link / ready phases to the existing module loader.
587 They are just the stubs and the actual implementations will be
588 forthcoming in the subsequnt patch.
590 And this patch paves the way to instantiate the module environment and
591 compile the executable code in the link phase. Move declaredVariables /
592 lexicalVariables from ModuleAnalyzer to JSModuleRecord to use them when
593 instantiating the module environment. Hold the source code in
594 JSModuleRecord to construct the executable in the link phase. And to
595 use HostResolveImportedModule operation from the C++ side, we expose
596 the JSMap from C++ to JS and use it in the builtin JS module loader
599 * builtins/ModuleLoaderObject.js:
600 (requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then.):
606 * parser/ModuleAnalyzer.cpp:
607 (JSC::ModuleAnalyzer::ModuleAnalyzer):
608 (JSC::ModuleAnalyzer::analyze):
609 * parser/ModuleAnalyzer.h:
610 * runtime/Completion.cpp:
611 (JSC::checkModuleSyntax):
612 * runtime/JSModuleRecord.cpp:
613 (JSC::JSModuleRecord::finishCreation):
614 (JSC::JSModuleRecord::visitChildren):
615 (JSC::identifierToJSValue):
616 (JSC::JSModuleRecord::hostResolveImportedModule):
617 (JSC::JSModuleRecord::link):
618 (JSC::JSModuleRecord::execute):
619 * runtime/JSModuleRecord.h:
620 (JSC::JSModuleRecord::create):
621 (JSC::JSModuleRecord::sourceCode):
622 (JSC::JSModuleRecord::moduleKey):
623 (JSC::JSModuleRecord::exportEntries):
624 (JSC::JSModuleRecord::importEntries):
625 (JSC::JSModuleRecord::declaredVariables):
626 (JSC::JSModuleRecord::lexicalVariables):
627 (JSC::JSModuleRecord::JSModuleRecord):
628 * runtime/ModuleLoaderObject.cpp:
629 (JSC::moduleLoaderObjectParseModule):
630 (JSC::moduleLoaderObjectRequestedModules):
631 (JSC::moduleLoaderObjectModuleDeclarationInstantiation):
632 (JSC::moduleLoaderObjectEvaluate):
633 (JSC::ModuleLoaderObject::requestInstantiateAll): Deleted.
634 * runtime/ModuleLoaderObject.h:
636 2015-08-27 Mark Lam <mark.lam@apple.com>
638 Add noDFG() to jsc to prevent DFG compilation of a specified function.
639 https://bugs.webkit.org/show_bug.cgi?id=148559
641 Reviewed by Geoffrey Garen and Saam Barati.
643 * API/JSCTestRunnerUtils.cpp:
644 (JSC::setNeverInline):
645 (JSC::setNeverOptimize):
646 * API/JSCTestRunnerUtils.h:
647 * bytecode/CodeBlock.cpp:
648 (JSC::CodeBlock::dumpAssumingJITType):
649 * dfg/DFGCapabilities.cpp:
650 (JSC::DFG::mightCompileEval):
651 (JSC::DFG::mightCompileProgram):
652 (JSC::DFG::mightCompileFunctionForCall):
653 (JSC::DFG::mightCompileFunctionForConstruct):
654 (JSC::DFG::mightInlineFunctionForCall):
656 (GlobalObject::finishCreation):
658 * runtime/Executable.h:
659 (JSC::ScriptExecutable::ecmaMode):
660 (JSC::ScriptExecutable::setNeverInline):
661 (JSC::ScriptExecutable::setNeverOptimize):
662 (JSC::ScriptExecutable::setDidTryToEnterInLoop):
663 (JSC::ScriptExecutable::neverInline):
664 (JSC::ScriptExecutable::neverOptimize):
665 (JSC::ScriptExecutable::didTryToEnterInLoop):
666 (JSC::ScriptExecutable::isInliningCandidate):
667 (JSC::ScriptExecutable::isOkToOptimize):
668 (JSC::ScriptExecutable::addressOfDidTryToEnterInLoop):
669 * runtime/TestRunnerUtils.cpp:
670 (JSC::setNeverInline):
671 (JSC::setNeverOptimize):
672 (JSC::optimizeNextInvocation):
673 * runtime/TestRunnerUtils.h:
675 2015-08-27 Commit Queue <commit-queue@webkit.org>
677 Unreviewed, rolling out r189064 and r189084.
678 https://bugs.webkit.org/show_bug.cgi?id=148560
680 Breaks 117 JSC tests. (Requested by mlam on #webkit).
684 "[ES6] Add TypedArray.prototype functionality."
685 https://bugs.webkit.org/show_bug.cgi?id=148035
686 http://trac.webkit.org/changeset/189064
688 "Unbreak JSC tests (broken since r189064)."
689 http://trac.webkit.org/changeset/189084
691 2015-08-27 Commit Queue <commit-queue@webkit.org>
693 Unreviewed, rolling out r189079.
694 https://bugs.webkit.org/show_bug.cgi?id=148555
696 broke the build (Requested by jessieberlin on #webkit).
700 "Create WebAssembly functions"
701 https://bugs.webkit.org/show_bug.cgi?id=148373
702 http://trac.webkit.org/changeset/189079
704 2015-08-27 Sukolsak Sakshuwong <sukolsak@gmail.com>
706 Create WebAssembly functions
707 https://bugs.webkit.org/show_bug.cgi?id=148373
709 Reviewed by Geoffrey Garen.
711 Create functions from WebAssembly files generated by pack-asmjs
712 <https://github.com/WebAssembly/polyfill-prototype-1>.
713 WebAssembly functions created by this patch can only return 0.
714 Actual code generation will be implemented in subsequent patches.
716 * bytecode/CodeBlock.cpp:
717 (JSC::CodeBlock::hash):
718 (JSC::CodeBlock::sourceCodeForTools):
719 (JSC::CodeBlock::dumpAssumingJITType):
720 (JSC::CodeBlock::dumpSource):
721 (JSC::CodeBlock::CodeBlock):
722 (JSC::CodeBlock::finalizeUnconditionally):
723 (JSC::CodeBlock::lineNumberForBytecodeOffset):
724 (JSC::CodeBlock::expressionRangeForBytecodeOffset):
725 (JSC::CodeBlock::install):
726 (JSC::CodeBlock::newReplacement):
727 (JSC::WebAssemblyCodeBlock::replacement):
728 (JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
729 (JSC::CodeBlock::updateAllPredictions):
730 (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
731 * bytecode/CodeBlock.h:
732 (JSC::CodeBlock::ownerExecutable):
733 (JSC::CodeBlock::ownerScriptExecutable):
734 (JSC::CodeBlock::codeType):
735 (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
736 * debugger/Debugger.cpp:
737 (JSC::Debugger::toggleBreakpoint):
738 * debugger/DebuggerCallFrame.cpp:
739 (JSC::DebuggerCallFrame::sourceIDForCallFrame):
740 * dfg/DFGByteCodeParser.cpp:
741 (JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
742 (JSC::DFG::ByteCodeParser::inliningCost):
743 (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
744 (JSC::DFG::ByteCodeParser::parseCodeBlock):
745 * dfg/DFGCapabilities.cpp:
746 (JSC::DFG::isSupportedForInlining):
748 (JSC::DFG::Graph::executableFor):
749 * dfg/DFGOSREntry.cpp:
750 (JSC::DFG::prepareOSREntry):
751 * inspector/ScriptCallStackFactory.cpp:
752 (Inspector::CreateScriptCallStackFunctor::operator()):
753 * interpreter/Interpreter.cpp:
755 (JSC::isWebAssemblyExecutable):
756 (JSC::GetStackTraceFunctor::operator()):
757 (JSC::UnwindFunctor::operator()):
758 * interpreter/StackVisitor.cpp:
759 (JSC::StackVisitor::Frame::sourceURL):
760 (JSC::StackVisitor::Frame::computeLineAndColumn):
761 * jit/JITOperations.cpp:
763 (JSC::isWebAssemblyExecutable):
764 (JSC::linkPolymorphicCall):
765 * llint/LLIntData.cpp:
766 (JSC::LLInt::Data::performAssertions):
767 * llint/LLIntSlowPaths.cpp:
768 (JSC::LLInt::setUpCall):
769 * llint/LowLevelInterpreter.asm:
770 * runtime/CommonSlowPaths.cpp:
771 (JSC::SLOW_PATH_DECL):
772 * runtime/Executable.cpp:
773 (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
774 (JSC::WebAssemblyExecutable::destroy):
775 (JSC::WebAssemblyExecutable::visitChildren):
776 (JSC::WebAssemblyExecutable::clearCode):
777 (JSC::WebAssemblyExecutable::prepareForExecution):
778 * runtime/Executable.h:
779 (JSC::ExecutableBase::isEvalExecutable):
780 (JSC::ExecutableBase::isFunctionExecutable):
781 (JSC::ExecutableBase::isProgramExecutable):
782 (JSC::ExecutableBase::isWebAssemblyExecutable):
783 (JSC::ExecutableBase::clearCodeVirtual):
784 * runtime/JSFunction.cpp:
785 (JSC::JSFunction::create):
786 * runtime/JSFunction.h:
787 * runtime/JSFunctionInlines.h:
788 (JSC::JSFunction::JSFunction):
789 (JSC::JSFunction::isBuiltinFunction):
794 * wasm/JSWASMModule.h:
795 (JSC::JSWASMModule::functions):
796 * wasm/WASMFunctionParser.cpp:
797 (JSC::WASMFunctionParser::compile):
798 * wasm/WASMFunctionParser.h:
799 * wasm/WASMModuleParser.cpp:
800 (JSC::WASMModuleParser::WASMModuleParser):
801 (JSC::WASMModuleParser::parse):
802 (JSC::WASMModuleParser::parseFunctionDeclarationSection):
803 (JSC::WASMModuleParser::parseFunctionDefinition):
804 (JSC::WASMModuleParser::parseExportSection):
805 (JSC::parseWebAssembly):
806 * wasm/WASMModuleParser.h:
808 2015-08-27 Brent Fulgham <bfulgham@apple.com>
810 [Win] Unreviewed build fix after r189064.
812 JSTypedArrayViewPrototypes.{h,cpp} -> JSTypedArrayViewPrototype.{h,cpp}
814 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
815 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
817 2015-08-27 Alex Christensen <achristensen@webkit.org>
819 Make DLLLauncherMain executables dependent on dll
820 https://bugs.webkit.org/show_bug.cgi?id=148548
822 Reviewed by Brent Fulgham.
824 * shell/CMakeLists.txt:
825 * shell/PlatformWin.cmake:
827 2015-08-27 Filip Pizlo <fpizlo@apple.com>
829 DFG::StrCat isn't really effectful
830 https://bugs.webkit.org/show_bug.cgi?id=148443
832 Reviewed by Geoffrey Garen.
834 I previously made the DFG StrCat node effectful because it is implemented by calling a
835 DFGOperations function that could cause arbitrary effects. But, the node is only generated from the
836 op_strcat bytecode operation, and that operation is only used when we first ensure that its
837 operands are primitives. Primitive operands to StrCat cannot cause arbitrary side-effects. The
838 reason why I didn't immediately mark StrCat as pure was because there was nothing in DFG IR that
839 guaranteed that StrCat's children were primitives.
841 This change adds a KnownPrimitiveUse use kind, and applies it to StrCat. This allows us to mark
842 StrCat as being pure. This should be a speed-up because we can CSE StrCat and because it means that
843 we can OSR exit after a StrCat (a pure node doesn't clobber exit state), so we can convert more
844 of a large string concatenation into MakeRope's.
846 * dfg/DFGAbstractInterpreterInlines.h:
847 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
848 * dfg/DFGClobberize.h:
849 (JSC::DFG::clobberize):
850 * dfg/DFGFixupPhase.cpp:
851 (JSC::DFG::FixupPhase::fixupNode):
852 (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
853 * dfg/DFGOperations.cpp:
854 * dfg/DFGSafeToExecute.h:
855 (JSC::DFG::SafeToExecuteEdge::operator()):
856 * dfg/DFGSpeculativeJIT.cpp:
857 (JSC::DFG::SpeculativeJIT::speculate):
858 * dfg/DFGSpeculativeJIT32_64.cpp:
859 (JSC::DFG::SpeculativeJIT::compile):
860 * dfg/DFGSpeculativeJIT64.cpp:
861 (JSC::DFG::SpeculativeJIT::compile):
862 * dfg/DFGUseKind.cpp:
863 (WTF::printInternal):
865 (JSC::DFG::typeFilterFor):
866 (JSC::DFG::shouldNotHaveTypeCheck):
867 * ftl/FTLCapabilities.cpp:
868 (JSC::FTL::canCompile):
869 * ftl/FTLLowerDFGToLLVM.cpp:
870 (JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
871 (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
873 2015-08-27 Brent Fulgham <bfulgham@apple.com>
875 [Win] Unreviewed build fix after r189064.
877 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
878 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
880 2015-08-27 Yusuke Suzuki <utatane.tea@gmail.com>
882 Add module loader "resolve" hook for local file system to test the loader in JSC shell
883 https://bugs.webkit.org/show_bug.cgi?id=148543
885 Reviewed by Filip Pizlo.
887 Add the module loader "resolve" hook to the JSC shell.
888 It takes the module name and the referrer module key and resolves the name to the unique module key.
890 resolve(ModuleName moduleName, ModuleKey referrer) -> Promise<ModuleKey>
892 In the JSC shell, since we load the module from the local file system, we treat an absolute file path
893 as a module key. So, in this patch, we implement the "resolve" hook that resolves the module name to
894 the absolute file path.
896 This local file system "resolve" functionality makes JSC shell easy to test the module loader.
899 (GlobalObject::finishCreation):
900 (GlobalObject::moduleLoaderFetch):
902 (extractDirectoryName):
903 (currentWorkingDirectory):
905 (GlobalObject::moduleLoaderResolve):
906 (functionDrainMicrotasks):
907 * runtime/JSInternalPromiseDeferred.cpp:
908 (JSC::JSInternalPromiseDeferred::resolve):
909 (JSC::JSInternalPromiseDeferred::reject):
910 * runtime/JSInternalPromiseDeferred.h:
911 * tests/stress/pathname-resolve.js: Added.
915 2015-08-27 Filip Pizlo <fpizlo@apple.com>
917 Unreviewed, fix some FIXMEs and add some new ones, based on things we've learned from some
918 recent OSR exit work.
920 * dfg/DFGLICMPhase.cpp:
921 (JSC::DFG::LICMPhase::run):
922 (JSC::DFG::LICMPhase::attemptHoist):
923 * dfg/DFGMayExit.cpp:
926 2015-08-27 Keith Miller <keith_miller@apple.com>
928 [ES6] Add TypedArray.prototype functionality.
929 https://bugs.webkit.org/show_bug.cgi?id=148035
931 Reviewed by Geoffrey Garen.
933 This patch should add most of the functionality for
934 the prototype properties of TypedArray objects in ES6.
935 There are a few exceptions to this, which will be added
938 1) First we do not use the species constructor for some
939 of the TypedArray prototype functions (namely: map, filter,
940 slice, and subarray). That will need to be added when
941 species constructors are finished.
943 2) TypedArrays still have a length, byteOffset, byteLength,
944 and buffer are still attached to the TypedArray instance (in
945 the spec they are on the TypedArray.prototype instance object)
946 since the JIT currently assumes those properties are fixed.
948 3) The TypedArray.constructor property is not added yet
949 as it should point to the TypedArray instance object,
950 which will be added in a future patch.
953 * JavaScriptCore.xcodeproj/project.pbxproj:
954 * builtins/TypedArray.prototype.js: Added.
969 * runtime/ArrayPrototype.cpp:
970 * runtime/ArrayPrototype.h:
971 * runtime/CommonIdentifiers.h:
972 * runtime/JSGenericTypedArrayView.h:
974 (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
975 (JSC::JSGenericTypedArrayView::setRangeToValue):
976 (JSC::JSGenericTypedArrayView::sort):
977 * runtime/JSGenericTypedArrayViewInlines.h:
978 * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
979 (JSC::argumentClampedIndexFromStartOrEnd):
980 (JSC::genericTypedArrayViewProtoFuncSet):
981 (JSC::genericTypedArrayViewProtoFuncEntries):
982 (JSC::genericTypedArrayViewProtoFuncCopyWithin):
983 (JSC::genericTypedArrayViewProtoFuncFill):
984 (JSC::genericTypedArrayViewProtoFuncIndexOf):
985 (JSC::genericTypedArrayViewProtoFuncJoin):
986 (JSC::genericTypedArrayViewProtoFuncKeys):
987 (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
988 (JSC::genericTypedArrayViewProtoGetterFuncLength):
989 (JSC::genericTypedArrayViewProtoGetterFuncByteLength):
990 (JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
991 (JSC::genericTypedArrayViewProtoFuncReverse):
992 (JSC::genericTypedArrayViewPrivateFuncSort):
993 (JSC::genericTypedArrayViewProtoFuncSlice):
994 (JSC::genericTypedArrayViewProtoFuncSubarray):
995 (JSC::typedArrayViewProtoFuncValues):
996 * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
997 (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
998 (JSC::genericTypedArrayViewProtoFuncSet): Deleted.
999 (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
1000 * runtime/JSGlobalObject.cpp:
1001 (JSC::JSGlobalObject::init):
1002 * runtime/JSObject.h:
1003 * runtime/JSTypedArrayPrototypes.cpp:
1004 * runtime/JSTypedArrayPrototypes.h:
1005 * runtime/JSTypedArrayViewPrototype.cpp: Added.
1006 (JSC::typedArrayViewPrivateFuncLength):
1007 (JSC::typedArrayViewPrivateFuncSort):
1008 (JSC::typedArrayViewProtoFuncSet):
1009 (JSC::typedArrayViewProtoFuncEntries):
1010 (JSC::typedArrayViewProtoFuncCopyWithin):
1011 (JSC::typedArrayViewProtoFuncFill):
1012 (JSC::typedArrayViewProtoFuncLastIndexOf):
1013 (JSC::typedArrayViewProtoFuncIndexOf):
1014 (JSC::typedArrayViewProtoFuncJoin):
1015 (JSC::typedArrayViewProtoFuncKeys):
1016 (JSC::typedArrayViewProtoGetterFuncLength):
1017 (JSC::typedArrayViewProtoGetterFuncByteLength):
1018 (JSC::typedArrayViewProtoGetterFuncByteOffset):
1019 (JSC::typedArrayViewProtoFuncReverse):
1020 (JSC::typedArrayViewProtoFuncSubarray):
1021 (JSC::typedArrayViewProtoFuncSlice):
1022 (JSC::typedArrayViewProtoFuncValues):
1023 (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
1024 (JSC::JSTypedArrayViewPrototype::finishCreation):
1025 (JSC::JSTypedArrayViewPrototype::create):
1026 (JSC::JSTypedArrayViewPrototype::createStructure):
1027 * runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
1029 2015-08-27 Alex Christensen <achristensen@webkit.org>
1031 Isolate Source directories in CMake build
1032 https://bugs.webkit.org/show_bug.cgi?id=148389
1034 Reviewed by Brent Fulgham.
1036 * PlatformWin.cmake:
1037 Include ../include/private to find WTF headers in internal build.
1038 Don't use a script to generate forwarding headers.
1039 * shell/PlatformWin.cmake:
1040 Copy inspector scripts to the forwarding headers directory to be used by WebCore.
1042 2015-08-27 Alex Christensen <achristensen@webkit.org>
1044 [Win CMake] Fix incremental build after r188673
1045 https://bugs.webkit.org/show_bug.cgi?id=148539
1047 Reviewed by Brent Fulgham.
1049 * PlatformWin.cmake:
1050 Use xcopy as a build step instead of file(COPY ...) to copy updated headers.
1052 2015-08-27 Jon Davis <jond@apple.com>
1054 Include ES6 Generators and Proxy object status to feature status page.
1055 https://bugs.webkit.org/show_bug.cgi?id=148095
1057 Reviewed by Timothy Hatcher.
1061 2015-08-27 Filip Pizlo <fpizlo@apple.com>
1063 Unreviewed, add a comment to describe something I learned about a confusingly-named function.
1068 2015-08-27 Basile Clement <basile_clement@apple.com>
1070 REGRESSION(r184779): Possible read-after-free in JavaScriptCore/dfg/DFGClobberize.h
1071 https://bugs.webkit.org/show_bug.cgi?id=148411
1073 Reviewed by Geoffrey Garen and Filip Pizlo.
1075 * dfg/DFGClobberize.h:
1076 (JSC::DFG::clobberize):
1078 2015-08-27 Brian Burg <bburg@apple.com>
1080 Web Inspector: FrontendChannel should know its own connection type
1081 https://bugs.webkit.org/show_bug.cgi?id=148482
1083 Reviewed by Joseph Pecoraro.
1085 * inspector/InspectorFrontendChannel.h: Add connectionType().
1086 * inspector/remote/RemoteInspectorDebuggableConnection.h:
1088 2015-08-26 Filip Pizlo <fpizlo@apple.com>
1090 Node::origin should always be set, and the dead zone due to SSA Phis can just use exitOK=false
1091 https://bugs.webkit.org/show_bug.cgi?id=148462
1093 Reviewed by Saam Barati.
1095 The need to label nodes that absolutely cannot exit was first observed when we introduced SSA form.
1096 We indicated this by not setting the CodeOrigin.
1098 But just recently (http://trac.webkit.org/changeset/188979), we added a more comprehensive "exitOK"
1099 bit in NodeOrigin. After that change, there were two ways of indicating that you cannot exit:
1100 !exitOK and an unset NodeOrigin. An unset NodeOrigin implied !exitOK.
1102 Now, this change is about removing the old way so that we only use !exitOK. From now on, all nodes
1103 must have their NodeOrigin set, and the IR validation will check this. This means that I could
1104 remove various pieces of cruft for dealing with unset NodeOrigins, but I did have to add some new
1105 cruft to ensure that all nodes we create have a NodeOrigin.
1107 This change simplifies our IR by having a simpler rule about when NodeOrigin is set: it's always
1110 * dfg/DFGBasicBlock.cpp:
1111 (JSC::DFG::BasicBlock::isInBlock):
1112 (JSC::DFG::BasicBlock::removePredecessor):
1113 (JSC::DFG::BasicBlock::firstOriginNode): Deleted.
1114 (JSC::DFG::BasicBlock::firstOrigin): Deleted.
1115 * dfg/DFGBasicBlock.h:
1116 (JSC::DFG::BasicBlock::begin):
1117 (JSC::DFG::BasicBlock::end):
1118 (JSC::DFG::BasicBlock::numSuccessors):
1119 (JSC::DFG::BasicBlock::successor):
1120 * dfg/DFGCombinedLiveness.cpp:
1121 (JSC::DFG::liveNodesAtHead):
1122 * dfg/DFGConstantHoistingPhase.cpp:
1123 * dfg/DFGCriticalEdgeBreakingPhase.cpp:
1124 (JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
1125 * dfg/DFGForAllKills.h:
1126 (JSC::DFG::forAllKilledOperands):
1127 * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1128 * dfg/DFGLoopPreHeaderCreationPhase.cpp:
1129 (JSC::DFG::createPreHeader):
1130 (JSC::DFG::LoopPreHeaderCreationPhase::run):
1131 * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
1132 (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
1133 * dfg/DFGObjectAllocationSinkingPhase.cpp:
1134 * dfg/DFGPutStackSinkingPhase.cpp:
1135 * dfg/DFGSSAConversionPhase.cpp:
1136 (JSC::DFG::SSAConversionPhase::run):
1137 * dfg/DFGValidate.cpp:
1138 (JSC::DFG::Validate::validate):
1139 (JSC::DFG::Validate::validateSSA):
1141 2015-08-26 Saam barati <sbarati@apple.com>
1143 MarkedBlock::allocateBlock will have the wrong allocation size when (sizeof(MarkedBlock) + bytes) is divisible by WTF::pageSize()
1144 https://bugs.webkit.org/show_bug.cgi?id=148500
1146 Reviewed by Mark Lam.
1148 Consider the following scenario:
1149 - On OS X, WTF::pageSize() is 4*1024 bytes.
1150 - JSEnvironmentRecord::allocationSizeForScopeSize(6621) == 53000
1151 - sizeof(MarkedBlock) == 248
1152 - (248 + 53000) is a multiple of 4*1024.
1153 - (248 + 53000)/(4*1024) == 13
1155 We will allocate a chunk of memory of size 53248 bytes that looks like this:
1156 0 248 256 53248 53256
1157 [Marked Block | 8 bytes | payload ...... ] 8 bytes |
1159 Our Environment record starts here. ^
1161 Our last JSValue in the environment record will go from byte 53248 to 53256. But, we don't own this memory.
1163 We need to ensure that we round up sizeof(MarkedBlock) to an
1164 atomSize boundary. We need to do this because the first atom
1165 inside the MarkedBlock will start at the rounded up multiple
1166 of atomSize past MarkedBlock. If we end up with an allocation
1167 that is perfectly aligned to the page size, then we will be short
1168 8 bytes (in the current implementation where atomSize is 16 bytes,
1169 and MarkedBlock is 248 bytes).
1171 * heap/MarkedAllocator.cpp:
1172 (JSC::MarkedAllocator::allocateBlock):
1173 * tests/stress/heap-allocator-allocates-incorrect-size-for-activation.js: Added.
1177 2015-08-26 Mark Lam <mark.lam@apple.com>
1179 watchdog m_didFire state erroneously retained.
1180 https://bugs.webkit.org/show_bug.cgi?id=131082
1182 Reviewed by Geoffrey Garen.
1184 The watchdog can fire for 2 reasons:
1185 1. an external controlling entity (i.e. another thread) has scheduled termination
1186 of the script thread via watchdog::terminateSoon().
1187 2. the allowed CPU time has expired.
1189 For case 1, we're doing away with the m_didFire flag. Watchdog::terminateSoon()
1190 will set the timer deadlines and m_timeLimit to 0, and m_timerDidFire to true.
1191 This will get the script thread to check Watchdog::didFire() and terminate
1194 Note: the watchdog only guarantees that script execution will terminate as soon
1195 as possible due to a time limit of 0. Once we've exited the VM, the client of the
1196 VM is responsible from keeping a flag to prevent new script execution.
1198 In a race condition, if terminateSoon() is called just after execution has gotten
1199 past the client's reentry check and the client is in the process of re-entering,
1200 the worst that can happen is that we will schedule the watchdog timer to fire
1201 after a period of 0. This will terminate script execution quickly, and thereafter
1202 the client's check should be able to prevent further entry into the VM.
1204 The correctness (i.e. has no race condition) of this type of termination relies
1205 on the termination state being sticky. Once the script thread is terminated this
1206 way, the VM will continue to terminate scripts quickly until the client sets the
1207 time limit to a non-zero value (or clears it which sets the time limit to
1210 For case 2, the watchdog does not alter m_timeLimit. If the CPU deadline has
1211 been reached, the script thread will terminate execution and exit the VM.
1213 If the client of the VM starts new script execution, the watchdog will allow
1214 execution for the specified m_timeLimit. In this case, since m_timeLimit is not
1215 0, the script gets a fresh allowance of CPU time to execute. Hence, terminations
1216 due to watchdog time outs are no longer sticky.
1218 * API/JSContextRef.cpp:
1219 (JSContextGroupSetExecutionTimeLimit):
1220 (JSContextGroupClearExecutionTimeLimit):
1221 * API/tests/ExecutionTimeLimitTest.cpp:
1222 - Add test scenarios to verify that the watchdog is automatically reset by the VM
1223 upon throwing the TerminatedExecutionException.
1225 (testResetAfterTimeout):
1226 (testExecutionTimeLimit):
1227 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1228 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1229 * JavaScriptCore.xcodeproj/project.pbxproj:
1230 * dfg/DFGByteCodeParser.cpp:
1231 (JSC::DFG::ByteCodeParser::parseBlock):
1232 * interpreter/Interpreter.cpp:
1233 (JSC::Interpreter::execute):
1234 (JSC::Interpreter::executeCall):
1235 (JSC::Interpreter::executeConstruct):
1236 * jit/JITOpcodes.cpp:
1237 (JSC::JIT::emit_op_loop_hint):
1238 (JSC::JIT::emitSlow_op_loop_hint):
1239 * jit/JITOperations.cpp:
1240 * llint/LLIntSlowPaths.cpp:
1241 (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1244 (JSC::VM::ensureWatchdog):
1246 * runtime/VMInlines.h: Added.
1247 (JSC::VM::shouldTriggerTermination):
1248 * runtime/Watchdog.cpp:
1249 (JSC::Watchdog::Watchdog):
1250 (JSC::Watchdog::setTimeLimit):
1251 (JSC::Watchdog::terminateSoon):
1252 (JSC::Watchdog::didFireSlow):
1253 (JSC::Watchdog::hasTimeLimit):
1254 (JSC::Watchdog::enteredVM):
1255 (JSC::Watchdog::exitedVM):
1256 (JSC::Watchdog::startTimer):
1257 (JSC::Watchdog::stopTimer):
1258 (JSC::Watchdog::hasStartedTimer): Deleted.
1259 (JSC::Watchdog::fire): Deleted.
1260 * runtime/Watchdog.h:
1261 (JSC::Watchdog::didFire):
1262 (JSC::Watchdog::timerDidFireAddress):
1264 2015-08-26 Joseph Pecoraro <pecoraro@apple.com>
1266 Web Inspector: Implement tracking of active stylesheets in the frontend
1267 https://bugs.webkit.org/show_bug.cgi?id=105828
1269 Reviewed by Timothy Hatcher.
1271 * inspector/protocol/CSS.json:
1272 Add new events for when a StyleSheet is added or removed.
1274 2015-08-26 Chris Dumez <cdumez@apple.com>
1276 Distinguish Web IDL callback interfaces from Web IDL callback functions
1277 https://bugs.webkit.org/show_bug.cgi?id=148434
1279 Reviewed by Geoffrey Garen.
1281 Add isNull() convenience method on PropertyName.
1283 * runtime/PropertyName.h:
1284 (JSC::PropertyName::isNull):
1286 2015-08-26 Filip Pizlo <fpizlo@apple.com>
1288 Node::origin should be able to tell you if it's OK to exit
1289 https://bugs.webkit.org/show_bug.cgi?id=145204
1291 Reviewed by Geoffrey Garen.
1293 This is a major change to DFG IR, that makes it easier to reason about where nodes with
1294 speculations can be soundly hoisted.
1296 A program in DFG IR is a sequence of operations that compute the values of SSA variables,
1297 perform effects on the heap or stack, and perform updates to the OSR exit state. Because
1298 effects and OSR exit updates are interleaved, there are points in execution where exiting
1299 simply won't work. For example, we may have some bytecode operation:
1301 [ 24] op_foo loc42 // does something, and puts a value in loc42.
1303 that gets compiled down to a sequence of DFG IR nodes like:
1305 a: Foo(W:Heap, R:World, bc#24) // writes heap, reads world - i.e. an observable effect.
1306 b: MovHint(@a, loc42, bc#24)
1307 c: SetLocal(Check:Int32:@a, loc42, bc#24, exit: bc#26)
1309 Note that we can OSR exit at @a because we haven't yet performed any effects for bc#24 yet and
1310 we have performed all effects for prior bytecode operations. That's what the origin.forExit
1311 being set to "bc#24" guarantees. So, an OSR exit at @a would transfer execution to bc#24 and
1312 this would not be observable. But at @b, if we try to exit to bc#24 as indicated by forExit, we
1313 would end up causing the side effect of bc#24 to execute a second time. This would be
1314 observable, so we cannot do it. And we cannot exit to the next instruction - bc#26 - either,
1315 because @b is responsible for updating the OSR state to indicate that the result of @a should
1316 be put into loc42. It's not until we get to @c that we can exit again.
1318 This is a confusing, but useful, property of DFG IR. It's useful because it allows us to use IR
1319 to spell out how we would have affected the bytecode state, and we use this to implement hard
1320 things like object allocation elimination, where we use IR instructions to indicate what object
1321 allocation and mutation operations we would have performed, and which bytecode variables would
1322 have pointed to those objects. So long as IR allows us to describe how OSR exit state is
1323 updated, there will be points in execution where that state is invalid - especially if the IR
1324 to update exit state is separate from the IR to perform actual effects.
1326 But this property is super confusing! It's difficult to explain that somehow magically, @b is a
1327 bad place to put OSR exits, and that magically we will only have OSR exits at @a. Of course, it
1328 all kind of makes sense - we insert OSR exit checks in phases that *know* where it's safe to
1329 exit - but it's just too opaque. This also gets in the way of more sophisticated
1330 transformations. For example, LICM barely works - it magically knows that loop pre-headers are
1331 good places to exit from, but it has no way of determining if that is actually true. It would
1332 be odd to introduce a restriction that anytime some block qualifies as a pre-header according
1333 to our loop calculator, it must end with a terminal at which it is OK to exit. So, our choices
1334 are to either leave LICM in a magical state and exercise extreme caution when introducing new
1335 optimizations that hoist checks, or to do something to make the "can I exit here" property more
1338 We have already, in a separate change, added a NodeOrigin::exitOK property, though it didn't do
1339 anything yet. This change puts exitOK to work, and makes it an integral part of IR. The key
1340 intuition behind this change is that if we know which nodes clobber exit state - i.e. after the
1341 node, it's no longer possible to OSR exit until the exit state is fixed up - then we can figure
1342 out where it's fine to exit. This change mostly adopts the already implicit rule that it's
1343 always safe to exit right at the boundary of exit origins (in between two nodes where
1344 origin.forExit differs), and adds a new node, called ExitOK, which is a kind of declaration
1345 that exit state is good again. When making this change, I struggled with the question of
1346 whether to make origin.exitOK be explicit, or something that we can compute with an analysis.
1347 Of course if we are armed with a clobbersExitState(Node*) function, we can find the places
1348 where it's fine to exit. But this kind of computation could get quite sophisticated if the
1349 nodes belonging to an exit origin are lowered to a control-flow construct. It would also be
1350 harder to see what the original intent was, if we found an error: is the bug that we shouldn't
1351 be clobbering exit state, or that we shouldn't be exiting? This change opts to make exitOK be
1352 an explicit property of IR, so that DFG IR validation will reject any program where exitOK is
1353 true after a node that clobbersExitState(), or if exitOK is true after a node has exitOK set to
1354 false - unless the latter node has a different exit origin or is an ExitOK node. It will also
1355 reject any program where a node mayExit() with !exitOK.
1357 It turns out that this revealed a lot of sloppiness and what almost looked like an outright
1358 bug: the callee property of an inline closure call frame was being set up "as if" by the
1359 callee's op_enter. If we did hoist a check per the old rule - to the boundary of exit origins -
1360 then we would crash because the callee is unknown. It also revealed that LICM could *almost*
1361 get hosed by having a pre-header where there are effects before the jump. I wasn't able to
1362 construct a test case that would crash trunk, but I also couldn't quite prove why such a
1363 program couldn't be constructed. I did fix the issue in loop pre-header creation, and the
1364 validater does catch the issue because of its exitOK assertions.
1366 This doesn't yet add any other safeguards to LICM - that phase still expects that pre-headers
1367 are in place and that they were created in such a way that their terminal origins have exitOK.
1368 It also still keeps the old way of saying "not OK to exit" - having a clear NodeOrigin. In a
1369 later patch I'll remove that and use !exitOK everywhere. Note that I did consider using clear
1370 NodeOrigins to signify that it's not OK to exit, but that would make DFGForAllKills a lot more
1371 expensive - it would have to sometimes search to find nearby forExit origins if the current
1372 node doesn't have it set - and that's a critical phase for DFG compilation performance.
1373 Requiring that forExit is usually set to *something* and that properly shadows the original
1374 bytecode is cheap and easy, so it seemed like a good trade-off.
1376 This change has no performance effect. Its only effect is that it makes the compiler easier to
1377 understand by turning a previously magical concept into an explicit one.
1380 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1381 * JavaScriptCore.xcodeproj/project.pbxproj:
1382 * dfg/DFGAbstractHeap.h:
1383 * dfg/DFGAbstractInterpreterInlines.h:
1384 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1385 * dfg/DFGArgumentsEliminationPhase.cpp:
1386 * dfg/DFGByteCodeParser.cpp:
1387 (JSC::DFG::ByteCodeParser::setDirect):
1388 (JSC::DFG::ByteCodeParser::currentNodeOrigin):
1389 (JSC::DFG::ByteCodeParser::branchData):
1390 (JSC::DFG::ByteCodeParser::addToGraph):
1391 (JSC::DFG::ByteCodeParser::handleCall):
1392 (JSC::DFG::ByteCodeParser::inlineCall):
1393 (JSC::DFG::ByteCodeParser::handleInlining):
1394 (JSC::DFG::ByteCodeParser::handleGetById):
1395 (JSC::DFG::ByteCodeParser::handlePutById):
1396 (JSC::DFG::ByteCodeParser::parseBlock):
1397 * dfg/DFGCFGSimplificationPhase.cpp:
1398 (JSC::DFG::CFGSimplificationPhase::run):
1399 * dfg/DFGClobberize.h:
1400 (JSC::DFG::clobberize):
1401 * dfg/DFGClobbersExitState.cpp: Added.
1402 (JSC::DFG::clobbersExitState):
1403 * dfg/DFGClobbersExitState.h: Added.
1404 * dfg/DFGConstantFoldingPhase.cpp:
1405 (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
1406 * dfg/DFGDoesGC.cpp:
1408 * dfg/DFGFixupPhase.cpp:
1409 (JSC::DFG::FixupPhase::fixupNode):
1410 (JSC::DFG::FixupPhase::convertStringAddUse):
1411 (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1412 (JSC::DFG::FixupPhase::fixupGetAndSetLocalsInBlock):
1413 (JSC::DFG::FixupPhase::fixupChecksInBlock):
1414 * dfg/DFGFlushFormat.h:
1415 (JSC::DFG::useKindFor):
1416 (JSC::DFG::uncheckedUseKindFor):
1417 (JSC::DFG::typeFilterFor):
1419 (JSC::DFG::printWhiteSpace):
1420 (JSC::DFG::Graph::dumpCodeOrigin):
1421 (JSC::DFG::Graph::dump):
1423 (JSC::DFG::Graph::addSpeculationMode):
1424 * dfg/DFGInsertionSet.cpp:
1425 (JSC::DFG::InsertionSet::insertSlow):
1426 (JSC::DFG::InsertionSet::execute):
1427 * dfg/DFGLoopPreHeaderCreationPhase.cpp:
1428 (JSC::DFG::LoopPreHeaderCreationPhase::run):
1429 * dfg/DFGMayExit.cpp:
1430 (JSC::DFG::mayExit):
1431 (WTF::printInternal):
1433 * dfg/DFGMovHintRemovalPhase.cpp:
1434 * dfg/DFGNodeOrigin.cpp: Added.
1435 (JSC::DFG::NodeOrigin::dump):
1436 * dfg/DFGNodeOrigin.h:
1437 (JSC::DFG::NodeOrigin::NodeOrigin):
1438 (JSC::DFG::NodeOrigin::isSet):
1439 (JSC::DFG::NodeOrigin::withSemantic):
1440 (JSC::DFG::NodeOrigin::withExitOK):
1441 (JSC::DFG::NodeOrigin::withInvalidExit):
1442 (JSC::DFG::NodeOrigin::takeValidExit):
1443 (JSC::DFG::NodeOrigin::forInsertingAfter):
1444 (JSC::DFG::NodeOrigin::operator==):
1445 (JSC::DFG::NodeOrigin::operator!=):
1446 * dfg/DFGNodeType.h:
1447 * dfg/DFGOSREntrypointCreationPhase.cpp:
1448 (JSC::DFG::OSREntrypointCreationPhase::run):
1449 * dfg/DFGOSRExit.cpp:
1450 (JSC::DFG::OSRExit::OSRExit):
1451 (JSC::DFG::OSRExit::setPatchableCodeOffset):
1452 * dfg/DFGOSRExitBase.h:
1453 * dfg/DFGObjectAllocationSinkingPhase.cpp:
1454 * dfg/DFGPhantomInsertionPhase.cpp:
1456 (JSC::DFG::Phase::validate):
1457 (JSC::DFG::Phase::beginPhase):
1458 (JSC::DFG::Phase::endPhase):
1460 (JSC::DFG::Phase::vm):
1461 (JSC::DFG::Phase::codeBlock):
1462 (JSC::DFG::Phase::profiledBlock):
1463 * dfg/DFGPredictionPropagationPhase.cpp:
1464 (JSC::DFG::PredictionPropagationPhase::propagate):
1465 * dfg/DFGPutStackSinkingPhase.cpp:
1466 * dfg/DFGSSAConversionPhase.cpp:
1467 (JSC::DFG::SSAConversionPhase::run):
1468 * dfg/DFGSafeToExecute.h:
1469 (JSC::DFG::safeToExecute):
1470 * dfg/DFGSpeculativeJIT.cpp:
1471 (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
1472 (JSC::DFG::SpeculativeJIT::speculationCheck):
1473 (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
1474 (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
1475 (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1476 (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
1477 (JSC::DFG::SpeculativeJIT::compile):
1478 * dfg/DFGSpeculativeJIT.h:
1479 * dfg/DFGSpeculativeJIT32_64.cpp:
1480 (JSC::DFG::SpeculativeJIT::compile):
1481 * dfg/DFGSpeculativeJIT64.cpp:
1482 (JSC::DFG::SpeculativeJIT::compile):
1483 * dfg/DFGStoreBarrierInsertionPhase.cpp:
1484 * dfg/DFGTypeCheckHoistingPhase.cpp:
1485 (JSC::DFG::TypeCheckHoistingPhase::run):
1486 * dfg/DFGValidate.cpp:
1487 (JSC::DFG::Validate::validate):
1488 * ftl/FTLCapabilities.cpp:
1489 (JSC::FTL::canCompile):
1490 * ftl/FTLLowerDFGToLLVM.cpp:
1491 (JSC::FTL::DFG::LowerDFGToLLVM::lower):
1492 (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
1493 (JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon):
1494 (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
1495 (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
1497 2015-08-26 Andreas Kling <akling@apple.com>
1499 [JSC] StructureTransitionTable should eagerly deallocate single-transition WeakImpls.
1500 <https://webkit.org/b/148478>
1502 Reviewed by Geoffrey Garen.
1504 Use a WeakHandleOwner to eagerly deallocate StructureTransitionTable's Weak pointers
1505 when it's using the single-transition optimization and the Structure it transitioned
1508 This prevents Structures from keeping WeakBlocks alive longer than necessary when
1509 they've been transitioned away from but are still in use themselves.
1511 * runtime/Structure.cpp:
1512 (JSC::singleSlotTransitionWeakOwner):
1513 (JSC::StructureTransitionTable::singleTransition):
1514 (JSC::StructureTransitionTable::setSingleTransition):
1515 (JSC::StructureTransitionTable::add):
1516 * runtime/StructureTransitionTable.h:
1517 (JSC::StructureTransitionTable::singleTransition): Deleted.
1518 (JSC::StructureTransitionTable::setSingleTransition): Deleted.
1520 2015-08-26 Brian Burg <bburg@apple.com>
1522 Web Inspector: REGRESSION(r188965): BackendDispatcher loses request ids when called re-entrantly
1523 https://bugs.webkit.org/show_bug.cgi?id=148480
1525 Reviewed by Joseph Pecoraro.
1527 I added an assertion that m_currentRequestId is Nullopt when dispatch() is called, but this should
1528 not hold if dispatching a backend command while debugger is paused. I will remove the assertion
1529 and add proper scoping for all dispatch() branches.
1531 No new tests, this wrong assert caused inspector/dom-debugger/node-removed.html to crash reliably.
1533 * inspector/InspectorBackendDispatcher.cpp:
1534 (Inspector::BackendDispatcher::dispatch): Cover each exit with an appropriate TemporaryChange scope.
1536 2015-08-26 Sukolsak Sakshuwong <sukolsak@gmail.com>
1538 Remove the unused *Executable::unlinkCalls() and CodeBlock::unlinkCalls()
1539 https://bugs.webkit.org/show_bug.cgi?id=148469
1541 Reviewed by Geoffrey Garen.
1543 We use CodeBlock::unlinkIncomingCalls() to unlink calls.
1544 (...)Executable::unlinkCalls() and CodeBlock::unlinkCalls() are no longer used.
1546 * bytecode/CodeBlock.cpp:
1547 (JSC::CodeBlock::unlinkCalls): Deleted.
1548 * bytecode/CodeBlock.h:
1549 * runtime/Executable.cpp:
1550 (JSC::EvalExecutable::unlinkCalls): Deleted.
1551 (JSC::ProgramExecutable::unlinkCalls): Deleted.
1552 (JSC::FunctionExecutable::unlinkCalls): Deleted.
1553 * runtime/Executable.h:
1554 (JSC::ScriptExecutable::unlinkCalls): Deleted.
1556 2015-08-25 Brian Burg <bburg@apple.com>
1558 Web Inspector: no need to allocate protocolErrors array for every dispatched backend command
1559 https://bugs.webkit.org/show_bug.cgi?id=146466
1561 Reviewed by Joseph Pecoraro.
1563 Clean up some of the backend dispatcher code, with a focus on eliminating useless allocations
1564 of objects in the common case when no protocol errors happen. This is done by saving the
1565 current id of each request as it is being processed by the backend dispatcher, and tagging any
1566 subsequent errors with that id. This also means we don't have to thread the requestId except
1567 in the async command code path.
1569 This patch also lifts some common code shared between all generated backend command
1570 implementatations into the per-domain dispatch method instead. This reduces generated code size.
1572 To be consistent, this patch standardizes on calling the id of a backend message its 'requestId'.
1573 Requests can be handled synchronously or asynchronously (triggered via the 'async' property).
1575 No new tests, covered by existing protocol tests.
1577 * inspector/InspectorBackendDispatcher.cpp:
1578 (Inspector::BackendDispatcher::CallbackBase::CallbackBase): Split the two code paths for reporting
1579 success and failure.
1581 (Inspector::BackendDispatcher::CallbackBase::sendFailure):
1582 (Inspector::BackendDispatcher::CallbackBase::sendSuccess): Renamed from sendIfActive.
1583 (Inspector::BackendDispatcher::dispatch): Reset counters and current requestId before dispatching.
1584 No need to manually thread the requestId to all reportProtocolError calls.
1586 (Inspector::BackendDispatcher::hasProtocolErrors): Added.
1587 (Inspector::BackendDispatcher::sendResponse):
1588 (Inspector::BackendDispatcher::sendPendingErrors): Send any saved protocol errors to the frontend.
1589 Always send a 'data' member with all of the errors, even if there's just one. We might want to add
1590 more information about errors later.
1592 (Inspector::BackendDispatcher::reportProtocolError): Enqueue a protocol error to be sent later.
1593 (Inspector::BackendDispatcher::getPropertyValue): Remove useless type parameters and nuke most of
1594 the type conversion methods. Use std::function types instead of function pointer types.
1596 (Inspector::castToInteger): Added.
1597 (Inspector::castToNumber): Added.
1598 (Inspector::BackendDispatcher::getInteger):
1599 (Inspector::BackendDispatcher::getDouble):
1600 (Inspector::BackendDispatcher::getString):
1601 (Inspector::BackendDispatcher::getBoolean):
1602 (Inspector::BackendDispatcher::getObject):
1603 (Inspector::BackendDispatcher::getArray):
1604 (Inspector::BackendDispatcher::getValue):
1605 (Inspector::getPropertyValue): Deleted.
1606 (Inspector::AsMethodBridges::asInteger): Deleted.
1607 (Inspector::AsMethodBridges::asDouble): Deleted.
1608 (Inspector::AsMethodBridges::asString): Deleted.
1609 (Inspector::AsMethodBridges::asBoolean): Deleted.
1610 (Inspector::AsMethodBridges::asObject): Deleted.
1611 (Inspector::AsMethodBridges::asArray): Deleted.
1612 (Inspector::AsMethodBridges::asValue): Deleted.
1613 * inspector/InspectorBackendDispatcher.h:
1614 * inspector/scripts/codegen/cpp_generator_templates.py: Extract 'params' object in domain dispatch method.
1615 Omit requestIds where possible. Convert dispatch tables to use NeverDestroyed. Check the protocol error count
1616 to decide whether to abort the dispatch or not, rather than allocating our own errors array.
1618 * inspector/scripts/codegen/cpp_generator_templates.py:
1620 * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: Revert to passing RefPtr<InspectorObject>
1621 since parameters are now being passed rather than the message object. Some commands do not require parameters.
1622 * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
1623 (CppBackendDispatcherImplementationGenerator.generate_output):
1624 (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
1625 (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
1626 * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
1627 (ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declaration_for_command):
1628 * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
1629 (ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_command):
1630 (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
1631 * inspector/scripts/codegen/objc_generator_templates.py:
1633 Rebaseline some protocol generator tests.
1634 * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
1635 * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
1636 * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
1637 * inspector/scripts/tests/expected/enum-values.json-result:
1638 * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
1639 * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
1640 * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
1641 * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
1642 * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
1643 * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
1644 * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
1645 * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
1646 * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
1648 2015-08-25 Saam barati <sbarati@apple.com>
1650 Lets rename codeOriginIndex to callSiteIndex and get rid of CallFrame::Location.
1651 https://bugs.webkit.org/show_bug.cgi?id=148213
1653 Reviewed by Filip Pizlo.
1655 This patch introduces a struct called CallSiteIndex which is
1656 used as a wrapper for a 32-bit int to place things in the tag for ArgumentCount
1657 in the call frame. On 32-bit we place Instruction* into this slot for LLInt and Basline.
1658 For 32-bit DFG we place a an index into the code origin table in this slot.
1659 On 64-bit we place a bytecode offset into this slot for LLInt and Baseline.
1660 On 64-bit we place the index into the code origin table in this slot in the
1663 This patch also gets rid of the encoding scheme that describes if something is a
1664 bytecode index or a code origin table index. This information can always
1665 be determined based on the CodeBlock's' JITType.
1667 StructureStubInfo now also has a CallSiteIndex which it stores to
1668 the call frame when making a call.
1670 * bytecode/CodeBlock.h:
1671 (JSC::CodeBlock::hasCodeOrigins):
1672 (JSC::CodeBlock::canGetCodeOrigin):
1673 (JSC::CodeBlock::codeOrigin):
1674 (JSC::CodeBlock::addFrequentExitSite):
1675 * bytecode/StructureStubInfo.h:
1676 (JSC::StructureStubInfo::StructureStubInfo):
1677 * dfg/DFGCommonData.cpp:
1678 (JSC::DFG::CommonData::notifyCompilingStructureTransition):
1679 (JSC::DFG::CommonData::addCodeOrigin):
1680 (JSC::DFG::CommonData::shrinkToFit):
1681 * dfg/DFGCommonData.h:
1682 (JSC::DFG::CommonData::CommonData):
1683 * dfg/DFGJITCompiler.h:
1684 (JSC::DFG::JITCompiler::setEndOfCode):
1685 (JSC::DFG::JITCompiler::addCallSite):
1686 (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
1687 * dfg/DFGOSRExitCompilerCommon.cpp:
1688 (JSC::DFG::reifyInlinedCallFrames):
1689 * dfg/DFGSpeculativeJIT.cpp:
1690 (JSC::DFG::SpeculativeJIT::compileIn):
1691 * dfg/DFGSpeculativeJIT32_64.cpp:
1692 (JSC::DFG::SpeculativeJIT::cachedGetById):
1693 (JSC::DFG::SpeculativeJIT::cachedPutById):
1694 * dfg/DFGSpeculativeJIT64.cpp:
1695 (JSC::DFG::SpeculativeJIT::cachedGetById):
1696 (JSC::DFG::SpeculativeJIT::cachedPutById):
1697 * ftl/FTLCompile.cpp:
1698 (JSC::FTL::mmAllocateDataSection):
1699 * ftl/FTLInlineCacheDescriptor.h:
1700 (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
1701 (JSC::FTL::InlineCacheDescriptor::stackmapID):
1702 (JSC::FTL::InlineCacheDescriptor::callSiteIndex):
1703 (JSC::FTL::InlineCacheDescriptor::uid):
1704 (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
1705 (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
1706 (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
1707 (JSC::FTL::InlineCacheDescriptor::codeOrigin): Deleted.
1710 * ftl/FTLLowerDFGToLLVM.cpp:
1711 (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
1712 (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
1713 (JSC::FTL::DFG::LowerDFGToLLVM::getById):
1714 (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
1715 * ftl/FTLSlowPathCall.cpp:
1716 (JSC::FTL::storeCodeOrigin):
1717 * interpreter/CallFrame.cpp:
1718 (JSC::CallFrame::currentVPC):
1719 (JSC::CallFrame::setCurrentVPC):
1720 (JSC::CallFrame::callSiteBitsAsBytecodeOffset):
1721 (JSC::CallFrame::bytecodeOffset):
1722 (JSC::CallFrame::codeOrigin):
1723 (JSC::CallFrame::topOfFrameInternal):
1724 (JSC::CallFrame::locationAsBytecodeOffset): Deleted.
1725 (JSC::CallFrame::setLocationAsBytecodeOffset): Deleted.
1726 (JSC::CallFrame::bytecodeOffsetFromCodeOriginIndex): Deleted.
1727 * interpreter/CallFrame.h:
1728 (JSC::CallSiteIndex::CallSiteIndex):
1729 (JSC::CallSiteIndex::bits):
1730 (JSC::ExecState::returnPCOffset):
1731 (JSC::ExecState::abstractReturnPC):
1732 (JSC::ExecState::topOfFrame):
1733 (JSC::ExecState::setCallerFrame):
1734 (JSC::ExecState::setScope):
1735 (JSC::ExecState::currentVPC): Deleted.
1736 (JSC::ExecState::setCurrentVPC): Deleted.
1737 * interpreter/CallFrameInlines.h:
1738 (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
1739 (JSC::CallFrame::callSiteBitsAreCodeOriginIndex):
1740 (JSC::CallFrame::callSiteAsRawBits):
1741 (JSC::CallFrame::callSiteIndex):
1742 (JSC::CallFrame::hasActivation):
1743 (JSC::CallFrame::Location::encode): Deleted.
1744 (JSC::CallFrame::Location::decode): Deleted.
1745 (JSC::CallFrame::Location::encodeAsBytecodeOffset): Deleted.
1746 (JSC::CallFrame::Location::encodeAsBytecodeInstruction): Deleted.
1747 (JSC::CallFrame::Location::encodeAsCodeOriginIndex): Deleted.
1748 (JSC::CallFrame::Location::isBytecodeLocation): Deleted.
1749 (JSC::CallFrame::Location::isCodeOriginIndex): Deleted.
1750 (JSC::CallFrame::hasLocationAsBytecodeOffset): Deleted.
1751 (JSC::CallFrame::hasLocationAsCodeOriginIndex): Deleted.
1752 (JSC::CallFrame::locationAsRawBits): Deleted.
1753 (JSC::CallFrame::setLocationAsRawBits): Deleted.
1754 (JSC::CallFrame::locationAsBytecodeOffset): Deleted.
1755 (JSC::CallFrame::setLocationAsBytecodeOffset): Deleted.
1756 (JSC::CallFrame::locationAsCodeOriginIndex): Deleted.
1757 * interpreter/StackVisitor.cpp:
1758 (JSC::StackVisitor::readFrame):
1759 (JSC::StackVisitor::readNonInlinedFrame):
1760 (JSC::StackVisitor::Frame::print):
1762 (JSC::JIT::compileOpCall):
1763 * jit/JITCall32_64.cpp:
1764 (JSC::JIT::compileOpCall):
1765 * jit/JITInlineCacheGenerator.cpp:
1766 (JSC::garbageStubInfo):
1767 (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
1768 (JSC::JITByIdGenerator::JITByIdGenerator):
1769 (JSC::JITByIdGenerator::generateFastPathChecks):
1770 (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1771 (JSC::JITGetByIdGenerator::generateFastPath):
1772 (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
1773 * jit/JITInlineCacheGenerator.h:
1774 (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
1775 (JSC::JITInlineCacheGenerator::stubInfo):
1776 (JSC::JITByIdGenerator::JITByIdGenerator):
1777 (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1778 (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
1780 (JSC::JIT::updateTopCallFrame):
1781 * jit/JITOperations.cpp:
1783 (JSC::tryGetByValOptimize):
1784 * jit/JITPropertyAccess.cpp:
1785 (JSC::JIT::emitGetByValWithCachedId):
1786 (JSC::JIT::emitPutByValWithCachedId):
1787 (JSC::JIT::emit_op_get_by_id):
1788 (JSC::JIT::emit_op_put_by_id):
1789 * jit/JITPropertyAccess32_64.cpp:
1790 (JSC::JIT::emitGetByValWithCachedId):
1791 (JSC::JIT::emitPutByValWithCachedId):
1792 (JSC::JIT::emit_op_get_by_id):
1793 (JSC::JIT::emit_op_put_by_id):
1795 (JSC::generateByIdStub):
1797 2015-08-25 Aleksandr Skachkov <gskachkov@gmail.com>
1799 Function.prototype.toString is incorrect for ArrowFunction
1800 https://bugs.webkit.org/show_bug.cgi?id=148148
1802 Reviewed by Saam Barati.
1804 Added correct support of toString() method for arrow function.
1806 * parser/ASTBuilder.h:
1807 (JSC::ASTBuilder::createFunctionMetadata):
1808 (JSC::ASTBuilder::createArrowFunctionExpr):
1810 (JSC::FunctionMetadataNode::FunctionMetadataNode):
1812 * parser/Parser.cpp:
1813 (JSC::Parser<LexerType>::parseFunctionBody):
1814 (JSC::Parser<LexerType>::parseFunctionInfo):
1815 * parser/SyntaxChecker.h:
1816 (JSC::SyntaxChecker::createFunctionMetadata):
1817 * runtime/FunctionPrototype.cpp:
1818 (JSC::functionProtoFuncToString):
1819 * tests/stress/arrowfunction-tostring.js: Added.
1821 2015-08-25 Saam barati <sbarati@apple.com>
1823 Callee can be incorrectly overridden when it's captured
1824 https://bugs.webkit.org/show_bug.cgi?id=148400
1826 Reviewed by Filip Pizlo.
1828 We now resort to always creating the function name scope
1829 when the function name is in scope. Because the bytecode
1830 generator now has a notion of local lexical scoping,
1831 this incurs no runtime penalty for function expression names
1832 that aren't heap allocated. If they are heap allocated,
1833 this means we may now have one more scope on the runtime
1834 scope stack than before. This modification simplifies the
1835 callee initialization code and uses the lexical scoping constructs
1836 to implement this. This implementation also ensures
1837 that everything Just Works for function's with default
1838 parameter values. Before this patch, IIFE functions
1839 with default parameter values and a captured function
1840 name would crash JSC.
1842 * bytecompiler/BytecodeGenerator.cpp:
1843 (JSC::BytecodeGenerator::BytecodeGenerator):
1844 (JSC::BytecodeGenerator::pushLexicalScopeInternal):
1845 (JSC::BytecodeGenerator::popLexicalScopeInternal):
1846 (JSC::BytecodeGenerator::variable):
1847 (JSC::BytecodeGenerator::resolveType):
1848 (JSC::BytecodeGenerator::emitThrowTypeError):
1849 (JSC::BytecodeGenerator::emitPushFunctionNameScope):
1850 (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
1851 * bytecompiler/BytecodeGenerator.h:
1852 (JSC::Variable::isReadOnly):
1853 (JSC::Variable::isSpecial):
1854 (JSC::Variable::isConst):
1855 (JSC::Variable::setIsReadOnly):
1856 * bytecompiler/NodesCodegen.cpp:
1857 (JSC::PostfixNode::emitResolve):
1858 (JSC::PrefixNode::emitResolve):
1859 (JSC::ReadModifyResolveNode::emitBytecode):
1860 (JSC::AssignResolveNode::emitBytecode):
1861 (JSC::BindingNode::bindValue):
1862 * tests/stress/IIFE-es6-default-parameters.js: Added.
1865 * tests/stress/IIFE-function-name-captured.js: Added.
1869 2015-08-24 Brian Burg <bburg@apple.com>
1871 Web Inspector: add protocol test for existing error handling performed by the backend
1872 https://bugs.webkit.org/show_bug.cgi?id=147097
1874 Reviewed by Joseph Pecoraro.
1876 A new test revealed that the protocol "method" parameter was being parsed in a naive way.
1877 Rewrite it to use String::split and improve error checking to avoid failing later.
1879 * inspector/InspectorBackendDispatcher.cpp:
1880 (Inspector::BackendDispatcher::dispatch):
1882 2015-08-24 Yusuke Suzuki <utatane.tea@gmail.com>
1884 [ES6] Return JSInternalPromise as result of evaluateModule
1885 https://bugs.webkit.org/show_bug.cgi?id=148173
1887 Reviewed by Saam Barati.
1889 Now evaluateModule returns JSInternalPromise* as its result value.
1890 When an error occurs while loading or executing the modules,
1891 this promise is rejected by that error. By leveraging this, we implemented
1892 asynchronous error reporting when executing the modules in JSC shell.
1894 And this patch also changes the evaluateModule signature to accept the entry
1895 point by the moduleName. By using it, JSC shell can start executing the modules
1896 with the entry point module name.
1898 * builtins/ModuleLoaderObject.js:
1903 * runtime/Completion.cpp:
1904 (JSC::evaluateModule):
1905 * runtime/Completion.h:
1906 * runtime/JSInternalPromise.cpp:
1907 (JSC::JSInternalPromise::then):
1908 * runtime/JSInternalPromise.h:
1909 * runtime/ModuleLoaderObject.cpp:
1910 (JSC::ModuleLoaderObject::requestInstantiateAll):
1911 (JSC::ModuleLoaderObject::loadModule):
1912 (JSC::ModuleLoaderObject::resolve):
1913 (JSC::ModuleLoaderObject::fetch):
1914 (JSC::ModuleLoaderObject::translate):
1915 (JSC::ModuleLoaderObject::instantiate):
1916 (JSC::moduleLoaderObjectParseModule):
1917 * runtime/ModuleLoaderObject.h:
1919 2015-08-24 Basile Clement <basile_clement@apple.com>
1921 REPTACH is not a word
1922 https://bugs.webkit.org/show_bug.cgi?id=148401
1924 Reviewed by Saam Barati.
1926 * assembler/MacroAssemblerX86_64.h:
1927 (JSC::MacroAssemblerX86_64::callWithSlowPathReturnType):
1928 (JSC::MacroAssemblerX86_64::call):
1929 (JSC::MacroAssemblerX86_64::tailRecursiveCall):
1930 (JSC::MacroAssemblerX86_64::makeTailRecursiveCall):
1931 (JSC::MacroAssemblerX86_64::readCallTarget):
1932 (JSC::MacroAssemblerX86_64::linkCall):
1933 (JSC::MacroAssemblerX86_64::repatchCall):
1935 2015-08-24 Mark Lam <mark.lam@apple.com>
1937 Add support for setting JSC options from a file.
1938 https://bugs.webkit.org/show_bug.cgi?id=148394
1940 Reviewed by Saam Barati.
1942 This is needed for environments where the JSC executable does not have access to
1943 environmental variables. This is only needed for debugging, and is currently
1944 guarded under a #define USE_OPTIONS_FILE in Options.cpp, and is disabled by
1947 Also fixed Options::setOptions() to be allow for whitespace that is not a single
1948 ' '. This makes setOptions() much more flexible and friendlier to use for loading
1951 For example, this current use case of loading options from a file may have '\n's
1952 in the character stream, and this feature is easier to implement if setOptions()
1953 just support more than 1 whitespace char between options, and recognize whitespace
1954 characters other than ' '.
1956 * runtime/Options.cpp:
1958 (JSC::Options::initialize):
1959 (JSC::Options::setOptions):
1961 2015-08-24 Filip Pizlo <fpizlo@apple.com>
1963 DFG::FixupPhase should use the lambda form of m_graph.doToChildren() rather than the old macro
1964 https://bugs.webkit.org/show_bug.cgi?id=148397
1966 Reviewed by Geoffrey Garen.
1968 We used to iterate the edges of a node by using the DFG_NODE_DO_TO_CHILDREN macro. We
1969 don't need to do that anymore since we have the lambda-based m_graph.doToChildren(). This
1970 allows us to get rid of a bunch of helper methods in DFG::FixupPhase.
1972 I also took the opportunity to give the injectTypeConversionsInBlock() method a more
1973 generic name, since after https://bugs.webkit.org/show_bug.cgi?id=145204 it will be used
1974 for fix-up of checks more broadly.
1976 * dfg/DFGFixupPhase.cpp:
1977 (JSC::DFG::FixupPhase::run):
1978 (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
1979 (JSC::DFG::FixupPhase::fixupChecksInBlock):
1980 (JSC::DFG::FixupPhase::injectTypeConversionsInBlock): Deleted.
1981 (JSC::DFG::FixupPhase::tryToRelaxRepresentation): Deleted.
1982 (JSC::DFG::FixupPhase::fixEdgeRepresentation): Deleted.
1983 (JSC::DFG::FixupPhase::injectTypeConversionsForEdge): Deleted.
1985 2015-08-24 Geoffrey Garen <ggaren@apple.com>
1987 Some renaming to clarify CodeBlock and UnlinkedCodeBlock
1988 https://bugs.webkit.org/show_bug.cgi?id=148391
1990 Reviewed by Saam Barati.
1992 * bytecode/UnlinkedFunctionExecutable.cpp:
1993 (JSC::generateUnlinkedFunctionCodeBlock):
1994 (JSC::UnlinkedFunctionExecutable::visitChildren):
1995 (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
1996 (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
1997 (JSC::generateFunctionCodeBlock): Deleted.
1998 (JSC::UnlinkedFunctionExecutable::codeBlockFor): Deleted.
1999 * bytecode/UnlinkedFunctionExecutable.h: Call our CodeBlocks "unlinked"
2000 in the name for clarity, since we are unlinked.
2003 (JSC::Heap::objectTypeCounts):
2004 (JSC::Heap::deleteAllCodeBlocks):
2005 (JSC::Heap::deleteAllUnlinkedCodeBlocks):
2006 (JSC::Heap::clearUnmarkedExecutables):
2007 (JSC::Heap::deleteOldCode):
2008 (JSC::Heap::FinalizerOwner::finalize):
2009 (JSC::Heap::addExecutable):
2010 (JSC::Heap::collectAllGarbageIfNotDoneRecently):
2011 (JSC::Heap::deleteAllCompiledCode): Deleted.
2012 (JSC::Heap::deleteAllUnlinkedFunctionCode): Deleted.
2013 (JSC::Heap::addCompiledCode): Deleted.
2015 (JSC::Heap::notifyIsSafeToCollect):
2016 (JSC::Heap::isSafeToCollect):
2017 (JSC::Heap::sizeBeforeLastFullCollection):
2018 (JSC::Heap::sizeAfterLastFullCollection):
2019 (JSC::Heap::compiledCode): Deleted.
2021 deleteAllCompiledCode => deleteAllCodeBlocks because "compiled"
2022 is a broad phrase these days.
2024 m_compiledCode => m_executables for the same reason.
2026 addCompiledCode => addExecutable for the same reason.
2028 deleteAllUnlinkedFunctionCode => deleteAllUnlinkedCodeBlocks
2032 (functionDeleteAllCompiledCode):
2034 * runtime/Executable.cpp:
2035 (JSC::ScriptExecutable::newCodeBlockFor): codeBlockFor => unlinkedCodeBlockFor
2037 (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation): Deleted.
2038 It was strange to put this function on executable, since its name implied
2039 that it only changed the executable, but it actually changed all cached
2040 code. Now, a client that wants to change cached code must do so explicitly.
2042 * runtime/Executable.h:
2043 (JSC::ScriptExecutable::finishCreation):
2045 (JSC::VM::deleteAllCode):
2046 * runtime/VMEntryScope.cpp:
2047 (JSC::VMEntryScope::VMEntryScope): Updated for renames above.
2049 2015-08-22 Filip Pizlo <fpizlo@apple.com>
2051 DFG::InsertionSet should be tolerant of occasional out-of-order insertions
2052 https://bugs.webkit.org/show_bug.cgi?id=148367
2054 Reviewed by Geoffrey Garen and Saam Barati.
2056 Since forever, the DFG::InsertionSet has been the way we insert nodes into DFG IR, and it
2057 requires that you walk a block in order and perform insertions in order: you can't insert
2058 something at index J, then at index I where I < J, except if you do a second pass.
2060 This restriction makes sense, because it enables a very fast algorithm. And it's very
2061 rare that a phase would need to insert things out of order.
2063 But sometimes - rarely - we need to insert things slightly out-of-order. For example we
2064 may want to insert a node at index J, but to insert a check associated with that node, we
2065 may need to use index I where I < J. This will come up from the work on
2066 https://bugs.webkit.org/show_bug.cgi?id=145204. And it has already come up in the past.
2067 It seems like it would be best to just lift this restriction.
2070 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2071 * JavaScriptCore.xcodeproj/project.pbxproj:
2072 * dfg/DFGInsertionSet.cpp: Added.
2073 (JSC::DFG::InsertionSet::insertSlow):
2074 * dfg/DFGInsertionSet.h:
2075 (JSC::DFG::InsertionSet::InsertionSet):
2076 (JSC::DFG::InsertionSet::graph):
2077 (JSC::DFG::InsertionSet::insert):
2078 (JSC::DFG::InsertionSet::execute):
2080 2015-08-24 Yusuke Suzuki <utatane.tea@gmail.com>
2082 Create ById IC for ByVal operation only when the specific Id comes more than once
2083 https://bugs.webkit.org/show_bug.cgi?id=148288
2085 Reviewed by Geoffrey Garen.
2087 After introducing byId ICs into byVal ops, byVal ops creates much ICs than before.
2088 The failure fixed in r188767 figures out these ICs are created even if this op is executed only once.
2090 The situation is the following;
2091 In the current code, when byVal op is executed with the Id, we immediately set up the byId IC for that byVal op.
2092 But setting up JITGetByIdGenerator generates the fast path IC code and consumes executable memory.
2093 As a result, if we call eval("contains byVal ops") with the different strings repeatedly under no-llint environment, each eval call creates byId IC for byVal and consumes executable memory.
2095 To solve it, we will add "seen" flag to ByValInfo.
2096 And we will create the IC on the second byVal op call with the same Id.
2098 * bytecode/ByValInfo.h:
2099 (JSC::ByValInfo::ByValInfo):
2100 * jit/JITOperations.cpp:
2101 (JSC::tryGetByValOptimize):
2102 * jit/JITPropertyAccess.cpp:
2103 (JSC::JIT::privateCompileGetByValWithCachedId): Deleted.
2104 (JSC::JIT::privateCompilePutByValWithCachedId): Deleted.
2106 2015-08-23 Benjamin Poulain <bpoulain@apple.com>
2108 [JSC] Get rid of NodePointerTraits
2109 https://bugs.webkit.org/show_bug.cgi?id=148340
2111 Reviewed by Anders Carlsson.
2113 NodePointerTraits does exactly the same thing has the default trait.
2115 * dfg/DFGBasicBlock.h:
2117 (JSC::DFG::NodePointerTraits::defaultValue): Deleted.
2118 (JSC::DFG::NodePointerTraits::isEmptyForDump): Deleted.
2120 2015-08-23 Benjamin Poulain <bpoulain@apple.com>
2122 [JSC] Reduce the memory usage of BytecodeLivenessAnalysis
2123 https://bugs.webkit.org/show_bug.cgi?id=148353
2125 Reviewed by Darin Adler.
2127 BytecodeLivenessAnalysis easily takes kilobytes of memory for
2128 non trivial blocks and that memory sticks around because
2129 it stored on CodeBlock.
2131 This patch reduces that memory use a bit.
2133 Most of the memory is in the array of BytecodeBasicBlock.
2134 BytecodeBasicBlock is shrunk by:
2135 -Making it not ref-counted.
2136 -Removing m_predecessors, it was only used for debugging and
2138 -Added a shrinkToFit() phase to shrink the vectors once we are
2139 done building the BytecodeBasicBlock.
2141 There are more things we should do in the future:
2142 -Store all the BytecodeBasicBlock direclty in the array.
2143 We know the size ahead of time, this would be a pure win.
2144 The only tricky part is changing m_successors to have the
2145 index of the successor instead of a pointer.
2146 -Stop putting duplicates in m_successors.
2148 * bytecode/BytecodeBasicBlock.cpp:
2149 (JSC::computeBytecodeBasicBlocks):
2150 (JSC::BytecodeBasicBlock::shrinkToFit): Deleted.
2151 (JSC::linkBlocks): Deleted.
2152 * bytecode/BytecodeBasicBlock.h:
2153 (JSC::BytecodeBasicBlock::addSuccessor):
2154 (JSC::BytecodeBasicBlock::addPredecessor): Deleted.
2155 (JSC::BytecodeBasicBlock::predecessors): Deleted.
2156 * bytecode/BytecodeLivenessAnalysis.cpp:
2157 (JSC::getLeaderOffsetForBasicBlock):
2158 (JSC::findBasicBlockWithLeaderOffset):
2159 (JSC::findBasicBlockForBytecodeOffset):
2160 (JSC::stepOverInstruction):
2161 (JSC::computeLocalLivenessForBytecodeOffset):
2162 (JSC::computeLocalLivenessForBlock):
2163 (JSC::BytecodeLivenessAnalysis::dumpResults): Deleted.
2164 * bytecode/BytecodeLivenessAnalysis.h:
2166 2015-08-23 Geoffrey Garen <ggaren@apple.com>
2168 Unreviewed, rolling back in r188792.
2169 https://bugs.webkit.org/show_bug.cgi?id=148347
2171 Previously reverted changesets:
2173 "Unify code paths for manually deleting all code"
2174 https://bugs.webkit.org/show_bug.cgi?id=148280
2175 http://trac.webkit.org/changeset/188792
2177 The previous patch caused some inspector tests to hang because it
2178 introduced extra calls to sourceParsed, and sourceParsed is
2179 pathologically slow in WK1 debug builds. This patch restores pre-existing
2180 code to limit calls to sourceParsed, excluding code not being debugged
2181 (i.e., inspector code).
2183 2015-08-23 Geoffrey Garen <ggaren@apple.com>
2185 Unreviewed, rolling back in r188803.
2187 Previously reverted changesets:
2189 "Debugger's VM should never be null"
2190 https://bugs.webkit.org/show_bug.cgi?id=148341
2191 http://trac.webkit.org/changeset/188803
2193 * debugger/Debugger.cpp:
2194 (JSC::Debugger::Debugger):
2195 (JSC::Debugger::attach):
2196 (JSC::Debugger::detach):
2197 (JSC::Debugger::isAttached):
2198 (JSC::Debugger::setSteppingMode):
2199 (JSC::Debugger::registerCodeBlock):
2200 (JSC::Debugger::toggleBreakpoint):
2201 (JSC::Debugger::recompileAllJSFunctions):
2202 (JSC::Debugger::setBreakpoint):
2203 (JSC::Debugger::clearBreakpoints):
2204 (JSC::Debugger::clearDebuggerRequests):
2205 (JSC::Debugger::setBreakpointsActivated):
2206 (JSC::Debugger::breakProgram):
2207 (JSC::Debugger::stepOutOfFunction):
2208 (JSC::Debugger::returnEvent):
2209 (JSC::Debugger::didExecuteProgram):
2210 * debugger/Debugger.h:
2211 * inspector/JSGlobalObjectScriptDebugServer.cpp:
2212 (Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
2213 (Inspector::JSGlobalObjectScriptDebugServer::removeListener):
2214 (Inspector::JSGlobalObjectScriptDebugServer::runEventLoopWhilePaused):
2215 (Inspector::JSGlobalObjectScriptDebugServer::recompileAllJSFunctions): Deleted.
2216 * inspector/JSGlobalObjectScriptDebugServer.h:
2217 * inspector/ScriptDebugServer.cpp:
2218 (Inspector::ScriptDebugServer::ScriptDebugServer):
2219 * inspector/ScriptDebugServer.h:
2221 2015-08-22 Filip Pizlo <fpizlo@apple.com>
2223 DFG string concatenation shouldn't be playing fast and loose with effects and OSR exit
2224 https://bugs.webkit.org/show_bug.cgi?id=148338
2226 Reviewed by Michael Saboff and Saam Barati.
2228 Prior to this change, DFG string concatenation appeared to have various different ways of
2229 creating an OSR exit right after a side effect. That's bad, because the exit will cause
2230 us to reexecute the side effect. The code appears to have some hacks for avoiding this,
2231 but some cases are basically unavoidable, like the OOM case of string concatenation: in
2232 trunk that could cause two executions of the toString operation.
2234 This changes the string concatenation code to either be speculative or effectful but
2235 never both. It's already the case that when this code needs to be effectful, it also
2236 needs to be slow (it does int->string conversions, calls JS functions, etc). So, this is
2237 a small price to pay for sanity.
2239 The biggest part of this change is the introduction of StrCat, which is like MakeRope but
2240 does toString conversions on its own instead of relying on separate nodes. StrCat can
2241 take either 2 or 3 children. It's the effectful but not speculative version of MakeRope.
2243 * dfg/DFGAbstractInterpreterInlines.h:
2244 (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2245 * dfg/DFGBackwardsPropagationPhase.cpp:
2246 (JSC::DFG::BackwardsPropagationPhase::propagate):
2247 * dfg/DFGByteCodeParser.cpp:
2248 (JSC::DFG::ByteCodeParser::parseBlock):
2249 * dfg/DFGClobberize.h:
2250 (JSC::DFG::clobberize):
2251 * dfg/DFGDoesGC.cpp:
2253 * dfg/DFGFixupPhase.cpp:
2254 (JSC::DFG::FixupPhase::fixupNode):
2255 (JSC::DFG::FixupPhase::convertStringAddUse):
2256 (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
2257 (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
2258 (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
2259 * dfg/DFGNodeType.h:
2260 * dfg/DFGOperations.cpp:
2261 * dfg/DFGOperations.h:
2262 * dfg/DFGPredictionPropagationPhase.cpp:
2263 (JSC::DFG::PredictionPropagationPhase::propagate):
2264 * dfg/DFGSafeToExecute.h:
2265 (JSC::DFG::safeToExecute):
2266 * dfg/DFGSpeculativeJIT.h:
2267 (JSC::DFG::SpeculativeJIT::callOperation):
2268 (JSC::DFG::JSValueOperand::JSValueOperand):
2269 (JSC::DFG::JSValueOperand::~JSValueOperand):
2270 * dfg/DFGSpeculativeJIT32_64.cpp:
2271 (JSC::DFG::SpeculativeJIT::compile):
2272 * dfg/DFGSpeculativeJIT64.cpp:
2273 (JSC::DFG::SpeculativeJIT::compile):
2274 * dfg/DFGValidate.cpp:
2275 (JSC::DFG::Validate::validate):
2276 * ftl/FTLCapabilities.cpp:
2277 (JSC::FTL::canCompile):
2278 * ftl/FTLIntrinsicRepository.h:
2279 * ftl/FTLLowerDFGToLLVM.cpp:
2280 (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
2281 (JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
2282 (JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
2283 (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
2284 * jit/JITOperations.h:
2285 * tests/stress/exception-effect-strcat.js: Added. This test previously failed.
2286 * tests/stress/exception-in-strcat-string-overflow.js: Added. An earlier version of this patch made this fail.
2287 * tests/stress/exception-in-strcat.js: Added.
2289 2015-08-22 Andreas Kling <akling@apple.com>
2291 [JSC] Static hash tables should be 100% compile-time constant.
2292 <https://webkit.org/b/148359>
2294 Reviewed by Michael Saboff.
2296 We were dirtying the memory pages containing static hash tables the
2297 first time they were used, when a dynamically allocated index-to-key
2298 table was built and cached in the HashTable struct.
2300 It turns out that this "optimization" was completely useless, since
2301 we've long since decoupled static hash tables from the JSC::VM and
2302 we can get the key for an index via HashTable::values[index].m_key!
2304 We also get rid of VM::keywords which was a little wrapper around
2305 a VM-specific copy of JSC::mainTable. There was nothing VM-specific
2306 about it at all, so clients now use JSC::mainTable directly.
2308 After this change all fooHashTable structs end up in __DATA __const
2309 and no runtime initialization/allocation takes place.
2311 * create_hash_table:
2314 (JSC::isLexerKeyword):
2315 (JSC::Lexer<LChar>::parseIdentifier):
2316 (JSC::Lexer<UChar>::parseIdentifier):
2317 (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
2318 (JSC::Keywords::Keywords): Deleted.
2320 (JSC::Keywords::isKeyword): Deleted.
2321 (JSC::Keywords::getKeyword): Deleted.
2322 (JSC::Keywords::~Keywords): Deleted.
2323 * runtime/LiteralParser.cpp:
2324 (JSC::LiteralParser<CharType>::tryJSONPParse):
2325 * runtime/Lookup.cpp:
2326 (JSC::HashTable::createTable): Deleted.
2327 (JSC::HashTable::deleteTable): Deleted.
2329 (JSC::HashTable::entry):
2330 (JSC::HashTable::ConstIterator::key):
2331 (JSC::HashTable::ConstIterator::skipInvalidKeys):
2332 (JSC::HashTable::copy): Deleted.
2333 (JSC::HashTable::initializeIfNeeded): Deleted.
2334 (JSC::HashTable::begin): Deleted.
2335 (JSC::HashTable::end): Deleted.
2337 (JSC::VM::VM): Deleted.
2341 2015-08-21 Commit Queue <commit-queue@webkit.org>
2343 Unreviewed, rolling out r188792 and r188803.
2344 https://bugs.webkit.org/show_bug.cgi?id=148347
2346 broke lots of tests, ggaren is going to investigate and reland
2347 (Requested by thorton on #webkit).
2349 Reverted changesets:
2351 "Unify code paths for manually deleting all code"
2352 https://bugs.webkit.org/show_bug.cgi?id=148280
2353 http://trac.webkit.org/changeset/188792
2355 "Debugger's VM should never be null"
2356 https://bugs.webkit.org/show_bug.cgi?id=148341
2357 http://trac.webkit.org/changeset/188803
2359 2015-08-21 Sukolsak Sakshuwong <sukolsak@gmail.com>
2361 Parse control flow statements in WebAssembly
2362 https://bugs.webkit.org/show_bug.cgi?id=148333
2364 Reviewed by Geoffrey Garen.
2366 Parse control flow statements in WebAssembly files generated by pack-asmjs
2367 <https://github.com/WebAssembly/polyfill-prototype-1>.
2369 * wasm/WASMConstants.h:
2370 * wasm/WASMFunctionParser.cpp:
2371 (JSC::WASMFunctionParser::parseStatement):
2372 (JSC::WASMFunctionParser::parseIfStatement):
2373 (JSC::WASMFunctionParser::parseIfElseStatement):
2374 (JSC::WASMFunctionParser::parseWhileStatement):
2375 (JSC::WASMFunctionParser::parseDoStatement):
2376 (JSC::WASMFunctionParser::parseLabelStatement):
2377 (JSC::WASMFunctionParser::parseBreakStatement):
2378 (JSC::WASMFunctionParser::parseBreakLabelStatement):
2379 (JSC::WASMFunctionParser::parseContinueStatement):
2380 (JSC::WASMFunctionParser::parseContinueLabelStatement):
2381 (JSC::WASMFunctionParser::parseSwitchStatement):
2382 * wasm/WASMFunctionParser.h:
2383 (JSC::WASMFunctionParser::WASMFunctionParser):
2384 * wasm/WASMReader.cpp:
2385 (JSC::WASMReader::readCompactInt32):
2386 (JSC::WASMReader::readSwitchCase):
2387 * wasm/WASMReader.h:
2389 2015-08-21 Geoffrey Garen <ggaren@apple.com>
2391 Debugger's VM should never be null
2392 https://bugs.webkit.org/show_bug.cgi?id=148341
2394 Reviewed by Joseph Pecoraro.
2396 It doesn't make sense for a Debugger's VM to be null, and code related
2397 to maintaining that illusion just caused the Web Inspector to crash on
2398 launch (https://bugs.webkit.org/show_bug.cgi?id=148312). So, let's stop
2401 Now, Debugger requires its subclass to provide a never-null VM&.
2403 Also took the opportunity, based on review feedback, to remove some
2404 confusion in the virtual recompileAllJSFunctions hierarchy, by eliminating
2405 the pure virtual in ScriptDebugServer and the unnecessary override in
2406 JSGlobalObjectScriptDebugServer.
2408 * debugger/Debugger.cpp:
2409 (JSC::Debugger::Debugger):
2410 (JSC::Debugger::attach):
2411 (JSC::Debugger::detach):
2412 (JSC::Debugger::isAttached):
2413 (JSC::Debugger::setSteppingMode):
2414 (JSC::Debugger::registerCodeBlock):
2415 (JSC::Debugger::toggleBreakpoint):
2416 (JSC::Debugger::recompileAllJSFunctions):
2417 (JSC::Debugger::setBreakpoint):
2418 (JSC::Debugger::clearBreakpoints):
2419 (JSC::Debugger::clearDebuggerRequests):
2420 (JSC::Debugger::setBreakpointsActivated):
2421 (JSC::Debugger::breakProgram):
2422 (JSC::Debugger::stepOutOfFunction):
2423 (JSC::Debugger::returnEvent):
2424 (JSC::Debugger::didExecuteProgram):
2425 * debugger/Debugger.h:
2426 * inspector/JSGlobalObjectScriptDebugServer.cpp:
2427 (Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
2428 (Inspector::JSGlobalObjectScriptDebugServer::recompileAllJSFunctions):
2429 (Inspector::JSGlobalObjectScriptDebugServer::runEventLoopWhilePaused):
2430 * inspector/ScriptDebugServer.cpp:
2431 (Inspector::ScriptDebugServer::ScriptDebugServer):
2432 * inspector/ScriptDebugServer.h:
2434 2015-08-21 Basile Clement <basile_clement@apple.com>
2436 Remove unused code relative to allocation sinking
2437 https://bugs.webkit.org/show_bug.cgi?id=148342
2439 Reviewed by Mark Lam.
2441 This removes two things:
2443 - The DFGPromoteHeapAccess.h file which is a relic of the old sinking
2444 phase and is no longer used (it has been subsumed by
2445 ObjectAllocationSinking::promoteLocalHeap)
2447 - Code in the allocation sinking phase for sinking
2448 MaterializeCreateActivation and MaterializeNewObject. Handling those
2449 is no longer necessary since the phase no longer runs in a fixpoint
2450 and thus will never see those nodes, since no other phase creates
2453 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2454 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2455 * JavaScriptCore.xcodeproj/project.pbxproj:
2456 * dfg/DFGObjectAllocationSinkingPhase.cpp:
2457 * dfg/DFGPromoteHeapAccess.h: Removed.
2459 2015-08-21 Geoffrey Garen <ggaren@apple.com>
2461 Unify code paths for manually deleting all code
2462 https://bugs.webkit.org/show_bug.cgi?id=148280
2464 Reviewed by Saam Barati.
2466 We used to have three paths for manually deleting all code. Now we have
2469 * debugger/Debugger.cpp:
2470 (JSC::Debugger::attach): Notify the debugger of all previous code when
2471 it attaches. We used to do this when recompiling, which was only correct
2474 (JSC::Debugger::recompileAllJSFunctions): Switch to the shared path.
2477 (JSC::Heap::compiledCode):
2479 * inspector/agents/InspectorRuntimeAgent.cpp:
2480 (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
2481 (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
2482 (Inspector::InspectorRuntimeAgent::setTypeProfilerEnabledState):
2483 (Inspector::InspectorRuntimeAgent::getBasicBlocks):
2484 (Inspector::TypeRecompiler::visit): Deleted.
2485 (Inspector::TypeRecompiler::operator()): Deleted.
2486 (Inspector::recompileAllJSFunctionsForTypeProfiling): Deleted. Switch
2490 (JSC::VM::afterVMExit): Added a helper for scheduling an activity after
2491 VM exit. We can't delete code while it's on the stack, and we can't
2492 delete auxiliary profiling data while profiling code is on the stack,
2493 so in those cases, we schedule the deletion for the next time we exit.
2495 (JSC::VM::deleteAllCode): Use afterVMExit because we might have code
2496 on the stack when debugger, profiler, or watchdog state changes.
2500 * runtime/VMEntryScope.cpp:
2501 (JSC::VMEntryScope::VMEntryScope):
2502 (JSC::VMEntryScope::addDidPopListener):
2503 (JSC::VMEntryScope::~VMEntryScope):
2504 (JSC::VMEntryScope::setEntryScopeDidPopListener): Deleted.
2505 * runtime/VMEntryScope.h:
2506 (JSC::VMEntryScope::globalObject): Removed the uniquing feature from
2507 the scope pop listener list because we don't have a client that wants
2508 it, and it's not convenient to use correctly since you can't take
2509 the address of a member function, a lambda, or an std::function. We can
2510 add this feature back if we discover that we want it.
2512 2015-08-21 Sukolsak Sakshuwong <sukolsak@gmail.com>
2514 Implement WebAssembly function parser
2515 https://bugs.webkit.org/show_bug.cgi?id=147738
2517 Reviewed by Filip Pizlo.
2519 Implement WebAssembly function parser for WebAssembly files produced by pack-asmjs
2520 <https://github.com/WebAssembly/polyfill-prototype-1>. This patch parses only
2521 some instructions on statements and int32 expressions. Parsing of the rest
2522 will be implemented in subsequent patches. The instruction lists in WASMConstants.h
2523 are slightly modified from
2524 <https://github.com/WebAssembly/polyfill-prototype-1/blob/master/src/shared.h>.
2527 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2528 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2529 * JavaScriptCore.xcodeproj/project.pbxproj:
2530 * wasm/WASMConstants.h: Added.
2531 * wasm/WASMFormat.h:
2532 * wasm/WASMFunctionParser.cpp: Added.
2533 (JSC::WASMFunctionParser::checkSyntax):
2534 (JSC::WASMFunctionParser::parseFunction):
2535 (JSC::WASMFunctionParser::parseLocalVariables):
2536 (JSC::WASMFunctionParser::parseStatement):
2537 (JSC::WASMFunctionParser::parseSetLocalStatement):
2538 (JSC::WASMFunctionParser::parseReturnStatement):
2539 (JSC::WASMFunctionParser::parseBlockStatement):
2540 (JSC::WASMFunctionParser::parseExpression):
2541 (JSC::WASMFunctionParser::parseExpressionI32):
2542 (JSC::WASMFunctionParser::parseImmediateExpressionI32):
2543 * wasm/WASMFunctionParser.h: Added.
2544 (JSC::WASMFunctionParser::WASMFunctionParser):
2545 * wasm/WASMFunctionSyntaxChecker.h: Renamed from Source/JavaScriptCore/wasm/WASMMagicNumber.h.
2546 * wasm/WASMModuleParser.cpp:
2547 (JSC::WASMModuleParser::WASMModuleParser):
2548 (JSC::WASMModuleParser::parseFunctionDefinitionSection):
2549 (JSC::WASMModuleParser::parseFunctionDefinition):
2550 * wasm/WASMModuleParser.h:
2551 * wasm/WASMReader.cpp:
2552 (JSC::WASMReader::readType):
2553 (JSC::WASMReader::readExpressionType):
2554 (JSC::WASMReader::readExportFormat):
2555 (JSC::WASMReader::readOpStatement):
2556 (JSC::WASMReader::readOpExpressionI32):
2557 (JSC::WASMReader::readVariableTypes):
2558 (JSC::WASMReader::readOp):
2559 * wasm/WASMReader.h:
2560 (JSC::WASMReader::offset):
2561 (JSC::WASMReader::setOffset):
2563 2015-08-21 Filip Pizlo <fpizlo@apple.com>
2565 DFG::PutStackSinkingPhase doesn't need to emit KillStack nodes
2566 https://bugs.webkit.org/show_bug.cgi?id=148331
2568 Reviewed by Geoffrey Garen.
2570 PutStackSinkingPhase previously emitted a KillStack node when it sank a PutStack. This
2571 isn't necessary because KillStack is only interesting for OSR exit, and PutStack nodes
2572 that are relevant to OSR will already be preceded by a KillStack/MovHint pair.
2574 * dfg/DFGPutStackSinkingPhase.cpp:
2576 2015-08-21 Filip Pizlo <fpizlo@apple.com>
2578 DFG::NodeOrigin should have a flag determining if exiting is OK right now
2579 https://bugs.webkit.org/show_bug.cgi?id=148323
2581 Reviewed by Saam Barati.
2583 * dfg/DFGByteCodeParser.cpp:
2584 (JSC::DFG::ByteCodeParser::currentNodeOrigin):
2585 (JSC::DFG::ByteCodeParser::branchData):
2586 * dfg/DFGInsertionSet.h:
2587 (JSC::DFG::InsertionSet::insertConstant):
2588 (JSC::DFG::InsertionSet::insertConstantForUse):
2589 (JSC::DFG::InsertionSet::insertBottomConstantForUse):
2590 * dfg/DFGIntegerCheckCombiningPhase.cpp:
2591 (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
2592 * dfg/DFGLICMPhase.cpp:
2593 (JSC::DFG::LICMPhase::attemptHoist):
2594 * dfg/DFGNodeOrigin.h:
2595 (JSC::DFG::NodeOrigin::NodeOrigin):
2596 (JSC::DFG::NodeOrigin::isSet):
2597 (JSC::DFG::NodeOrigin::withSemantic):
2598 * dfg/DFGObjectAllocationSinkingPhase.cpp:
2600 2015-08-21 Saam barati <sbarati@apple.com>
2602 DFG callOperations should not implicitly emit an exception check. At callOperation call sites, we should explicitly emit exception checks
2603 https://bugs.webkit.org/show_bug.cgi?id=147988
2605 Reviewed by Geoffrey Garen.
2607 This is in preparation for the DFG being able to handle exceptions.
2608 To do this, we need more control over when we emit exception checks.
2609 Specifically, we want to be able to silentFill before emitting an exception check.
2610 This patch does that. This patch also allows us to easily see which
2611 operations do and do not emit exception checks. Finding this information
2612 out before was a pain.
2614 * assembler/AbortReason.h:
2615 * dfg/DFGArrayifySlowPathGenerator.h:
2616 * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
2617 * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
2618 * dfg/DFGJITCompiler.h:
2619 (JSC::DFG::JITCompiler::appendCall):
2620 (JSC::DFG::JITCompiler::exceptionCheck):
2621 * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
2622 * dfg/DFGSlowPathGenerator.h:
2623 (JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
2624 (JSC::DFG::CallSlowPathGenerator::tearDown):
2625 (JSC::DFG::CallResultAndNoArgumentsSlowPathGenerator::CallResultAndNoArgumentsSlowPathGenerator):
2626 (JSC::DFG::CallResultAndOneArgumentSlowPathGenerator::CallResultAndOneArgumentSlowPathGenerator):
2627 (JSC::DFG::CallResultAndTwoArgumentsSlowPathGenerator::CallResultAndTwoArgumentsSlowPathGenerator):
2628 (JSC::DFG::CallResultAndThreeArgumentsSlowPathGenerator::CallResultAndThreeArgumentsSlowPathGenerator):
2629 (JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::CallResultAndFourArgumentsSlowPathGenerator):
2630 (JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::CallResultAndFiveArgumentsSlowPathGenerator):
2631 (JSC::DFG::slowPathCall):
2632 * dfg/DFGSpeculativeJIT.cpp:
2633 (JSC::DFG::SpeculativeJIT::compileIn):
2634 (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2635 (JSC::DFG::SpeculativeJIT::compileValueToInt32):
2636 (JSC::DFG::SpeculativeJIT::compileArithRound):
2637 (JSC::DFG::SpeculativeJIT::compileNewFunction):
2638 (JSC::DFG::SpeculativeJIT::compileCreateActivation):
2639 (JSC::DFG::SpeculativeJIT::compileCreateScopedArguments):
2640 (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
2641 (JSC::DFG::SpeculativeJIT::compileNotifyWrite):
2642 (JSC::DFG::SpeculativeJIT::compileRegExpExec):
2643 (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
2644 (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
2645 (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
2646 (JSC::DFG::SpeculativeJIT::emitSwitchImm):
2647 (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
2648 * dfg/DFGSpeculativeJIT.h:
2649 (JSC::DFG::SpeculativeJIT::callOperation):
2650 (JSC::DFG::SpeculativeJIT::callOperationWithCallFrameRollbackOnException):
2651 (JSC::DFG::SpeculativeJIT::prepareForExternalCall):
2652 (JSC::DFG::SpeculativeJIT::appendCall):
2653 (JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnException):
2654 (JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnExceptionSetResult):
2655 (JSC::DFG::SpeculativeJIT::appendCallSetResult):
2656 (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck): Deleted.
2657 (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult): Deleted.
2658 * dfg/DFGSpeculativeJIT32_64.cpp:
2659 (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
2660 (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
2661 (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
2662 (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
2663 (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
2664 (JSC::DFG::SpeculativeJIT::emitCall):
2665 (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2666 (JSC::DFG::SpeculativeJIT::compile):
2667 * dfg/DFGSpeculativeJIT64.cpp:
2668 (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
2669 (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
2670 (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
2671 (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
2672 (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
2673 (JSC::DFG::SpeculativeJIT::emitCall):
2674 (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2675 (JSC::DFG::SpeculativeJIT::compile):
2676 * ftl/FTLIntrinsicRepository.h:
2677 * ftl/FTLLowerDFGToLLVM.cpp:
2678 (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
2679 * jit/AssemblyHelpers.cpp:
2680 (JSC::AssemblyHelpers::jitAssertArgumentCountSane):
2681 (JSC::AssemblyHelpers::jitAssertNoException):
2682 (JSC::AssemblyHelpers::callExceptionFuzz):
2683 (JSC::AssemblyHelpers::emitExceptionCheck):
2684 * jit/AssemblyHelpers.h:
2685 (JSC::AssemblyHelpers::jitAssertIsInt32):
2686 (JSC::AssemblyHelpers::jitAssertIsJSInt32):
2687 (JSC::AssemblyHelpers::jitAssertIsNull):
2688 (JSC::AssemblyHelpers::jitAssertTagsInPlace):
2689 (JSC::AssemblyHelpers::jitAssertArgumentCountSane):
2690 (JSC::AssemblyHelpers::jitAssertNoException):
2691 * jit/JITOperations.cpp:
2692 * jit/JITOperations.h:
2694 (JSC::VM::scratchBufferForSize):
2695 (JSC::VM::exceptionFuzzingBuffer):
2697 2015-08-21 Geoffrey Garen <ggaren@apple.com>
2699 REGRESSION (r188714): RELEASE_ASSERT in JSC::Heap::incrementDeferralDepth() opening Web Inspector on daringfireball.net
2700 https://bugs.webkit.org/show_bug.cgi?id=148312
2702 Reviewed by Mark Lam.
2704 * debugger/Debugger.cpp:
2705 (JSC::Debugger::recompileAllJSFunctions): Use our vm argument instead of
2706 m_vm because sometimes they are different and m_vm is null. (This behavior
2707 is very strange, and we should probably eliminate it -- but we need a
2708 fix for this serious regression right now.)
2710 2015-08-20 Yusuke Suzuki <utatane.tea@gmail.com>
2712 [ES6] prototyping module loader in JSC shell
2713 https://bugs.webkit.org/show_bug.cgi?id=147876
2715 Reviewed by Saam Barati.
2717 This patch implements ES6 Module Loader part. The implementation is based on
2718 the latest draft[1, 2]. The naive implementation poses several problems.
2719 This patch attempts to solve the spec issues and proposes the fix[3, 4, 5].
2721 We construct the JSC internal module loader based on the ES6 Promises.
2722 The chain of the promises represents the dependency graph of the modules and
2723 it automatically enables asynchronous module fetching.
2724 To leverage the Promises internally, we use the InternalPromise landed in r188681.
2726 The loader has several platform-dependent hooks. The platform can implement
2727 these hooks to provide the functionality missing in the module loaders, like
2728 "how to fetch the resources". The method table of the JSGlobalObject is extended
2729 to accept these hooks from the platform.
2731 This patch focus on the loading part. So we don't create the module environment
2732 and don't link the modules yet.
2734 To test the current module progress easily, we add the `-m` option to the JSC shell.
2735 When this option is specified, we load the given script as the module. And to use
2736 the module loading inside the JSC shell, we added the simple loader hook for fetching.
2737 It fetches the module content from the file system.
2739 And to use the ES6 Map in the Loader implementation, we added @get and @set methods to the Map.
2740 But it conflicts with the existing `getPrivateName` method. Rename it to `lookUpPrivateName`.
2742 [1]: https://whatwg.github.io/loader/
2743 [2]: https://github.com/whatwg/loader/commit/214c7a6625b445bdf411c39984f36f01139a24be
2744 [3]: https://github.com/whatwg/loader/pull/66
2745 [4]: https://github.com/whatwg/loader/pull/67
2746 [5]: https://github.com/whatwg/loader/issues/68
2747 [6]: https://bugs.webkit.org/show_bug.cgi?id=148136
2750 * DerivedSources.make:
2751 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2752 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2753 * JavaScriptCore.xcodeproj/project.pbxproj:
2754 * builtins/BuiltinNames.h:
2755 (JSC::BuiltinNames::lookUpPrivateName):
2756 (JSC::BuiltinNames::lookUpPublicName):
2757 (JSC::BuiltinNames::getPrivateName): Deleted.
2758 (JSC::BuiltinNames::getPublicName): Deleted.
2759 * builtins/ModuleLoaderObject.js: Added.
2762 (forceFulfillPromise):
2765 (fulfillInstantiate):
2769 (requestInstantiate):
2770 (requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then.):
2771 (requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then):
2772 (requestResolveDependencies):
2773 (requestInstantiateAll):
2778 (GlobalObject::moduleLoaderFetch):
2779 (functionCheckModuleSyntax):
2782 (printUsageStatement):
2783 (CommandLine::parseArguments):
2785 (CommandLine::CommandLine): Deleted.
2787 (JSC::Lexer<LChar>::parseIdentifier):
2788 (JSC::Lexer<UChar>::parseIdentifier):
2789 * parser/ModuleAnalyzer.cpp:
2790 (JSC::ModuleAnalyzer::ModuleAnalyzer):
2791 (JSC::ModuleAnalyzer::exportVariable):
2792 (JSC::ModuleAnalyzer::analyze):
2793 * parser/ModuleAnalyzer.h:
2794 (JSC::ModuleAnalyzer::moduleRecord):
2795 * parser/ModuleRecord.cpp:
2796 (JSC::printableName): Deleted.
2797 (JSC::ModuleRecord::dump): Deleted.
2798 * parser/ModuleRecord.h:
2799 (JSC::ModuleRecord::ImportEntry::isNamespace): Deleted.
2800 (JSC::ModuleRecord::create): Deleted.
2801 (JSC::ModuleRecord::appendRequestedModule): Deleted.
2802 (JSC::ModuleRecord::addImportEntry): Deleted.
2803 (JSC::ModuleRecord::addExportEntry): Deleted.
2804 (JSC::ModuleRecord::addStarExportEntry): Deleted.
2806 * parser/NodesAnalyzeModule.cpp:
2807 (JSC::ImportDeclarationNode::analyzeModule):
2808 (JSC::ExportAllDeclarationNode::analyzeModule):
2809 (JSC::ExportNamedDeclarationNode::analyzeModule):
2810 * runtime/CommonIdentifiers.cpp:
2811 (JSC::CommonIdentifiers::lookUpPrivateName):
2812 (JSC::CommonIdentifiers::lookUpPublicName):
2813 (JSC::CommonIdentifiers::getPrivateName): Deleted.
2814 (JSC::CommonIdentifiers::getPublicName): Deleted.
2815 * runtime/CommonIdentifiers.h:
2816 * runtime/Completion.cpp:
2817 (JSC::checkModuleSyntax):
2818 (JSC::evaluateModule):
2819 * runtime/Completion.h:
2820 * runtime/ExceptionHelpers.cpp:
2821 (JSC::createUndefinedVariableError):
2822 * runtime/Identifier.h:
2823 * runtime/JSGlobalObject.cpp:
2824 (JSC::JSGlobalObject::init):
2825 (JSC::JSGlobalObject::visitChildren):
2826 * runtime/JSGlobalObject.h:
2827 (JSC::JSGlobalObject::moduleLoader):
2828 (JSC::JSGlobalObject::moduleRecordStructure):
2829 * runtime/JSModuleRecord.cpp: Renamed from Source/JavaScriptCore/parser/ModuleRecord.cpp.
2830 (JSC::JSModuleRecord::destroy):
2831 (JSC::JSModuleRecord::finishCreation):
2832 (JSC::printableName):
2833 (JSC::JSModuleRecord::dump):
2834 * runtime/JSModuleRecord.h: Renamed from Source/JavaScriptCore/parser/ModuleRecord.h.
2835 (JSC::JSModuleRecord::ImportEntry::isNamespace):
2836 (JSC::JSModuleRecord::createStructure):
2837 (JSC::JSModuleRecord::create):
2838 (JSC::JSModuleRecord::requestedModules):
2839 (JSC::JSModuleRecord::JSModuleRecord):
2840 (JSC::JSModuleRecord::appendRequestedModule):
2841 (JSC::JSModuleRecord::addImportEntry):
2842 (JSC::JSModuleRecord::addExportEntry):
2843 (JSC::JSModuleRecord::addStarExportEntry):
2844 * runtime/MapPrototype.cpp:
2845 (JSC::MapPrototype::finishCreation):
2846 * runtime/ModuleLoaderObject.cpp: Added.
2847 (JSC::ModuleLoaderObject::ModuleLoaderObject):
2848 (JSC::ModuleLoaderObject::finishCreation):
2849 (JSC::ModuleLoaderObject::getOwnPropertySlot):
2850 (JSC::printableModuleKey):
2851 (JSC::ModuleLoaderObject::provide):
2852 (JSC::ModuleLoaderObject::requestInstantiateAll):
2853 (JSC::ModuleLoaderObject::resolve):
2854 (JSC::ModuleLoaderObject::fetch):
2855 (JSC::ModuleLoaderObject::translate):
2856 (JSC::ModuleLoaderObject::instantiate):
2857 (JSC::moduleLoaderObjectParseModule):
2858 (JSC::moduleLoaderObjectRequestedModules):
2859 (JSC::moduleLoaderObjectResolve):
2860 (JSC::moduleLoaderObjectFetch):
2861 (JSC::moduleLoaderObjectTranslate):
2862 (JSC::moduleLoaderObjectInstantiate):
2863 * runtime/ModuleLoaderObject.h: Added.
2864 (JSC::ModuleLoaderObject::create):
2865 (JSC::ModuleLoaderObject::createStructure):
2866 * runtime/Options.h:
2868 2015-08-20 Filip Pizlo <fpizlo@apple.com>
2870 DFG should have a KnownBooleanUse for cases where we are required to know that the child is a boolean and it's not OK to speculate
2871 https://bugs.webkit.org/show_bug.cgi?id=148286
2873 Reviewed by Benjamin Poulain.
2875 This enables us to ensure that the Branch or LogicalNot after an effectful CompareXYZ can
2876 be marked as !mayExit(). I need that for https://bugs.webkit.org/show_bug.cgi?id=145204.
2878 * dfg/DFGFixupPhase.cpp:
2879 (JSC::DFG::FixupPhase::fixupNode):
2880 (JSC::DFG::FixupPhase::observeUseKindOnNode):
2881 * dfg/DFGSafeToExecute.h:
2882 (JSC::DFG::SafeToExecuteEdge::operator()):
2883 * dfg/DFGSpeculativeJIT.cpp:
2884 (JSC::DFG::SpeculativeJIT::speculate):
2885 * dfg/DFGSpeculativeJIT.h:
2886 (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand):
2887 * dfg/DFGSpeculativeJIT32_64.cpp:
2888 (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2889 (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2890 (JSC::DFG::SpeculativeJIT::emitBranch):
2891 * dfg/DFGSpeculativeJIT64.cpp:
2892 (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2893 (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2894 (JSC::DFG::SpeculativeJIT::emitBranch):
2895 * dfg/DFGUseKind.cpp:
2896 (WTF::printInternal):
2898 (JSC::DFG::typeFilterFor):
2899 (JSC::DFG::shouldNotHaveTypeCheck):
2900 * ftl/FTLCapabilities.cpp:
2901 (JSC::FTL::canCompile):
2902 * ftl/FTLLowerDFGToLLVM.cpp:
2903 (JSC::FTL::DFG::LowerDFGToLLVM::boolify):
2904 (JSC::FTL::DFG::LowerDFGToLLVM::lowBoolean):
2906 2015-08-20 Filip Pizlo <fpizlo@apple.com>
2908 Overflow check elimination fails for a simple test case
2909 https://bugs.webkit.org/show_bug.cgi?id=147387
2911 Reviewed by Benjamin Poulain.
2913 Overflow check elimination was having issues when things got constant-folded, because whereas an
2914 Add or LessThan operation teaches us about relationships between the things being added or
2915 compared, we don't do that when we see a JSConstant. We don't create a relationship between every
2916 JSConstant and every other JSConstant. So, if we constant-fold an Add, we forget the relationships
2917 that it would have had with its inputs.
2919 One solution would be to have every JSConstant create a relationship with every other JSConstant.
2920 This is dangerous, since it would create O(n^2) explosion of relationships.
2922 Instead, this patch teaches filtration and merging how to behave "as if" there were inter-constant
2923 relationships. Normally those operations only work on two relationships involving the same node
2924 pair. But now, if we have @x op @c and @x op @d, where @c and @d are different nodes but both are
2925 constants, we will do merging or filtering by grokking the constant values.
2927 This speeds up lots of tests in JSRegress, because it enables overflow check elimination on things
2930 for (var i = 0; i < 100; ++i)
2932 Previously, the fact that this was all constants would throw off the analysis because the analysis
2933 wouldn't "know" that 0 < 100.
2935 * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2937 2015-08-20 Geoffrey Garen <ggaren@apple.com>
2939 forEachCodeBlock should wait for all CodeBlocks automatically
2940 https://bugs.webkit.org/show_bug.cgi?id=148255
2942 Add back a line of code I deleted by accident in my last patch due to
2948 (JSC::VM::deleteAllCode):
2950 2015-08-20 Geoffrey Garen <ggaren@apple.com>
2952 forEachCodeBlock should wait for all CodeBlocks automatically
2953 https://bugs.webkit.org/show_bug.cgi?id=148255
2955 Reviewed by Saam Barati.
2957 Previously, all clients needed to wait manually before calling
2958 forEachCodeBlock. That's easy to get wrong, and at least one place
2959 got it wrong. Let's do this automatically instead.
2961 * debugger/Debugger.cpp:
2962 (JSC::Debugger::Debugger):
2963 (JSC::Debugger::setSteppingMode):
2964 (JSC::Debugger::toggleBreakpoint): No need to wait manually;
2965 forEachCodeBlock will do it automatically now.
2967 (JSC::Debugger::recompileAllJSFunctions): We still need to wait manually
2968 here because this is an iteration of the heap, which does not wait
2969 automatically. Use the new helper function for waiting.
2971 (JSC::Debugger::clearBreakpoints):
2972 (JSC::Debugger::clearDebuggerRequests):
2973 (JSC::Debugger::setBreakpointsActivated):
2974 (JSC::Debugger::forEachCodeBlock): Deleted. No need to wait manually.
2976 * debugger/Debugger.h:
2978 * dfg/DFGWorklist.cpp:
2979 (JSC::DFG::completeAllPlansForVM):
2980 * dfg/DFGWorklist.h:
2981 (JSC::DFG::completeAllPlansForVM): Added a helper function that replaces
2982 vm.prepareToDeleteCode. This new function is clearer because we need
2983 to call it sometimes even if we are not going to delete code.
2985 * heap/HeapInlines.h:
2986 (JSC::Heap::forEachCodeBlock): Moved.
2988 * inspector/agents/InspectorRuntimeAgent.cpp:
2989 (Inspector::recompileAllJSFunctionsForTypeProfiling): Use the new helper
2992 * runtime/JSCInlines.h:
2993 (JSC::Heap::forEachCodeBlock): Do the waiting automatically.
2996 (JSC::VM::stopSampling):
2997 (JSC::VM::deleteAllCode):
2998 (JSC::VM::setEnabledProfiler):
2999 (JSC::VM::prepareToDeleteCode): Deleted.
3000 * runtime/VM.h: No need to wait manually.
3002 2015-08-20 Commit Queue <commit-queue@webkit.org>
3004 Unreviewed, rolling out r188675.
3005 https://bugs.webkit.org/show_bug.cgi?id=148244
3007 "caused a 17% Mac PLT regression" (Requested by ggaren on
3012 "clearCode() should clear code"
3013 https://bugs.webkit.org/show_bug.cgi?id=148203
3014 http://trac.webkit.org/changeset/188675
3016 2015-08-11 Yusuke Suzuki <utatane.tea@gmail.com>
3018 Introduce put_by_id like IC into put_by_val when the given name is String or Symbol
3019 https://bugs.webkit.org/show_bug.cgi?id=147760
3021 Reviewed by Filip Pizlo.
3023 This patch adds put_by_id IC to put_by_val by caching the one candidate id,
3024 it is the same thing to the get_by_val IC extension.
3025 It will encourage the use of ES6 Symbols and ES6 computed properties in the object literals.
3027 In this patch, we leverage the existing CheckIdent and PutById / PutByVal in DFG,
3028 so this patch does not change FTL because the above operations are already supported in FTL.
3030 And this patch also includes refactoring to leverage byValInfo->slowPathCount in the cached Id path.
3032 Performance results report there's no regression in the existing tests. And in the synthetic
3033 benchmarks created by modifying put-by-id to put-by-val, we can see significant performance
3034 improvements up to 13.9x.
3036 * bytecode/PutByIdStatus.cpp:
3037 (JSC::PutByIdStatus::computeForStubInfo):
3038 * bytecode/PutByIdStatus.h:
3039 * dfg/DFGByteCodeParser.cpp:
3040 (JSC::DFG::ByteCodeParser::parseBlock):
3042 (JSC::JIT::compilePutByValWithCachedId):
3043 * jit/JITOperations.cpp:
3045 (JSC::tryGetByValOptimize):
3046 * jit/JITOperations.h:
3047 * jit/JITPropertyAccess.cpp:
3048 (JSC::JIT::emitGetByValWithCachedId):
3049 (JSC::JIT::emit_op_put_by_val):
3050 (JSC::JIT::emitPutByValWithCachedId):
3051 (JSC::JIT::emitSlow_op_put_by_val):
3052 (JSC::JIT::emitIdentifierCheck):
3053 (JSC::JIT::privateCompilePutByValWithCachedId):
3054 * jit/JITPropertyAccess32_64.cpp:
3055 (JSC::JIT::emitGetByValWithCachedId):
3056 (JSC::JIT::emit_op_put_by_val):
3057 (JSC::JIT::emitPutByValWithCachedId):
3058 (JSC::JIT::emitSlow_op_put_by_val):
3059 * tests/stress/put-by-val-with-string-break.js: Added.
3062 * tests/stress/put-by-val-with-string-generated.js: Added.
3067 * tests/stress/put-by-val-with-string-generic.js: Added.
3070 * tests/stress/put-by-val-with-symbol-break.js: Added.
3073 * tests/stress/put-by-val-with-symbol-generic.js: Added.
3077 2015-08-20 Alex Christensen <achristensen@webkit.org>
3079 Clean up CMake build after r188673
3080 https://bugs.webkit.org/show_bug.cgi?id=148234
3082 Reviewed by Tim Horton.
3084 * shell/PlatformWin.cmake:
3085 Define WIN_CAIRO so the WinCairo jsc.exe can find the correct dlls.
3087 2015-08-20 Mark Lam <mark.lam@apple.com>
3089 A watchdog tests is failing on Windows.
3090 https://bugs.webkit.org/show_bug.cgi?id=148228
3092 Reviewed by Brent Fulgham.
3094 The test just needed a little more time because Windows' timer resolution is low.
3095 After increasing the test deadlines, the test started passing.
3097 * API/tests/ExecutionTimeLimitTest.cpp:
3098 (testExecutionTimeLimit):
3100 2015-08-20 Mark Lam <mark.lam@apple.com>
3102 Fixed some warnings on Windows.
3103 https://bugs.webkit.org/show_bug.cgi?id=148224
3105 Reviewed by Brent Fulgham.
3107 The Windows build was complaining that function params were hiding a global variable.
3108 Since the function params were unused, I resolved this by removing the param names.
3110 * API/tests/ExecutionTimeLimitTest.cpp:
3111 (currentCPUTimeAsJSFunctionCallback):
3112 (shouldTerminateCallback):
3113 (cancelTerminateCallback):
3114 (extendTerminateCallback):
3116 2015-08-19 Yusuke Suzuki <utatane.tea@gmail.com>
3118 Add InternalPromise to use Promises safely in the internals
3119 https://bugs.webkit.org/show_bug.cgi?id=148136
3121 Reviewed by Saam Barati.
3123 This patch implements InternalPromise.
3124 It is completely different instance set (constructor, prototype, instance)
3125 but it has the same feature to the Promise.
3127 In the Promise operations, when resolving the promise with the returned promise
3128 from the fulfill handler, we need to look up "then" method.
3131 var p3 = p1.then(function handler(...) {
3135 When handler is executed, we retrieve the returned `p2` promise. And to resolve
3136 the returned promise by "then" method (that is `p3`), we construct the chain by executing
3137 `p2.then(resolving function for p3)`. So if the user modify the Promise.prototype.then,
3138 we can observe the internal operations.
3140 By using InternalPromise, we completely hide InternalPromise.prototype from the users.
3141 It allows JSC to use Promises internally; even if the user modify / override
3142 the Promise.prototype.then function, it does not effect on InternalPromise.
3144 One limitation is that the implementation need to take care not to leak the InternalPromise instance
3148 * DerivedSources.make:
3149 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3150 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3151 * JavaScriptCore.xcodeproj/project.pbxproj:
3152 * builtins/InternalPromiseConstructor.js: Added.
3153 (internalAll.newResolveElement):
3155 * builtins/Operations.Promise.js:
3156 (newPromiseDeferred): Deleted.
3157 * builtins/PromiseConstructor.js:
3158 (privateAll.newResolveElement): Deleted.
3159 (privateAll): Deleted.
3160 * runtime/CommonIdentifiers.h:
3161 * runtime/JSGlobalObject.cpp:
3162 (JSC::JSGlobalObject::init):
3163 (JSC::JSGlobalObject::visitChildren):
3164 * runtime/JSGlobalObject.h:
3165 (JSC::JSGlobalObject::promiseConstructor):
3166 (JSC::JSGlobalObject::internalPromiseConstructor):
3167 (JSC::JSGlobalObject::newPromiseCapabilityFunction):
3168 (JSC::JSGlobalObject::newPromiseDeferredFunction): Deleted.
3169 * runtime/JSInternalPromise.cpp: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.h.
3170 (JSC::JSInternalPromise::create):
3171 (JSC::JSInternalPromise::createStructure):
3172 (JSC::JSInternalPromise::JSInternalPromise):
3173 * runtime/JSInternalPromise.h: Copied from Source/JavaScriptCore/runtime/JSPromise.h.
3174 * runtime/JSInternalPromiseConstructor.cpp: Added.
3175 (JSC::JSInternalPromiseConstructor::create):
3176 (JSC::JSInternalPromiseConstructor::createStructure):
3177 (JSC::JSInternalPromiseConstructor::JSInternalPromiseConstructor):
3178 (JSC::constructPromise):
3179 (JSC::JSInternalPromiseConstructor::getConstructData):
3180 (JSC::JSInternalPromiseConstructor::getCallData):
3181 (JSC::JSInternalPromiseConstructor::getOwnPropertySlot):
3182 * runtime/JSInternalPromiseConstructor.h: Copied from Source/JavaScriptCore/runtime/JSPromiseConstructor.h.
3183 * runtime/JSInternalPromiseDeferred.cpp: Added.
3184 (JSC::JSInternalPromiseDeferred::create):
3185 (JSC::JSInternalPromiseDeferred::JSInternalPromiseDeferred):
3186 (JSC::JSInternalPromiseDeferred::promise):
3187 * runtime/JSInternalPromiseDeferred.h: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.h.
3188 * runtime/JSInternalPromisePrototype.cpp: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.cpp.
3189 (JSC::JSInternalPromisePrototype::create):
3190 (JSC::JSInternalPromisePrototype::createStructure):
3191 (JSC::JSInternalPromisePrototype::JSInternalPromisePrototype):
3192 * runtime/JSInternalPromisePrototype.h: Copied from Source/JavaScriptCore/runtime/JSPromise.h.
3193 * runtime/JSPromise.cpp:
3194 (JSC::JSPromise::create):
3195 (JSC::JSPromise::JSPromise):
3196 (JSC::JSPromise::initialize):
3197 * runtime/JSPromise.h:
3198 * runtime/JSPromiseConstructor.cpp:
3199 (JSC::JSPromiseConstructor::JSPromiseConstructor):
3200 (JSC::constructPromise):
3201 (JSC::JSPromiseConstructor::getOwnPropertySlot):
3202 (JSC::JSPromiseConstructor::finishCreation): Deleted.
3203 * runtime/JSPromiseConstructor.h:
3204 * runtime/JSPromiseDeferred.cpp:
3205 (JSC::newPromiseCapability):
3206 (JSC::JSPromiseDeferred::create):
3207 (JSC::JSPromiseDeferred::JSPromiseDeferred):
3208 * runtime/JSPromiseDeferred.h:
3209 * runtime/JSPromisePrototype.cpp:
3210 (JSC::JSPromisePrototype::getOwnPropertySlot):
3211 * runtime/JSPromisePrototype.h:
3216 2015-08-19 Filip Pizlo <fpizlo@apple.com>
3218 Remove WTF::SpinLock
3219 https://bugs.webkit.org/show_bug.cgi?id=148208
3221 Reviewed by Geoffrey Garen.
3223 Remove the one remaining use of SpinLock.
3226 (handerForStructTag):
3228 2015-08-19 Geoffrey Garen <ggaren@apple.com>
3230 clearCode() should clear code
3231 https://bugs.webkit.org/show_bug.cgi?id=148203
3233 Reviewed by Saam Barati.
3235 Clearing code used to require two steps: clearCode() and
3236 clearUnlinkedCodeForRecompilation(). Unsurprisingly, clients sometimes
3237 did one or the other or both without much rhyme or reason.
3239 This patch simplifies things by merging both functions into clearCode().
3241 * bytecode/UnlinkedFunctionExecutable.h:
3242 * debugger/Debugger.cpp:
3244 (JSC::Heap::deleteAllCompiledCode):
3245 (JSC::Heap::clearUnmarkedExecutables):
3246 (JSC::Heap::deleteAllUnlinkedFunctionCode): Deleted. No need for this
3247 function anymore since it was only used by clients who already called
3248 clearCode() (and it would be terribly wrong to use without doing both.)
3251 (JSC::Heap::sizeAfterLastFullCollection):
3252 * inspector/agents/InspectorRuntimeAgent.cpp:
3253 (Inspector::TypeRecompiler::visit):
3254 (Inspector::TypeRecompiler::operator()):
3255 * runtime/Executable.cpp:
3256 (JSC::FunctionExecutable::visitChildren):
3257 (JSC::FunctionExecutable::clearCode):
3258 (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation): Deleted.
3259 * runtime/Executable.h:
3261 (JSC::VM::deleteAllCode):
3263 2015-08-19 Alex Christensen <achristensen@webkit.org>
3265 CMake Windows build should not include files directly from other Source directories
3266 https://bugs.webkit.org/show_bug.cgi?id=148198
3268 Reviewed by Brent Fulgham.
3271 JavaScriptCore_FORWARDING_HEADERS_FILES is no longer necessary because all the headers
3272 that used to be in it are now in JavaScriptCore_FORWARDING_HEADERS_DIRECTORIES
3273 * PlatformEfl.cmake:
3274 * PlatformGTK.cmake:
3275 * PlatformMac.cmake:
3276 * PlatformWin.cmake:
3278 2015-08-19 Eric Carlson <eric.carlson@apple.com>
3280 Remove ENABLE_WEBVTT_REGIONS
3281 https://bugs.webkit.org/show_bug.cgi?id=148184
3283 Reviewed by Jer Noble.
3285 * Configurations/FeatureDefines.xcconfig: Remove ENABLE_WEBVTT_REGIONS.
3287 2015-08-19 Joseph Pecoraro <pecoraro@apple.com>
3289 Web Inspector: Unexpected node preview format for an element with newlines in className attribute
3290 https://bugs.webkit.org/show_bug.cgi?id=148192
3292 Reviewed by Brian Burg.
3294 * inspector/InjectedScriptSource.js:
3295 (InjectedScript.prototype._nodePreview):
3296 Replace whitespace blocks with single spaces to produce a simpler class string for previews.
3298 2015-08-19 Mark Lam <mark.lam@apple.com>
3300 Add support for CheckWatchdogTimer as slow path in DFG and FTL.
3301 https://bugs.webkit.org/show_bug.cgi?id=147968
3303 Reviewed by Michael Saboff.
3305 Re-implement the DFG's CheckWatchdogTimer as a slow path instead of a speculation
3306 check. Since the watchdog timer can fire spuriously, this allows the code to
3307 stay optimized if all we have are spurious fires.
3309 Implement the equivalent slow path for CheckWatchdogTimer in the FTL.
3311 The watchdog tests in ExecutionTimeLimitTest.cpp has already been updated in
3312 https://bugs.webkit.org/show_bug.cgi?id=148125 to test for the FTL's watchdog
git://git.webkit.org / WebKit-https.git / blob